簡(jiǎn)介面向Web前端初學(xué)者與交互效果練習(xí)者的JavaScript圖片翻轉(zhuǎn)示例包圍繞點(diǎn)擊圖片沿X/Y軸翻轉(zhuǎn)并平滑恢復(fù)這一常見(jiàn)交互展開(kāi)可用于理解DOM操作、事件監(jiān)聽(tīng)與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)目入門(mén)的參考。示例通過(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)畫(huà)的實(shí)現(xiàn)思路。1. 一張豎拍照片翻正后反而變糊JavaScript 圖片翻轉(zhuǎn)到底在翻什么前端做圖像處理JavaScript 圖片翻轉(zhuǎn)大概是出現(xiàn)頻率最高、也最容易被低估的需求用戶傳一張手機(jī)豎拍的照片預(yù)覽是躺倒的得轉(zhuǎn)正證件照工具要左右鏡像拼圖、貼紙、九宮格切圖要上下對(duì)調(diào)?？瓷先ブ皇莄tx.scale(-1, 1)一行的事真上手就會(huì)撞上畫(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)寫(xiě)法與那個(gè)必踩的負(fù)縮放坑Canvas 的坐標(biāo)原點(diǎn)在左上角x 向右為正y 向下為正。所謂翻轉(zhuǎn)本質(zhì)是把對(duì)應(yīng)軸做一次取反讓繪制內(nèi)容落到負(fù)區(qū)間去。理解這一句后面所有為什么畫(huà)不出來(lái)的問(wèn)題都能自己推出來(lái)。2.1 為什么 ctx.scale(-1, 1) 之后畫(huà)布是空的新手最常見(jiàn)的寫(xiě)法是這個(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); // 圖片被畫(huà)到 x ∈ [-w, 0] 區(qū)間畫(huà)布上什么都沒(méi)有scale(-1, 1)之后原本落在[0, w]的繪制內(nèi)容被映射到[-w, 0]整塊跑到畫(huà)布左邊界之外所以你看到的是一張空白圖。正確寫(xiě)法要在縮放之前補(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正好落回畫(huà)布。如果先scale再translate平移量也跟著被取反了等于白翻。血淚經(jīng)驗(yàn)就一條平移量永遠(yuǎn)按目標(biāo)畫(huà)布尺寸給不要按源圖尺寸給兩者一旦不一致比如做了縮放適配翻轉(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)出編碼上傳后要落盤(pán)、要下載的場(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是畫(huà)布的像素緩沖區(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寫(xiě)一個(gè)能直接用的 flipImage 模塊坐標(biāo)系搞清楚之后剩下的是一條完整的管線拿到File→ 解碼成可繪制的位圖 → 翻轉(zhuǎn) → 編碼成Blob交出去。這條鏈上每一步都有一個(gè)參數(shù)會(huì)咬人。3.1 解碼階段與 EXIF 方向的雙重旋轉(zhuǎn)問(wèn)題手機(jī)拍的照片像素?cái)?shù)據(jù)往往是橫著存的方向信息寫(xiě)在 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里顯式寫(xiě)(0, 0, w, h)而不是只傳(0, 0)是因?yàn)樵贗mageBitmap和HTMLImageElement混用時(shí)省略寬高會(huì)讓瀏覽器按源的自然尺寸去畫(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常見(jiàn)原因是畫(huà)布尺寸為 0 或者圖片觸發(fā)了跨域污染。用img.crossOrigin anonymous加載外鏈圖并且服務(wù)端要回Access-Control-Allow-Origin缺一個(gè)都會(huì)讓畫(huà)布變成臟畫(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è)畫(huà)布緩沖區(qū)尺寸和繪制尺寸不一致觸發(fā)了重采樣。典型寫(xiě)法是canvas.width 300、canvas.height 300但drawImage(img, 0, 0)畫(huà)進(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ù)撤銷重做之后畫(huà)質(zhì)肉眼可見(jiàn)地崩最后就是靠只保留原圖 操作?；胤沤鉀Q的。5. 像素級(jí)翻轉(zhuǎn)用 ImageData 手動(dòng)對(duì)調(diào)順帶扔進(jìn) WorkerCanvas 變換吩咐了瀏覽器去做好處是快、代碼少但有些場(chǎng)景必須自己搬像素——需要在翻轉(zhuǎn)同時(shí)做逐像素判斷或者要繞開(kāi)主線程的卡頓。這時(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)比手寫(xiě)循環(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)基本就是幾百毫秒的白屏。解決辦法是把畫(huà)布控制權(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 —— 離屏畫(huà)布 像素搬運(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ō)明矩陣寫(xiě)錯(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ù)肉眼可見(jiàn)地下降。包里那份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)擊獲取