简介面向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 三条实现路径的成本对照同一个翻转需求至少有三种落法选错了不是能不能用的问题是性能和维护成本差一个量级的问题。路径核心 API优点代价适用场景CSS 变换transform: scaleX(-1)零代码成本不占内存只改显示导出的文件仍是原图纯预览、交互态镜像Canvas 绘制ctx.translatectx.scaledrawImage能导出新图浏览器内部走 GPU 路径需要处理尺寸、DPR、导出编码上传后要落盘、要下载的场景ImageData 搬运getImageData 行/像素对调完全可控能塞进 Worker大图内存翻倍纯 CPU批量处理、离屏计算、需要逐像素判断的场景我一般的判断标准是只要产物要交给后端或者触发下载就走 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的好处是能直接喂给 Workerimg的好处是兼容性更稳。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 - xvertical是y h - yboth是两者叠加。drawImage里显式写(0, 0, w, h)而不是只传(0, 0)是因为在ImageBitmap和HTMLImageElement混用时省略宽高会让浏览器按源的自然尺寸去画一旦源被缩放过就会错位。如果要批量处理把这个函数里的document.createElement(canvas)换成复用的 canvas 实例同一个尺寸反复用能省掉大量 GC 压力。3.3 导出参数格式、质量与透明底最后一步是把 canvas 变成能下载的Blobfunction 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/pngPNG 无损但体积大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 变成了 PNGtoBlob不传type时的默认行为就是 PNG无损编码对有噪点的照片极其不友好二是quality用了 0.95 以上接近无损但体积爆炸三是把 canvas 尺寸按 DPR 放大了两倍再导出像素数直接四倍。解决办法显式传type照片类内容统一走image/jpegquality: 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 手动对调顺带扔进 WorkerCanvas 变换吩咐了浏览器去做好处是快、代码少但有些场景必须自己搬像素——需要在翻转同时做逐像素判断或者要绕开主线程的卡顿。这时候就得上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是 transferablepostMessage的第二个参数把它转移过去主线程侧的对象会被置空这是零拷贝的关键Worker 里没有document只能用OffscreenCanvasconvertToBlob的参数和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 章的两个校验跑一遍基本就能确认它在你自己的图上是靠谱的。翻转这种小功能代码量从来不是问题真正花时间的是那些看起来对但其实反了的边界把校验挂上去比事后擦屁股省事得多。希望帮到你。本文还有配套的精品资源点击获取