前端处理几百MB大图预览第一个要改掉的直觉就是把文件地址塞进img等它自己显示。文件几百MB只是表面真正压垮浏览器的是解码后的像素内存、主线程解码耗时、Canvas 纹理上限和频繁重绘。尤其扫描件、设计稿、长图、地图切片这类素材尺寸动辄一两万像素起步直接预览很容易白屏、卡死移动端甚至直接刷新页面。这个主题适合正在做内容管理、档案预览、在线设计审阅、图像工具的前端开发者也适合刚接触大图加载、想搞清楚“为什么不能直接img”的同行。下面我按实际项目里的取舍把几百MB大图预览从算账、选型到代码落地拆一遍。1. 几百MB大图预览为什么不能直接交给 img1.1 文件大小只是表象解码后的像素内存才是硬账很多人判断一张图“重不重”会看文件大小几百MB确实吓人但浏览器真正吃掉的是解码后的位图内存。一个像素在 Canvas 里通常按 RGBA 四个通道算每个通道 1 字节也就是 4 字节如果图片是 20000×15000像素总数是 3 亿光是一张 RGBA 位图就接近 1.2GB。这个数字还没算原始文件缓冲、解码中间态、Canvas 后备存储、GPU 纹理以及页面里其他对象。桌面浏览器可能勉强扛一下移动端基本没有商量空间。我在排查大图白屏时习惯先做这个估算而不是先怀疑网络。公式很简单宽 × 高 × 4 × 副本数。副本数取决于你有没有同时保留ImageBitmap、离屏 Canvas、主 Canvas、缩略图和缓存瓦片。很多“明明只加载了一张图”的页面实际内存里有三四份不同尺寸的位图峰值直接翻倍。尤其是先createImageBitmap再画到 Canvas再transferToImageBitmap如果旧对象没有及时close()垃圾回收跟不上内存曲线会非常难看。还有一个容易忽略的点浏览器对单张图片的尺寸和 Canvas 画布尺寸都有上限不同设备、不同图形后端并不一致。你可能在桌面端能画出 12000×12000 的 Canvas到了移动端就只剩一块空白。稳妥做法是把“最大画布尺寸”当成运行时能力来探测而不是写死一个看起来很大的值。用 WebGL 时可以参考MAX_TEXTURE_SIZE用 Canvas 时则要给自己的业务设一个硬上限超过就降采样或切瓦片。注意不要用“文件小于多少MB”作为是否走大图方案的唯一标准。一张压缩率很高的 PNG 可能文件不大但像素尺寸惊人反过来某些未压缩格式文件很大像素尺寸未必夸张。像素总数和单边尺寸更值得关注。1.2 主线程解码、纹理上传和绘制三层卡顿直接img预览的链路大致是网络读取、图片解码、生成位图、合成上屏。文件小的时候这条链路很快几百MB大图就会暴露出三层卡顿。第一层是解码浏览器要在主线程之外或合成线程里处理大量压缩数据期间页面可能还能响应但一旦你把它画进 Canvas第二层就来了大位图上传到 GPU 或后备存储耗时和内存峰值都很高。第三层是交互绘制用户缩放、拖拽时如果每帧都从整张大图重绘帧率会断崖式下跌。我见过最常见的写法是拿到文件后直接URL.createObjectURL(file)塞进img等onload后画到全尺寸 Canvas再在外面套一个缩放容器。这个方案在 4000×3000 的图上很舒服到了 20000×15000 就会出现“图片出来了但鼠标一动就卡”“缩放时浏览器无响应”“控制台报内存不足”。原因不是缩放容器做得不对而是底层还在拿整张位图做重绘Canvas 没有能力替你变出按需解码。更麻烦的是图片解码失败不一定有清晰报错。有些环境会直接给空白图有些会触发页面崩溃后自动恢复有些会在控制台留下一条很短的警告。排查时不能只看img.onerror还要看naturalWidth是否为 0、Canvas 是否拿到有效上下文、绘制后像素是否全透明。我的习惯是做一个最小验证页只加载、只画一次、只读一个像素先把“解码是否成功”和“渲染是否成功”分开再谈性能优化。1.3 三条技术路线降采样预览、瓦片按需、离线分块解码几百MB大图预览不是只有一种答案实际项目里通常分三条路线。第一条是降采样预览也就是先不管原图多清晰生成一张最大边 1024 或 1600 的缩略图让用户先看见全貌后续再决定是否加载细节。这条路线实现成本最低适合“只需要看整体构图、文字能辨认个大概”的场景比如设计稿初审、扫描件快速浏览。它的短板是放大后糊不能替代真正的高清查看。第二条是瓦片按需加载把大图切成金字塔每一层按 256 或 512 的瓦片切分用户看到哪块就加载哪块。地图类应用最熟悉这套思路扫描件、长图、检测图也适用。它的优势是内存可控、首屏快、缩放平滑代价是需要预处理或服务端切片能力前端要维护层级、坐标、缓存和预加载。远程图片如果没有切片服务只靠前端很难凭空把普通 JPEG 切成可独立解码的瓦片。第三条是纯前端离线分块解码适合文件只在本地、不能上传、又必须看细节的场景。前端读取文件的字节区间用 WebAssembly 解码模块按区域或按降采样级别解码再把结果画到离屏画布。这条路最硬涉及格式解析、解码器接入、线程池和内存释放。它也不是万能的普通 JPEG、PNG 并不天然支持随机瓦片读取真正适合的是带分块/分条结构的格式或者你愿意接受“先完整解码一次再切瓦片”的内存峰值。我的选型经验是能服务端预处理就别把压力全推给浏览器不能上传但只需要整体预览就降采样不能上传又要看局部细节再考虑分块格式和 WebAssembly 解码。不要一上来就做最复杂的那条先把用户“第一眼看到图”的路径做稳后面再逐步加清晰度。2. 大图预览的整体架构与参数计算2.1 预览链路先低清可见再按需清晰一个比较稳的预览链路是先读图片头拿到宽高生成一张低清缩略图占位视图初始化时按容器尺寸计算合适的缩放级别只加载当前视口覆盖的瓦片用户缩放或拖拽时先显示已有低清图或缓存瓦片再异步补新瓦片空闲时预加载视口周边一圈。这样用户不会盯着白屏等几百MB文件内存也不会在首屏就冲到峰值。这条链路里“低清图”不是可有可无的装饰。它承担三个作用第一告诉用户图片已经打开降低等待焦虑第二在瓦片没到位时作为背景避免频繁白屏闪烁第三给缩放操作一个稳定的视觉参考。低清图最大边我一般控制在 1024 到 1600 之间太大失去占位意义太小又看不清整体内容。对于文字密集的扫描件可以适当提高到 2048但要注意移动端内存。瓦片视图的容器建议用固定尺寸的div包住 CanvasCanvas 尺寸跟随容器和设备像素比但设备像素比要设上限。移动端高刷屏的devicePixelRatio可能到 3如果容器是 1200×800实际画布就是 3600×2400内存和绘制量都会上去。我的做法是把有效 DPR 限制在 2 以内极端低端设备限制在 1.5肉眼差异没有想象中大流畅度收益更明显。2.2 瓦片金字塔的层级、瓦片数和内存预算瓦片金字塔的核心是“每一层缩小一半”。假设原图最大边是maxSide瓦片边长是tileSize最顶层只需要一张或几张瓦片覆盖全图最底层是原图。层级数量可以用ceil(log2(maxSide / tileSize))估算。比如最大边 20000瓦片 51220000/512≈39log2(39)≈5.3向上取整得到 6 层左右。实际实现时从 0 层到maxLevel编号每一层的缩放比例是1 / 2^level层内瓦片坐标按tileSize切分。内存预算要单独算。一个 512×512 的 RGBA 瓦片是512×512×41MB一个 256×256 瓦片是 256KB。假设给瓦片缓存 96MB512 瓦片最多放 96 张256 瓦片最多放 384 张。实际不能全用满还要留出缩略图、当前绘制缓冲和浏览器自身开销所以缓存上限可以按预算的 70% 到 80% 设置。我通常先定缓存预算再反推最大瓦片数而不是先定一个“缓存 200 张”的拍脑袋数字。参数常见起点说明瓦片边长256 或 512512 减少请求数单块内存更高256 更灵活适合移动端缩略图最大边1024 到 1600只负责占位和整体浏览不追求细节桌面瓦片缓存96MB 到 128MB512 瓦片约 96 到 128 张移动端瓦片缓存32MB 到 48MB低内存设备还要继续下调并发加载数4 到 6太高会抢占带宽和主线程太低首屏慢预加载圈数1 圈视口周边一圈足够太多会浪费流量解码 Worker 数2 到 4按设备核心数和单瓦片解码耗时调整层级计算还有一个细节不要直接把“当前缩放比例”当成层级因为浮点缩放和瓦片层级不是一一对应。比较稳的做法是维护一个scale渲染时选择“最接近且不小于当前显示精度”的层级再用drawImage缩放到目标尺寸。层级切换时保留上一层的瓦片作为过渡等新层覆盖率达到一定比例再替换避免缩放过程中出现大片空白。2.3 本地文件与远程图片的读取差异本地文件通过File或Blob读取好处是不受网络影响坏处是不能像远程 URL 那样直接按瓦片请求。Blob.slice(start, end)可以读字节区间但读出来的是压缩数据不等于一张可显示的图片。普通 JPEG 的字节流不是按二维区域排列的PNG 的IDAT也是压缩流随便切一段给浏览器解码只会失败。所以本地文件走“完整解码再切瓦片”时内存峰值躲不开要走真正的分块解码就得选支持分块结构的格式或者接入能按区域解码的 WebAssembly 模块。远程图片相对灵活。服务端可以预生成瓦片金字塔前端按level/x/y请求小图也可以提供支持Range的接口让前端读取文件头和必要字节。Range请求只能解决“少下载一点”不能解决“少解码一点”。如果服务端返回的是整张 JPEG前端拿到一段字节也没法直接显示局部。因此远程方案的重点不是前端多会切而是服务端有没有把图像预处理成可消费的瓦片或缩略图。还有跨域问题。瓦片请求、Range请求、Canvas 读取像素都可能受跨域限制。如果只是显示img带跨域属性通常够用如果要读像素做颜色分析就要服务端返回合适的跨域头。排查时先看网络面板的状态码和响应头再看控制台有没有跨域污染 Canvas 的报错。不要一上来改前端绘制代码很多“画不出来”其实是资源根本没拿到。3. 前端核心实现尺寸探测、缩略预览与瓦片渲染3.1 只读文件头拿到宽高避免整图解码做预览前先知道图片尺寸后面才能算缩放比例、瓦片层级和内存预算。直接new Image()加载整图再读naturalWidth当然可以但对几百MB文件来说代价太高。更稳的做法是只读文件前几百KB解析 PNG 的IHDR或 JPEG 的SOF段。下面是一个简化示例生产环境还要补异常分支、更多格式和边界检查。function readPngSize(buf) { if (buf.length 24) return null; const sig [137, 80, 78, 71, 13, 10, 26, 10]; for (let i 0; i 8; i) { if (buf[i] ! sig[i]) return null; } const dv new DataView(buf.buffer, buf.byteOffset, buf.byteLength); return { width: dv.getUint32(16), height: dv.getUint32(20) }; } function readJpegSize(buf) { let i 2; while (i 9 buf.length) { if (buf[i] ! 0xff) { i; continue; } const marker buf[i 1]; if (marker 0xd8 || marker 0x01 || (marker 0xd0 marker 0xd7)) { i 2; continue; } if (marker 0xda) break; const len (buf[i 2] 8) | buf[i 3]; const isSof marker 0xc0 marker 0xcf ![0xc4, 0xc8, 0xcc].includes(marker); if (isSof) { return { height: (buf[i 5] 8) | buf[i 6], width: (buf[i 7] 8) | buf[i 8] }; } i 2 len; } return null; } async function readImageSize(file) { const head new Uint8Array(await file.slice(0, 256 * 1024).arrayBuffer()); return readPngSize(head) || readJpegSize(head); }这段代码的意图很明确用最小读取量换取布局所需信息。读不到尺寸时再降级到createImageBitmap或Image但要有超时和错误提示。对于 TIFF 这类带目录结构的格式文件头解析会更复杂通常要读IFD偏移、标签数量和标签值建议交给专门的解析模块不要在主线程里手写一大坨。注意图片可能存在方向信息。手机拍摄或扫描设备生成的图片像素尺寸和显示方向可能不一致。预览时如果不处理方向会出现“宽高对上了但图是横的”。能使用解码器的方向选项就交给解码器不能使用就解析方向标签后在绘制时做旋转并且保证瓦片坐标也在同一套变换下计算。3.2 在 Worker 里用 createImageBitmap 做降采样预览低清预览的目标不是还原原图而是在可接受的内存里给用户一个整体视图。createImageBitmap支持在解码时指定目标尺寸适合做这件事。关键点是先算好保持宽高比的目标宽高再把它放进 Worker避免主线程被解码拖住。下面是一个示意实现实际使用时要把readImageSize也放进 Worker 或提前传给 Worker。// image-worker.js self.onmessage async (event) { const { file, maxEdge } event.data; try { const size await readImageSize(file); if (!size) throw new Error(无法读取图片尺寸); const scale Math.min(1, maxEdge / Math.max(size.width, size.height)); const width Math.max(1, Math.round(size.width * scale)); const height Math.max(1, Math.round(size.height * scale)); const bitmap await createImageBitmap(file, { resizeWidth: width, resizeHeight: height, resizeQuality: high }); const canvas new OffscreenCanvas(width, height); const ctx canvas.getContext(2d); ctx.drawImage(bitmap, 0, 0); bitmap.close?.(); const preview canvas.transferToImageBitmap(); self.postMessage({ preview }, [preview]); } catch (error) { self.postMessage({ error: String(error) }); } };主线程拿到preview后把它画到占位 Canvas 或作为ImageBitmap保存。这里要强调resizeWidth/resizeHeight不是所有环境都保证“先降采样再解码”有些实现可能仍然要处理完整解码数据只是输出变小。所以它不是几百MB大图的万能钥匙但在几十MB到一百多MB、像素尺寸没有夸张到离谱的场景里能明显降低后续绘制和缓存压力。真正的几百MB超大图还是要靠瓦片或服务端缩略图。如果环境不支持OffscreenCanvas可以退回主线程加setTimeout分片但体验会差一截。我的建议是把“是否支持 Worker 和 OffscreenCanvas”作为能力探测的一部分支持就走完整链路不支持就降级到更保守的预览尺寸比如最大边 800先保证不崩。3.3 OffscreenCanvas 绘制瓦片与 LRU 缓存瓦片渲染的核心是“源矩形到目标矩形”的映射。假设当前层级的瓦片在源图上覆盖sourceSize tileSize * 2^level的区域瓦片坐标是x/y那么源矩形就是sx x * sourceSize、sy y * sourceSize宽高都是sourceSize。目标位置则由视图的缩放和平移决定。下面是一个简化绘制函数假设手里已经有一张完整解码的ImageBitmap或离屏画布。const TILE 512; function drawTile(ctx, bitmap, tile, view) { const sourceSize TILE * Math.pow(2, tile.level); const sx tile.x * sourceSize; const sy tile.y * sourceSize; const sw Math.min(sourceSize, bitmap.width - sx); const sh Math.min(sourceSize, bitmap.height - sy); if (sw 0 || sh 0) return; const destX (sx - view.offsetX) * view.scale; const destY (sy - view.offsetY) * view.scale; const destW sw * view.scale; const destH sh * view.scale; ctx.drawImage(bitmap, sx, sy, sw, sh, destX, destY, destW, destH); }这段代码只适合“已经有完整位图”的场景比如本地文件已经完整解码一次、或者原图尺寸还在可控范围。真正按需加载时每个瓦片是独立的小图绘制时直接用drawImage(tileBitmap, destX, destY, destW, destH)不需要再从大图裁。两种模式的缓存键可以统一成level/x/y但缓存对象不同前者缓存的是绘制结果后者缓存的是瓦片位图。缓存建议用 LRU并且按字节而不是按张数限制。下面是一个够用的骨架生产环境还要处理并发、过期和正在加载的占位状态。class LRU { constructor(maxBytes, sizeOf) { this.maxBytes maxBytes; this.sizeOf sizeOf; this.map new Map(); this.bytes 0; } get(key) { if (!this.map.has(key)) return undefined; const value this.map.get(key); this.map.delete(key); this.map.set(key, value); return value; } set(key, value) { if (this.map.has(key)) { this.bytes - this.sizeOf(this.map.get(key)); this.map.delete(key); } this.map.set(key, value); this.bytes this.sizeOf(value); while (this.bytes this.maxBytes this.map.size 0) { const firstKey this.map.keys().next().value; const firstValue this.map.get(firstKey); this.map.delete(firstKey); this.bytes - this.sizeOf(firstValue); firstValue.close?.(); } } }注意ImageBitmap和离屏画布都可能占用显存或原生内存Map里删掉不等于立刻释放。能close()的对象要及时关闭尤其是切换大层级、关闭预览弹窗、重新选择文件时。缓存上限只是控制峰值不是垃圾回收器。3.4 远程大图用 Range 请求按块拉取远程大图如果服务端支持Range前端可以只取文件头或指定字节段减少首屏下载量。下面是最小示例重点看请求头和 206 状态判断。实际项目还要处理Content-Range、重试、超时和取消。async function fetchRange(url, start, end, signal) { const response await fetch(url, { signal, headers: { Range: bytes${start}-${end} } }); if (response.status ! 206) { throw new Error(服务端未返回分段内容); } return new Uint8Array(await response.arrayBuffer()); }Range适合做两件事读取图片头拿尺寸或者配合支持分块的格式读取瓦片字节。它不适合把普通 JPEG 随便切一段就当图片显示。判断服务端是否支持可以看响应头里有没有Accept-Ranges: bytes但最终以实际请求返回 206 为准。跨域场景下如果前端需要读取Content-Range服务端要允许暴露这个响应头否则浏览器里拿不到。远程瓦片更推荐直接用独立 URL比如/tile?level3x12y8每个 URL 返回一张小图。这样浏览器缓存、并发控制和错误重试都更自然前端不需要自己拆字节流。服务端可以预生成金字塔也可以按需裁剪但要有缓存避免每次请求都重新解码原图。4. 纯前端离线的硬骨头区域解码与分块格式4.1 JPEG/PNG 为什么不适合直接按区域解码普通 JPEG 的压缩数据按 MCU 块排列还带熵编码和扫描结构不是“左上角一块、右下角一块”的简单布局。随机读取某个区域的字节往往无法独立解码出完整像素需要从扫描起点开始处理。渐进式 JPEG 可以分阶段显示低清到清晰但最终仍然要处理大量数据内存不会因为“渐进”就变成按瓦片分配。PNG 的IDAT是压缩流按行滤波后再压缩想取某几行也要从压缩流开头解压随机区域读取并不划算。所以纯前端离线处理普通 JPEG/PNG 时现实做法通常是“完整解码一次再切瓦片缓存”。这能改善后续交互但首屏峰值内存仍然高。如果图片大到完整解码都过不去就要换思路要么让用户先看降采样预览要么使用支持分块的格式要么接入能在解码阶段做裁剪或缩放的 WebAssembly 模块。不要指望用Blob.slice切一段 JPEG 字节就能显示局部这个坑很常见。4.2 TIFF 分块/分条读取的实操思路TIFF 的结构比普通网页图片更适合大图分块。它的目录里可以记录TileWidth、TileLength、TileOffsets、TileByteCounts也可能使用按行分条的StripOffsets和StripByteCounts。前端解析这些标签后就能知道每个瓦片在文件中的字节偏移和长度按需读取并解码。扫描件、档案影像里这种格式并不少见做离线预览时值得优先支持。落地步骤可以分成四步第一读取文件头判断字节序找到第一个IFD偏移第二遍历标签拿到宽高、压缩方式、分块参数和偏移表第三根据当前视口计算需要的瓦片索引用file.slice读取对应字节段第四把字节段交给解码模块得到 RGBA 数据后画到离屏画布。下面只是伪代码重点是流程不是完整解析器。// 伪代码按需读取 TIFF 瓦片 async function loadTiffTile(file, meta, tileX, tileY) { const index tileY * meta.tilesAcross tileX; const offset meta.tileOffsets[index]; const byteCount meta.tileByteCounts[index]; const chunk file.slice(offset, offset byteCount); const rgba await decodeTiffTile(chunk, meta); return new ImageData(new Uint8ClampedArray(rgba), meta.tileWidth, meta.tileHeight); }这条路的难点在解码器不在切片。不同压缩方式、光度解释、位深、色差子采样都要处理自己从头写不现实。比较稳的策略是选一个可靠的 WebAssembly 解码模块把格式兼容性交给它前端只负责读偏移、调度和绘制。只支持未压缩或少数压缩方式也能覆盖一部分场景但要提前和业务确认素材范围不要等上线后才发现一批文件打不开。4.3 WASM 解码模块接入与线程模型WebAssembly 解码模块的价值在于把重计算从 JavaScript 主线程挪走并且能复用成熟的图像解码逻辑。接入时我最关注四件事输入输出内存怎么传、解码结果是不是 RGBA、能不能按缩放比例解码、异常时怎么释放。理想情况下Worker 里读取字节段调用模块解码到一块线性内存再把ArrayBuffer转移回主线程或直接在 Worker 里画到OffscreenCanvas。转移所有权比复制更省内存但要注意转移后原线程不能再访问。线程模型上不建议每个瓦片开一个 Worker。Worker 创建和模块初始化都有成本瓦片解码又很频繁最好是固定一个小型线程池比如 2 到 4 个 Worker用消息队列分发任务。每个任务带上level/x/y和取消标记用户快速拖拽时旧任务即使已经开始也可以在结果返回后丢弃避免把过期瓦片画到屏幕上。并发数不是越大越好解码本身吃 CPU 和内存开太多只会让整机变卡。注意WebAssembly 线性内存增长后不会自动缩回处理完一批超大瓦片后要观察内存曲线。如果模块支持重置或复用缓冲区就在任务批次结束时复用如果不支持宁可重建 Worker也不要让一个 Worker 长期持有巨大内存。5. 大图预览常见问题与排查技巧实录5.1 白屏、OOM、错位与颜色异常的排查顺序白屏先分三层查资源有没有拿到、解码有没有成功、绘制有没有发生。资源层看网络状态、跨域头、Range是否返回 206解码层看尺寸解析是否成功、createImageBitmap是否抛错、ImageBitmap的宽高是否为 0绘制层看 Canvas 上下文是否为空、画布尺寸是否超过设备上限、绘制坐标是否落在视口外。很多白屏不是图片坏了而是画布尺寸超限后上下文静默失效。OOM 一般来自四个地方缓存太大、重复解码、对象没释放、一次性画了整张大图。排查时先看峰值内存出现在首屏还是缩放时。首屏就高说明缩略图或首图解码太大缩放时高说明层级切换时同时保留了新旧两层瓦片或者缓存没有按字节限制。我的习惯是给缓存加一个调试面板实时显示当前瓦片数、估算字节数、正在加载数和命中率比盲猜有效得多。错位通常和坐标系有关。检查三件事瓦片源矩形是不是按tileSize * 2^level算的视图偏移是不是在同一个坐标系里设备像素比有没有重复乘。颜色异常则先看色彩空间和透明度再看解码器输出是 RGB 还是 RGBA、有没有预乘 alpha、通道顺序有没有搞反。TIFF 还要看光度解释和位深普通 JPEG 则要留意 CMYK 之类的特殊色彩模式。5.2 移动端低内存的降级策略移动端不能照搬桌面参数。我的降级顺序是先降缩略图最大边再降瓦片缓存再降并发再降设备像素比最后减少预加载圈数。比如桌面端缩略图 1600、缓存 128MB、并发 6移动端可以降到缩略图 1024、缓存 40MB、并发 3、DPR 上限 1.5。体验上会稍微糊一点但页面能稳住用户至少能完成浏览。还要监听页面可见性和内存压力。页面切到后台时可以清掉非当前层级的瓦片缓存关闭不再使用的ImageBitmap回到前台再按视口重新加载。低内存设备上不要一次性预加载太多层级预加载一圈就够用户快速滑动时再用占位图过渡。真正的低端机宁可让用户多点一次“查看高清”也不要在首屏把所有瓦片都拉下来。5.3 常见问题速查表现象高频原因排查动作处理建议首屏白屏尺寸解析失败、跨域、画布超限看资源状态、读宽高、打印画布尺寸先出缩略图画布设上限补错误提示页面崩溃或刷新整图解码内存过高、缓存无上限估算峰值内存记录缓存字节数改瓦片或降采样缓存按字节做 LRU缩放时卡顿每帧重绘整图、并发过高看帧率、看同时加载数只画视口瓦片限制并发层级过渡瓦片错位源矩形算错、DPR 重复乘打印瓦片坐标和源矩形统一坐标系DPR 只在画布尺寸处乘一次图片颜色不对通道顺序、透明度、色彩空间读一个像素对比原图统一输出 RGBA检查预乘 alpha局部模糊层级选低、缩略图被放大看当前层级和源瓦片尺寸提高层级补预加载限制最大放大倍数内存越用越高ImageBitmap未关闭、URL 未释放看缓存对象和对象 URL 数量及时close()和revokeObjectURL6. 一套可抄的参数起点与压测方法6.1 瓦片、缓存、并发与降采样参数如果你现在就要搭一个可用的版本我建议从这组参数起步瓦片 512缩略图最大边 1600桌面缓存 96MB移动端缓存 40MB并发 4预加载 1 圈解码 Worker 2 个DPR 上限 2。这套参数在大多数桌面浏览器上比较稳移动端也能跑。等压测数据出来再按实际瓶颈调。文字密集的扫描件可以把缩略图提高到 2048但缓存要相应下调地图类高频缩放场景可以把瓦片降到 256换取更细的加载粒度。层级策略上优先保证“当前视口所在层级”先加载其次是上一层作为过渡最后才是预加载。用户快速拖拽时取消视口外还没开始的请求避免队列里堆满过期任务。缓存键要包含层级和坐标不要只按图片 URL 缓存否则同一张图的不同瓦片会互相覆盖。缩略图单独放一个固定键不参与瓦片淘汰。6.2 上线前的压测清单与验收口径压测不要只拿一张“看起来很大”的图。准备三组样本一组是超大像素但压缩率高的图一组是文件几百MB的扫描件一组是长宽比极端的长图。每组都记录首屏可见时间、峰值内存、缩放帧率、瓦片命中率、失败率和恢复情况。首屏可见时间以“用户看到低清全貌”为准不以“高清瓦片全部加载完”为准峰值内存要看整个交互过程不只看加载完成那一刻。验收时我重点看三个指标第一连续缩放 30 秒不崩、不白屏第二快速拖拽时旧瓦片不会盖住新位置第三关闭预览后内存能明显回落。前两个是体验底线第三个是长期稳定性。很多页面首次打开没问题反复开关几次后内存越来越高最后整个页面变卡这就是对象没释放的典型表现。把释放逻辑写进关闭流程比事后靠垃圾回收靠谱。最后分享一个我踩过坑后固定下来的习惯任何大图预览功能都先做一个“只显示尺寸和缩略图”的最小页面。这个页面能稳定跑通再往上加瓦片、缓存和 Worker。大图问题往往不是某一个 API 用错而是内存、并发、坐标系和生命周期一起出问题。先把最小链路压稳后面的优化才有意义。