简介：面向Web前端初学者与交互效果练习者的JavaScript图片翻转示例包，围绕点击图片沿X/Y轴翻转并平滑恢复这一常见交互展开，可用于理解DOM操作、事件监听与CSS变换的基础配合。压缩包共36个文件，以26个gif和7个jpg图片素材为主，辅以2个html页面和1个js脚本，整体约413KB，体量轻便，适合直接解压后对照页面结构与脚本逻辑学习。已有137人学习或浏览，可作为课堂演示、课后练习或前端小项目入门的参考。示例通过获取图片元素、绑定click事件，在rotateX(180deg)与初始状态间切换，并借助transition让翻转过程更自然；同时涉及翻转状态记录，避免连续点击时逻辑混乱，读者可据此掌握样式控制、状态管理与简单动画的实现思路。

1. 一张竖拍照片翻正后反而变糊：JavaScript 图片翻转到底在翻什么

前端做图像处理，JavaScript 图片翻转大概是出现频率最高、也最容易被低估的需求：用户传一张手机竖拍的照片，预览是躺倒的，得转正；证件照工具要左右镜像；拼图、贴纸、九宫格切图要上下对调。看上去只是ctx.scale(-1, 1)一行的事，真上手就会撞上画布空白、边缘发虚、透明底变黑、导出体积翻三倍这些事。

这份资源把翻转拆成两层：一层是 Canvas 绘制层面的坐标变换，一层是ImageData层面的像素搬运。两层各有各的边界，前者代码少、能吃到 GPU 加速，后者能在 Worker 里跑、不碰主线程。下面按我拆包时的顺序走，从坐标系讲起，一路讲到能自动跑的验收脚本。

2. 坐标系选型：三种翻转写法与那个必踩的负缩放坑

Canvas 的坐标原点在左上角，x 向右为正，y 向下为正。所谓翻转，本质是把对应轴做一次取反，让绘制内容落到负区间去。理解这一句，后面所有"为什么画不出来"的问题都能自己推出来。

2.1 为什么 ctx.scale(-1, 1) 之后画布是空的

新手最常见的写法是这个：

// 错误示范：只做负缩放，不补平移 const canvas = document.createElement('canvas'); canvas.width = img.naturalWidth; canvas.height = img.naturalHeight; const ctx = canvas.getContext('2d'); ctx.scale(-1, 1); // x 轴取反 ctx.drawImage(img, 0, 0); // 图片被画到 x ∈ [-w, 0] 区间，画布上什么都没有

scale(-1, 1)之后，原本落在[0, w]的绘制内容被映射到[-w, 0]，整块跑到画布左边界之外，所以你看到的是一张空白图。正确写法要在缩放之前补一次平移：

// 水平翻转（左右镜像） ctx.translate(canvas.width, 0); // 把原点挪到右上角 ctx.scale(-1, 1); // x 轴取反，绘制区间重新回到 [0, w] ctx.drawImage(img, 0, 0); // 垂直翻转（上下对调） // ctx.translate(0, canvas.height); // ctx.scale(1, -1); // 水平 + 垂直（等价于旋转 180 度） // ctx.translate(canvas.width, canvas.height); // ctx.scale(-1, -1);

这里有个反直觉的点：translate和scale的调用顺序不能调换。Canvas 的变换矩阵是右乘累积的，先translate(w, 0)再scale(-1, 1)，得到的是T·S，点p的最终位置是T·S·p，也就是"先缩放、再平移"，图片先被翻到[-w, 0]，再整体右移w，正好落回画布。如果先scale再translate，平移量也跟着被取反了，等于白翻。血泪经验就一条：平移量永远按目标画布尺寸给，不要按源图尺寸给，两者一旦不一致（比如做了缩放适配），翻转方向就会错得莫名其妙。

2.2 三条实现路径的成本对照

同一个翻转需求，至少有三种落法，选错了不是能不能用的问题，是性能和维护成本差一个量级的问题。

我一般的判断标准是：只要产物要交给后端或者触发下载，就走 Canvas 路径；只是页面上看个镜像效果，CSS 够了，别为了一个scaleX(-1)去建一块 canvas 再toDataURL，白白多一次编码。ImageData那条路只在两种情况下值得动：一是需要在翻转的同时做像素级判断（比如抠图后的边缘处理），二是图很大、必须挪到 Worker 里避免主线程卡顿。

顺便说一个容易忽略的对比：CSS 变换是"显示层镜像"，Canvas 是"数据层镜像"。曾有人用 CSS 做了镜像预览，用户点下载拿到的还是原图，反馈说"翻转没生效"。这不是 bug，是选型错了。

2.3 参数怎么定：尺寸、DPR 与平滑质量

Canvas 只有三个参数真正影响翻转结果：width、height和imageSmoothingQuality。

width/height是画布的像素缓冲区尺寸，不是显示尺寸。翻转场景下它应该等于源图的naturalWidth/naturalHeight，因为翻转不改变图像大小，任何额外的缩放都会引入一次重采样，图就糊了。很多人为了让预览清晰，把 canvas 的 CSS 宽高设成显示尺寸、缓冲区设成显示尺寸 * devicePixelRatio，这在缩放预览里是对的，但在翻转里是错的——翻转要的是 1:1 还原，只在显示时再用 CSS 缩下去：

// 翻转场景的正确做法：缓冲区 = 源图尺寸，显示尺寸交给 CSS canvas.width = img.naturalWidth; canvas.height = img.naturalHeight; canvas.style.width = '100%'; // 显示缩放与像素缓冲区解耦 canvas.style.maxWidth = '480px';

提示：img.naturalWidth在有 EXIF 方向的照片上已经是"旋转后"的宽高，直接用即可，不要再拿img.width去乘什么系数。

imageSmoothingQuality在翻转本身用不上（没有缩放就没有插值），但如果你在同一条管线里顺手做了缩略图，把它设成'high'会明显好于默认值。参数就三档'low' | 'medium' | 'high'，代价是耗时，大图批量处理时建议只对最终输出设 high，中间草稿用 low。

3. 从 File 到 Blob：写一个能直接用的 flipImage 模块

坐标系搞清楚之后，剩下的是一条完整的管线：拿到File→ 解码成可绘制的位图 → 翻转 → 编码成Blob交出去。这条链上每一步都有一个参数会咬人。

3.1 解码阶段与 EXIF 方向的双重旋转问题

手机拍的照片，像素数据往往是横着存的，方向信息写在 EXIF 里。现代浏览器在渲染<img>时默认就应用了 EXIF 方向（image-orientation: from-image是初始值），所以img.naturalWidth已经是转正后的尺寸。问题出在解码 API 上：

// 方案 A：用 <img> 解码，浏览器已按 EXIF 方向渲染 async function loadViaImg(file) { const url = URL.createObjectURL(file); const img = new Image(); img.src = url; await img.decode(); // decode() 比 onload 更可靠，能拿到解码失败的原因 URL.revokeObjectURL(url); // 记得释放，否则 File 一直挂在内存里 return img; // naturalWidth/Height 已经是方向修正后的值 } // 方案 B：用 createImageBitmap 解码，方向行为要显式声明 async function loadViaBitmap(file) { // imageOrientation: 'from-image' 表示按 EXIF 应用方向 // 若源图已经在 <img> 里被转正过一次，这里再加一次就是双重旋转 return await createImageBitmap(file, { imageOrientation: 'from-image' }); }

这两条路混用就会翻车：先用<img>预览（已转正），再把原始File丢给createImageBitmap({imageOrientation:'from-image'})（又转一次），结果照片被多转了 90 度。我一般固定选一条路走到底——预览和导出都用<img>，或者都用createImageBitmap，中间不换。createImageBitmap的好处是能直接喂给 Worker，<img>的好处是兼容性更稳。

3.2 flipImage 主函数与三种模式

核心函数不长，但每个分支都要照顾到"翻转后尺寸不变"这个前提：

/** * @param {ImageBitmap|HTMLImageElement} source 已解码的图像源 * @param {'horizontal'|'vertical'|'both'} mode 翻转模式 * @returns {HTMLCanvasElement} */ function flipImage(source, mode = 'horizontal') { const w = source.width || source.naturalWidth; const h = source.height || source.naturalHeight; const canvas = document.createElement('canvas'); canvas.width = w; // 缓冲区尺寸等于源图，绝不缩放 canvas.height = h; const ctx = canvas.getContext('2d'); // 按模式设置变换矩阵，注意 translate 在前、scale 在后 if (mode === 'horizontal') { ctx.translate(w, 0); ctx.scale(-1, 1); } else if (mode === 'vertical') { ctx.translate(0, h); ctx.scale(1, -1); } else if (mode === 'both') { ctx.translate(w, h); ctx.scale(-1, -1); // 两次取反，等价于旋转 180 度 } ctx.drawImage(source, 0, 0, w, h); // 显式传目标宽高，避免 source 尺寸歧义 return canvas; }

三个模式对应的矩阵其实是一张表：horizontal是x' = w - x，vertical是y' = h - y，both是两者叠加。drawImage里显式写(0, 0, w, h)而不是只传(0, 0)，是因为在ImageBitmap和HTMLImageElement混用时，省略宽高会让浏览器按源的自然尺寸去画，一旦源被缩放过就会错位。

如果要批量处理，把这个函数里的document.createElement('canvas')换成复用的 canvas 实例，同一个尺寸反复用，能省掉大量 GC 压力。

3.3 导出参数：格式、质量与透明底

最后一步是把 canvas 变成能下载的Blob：

function canvasToBlob(canvas, { type = 'image/jpeg', quality = 0.85 } = {}) { return new Promise((resolve, reject) => { canvas.toBlob( (blob) => (blob ? resolve(blob) : reject(new Error('toBlob 返回 null'))), type, quality // 只对 image/jpeg 和 image/webp 生效，PNG 会忽略 ); }); } // 导出 JPEG 前必须补白底，否则透明区域会被填成黑色 function flattenToWhite(canvas) { const ctx = canvas.getContext('2d'); ctx.save(); ctx.globalCompositeOperation = 'destination-over'; // 只在透明像素下面铺底 ctx.fillStyle = '#ffffff'; ctx.fillRect(0, 0, canvas.width, canvas.height); ctx.restore(); return canvas; }

三个参数要记牢：type缺省是image/png，PNG 无损但体积大；quality在 0 到 1 之间，JPEG 建议 0.82 到 0.88，再高体积涨得快、肉眼几乎看不出差别；globalCompositeOperation: 'destination-over'是补底色的正确姿势，用source-over会在图片上面糊一层白。

注意：toBlob的回调可能收到null，常见原因是画布尺寸为 0 或者图片触发了跨域污染。用img.crossOrigin = 'anonymous'加载外链图，并且服务端要回Access-Control-Allow-Origin，缺一个都会让画布变成"脏画布"，toBlob/getImageData全部抛安全错误。

4. 排查清单：翻转后发虚、偏色、体积翻倍的五个真实原因

这一章按"现象 → 原因 → 解决"来，都是我实际遇到过、并且能在五分钟内定位的问题。

4.1 现象：翻转后边缘发虚，文字和细线糊成一团

原因基本只有一个：画布缓冲区尺寸和绘制尺寸不一致，触发了重采样。典型写法是canvas.width = 300、canvas.height = 300，但drawImage(img, 0, 0)画进去的是一张 4000×3000 的图，浏览器先缩小一次；或者反过来，canvas.width设成了 CSS 显示尺寸的像素值，在 2 倍屏上被拉伸一次。还有一种隐蔽情况：drawImage传了目标宽高但取的是img.width（带 CSS 缩放的显示宽度）而不是naturalWidth。

解决办法是固定一条铁律——翻转管线的 canvas 缓冲区必须等于naturalWidth/naturalHeight，显示用 CSS 兜。定位时可以在翻转后打印canvas.width和img.naturalWidth，两个数不相等就是它。

4.2 现象：PNG 透明图翻转后透明区域变黑了

原因不是翻转，是导出。toBlob('image/jpeg')或toDataURL('image/jpeg')用的 JPEG 不支持 alpha 通道，Canvas 的透明区域在编码时会被合成为黑色（某些实现下是白或黑，取决于浏览器）。如果原图是带透明底的抠图素材，翻转后直接导 JPEG 就废了。

解决办法：要么坚持导出 PNG（体积换正确性），要么在导出前用destination-over铺一层白底（或品牌色底）。判断标准很简单——源文件是 PNG/WebP 且可能带透明通道，就一定要做这一步，别指望用户理解。

4.3 现象：翻转后文件体积从 800KB 涨到 3MB

三种成因，从高到低排：一是格式从 JPEG 变成了 PNG（toBlob不传type时的默认行为就是 PNG），无损编码对有噪点的照片极其不友好；二是quality用了 0.95 以上，接近无损但体积爆炸；三是把 canvas 尺寸按 DPR 放大了两倍再导出，像素数直接四倍。

解决办法：显式传type，照片类内容统一走image/jpeg+quality: 0.85；只有需要透明背景的素材才用 PNG。翻转本身不产生新信息，体积膨胀一定是编码参数或者尺寸搞错了。

4.4 现象：手机竖拍照片翻转方向是错的，左右镜像变成了上下颠倒

典型原因是 EXIF 方向被应用了两次或零次。前面 3.1 讲过，<img>默认按 EXIF 渲染，createImageBitmap则取决于imageOrientation参数。混用两条解码路径，就会出现"看起来是横的，翻完还是横的，但方向反了"这种情况。

解决办法：整条管线只保留一个解码入口，并且在入口处就把方向问题解决掉，后续的翻转只处理"用户主动要求的镜像"。定位方法是在drawImage之前打印source.width和source.height，如果 4:3 的照片打印出 3:4，说明方向已经应用过，不要再转。

4.5 现象：连续翻转多次后图片越来越糊

这是有损编码的累积效应。每次翻转都经历了一轮"解码 → 重绘 → JPEG 编码"，每轮都会丢一点高频信息，翻十次就明显糊了，尤其是人像皮肤和大面积渐变色。

解决办法：不要拿翻转后的结果当下一轮的输入。原始File（或原始ImageBitmap）只解码一次并常驻，每次翻转都从它出发，最后只编码一次。如果确实需要保留历史步骤，中间态用 PNG 或者ImageBitmap存，别用 JPEG 存。这个坑我在一个图片编辑器项目里踩过，用户反复撤销重做之后画质肉眼可见地崩，最后就是靠"只保留原图 + 操作栈回放"解决的。

5. 像素级翻转：用 ImageData 手动对调，顺带扔进 Worker

Canvas 变换吩咐了浏览器去做，好处是快、代码少；但有些场景必须自己搬像素——需要在翻转同时做逐像素判断，或者要绕开主线程的卡顿。这时候就得上ImageData。

5.1 ImageData 逐行搬运的三个细节

ImageData.data是一个Uint8ClampedArray，每个像素 4 字节（RGBA），顺序是R, G, B, A平铺。所以第 y 行、第 x 个像素的红色分量下标是(y * width + x) * 4。

水平翻转是同一行内左右对调像素，垂直翻转是整行对调。后者能整块搬运，效率高得多：

/** * 垂直翻转：整行对调，用 TypedArray 的 set 做块拷贝 * @param {ImageData} imageData 原地修改 */ function flipVerticalInPlace(imageData) { const { width, height, data } = imageData; const rowBytes = width * 4; // 一行占多少字节 const temp = new Uint8ClampedArray(rowBytes); // 复用一个行缓冲，避免每行新建 for (let y = 0; y < Math.floor(height / 2); y++) { const top = y * rowBytes; const bottom = (height - 1 - y) * rowBytes; temp.set(data.subarray(top, top + rowBytes)); // 存上边一行 data.copyWithin(top, bottom, bottom + rowBytes); // 下边搬到上边 data.set(temp, bottom); // 上边放到下边 } return imageData; } /** * 水平翻转：行内左右像素对调，逐像素交换 4 个通道 */ function flipHorizontalInPlace(imageData) { const { width, height, data } = imageData; for (let y = 0; y < height; y++) { const rowStart = y * width * 4; for (let x = 0; x < Math.floor(width / 2); x++) { const left = rowStart + x * 4; const right = rowStart + (width - 1 - x) * 4; for (let c = 0; c < 4; c++) { // 四个通道一起换，漏一个就会偏色 const t = data[left + c]; data[left + c] = data[right + c]; data[right + c] = t; } } } return imageData; }

三个细节值得说：一是循环只跑到height / 2或者width / 2，跑到全长会把每对像素换两次、等于没换；二是copyWithin在同一块 buffer 内部搬运比手写循环快，但它不能用于重叠区有风险的方向，所以上下对调要借助temp中转；三是四个通道必须一起换，只换 RGB 不换 A，带透明渐变的图会出现诡异的光晕。

5.2 用 Worker + OffscreenCanvas 拆掉主线程卡顿

一张 4000×3000 的图，getImageData出来的数组是 48MB，主线程上跑一遍双重循环基本就是几百毫秒的白屏。解决办法是把画布控制权交给 Worker：

// main.js —— 主线程只负责派活和收活 const worker = new Worker('./flip.worker.js'); async function flipInWorker(file, mode = 'horizontal') { const bitmap = await createImageBitmap(file); return new Promise((resolve, reject) => { worker.onmessage = (e) => { if (e.data.error) return reject(new Error(e.data.error)); resolve(e.data.blob); }; // bitmap 是 transferable，转移后主线程不再持有，零拷贝 worker.postMessage({ bitmap, mode }, [bitmap]); }); }

// flip.worker.js —— 离屏画布 + 像素搬运 self.onmessage = async ({ data }) => { const { bitmap, mode } = data; try { const canvas = new OffscreenCanvas(bitmap.width, bitmap.height); const ctx = canvas.getContext('2d'); ctx.drawImage(bitmap, 0, 0); const imageData = ctx.getImageData(0, 0, bitmap.width, bitmap.height); if (mode === 'vertical') flipVerticalInPlace(imageData); else flipHorizontalInPlace(imageData); ctx.putImageData(imageData, 0, 0); // OffscreenCanvas 支持 convertToBlob，语义与 toBlob 一致 const blob = await canvas.convertToBlob({ type: 'image/jpeg', quality: 0.85 }); self.postMessage({ blob }); } catch (err) { self.postMessage({ error: err.message }); } };

要点有三个：createImageBitmap产生的bitmap是 transferable，postMessage的第二个参数把它转移过去，主线程侧的对象会被置空，这是零拷贝的关键；Worker 里没有document，只能用OffscreenCanvas；convertToBlob的参数和toBlob一致，但返回的是 Promise，不用再包一层。

注意：OffscreenCanvas在老版本 Safari 上是缺失的，落地时要做特性检测，typeof OffscreenCanvas === 'undefined'就回退到主线程的<canvas>路径。回退分支别省，很多用户的浏览器版本就是不支持。

6. 验收与进阶：两个能自动跑的校验，比肉眼靠谱

翻转这种东西，肉眼验收极不可靠——左右镜像和上下颠倒在没有参照物的时候长得一模一样，我在一个批量处理脚本上就吃过这个亏：跑了三千张图，人工抽查了二十张都说没问题，上线后用户反馈一半的证件照是倒的。从那以后我强制自己给翻转加两个自动校验，跑通才算完事。

第一个是对称性校验：任何翻转做两次必须还原。用同一张带明显不对称内容的图（比如左上角有个色块），翻转两次后逐像素比对原图，差异率超过千分之一就说明矩阵写错了或者中间做过重采样。

// 翻转两次应还原：比较像素平均绝对误差 function assertInvolution(img) { const once = flipImage(img, 'horizontal'); const twice = flipImage(once, 'horizontal'); const a = once.getContext('2d').getImageData(0, 0, once.width, once.height).data; const b = twice.getContext('2d').getImageData(0, 0, twice.width, twice.height).data; let diff = 0; for (let i = 0; i < a.length; i++) diff += Math.abs(a[i] - b[i]); const mae = diff / a.length; console.log('MAE =', mae.toFixed(3)); // 有损编码下 < 2 属正常，0 说明完全无损 return mae < 2; }

第二个是锚点校验：翻转前后取四个角各 10×10 的像素块，水平翻转后左上块应该等于原来的右上块。这个校验不需要原图缓存，适合在 CI 里对一组固定样张跑回归。两个校验加起来不到五十行，但能把"方向错"和"翻转丢失"这两类问题全部拦住。

进阶方向有两个。一是把翻转和旋转合并成一个变换枚举，{flipH, flipV, rotate}一共 8 种组合，用一张查找表映射到translate/scale/rotate的调用序列，比一堆 if-else 好维护得多。二是批处理时复用同一块 canvas 和同一个ImageData缓冲，尺寸不变的情况下能省掉大量分配，几千张图跑下来 GC 次数肉眼可见地下降。

包里那份flipImage.js和验收脚本我放在同一目录下，照着第 3 章的管线接一遍、再用第 6 章的两个校验跑一遍，基本就能确认它在你自己的图上是靠谱的。翻转这种小功能，代码量从来不是问题，真正花时间的是那些"看起来对但其实反了"的边界，把校验挂上去，比事后擦屁股省事得多。希望帮到你。

本文还有配套的精品资源，点击获取