簡(jiǎn)介面向Web前端初學(xué)者與交互效果練習(xí)者的JavaScript圖片翻轉(zhuǎn)示例包圍繞點(diǎn)擊圖片沿X/Y軸翻轉(zhuǎn)并平滑恢復(fù)這一常見交互展開可用于理解DOM操作、事件監(jiān)聽與CSS變換的基礎(chǔ)配合。壓縮包共36個(gè)文件以26個(gè)gif和7個(gè)jpg圖片素材為主輔以2個(gè)html頁(yè)面和1個(gè)js腳本整體約413KB體量輕便適合直接解壓后對(duì)照頁(yè)面結(jié)構(gòu)與腳本邏輯學(xué)習(xí)。已有137人學(xué)習(xí)或?yàn)g覽可作為課堂演示、課后練習(xí)或前端小項(xiàng)目入門的參考。示例通過(guò)獲取圖片元素、綁定click事件在rotateX(180deg)與初始狀態(tài)間切換并借助transition讓翻轉(zhuǎn)過(guò)程更自然同時(shí)涉及翻轉(zhuǎn)狀態(tài)記錄避免連續(xù)點(diǎn)擊時(shí)邏輯混亂讀者可據(jù)此掌握樣式控制、狀態(tài)管理與簡(jiǎn)單動(dòng)畫的實(shí)現(xiàn)思路。1. 一張豎拍照片翻正后反而變糊JavaScript 圖片翻轉(zhuǎn)到底在翻什么前端做圖像處理JavaScript 圖片翻轉(zhuǎn)大概是出現(xiàn)頻率最高、也最容易被低估的需求用戶傳一張手機(jī)豎拍的照片預(yù)覽是躺倒的得轉(zhuǎn)正證件照工具要左右鏡像拼圖、貼紙、九宮格切圖要上下對(duì)調(diào)。看上去只是ctx.scale(-1, 1)一行的事真上手就會(huì)撞上畫布空白、邊緣發(fā)虛、透明底變黑、導(dǎo)出體積翻三倍這些事。這份資源把翻轉(zhuǎn)拆成兩層一層是 Canvas 繪制層面的坐標(biāo)變換一層是ImageData層面的像素搬運(yùn)。兩層各有各的邊界前者代碼少、能吃到 GPU 加速后者能在 Worker 里跑、不碰主線程。下面按我拆包時(shí)的順序走從坐標(biāo)系講起一路講到能自動(dòng)跑的驗(yàn)收腳本。2. 坐標(biāo)系選型三種翻轉(zhuǎn)寫法與那個(gè)必踩的負(fù)縮放坑Canvas 的坐標(biāo)原點(diǎn)在左上角x 向右為正y 向下為正。所謂翻轉(zhuǎn)本質(zhì)是把對(duì)應(yīng)軸做一次取反讓繪制內(nèi)容落到負(fù)區(qū)間去。理解這一句后面所有為什么畫不出來(lái)的問(wèn)題都能自己推出來(lái)。2.1 為什么 ctx.scale(-1, 1) 之后畫布是空的新手最常見的寫法是這個(gè)// 錯(cuò)誤示范只做負(fù)縮放不補(bǔ)平移 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] 區(qū)間畫布上什么都沒(méi)有scale(-1, 1)之后原本落在[0, w]的繪制內(nèi)容被映射到[-w, 0]整塊跑到畫布左邊界之外所以你看到的是一張空白圖。正確寫法要在縮放之前補(bǔ)一次平移// 水平翻轉(zhuǎn)左右鏡像 ctx.translate(canvas.width, 0); // 把原點(diǎn)挪到右上角 ctx.scale(-1, 1); // x 軸取反繪制區(qū)間重新回到 [0, w] ctx.drawImage(img, 0, 0); // 垂直翻轉(zhuǎn)上下對(duì)調(diào) // ctx.translate(0, canvas.height); // ctx.scale(1, -1); // 水平 垂直等價(jià)于旋轉(zhuǎn) 180 度 // ctx.translate(canvas.width, canvas.height); // ctx.scale(-1, -1);這里有個(gè)反直覺(jué)的點(diǎn)translate和scale的調(diào)用順序不能調(diào)換。Canvas 的變換矩陣是右乘累積的先translate(w, 0)再scale(-1, 1)得到的是T·S點(diǎn)p的最終位置是T·S·p也就是先縮放、再平移圖片先被翻到[-w, 0]再整體右移w正好落回畫布。如果先scale再translate平移量也跟著被取反了等于白翻。血淚經(jīng)驗(yàn)就一條平移量永遠(yuǎn)按目標(biāo)畫布尺寸給不要按源圖尺寸給兩者一旦不一致比如做了縮放適配翻轉(zhuǎn)方向就會(huì)錯(cuò)得莫名其妙。2.2 三條實(shí)現(xiàn)路徑的成本對(duì)照同一個(gè)翻轉(zhuǎn)需求至少有三種落法選錯(cuò)了不是能不能用的問(wèn)題是性能和維護(hù)成本差一個(gè)量級(jí)的問(wèn)題。路徑核心 API優(yōu)點(diǎn)代價(jià)適用場(chǎng)景CSS 變換transform: scaleX(-1)零代碼成本不占內(nèi)存只改顯示導(dǎo)出的文件仍是原圖純預(yù)覽、交互態(tài)鏡像Canvas 繪制ctx.translatectx.scaledrawImage能導(dǎo)出新圖瀏覽器內(nèi)部走 GPU 路徑需要處理尺寸、DPR、導(dǎo)出編碼上傳后要落盤、要下載的場(chǎng)景ImageData 搬運(yùn)getImageData 行/像素對(duì)調(diào)完全可控能塞進(jìn) Worker大圖內(nèi)存翻倍純 CPU批量處理、離屏計(jì)算、需要逐像素判斷的場(chǎng)景我一般的判斷標(biāo)準(zhǔn)是只要產(chǎn)物要交給后端或者觸發(fā)下載就走 Canvas 路徑只是頁(yè)面上看個(gè)鏡像效果CSS 夠了別為了一個(gè)scaleX(-1)去建一塊 canvas 再toDataURL白白多一次編碼。ImageData那條路只在兩種情況下值得動(dòng)一是需要在翻轉(zhuǎn)的同時(shí)做像素級(jí)判斷比如摳圖后的邊緣處理二是圖很大、必須挪到 Worker 里避免主線程卡頓。順便說(shuō)一個(gè)容易忽略的對(duì)比CSS 變換是顯示層鏡像Canvas 是數(shù)據(jù)層鏡像。曾有人用 CSS 做了鏡像預(yù)覽用戶點(diǎn)下載拿到的還是原圖反饋說(shuō)翻轉(zhuǎn)沒(méi)生效。這不是 bug是選型錯(cuò)了。2.3 參數(shù)怎么定尺寸、DPR 與平滑質(zhì)量Canvas 只有三個(gè)參數(shù)真正影響翻轉(zhuǎn)結(jié)果width、height和imageSmoothingQuality。width/height是畫布的像素緩沖區(qū)尺寸不是顯示尺寸。翻轉(zhuǎn)場(chǎng)景下它應(yīng)該等于源圖的naturalWidth/naturalHeight因?yàn)榉D(zhuǎn)不改變圖像大小任何額外的縮放都會(huì)引入一次重采樣圖就糊了。很多人為了讓預(yù)覽清晰把 canvas 的 CSS 寬高設(shè)成顯示尺寸、緩沖區(qū)設(shè)成顯示尺寸 * devicePixelRatio這在縮放預(yù)覽里是對(duì)的但在翻轉(zhuǎn)里是錯(cuò)的——翻轉(zhuǎn)要的是 1:1 還原只在顯示時(shí)再用 CSS 縮下去// 翻轉(zhuǎn)場(chǎng)景的正確做法緩沖區(qū) 源圖尺寸顯示尺寸交給 CSS canvas.width img.naturalWidth; canvas.height img.naturalHeight; canvas.style.width 100%; // 顯示縮放與像素緩沖區(qū)解耦 canvas.style.maxWidth 480px;提示img.naturalWidth在有 EXIF 方向的照片上已經(jīng)是旋轉(zhuǎn)后的寬高直接用即可不要再拿img.width去乘什么系數(shù)。imageSmoothingQuality在翻轉(zhuǎn)本身用不上沒(méi)有縮放就沒(méi)有插值但如果你在同一條管線里順手做了縮略圖把它設(shè)成high會(huì)明顯好于默認(rèn)值。參數(shù)就三檔low | medium | high代價(jià)是耗時(shí)大圖批量處理時(shí)建議只對(duì)最終輸出設(shè) high中間草稿用 low。3. 從 File 到 Blob寫一個(gè)能直接用的 flipImage 模塊坐標(biāo)系搞清楚之后剩下的是一條完整的管線拿到File→ 解碼成可繪制的位圖 → 翻轉(zhuǎn) → 編碼成Blob交出去。這條鏈上每一步都有一個(gè)參數(shù)會(huì)咬人。3.1 解碼階段與 EXIF 方向的雙重旋轉(zhuǎn)問(wèn)題手機(jī)拍的照片像素?cái)?shù)據(jù)往往是橫著存的方向信息寫在 EXIF 里?，F(xiàn)代瀏覽器在渲染img時(shí)默認(rèn)就應(yīng)用了 EXIF 方向image-orientation: from-image是初始值所以img.naturalWidth已經(jīng)是轉(zhuǎn)正后的尺寸。問(wèn)題出在解碼 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 一直掛在內(nèi)存里 return img; // naturalWidth/Height 已經(jīng)是方向修正后的值 } // 方案 B用 createImageBitmap 解碼方向行為要顯式聲明 async function loadViaBitmap(file) { // imageOrientation: from-image 表示按 EXIF 應(yīng)用方向 // 若源圖已經(jīng)在 img 里被轉(zhuǎn)正過(guò)一次這里再加一次就是雙重旋轉(zhuǎn) return await createImageBitmap(file, { imageOrientation: from-image }); }這兩條路混用就會(huì)翻車先用img預(yù)覽已轉(zhuǎn)正再把原始File丟給createImageBitmap({imageOrientation:from-image})又轉(zhuǎn)一次結(jié)果照片被多轉(zhuǎn)了 90 度。我一般固定選一條路走到底——預(yù)覽和導(dǎo)出都用img或者都用createImageBitmap中間不換。createImageBitmap的好處是能直接喂給 Workerimg的好處是兼容性更穩(wěn)。3.2 flipImage 主函數(shù)與三種模式核心函數(shù)不長(zhǎng)但每個(gè)分支都要照顧到翻轉(zhuǎn)后尺寸不變這個(gè)前提/** * param {ImageBitmap|HTMLImageElement} source 已解碼的圖像源 * param {horizontal|vertical|both} mode 翻轉(zhuǎn)模式 * 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; // 緩沖區(qū)尺寸等于源圖絕不縮放 canvas.height h; const ctx canvas.getContext(2d); // 按模式設(shè)置變換矩陣注意 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); // 兩次取反等價(jià)于旋轉(zhuǎn) 180 度 } ctx.drawImage(source, 0, 0, w, h); // 顯式傳目標(biāo)寬高避免 source 尺寸歧義 return canvas; }三個(gè)模式對(duì)應(yīng)的矩陣其實(shí)是一張表horizontal是x w - xvertical是y h - yboth是兩者疊加。drawImage里顯式寫(0, 0, w, h)而不是只傳(0, 0)是因?yàn)樵贗mageBitmap和HTMLImageElement混用時(shí)省略寬高會(huì)讓瀏覽器按源的自然尺寸去畫一旦源被縮放過(guò)就會(huì)錯(cuò)位。如果要批量處理把這個(gè)函數(shù)里的document.createElement(canvas)換成復(fù)用的 canvas 實(shí)例同一個(gè)尺寸反復(fù)用能省掉大量 GC 壓力。3.3 導(dǎo)出參數(shù)格式、質(zhì)量與透明底最后一步是把 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 // 只對(duì) image/jpeg 和 image/webp 生效PNG 會(huì)忽略 ); }); } // 導(dǎo)出 JPEG 前必須補(bǔ)白底否則透明區(qū)域會(huì)被填成黑色 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; }三個(gè)參數(shù)要記牢type缺省是image/pngPNG 無(wú)損但體積大quality在 0 到 1 之間JPEG 建議 0.82 到 0.88再高體積漲得快、肉眼幾乎看不出差別globalCompositeOperation: destination-over是補(bǔ)底色的正確姿勢(shì)用source-over會(huì)在圖片上面糊一層白。注意toBlob的回調(diào)可能收到null常見原因是畫布尺寸為 0 或者圖片觸發(fā)了跨域污染。用img.crossOrigin anonymous加載外鏈圖并且服務(wù)端要回Access-Control-Allow-Origin缺一個(gè)都會(huì)讓畫布變成臟畫布toBlob/getImageData全部拋安全錯(cuò)誤。4. 排查清單翻轉(zhuǎn)后發(fā)虛、偏色、體積翻倍的五個(gè)真實(shí)原因這一章按現(xiàn)象 → 原因 → 解決來(lái)都是我實(shí)際遇到過(guò)、并且能在五分鐘內(nèi)定位的問(wèn)題。4.1 現(xiàn)象翻轉(zhuǎn)后邊緣發(fā)虛文字和細(xì)線糊成一團(tuán)原因基本只有一個(gè)畫布緩沖區(qū)尺寸和繪制尺寸不一致觸發(fā)了重采樣。典型寫法是canvas.width 300、canvas.height 300但drawImage(img, 0, 0)畫進(jìn)去的是一張 4000×3000 的圖瀏覽器先縮小一次或者反過(guò)來(lái)canvas.width設(shè)成了 CSS 顯示尺寸的像素值在 2 倍屏上被拉伸一次。還有一種隱蔽情況drawImage傳了目標(biāo)寬高但取的是img.width帶 CSS 縮放的顯示寬度而不是naturalWidth。解決辦法是固定一條鐵律——翻轉(zhuǎn)管線的 canvas 緩沖區(qū)必須等于naturalWidth/naturalHeight顯示用 CSS 兜。定位時(shí)可以在翻轉(zhuǎn)后打印canvas.width和img.naturalWidth兩個(gè)數(shù)不相等就是它。4.2 現(xiàn)象PNG 透明圖翻轉(zhuǎn)后透明區(qū)域變黑了原因不是翻轉(zhuǎn)是導(dǎo)出。toBlob(image/jpeg)或toDataURL(image/jpeg)用的 JPEG 不支持 alpha 通道Canvas 的透明區(qū)域在編碼時(shí)會(huì)被合成為黑色某些實(shí)現(xiàn)下是白或黑取決于瀏覽器。如果原圖是帶透明底的摳圖素材翻轉(zhuǎn)后直接導(dǎo) JPEG 就廢了。解決辦法要么堅(jiān)持導(dǎo)出 PNG體積換正確性要么在導(dǎo)出前用destination-over鋪一層白底或品牌色底。判斷標(biāo)準(zhǔn)很簡(jiǎn)單——源文件是 PNG/WebP 且可能帶透明通道就一定要做這一步別指望用戶理解。4.3 現(xiàn)象翻轉(zhuǎn)后文件體積從 800KB 漲到 3MB三種成因從高到低排一是格式從 JPEG 變成了 PNGtoBlob不傳type時(shí)的默認(rèn)行為就是 PNG無(wú)損編碼對(duì)有噪點(diǎn)的照片極其不友好二是quality用了 0.95 以上接近無(wú)損但體積爆炸三是把 canvas 尺寸按 DPR 放大了兩倍再導(dǎo)出像素?cái)?shù)直接四倍。解決辦法顯式傳type照片類內(nèi)容統(tǒng)一走image/jpegquality: 0.85只有需要透明背景的素材才用 PNG。翻轉(zhuǎn)本身不產(chǎn)生新信息體積膨脹一定是編碼參數(shù)或者尺寸搞錯(cuò)了。4.4 現(xiàn)象手機(jī)豎拍照片翻轉(zhuǎn)方向是錯(cuò)的左右鏡像變成了上下顛倒典型原因是 EXIF 方向被應(yīng)用了兩次或零次。前面 3.1 講過(guò)img默認(rèn)按 EXIF 渲染createImageBitmap則取決于imageOrientation參數(shù)?；煊脙蓷l解碼路徑就會(huì)出現(xiàn)看起來(lái)是橫的翻完還是橫的但方向反了這種情況。解決辦法整條管線只保留一個(gè)解碼入口并且在入口處就把方向問(wèn)題解決掉后續(xù)的翻轉(zhuǎn)只處理用戶主動(dòng)要求的鏡像。定位方法是在drawImage之前打印source.width和source.height如果 4:3 的照片打印出 3:4說(shuō)明方向已經(jīng)應(yīng)用過(guò)不要再轉(zhuǎn)。4.5 現(xiàn)象連續(xù)翻轉(zhuǎn)多次后圖片越來(lái)越糊這是有損編碼的累積效應(yīng)。每次翻轉(zhuǎn)都經(jīng)歷了一輪解碼 → 重繪 → JPEG 編碼每輪都會(huì)丟一點(diǎn)高頻信息翻十次就明顯糊了尤其是人像皮膚和大面積漸變色。解決辦法不要拿翻轉(zhuǎn)后的結(jié)果當(dāng)下一輪的輸入。原始File或原始ImageBitmap只解碼一次并常駐每次翻轉(zhuǎn)都從它出發(fā)最后只編碼一次。如果確實(shí)需要保留歷史步驟中間態(tài)用 PNG 或者ImageBitmap存別用 JPEG 存。這個(gè)坑我在一個(gè)圖片編輯器項(xiàng)目里踩過(guò)用戶反復(fù)撤銷重做之后畫質(zhì)肉眼可見地崩最后就是靠只保留原圖 操作?；胤沤鉀Q的。5. 像素級(jí)翻轉(zhuǎn)用 ImageData 手動(dòng)對(duì)調(diào)順帶扔進(jìn) WorkerCanvas 變換吩咐了瀏覽器去做好處是快、代碼少但有些場(chǎng)景必須自己搬像素——需要在翻轉(zhuǎn)同時(shí)做逐像素判斷或者要繞開主線程的卡頓。這時(shí)候就得上ImageData。5.1 ImageData 逐行搬運(yùn)的三個(gè)細(xì)節(jié)ImageData.data是一個(gè)Uint8ClampedArray每個(gè)像素 4 字節(jié)RGBA順序是R, G, B, A平鋪。所以第 y 行、第 x 個(gè)像素的紅色分量下標(biāo)是(y * width x) * 4。水平翻轉(zhuǎn)是同一行內(nèi)左右對(duì)調(diào)像素垂直翻轉(zhuǎn)是整行對(duì)調(diào)。后者能整塊搬運(yùn)效率高得多/** * 垂直翻轉(zhuǎn)整行對(duì)調(diào)用 TypedArray 的 set 做塊拷貝 * param {ImageData} imageData 原地修改 */ function flipVerticalInPlace(imageData) { const { width, height, data } imageData; const rowBytes width * 4; // 一行占多少字節(jié) const temp new Uint8ClampedArray(rowBytes); // 復(fù)用一個(gè)行緩沖避免每行新建 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; } /** * 水平翻轉(zhuǎn)行內(nèi)左右像素對(duì)調(diào)逐像素交換 4 個(gè)通道 */ 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) { // 四個(gè)通道一起換漏一個(gè)就會(huì)偏色 const t data[left c]; data[left c] data[right c]; data[right c] t; } } } return imageData; }三個(gè)細(xì)節(jié)值得說(shuō)一是循環(huán)只跑到height / 2或者width / 2跑到全長(zhǎng)會(huì)把每對(duì)像素?fù)Q兩次、等于沒(méi)換二是copyWithin在同一塊 buffer 內(nèi)部搬運(yùn)比手寫循環(huán)快但它不能用于重疊區(qū)有風(fēng)險(xiǎn)的方向所以上下對(duì)調(diào)要借助temp中轉(zhuǎn)三是四個(gè)通道必須一起換只換 RGB 不換 A帶透明漸變的圖會(huì)出現(xiàn)詭異的光暈。5.2 用 Worker OffscreenCanvas 拆掉主線程卡頓一張 4000×3000 的圖getImageData出來(lái)的數(shù)組是 48MB主線程上跑一遍雙重循環(huán)基本就是幾百毫秒的白屏。解決辦法是把畫布控制權(quán)交給 Worker// main.js —— 主線程只負(fù)責(zé)派活和收活 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轉(zhuǎn)移后主線程不再持有零拷貝 worker.postMessage({ bitmap, mode }, [bitmap]); }); }// flip.worker.js —— 離屏畫布 像素搬運(yùn) 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語(yǔ)義與 toBlob 一致 const blob await canvas.convertToBlob({ type: image/jpeg, quality: 0.85 }); self.postMessage({ blob }); } catch (err) { self.postMessage({ error: err.message }); } };要點(diǎn)有三個(gè)createImageBitmap產(chǎn)生的bitmap是 transferablepostMessage的第二個(gè)參數(shù)把它轉(zhuǎn)移過(guò)去主線程側(cè)的對(duì)象會(huì)被置空這是零拷貝的關(guān)鍵Worker 里沒(méi)有document只能用OffscreenCanvasconvertToBlob的參數(shù)和toBlob一致但返回的是 Promise不用再包一層。注意OffscreenCanvas在老版本 Safari 上是缺失的落地時(shí)要做特性檢測(cè)typeof OffscreenCanvas undefined就回退到主線程的canvas路徑?；赝朔种e省很多用戶的瀏覽器版本就是不支持。6. 驗(yàn)收與進(jìn)階兩個(gè)能自動(dòng)跑的校驗(yàn)比肉眼靠譜翻轉(zhuǎn)這種東西肉眼驗(yàn)收極不可靠——左右鏡像和上下顛倒在沒(méi)有參照物的時(shí)候長(zhǎng)得一模一樣我在一個(gè)批量處理腳本上就吃過(guò)這個(gè)虧跑了三千張圖人工抽查了二十張都說(shuō)沒(méi)問(wèn)題上線后用戶反饋一半的證件照是倒的。從那以后我強(qiáng)制自己給翻轉(zhuǎn)加兩個(gè)自動(dòng)校驗(yàn)跑通才算完事。第一個(gè)是對(duì)稱性校驗(yàn)任何翻轉(zhuǎn)做兩次必須還原。用同一張帶明顯不對(duì)稱內(nèi)容的圖比如左上角有個(gè)色塊翻轉(zhuǎn)兩次后逐像素比對(duì)原圖差異率超過(guò)千分之一就說(shuō)明矩陣寫錯(cuò)了或者中間做過(guò)重采樣。// 翻轉(zhuǎn)兩次應(yīng)還原比較像素平均絕對(duì)誤差 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 說(shuō)明完全無(wú)損 return mae 2; }第二個(gè)是錨點(diǎn)校驗(yàn)翻轉(zhuǎn)前后取四個(gè)角各 10×10 的像素塊水平翻轉(zhuǎn)后左上塊應(yīng)該等于原來(lái)的右上塊。這個(gè)校驗(yàn)不需要原圖緩存適合在 CI 里對(duì)一組固定樣張跑回歸。兩個(gè)校驗(yàn)加起來(lái)不到五十行但能把方向錯(cuò)和翻轉(zhuǎn)丟失這兩類問(wèn)題全部攔住。進(jìn)階方向有兩個(gè)。一是把翻轉(zhuǎn)和旋轉(zhuǎn)合并成一個(gè)變換枚舉{flipH, flipV, rotate}一共 8 種組合用一張查找表映射到translate/scale/rotate的調(diào)用序列比一堆 if-else 好維護(hù)得多。二是批處理時(shí)復(fù)用同一塊 canvas 和同一個(gè)ImageData緩沖尺寸不變的情況下能省掉大量分配幾千張圖跑下來(lái) GC 次數(shù)肉眼可見地下降。包里那份flipImage.js和驗(yàn)收腳本我放在同一目錄下照著第 3 章的管線接一遍、再用第 6 章的兩個(gè)校驗(yàn)跑一遍基本就能確認(rèn)它在你自己的圖上是靠譜的。翻轉(zhuǎn)這種小功能代碼量從來(lái)不是問(wèn)題真正花時(shí)間的是那些看起來(lái)對(duì)但其實(shí)反了的邊界把校驗(yàn)掛上去比事后擦屁股省事得多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取