简介面向Web前端初学者与JavaScript交互练习者这份项目围绕图片翻转效果展开提供可直接参考的示例页面与脚本帮助理解文档对象模型操作、点击事件监听、样式变换旋转以及过渡动画在真实页面中的配合方式也适合课堂演示、课后练习或小型交互实验便于建立从结构、样式到脚本控制的整体认识。压缩包共36个文件以26个gif和7个jpg图片素材为主辅以2个html示例页面和1个JavaScript脚本整体约413KB体积轻便便于快速浏览与对照。已有137人学习下载。资源将页面结构与交互脚本分开组织并配有多组按钮、箭头及角色状态图片读者可据此观察翻转前后的样式切换、事件响应与简单状态管理并通过素材组合理解不同状态下的视觉反馈进而迁移到卡片翻面、图片切换等常见前端交互场景。1. 一个需求催生的小工具用 JavaScript 写的图片翻转后台上传商品主图运营临时提要求模特朝左的那批图全部镜像一遍理由是详情页里人不能“背对”文案。二十来张PS 一张张翻也能交差但下个月促销换素材同样的活儿还会再来一次。我后来写的这份用 JavaScript 写的图片翻转源码就是为这种反复出现的琐事准备的纯前端、零依赖双击index.html就能跑图片拖进来点水平或垂直看着顺眼就下载一次也能丢十几张进去批量处理。它解决的不是“怎么把像素倒过来”这种算法题而是从选图、预览、翻转、导出到批量的整条链路如何不出错。适合手里有静态页面、想加个图片小工具的前端也适合刚学完 canvas、想找个能跑通的完整例子的人。代码量不大但每个环节都能单独拎出来改。2. 项目结构与技术选型从 CSS 到 Canvas 像素的三层实现拿到一份图片翻转的源码第一反应往往是去看scale(-1, 1)写在哪一行这没错但只看那一行会低估它。翻转这件事在浏览器里有三种完全不同层次的实现方式它们的成本、能力、失败模式都不一样。这份代码把三种都留了口子主链路走 CanvasCSS 作为轻量预览ImageData 作为教学和特殊场景的兜底。选型上它刻意保持了“裸奔”没有 React没有 Vite没有 npm install。原因很现实读者下载下来是为了改不是为了再配一套构建环境。一个页面级的小工具引入打包链只会把复现成本抬高而且这份代码里最值钱的部分是 canvas 的坐标变换和文件导出框架在这里没有任何增益。2.1 目录拆分每个文件只负责一件事先看文件结构短得可以一眼扫完image-flip/ ├── index.html # 唯一的页面工具栏 画布 空状态提示 ├── css/ │ └── style.css # 棋盘格背景、拖拽高亮、响应式 ├── js/ │ ├── main.js # 入口绑定事件、维护状态、串联流程 │ ├── loader.js # File - ImageBitmap负责解码和内存释放 │ ├── flipper.js # 三种翻转策略canvas 变换 / ImageData / CSS │ ├── exporter.js # canvas.toBlob a[download] │ └── history.js # 撤销栈只存状态不存像素 └── README.mdmain.js是唯一的“上帝文件”但它只做编排不碰像素flipper.js是纯函数集合输入输出都是 canvas 和位图没有 DOM 查询因此可以被 Worker 或者别的页面直接引走。这种拆法的好处是调试时能快速定位图显示不对八成在flipper.js图打不开去loader.js下载下来是空白看exporter.js。页面骨架用原生事件委托按钮上挂>!-- index.html没有构建工具直接用浏览器打开也能跑 -- div classtoolbar input typefile idfileInput acceptimage/* multiple hidden button>// js/loader.js export async function loadBitmap(file) { // 首选 createImageBitmap解码不阻塞主线程且支持 EXIF 方向参数 if (createImageBitmap in window) { try { return await createImageBitmap(file, { imageOrientation: from-image // 关键按相机记录的 EXIF 方向摆正 }); } catch (err) { console.warn(createImageBitmap 失败回退 Image 方案, err); } } // 回退部分旧版内核不支持上面的参数 const url URL.createObjectURL(file); const img new Image(); img.decoding async; try { await new Promise((resolve, reject) { img.onload resolve; img.onerror () reject(new Error(图片解码失败可能不是有效图片)); img.src url; }); return img; } finally { // 注意部分内核在首次 drawImage 时才真正回读数据稳妥起见延后释放 setTimeout(() URL.revokeObjectURL(url), 0); } }这段的关键参数是imageOrientation: from-image。手机拍的照片像素数据通常是横着的靠 EXIF 里的 Orientation 标记告诉看图软件“请旋转 90 度显示”。如果解码时忽略这个标记你翻转出来的方向就是错的用户会以为你的工具坏了。加上这个参数拿到的位图已经是摆正后的后续所有计算都基于视觉方向心智负担小很多。另一个点是revokeObjectURL的时机。URL.createObjectURL创建的引用不释放整个 Blob 会一直被浏览器持有批量处理几十张图就是几百 MB 的内存泄漏页面迟早崩。这里用setTimeout(..., 0)延后一拍是踩过坑之后的保守写法。3.2 Canvas 坐标系translate 加 scale 到底在干什么这是整个项目最核心的十几行。很多人背下来了却说不清原理改需求时一改就乱。理解它的关键是Canvas 的变换作用于“坐标系”不是作用于“已经画上去的内容”。// js/flipper.js export function drawFlipped(ctx, source, opts {}) { const { horizontal false, vertical false } opts; const w source.width; const h source.height; // 1. 先复位并清空避免上一张图的残影 ctx.setTransform(1, 0, 0, 1, 0, 0); ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height); // 2. 保存当前矩阵后面要还原 ctx.save(); // 3. 水平翻转把原点平移到右边界再把 x 轴取反 if (horizontal) { ctx.translate(w, 0); ctx.scale(-1, 1); } // 4. 垂直翻转把原点平移到下边界再把 y 轴取反 if (vertical) { ctx.translate(0, h); ctx.scale(1, -1); } ctx.drawImage(source, 0, 0, w, h); // 5. 必须还原否则变换会累加到下一次绘制 ctx.restore(); }逻辑说明scale(-1, 1)单独用的话图像会画到画布左侧外面去因为原点没动所有 x 坐标取反后变成负值。所以要先translate(w, 0)把原点挪到右上角再取反画面才落回可视区域。垂直方向同理。两个方向都开等价于旋转 180 度结果一样但语义不同代码里保留两个布尔量是为了让状态可读。参数说明source可以是ImageBitmap、HTMLImageElement或HTMLCanvasElementdrawImage都认w和h用源图的原始尺寸别用 canvas 的显示尺寸两者在 CSS 缩放下经常不一致混用会导致翻转后图像被裁掉一角。save和restore必须成对出现。漏掉restore下一次绘制会叠加在上一次的翻转矩阵上出现“翻一次正常、翻两次图没了”的诡异现象。这类 bug 排查起来很折磨人因为控制台不报错只是画面不对。3.3 逐像素翻转把 ImageData 的字节顺序搞明白Canvas 变换是黑盒想看清底层就得自己动字节。这份代码里保留了一个纯 ImageData 实现主要给需要“翻转 其他像素操作”合并处理的人用。// js/flipper.js —— 水平逐像素翻转 export function flipImageDataHorizontal(imageData) { const { data, width, height } imageData; const rowBytes width * 4; // 每像素 4 字节R G B A const tmp new Uint8ClampedArray(rowBytes); // 复用一行缓冲避免每行都新建 for (let y 0; y height; y) { const rowStart y * rowBytes; // 1. 整行拷进临时缓冲 tmp.set(data.subarray(rowStart, rowStart rowBytes)); // 2. 从右往左读临时缓冲从左往右写回原数组 for (let x 0; x width; x) { const src (width - 1 - x) * 4; const dst x * 4; data[rowStart dst] tmp[src]; // R data[rowStart dst 1] tmp[src 1]; // G data[rowStart dst 2] tmp[src 2]; // B data[rowStart dst 3] tmp[src 3]; // A } } return imageData; }逻辑说明ImageData.data是一个一维的Uint8ClampedArray长度是width * height * 4排列顺序是逐行、逐像素、逐通道。所以第 y 行第 x 个像素的红色分量下标是(y * width x) * 4。翻转就是同一行内左右对调跨行不动。先整行拷贝再写回是为了避免交换过程中覆盖还没读到的像素。参数说明Uint8ClampedArray会自动把赋值钳制在 0 到 255不用手动判断越界。内存上一张 4000×3000 的图data本身就是 48 MB再加上一份行缓冲处理时机的选择很关键这点在第 5 章会展开。垂直方向的逐像素翻转不需要行缓冲直接按行交换subarray更划算代码里也留了对应实现思路一致。3.4 导出与下载toBlob 的格式、画质和那个容易踩的 revoke画布上看着对了不代表下载下来也对。toDataURL返回 base64 字符串大图会生成几 MB 的字符串浏览器标签页内存瞬间上去toBlob是异步的内存表现好得多也是这份代码采用的方式。// js/exporter.js export function exportCanvas(canvas, filename flipped, type image/png, quality 0.92) { return new Promise((resolve, reject) { canvas.toBlob((blob) { if (!blob) { reject(new Error(导出失败画布为空或已被跨域图片污染)); return; } const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download ${filename}.${type.split(/)[1]}; // 扩展名从 MIME 推导 document.body.appendChild(a); // 部分浏览器要求节点在文档里才触发下载 a.click(); a.remove(); // 立刻 revoke 会让部分浏览器的下载中断给 1 秒缓冲 setTimeout(() URL.revokeObjectURL(url), 1000); resolve(blob); }, type, quality); }); }参数说明type支持image/png、image/jpeg、image/webp默认 PNG 是为了保真但 PNG 体积大批量场景下换成 JPEG 或者 WebP 更合适quality只对 JPEG 和 WebP 生效取值 0 到 10.92 是画质和体积的常见平衡点再往上提升肉眼几乎无感体积却线性增长。注意quality传成 92 而不是 0.92会静默退化成默认值这个坑不少人都踩过。a.download在某些内核里对扩展名敏感所以从 MIME 里推导而不是写死。另外这个属性在跨域场景下会被忽略变成直接打开图片这一点在第 5 章会单独讲。4. 交互层状态模型决定了这个工具能长多大像素逻辑写完之后剩下的工作量其实都在交互上。这份代码有一个明确的设计判断翻转状态绝不累积在画布上而是用一个独立的状态对象描述每次重绘都从原图重新来过。这个决定直接影响了撤销、重置、批量能不能干净地实现。4.1 用布尔量描述翻转而不是累积 transform最容易写错的版本是这样的用户点一次水平翻转就给 canvas 的ctx.scale(-1, 1)一次。点两次-1 × -1 1回到原样看起来没问题。但一旦加上垂直、旋转、裁剪矩阵就会变成一坨没人能读懂的东西而且你无法从画布反推出“现在到底是翻了几次”。// js/main.js const state { source: null, // 原始位图永不修改作为唯一真相 horizontal: false, // 是否水平翻转 vertical: false, // 是否垂直翻转 }; function render() { if (!state.source) return; const canvas document.getElementById(stage); const ctx canvas.getContext(2d); // 先设尺寸再取上下文画注意给 width 赋值会重置全部上下文状态 canvas.width state.source.width; canvas.height state.source.height; drawFlipped(ctx, state.source, { horizontal: state.horizontal, vertical: state.vertical }); document.getElementById(empty).hidden true; } // 事件处理翻转布尔量再重绘不直接操作矩阵 document.addEventListener(click, (e) { const action e.target.dataset.action; if (action flip-h) { state.horizontal !state.horizontal; render(); } if (action flip-v) { state.vertical !state.vertical; render(); } if (action reset) { state.horizontal false; state.vertical false; render(); } });逻辑说明state是可序列化的、可比较的、可存历史记录的。翻转两次回到原状是布尔取反的自然结果不是靠-1相乘凑出来的。render每次从state.source全量重绘代价是一次drawImage对单图来说完全可以接受。canvas.width ...这一行有个副作用给它赋任何值哪怕前后一样都会清空画布并重置上下文状态包括变换矩阵、globalAlpha、fillStyle。所以顺序必须是先设尺寸再拿上下文做变换反过来写的表现会让人怀疑人生。4.2 拖拽、粘贴与批量队列的并发控制图片工具的入口越顺手用的人越多。除了文件选择拖拽和粘贴是两个高频通道尤其是截图之后直接 CtrlV。// js/main.js —— 拖拽与粘贴统一收口到 handleFiles document.addEventListener(drop, (e) { e.preventDefault(); // 不阻止默认行为浏览器会直接打开图片把页面顶掉 const files [...e.dataTransfer.files].filter(f f.type.startsWith(image/)); if (files.length) handleFiles(files); }); document.addEventListener(paste, (e) { const items [...(e.clipboardData?.items ?? [])]; const imageItem items.find(i i.type.startsWith(image/)); if (!imageItem) return; const file imageItem.getAsFile(); // 剪贴板图片没有文件名需要自己补 if (file) handleFiles([file]); });批量处理的坑不在循环而在并发数。十几张手机原图每张解码后都是几十 MB 的位图全部同时解码就是内存雪崩页面直接白屏。下面这个限流队列把同时处理的图片数压在 3 张以内// js/main.js —— 简单限流队列 async function runBatch(files, worker, concurrency 3) { const queue [...files]; const results []; const runners Array.from({ length: concurrency }, async () { while (queue.length) { const file queue.shift(); try { results.push({ file, blob: await worker(file) }); } catch (err) { results.push({ file, error: err.message }); } } }); await Promise.all(runners); return results; }参数说明concurrency默认 3是经验和内存之间折中的数字低端安卓机上建议降到 2每个 runner 是一个独立的异步循环靠queue.shift()抢任务天然避免了锁。错误被捕获后塞进结果数组而不是让整个Promise.all直接 reject否则一张图失败会把其余成功的也丢掉。4.3 撤销栈只存状态不存像素撤销功能有两种实现思路存画布快照或者存操作状态。前者一次快照就是几十 MB存十步内存就没了后者只是一个几十字节的对象。// js/history.js const stack []; const LIMIT 30; export function push(state) { // 只挑需要回滚的字段别把 ImageBitmap 也结构化克隆进去 stack.push({ horizontal: state.horizontal, vertical: state.vertical }); if (stack.length LIMIT) stack.shift(); // 超限丢最旧的防止无限增长 } export function undo(current) { return stack.pop() ?? current; // 栈空时返回当前状态调用方无感 } export function canUndo() { return stack.length 0; }逻辑说明push在每次状态变更前调用存的是“变更前的样子”。undo弹出并返回调用方拿到后赋给state再render()一次即可。LIMIT设 30 是因为用户真正需要回滚的步数很少超过这个量级再多的收益趋近于零。这里没用structuredClone因为state里混着ImageBitmap部分环境下克隆位图会抛异常或者直接复制一份显存。手动挑字段虽然啰嗦但绝对安全这也是血泪经验换来的写法。注意撤销栈和“重置”是两套逻辑。重置应该清空栈否则用户撤销一次又回到翻转状态会以为程序错乱。5. 避坑清单五个让翻转“看起来成功”的隐性失败这类工具最麻烦的地方在于它很少报错。画面看着对下载下来不对这台机器对那台机器糊单张对批量错。下面五条是实际调试中反复遇到的每条按现象、原因、解决写。5.1 翻转后图片变糊或者边缘出现半透明描边现象原图很锐利翻完之后整体发虚深色边缘有一圈灰白。原因多半出在画布尺寸和绘制尺寸不一致。如果 canvas 的逻辑尺寸被 CSS 缩放而drawImage又用了非整数坐标或非原始尺寸浏览器会做一次插值重采样锐利边缘就被抹平了。另一种情况是两个方向同时翻转时translate用了w - 1这种差一像素的写法导致内容整体偏移半个像素同样触发插值。解决canvas.width和canvas.height严格等于源图的naturalWidth、naturalHeight绘制时也用同样的宽高translate的位移量就是w和h不要减一。如果必须缩放显示用 CSS 的width: 100%控制视觉尺寸别去改 canvas 属性。改完用 1 像素宽的棋盘格图测一遍边缘是否清晰一眼就能看出来。5.2 浏览器里是正的下载下来方向又反了现象iPhone 拍的照片页面上预览正常导出的文件在电脑上看是躺着的或者上下颠倒。原因EXIF 的 Orientation 标记被保留在了导出文件里。你已经在解码时按from-image把像素摆正了但导出的 JPEG 如果又写入了原始 EXIF某些处理链路会看图软件会再转一次等于转了两次。解决导出时不要把原始 EXIF 透传下去。canvas.toBlob产出的文件本身不带 EXIF正常链路是安全的如果你在导出前又调用了别的库合并元数据记得显式清掉 Orientation。测试方法很简单用手机竖拍一张走完整链路导出的图在系统相册里看一眼就知道。5.3 批量处理十几张后页面卡死、标签页崩溃现象单张很快一次拖入二十张页面逐渐卡顿最后报“内存不足”或者直接白屏。原因每张图解码后都会生成一块与像素数成正比的内存手机原图 4000×3000 解出来约 48 MB二十张同时驻留就是近 1 GB。再加上每张都建了独立的 canvas 和 Blob内存只增不减。解决三件事一起做。一是限流同时处理的图片不超过 2 到 3 张用完立刻把ImageBitmap置空二是画布复用不要每张图都document.createElement(canvas)用一个离屏 canvas 处理完就覆盖三是把逐像素操作搬进 Worker主线程只负责最终的drawImage和导出。做完这三点同样的二十张图能在低端机上跑完。5.4 toBlob 返回 null控制台提示画布被污染现象图片能正常显示点下载没反应控制台出现安全错误toBlob回调里拿到null。原因绘制到 canvas 的图片来自不同源且响应头没有允许跨域读取。画布被标记为 tainted 之后任何读像素或读取数据的操作都会被拒绝toDataURL和toBlob都在此列。这在“从链接导入图片”的功能里特别常见。解决加载外部图片时设置img.crossOrigin anonymous同时确认图片服务返回了合适的 CORS 响应头两者缺一不可。如果图片源不可控那就退回服务端代理取图或者明确告诉用户“该图片不支持导出”。别试图用 try-catch 掩盖这是浏览器的安全边界绕不过去。5.5 移动端长按保存拿到的是没翻转的原图现象手机上翻转完用户习惯性长按图片保存结果存下来的是原图。原因canvas 上的内容对长按操作来说只是一块位图浏览器或微信的内置菜单保存的是画布的当前渲染结果但如果你的页面结构是“原图 img 叠在 canvas 下面”长按可能命中的是下面那张img。另一种情况是翻转只通过 CSStransform实现DOM 里的图片源文件从来没变。解决保证翻转后的可见元素就是 canvas 本身不要在它下面藏着原图给 canvas 加-webkit-touch-callout: default之外的显式处理同时提供一个明确的“下载”按钮把a[download]作为主路径引导用户。展示用 CSS、导出用 Canvas 的混合方案最容易在这里翻车宁可多渲染一次画布也不要留两套显示逻辑。6. 二次开发把翻转逻辑抽成一个能塞进任何页面的模块如果只是偶尔用一次改改按钮文案就够了。但多数人下载这份代码是为了把它并进自己的项目这时候第一件事是把reference里散落的 DOM 操作和翻转逻辑切开。我在几个内部页面里复用过这套代码最省事的做法是把flipper.js升级成一个不依赖页面的模块// flip.js —— 无 DOM 依赖的翻转模块可被页面、Worker、组件复用 export function flipToBlob(source, { horizontal false, vertical false, type image/png, quality 0.92 } {}) { const canvas new OffscreenCanvas(source.width, source.height); const ctx canvas.getContext(2d); const w source.width, h source.height; ctx.setTransform(1, 0, 0, 1, 0, 0); if (horizontal) { ctx.translate(w, 0); ctx.scale(-1, 1); } if (vertical) { ctx.translate(0, h); ctx.scale(1, -1); } ctx.drawImage(source, 0, 0, w, h); // OffscreenCanvas 走 convertToBlob语义和 toBlob 一致但可以在 Worker 里用 return canvas.convertToBlob({ type, quality }); }这段和原来的drawFlipped只差两点用OffscreenCanvas替代真实 canvas用convertToBlob替代toBlob。换来的能力是它可以整个跑在 Worker 里主线程一点都不卡批量的体验会明显好一个档次。代价是OffscreenCanvas在部分旧版 Safari 上不可用所以生产环境里我一般写成一个能力检测能上 Offscreen 就上不能就退回主线程版本。扩展方向按投入产出排我自己是这么做的改造点工作量价值增加 90 度旋转与翻转组合成八种朝向小高顺手就能做翻转后接裁剪框中高图片工具的必经之路批量导出打包成 zip中中需要引入压缩库像素操作搬进 Worker中高大图批量必做抽成 Web Component大视复用频率而定验证方法别偷懒。我固定用三个样本回归一张 1×1 的纯色图验证边界不越界一张带方向 EXIF 的手机竖拍图验证方向一致一张 4000 像素宽的大图验证内存和耗时。三个都过基本不会出大问题。性能上可以顺手在 Console 里打点记录解码、绘制、导出三段的耗时换个机型对比一下心里就有数了。改的时候有个容易忽略的地方旋转和翻转的组合不满足交换律90 度旋转之后再水平翻转和先翻转再旋转结果差一个方向。所以状态里不要只存布尔量最好存一个 0 到 7 的朝向枚举对应 D4 群的那八种变换重绘时统一查表。这个思路是我在自己写歪两次之后才想明白的一开始按布尔量顺序执行用户连点几下就出现了谁都说不清的结果。后来每次加新的几何变换我都会先把八种朝向的组合矩阵在纸上列一遍确认闭合了再写代码然后强制用那三张样本图走一遍完整链路。图片处理这类活儿肉眼看着对和真的对中间隔着的就是这种笨办法。希望帮到你。本文还有配套的精品资源点击获取