前端处理几百MB大图预览，第一个要改掉的直觉就是把文件地址塞进img等它自己显示。文件几百MB只是表面，真正压垮浏览器的是解码后的像素内存、主线程解码耗时、Canvas 纹理上限和频繁重绘。尤其扫描件、设计稿、长图、地图切片这类素材，尺寸动辄一两万像素起步，直接预览很容易白屏、卡死，移动端甚至直接刷新页面。这个主题适合正在做内容管理、档案预览、在线设计审阅、图像工具的前端开发者，也适合刚接触大图加载、想搞清楚“为什么不能直接img”的同行。下面我按实际项目里的取舍，把几百MB大图预览从算账、选型到代码落地拆一遍。

1. 几百MB大图预览为什么不能直接交给 img

1.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包住 Canvas，Canvas 尺寸跟随容器和设备像素比，但设备像素比要设上限。移动端高刷屏的devicePixelRatio可能到 3，如果容器是 1200×800，实际画布就是 3600×2400，内存和绘制量都会上去。我的做法是把有效 DPR 限制在 2 以内，极端低端设备限制在 1.5，肉眼差异没有想象中大，流畅度收益更明显。

2.2 瓦片金字塔的层级、瓦片数和内存预算

瓦片金字塔的核心是“每一层缩小一半”。假设原图最大边是maxSide，瓦片边长是tileSize，最顶层只需要一张或几张瓦片覆盖全图，最底层是原图。层级数量可以用ceil(log2(maxSide / tileSize))估算。比如最大边 20000，瓦片 512，20000/512≈39，log2(39)≈5.3，向上取整得到 6 层左右。实际实现时从 0 层到maxLevel编号，每一层的缩放比例是1 / 2^level，层内瓦片坐标按tileSize切分。

内存预算要单独算。一个 512×512 的 RGBA 瓦片是512×512×4=1MB，一个 256×256 瓦片是 256KB。假设给瓦片缓存 96MB，512 瓦片最多放 96 张，256 瓦片最多放 384 张。实际不能全用满，还要留出缩略图、当前绘制缓冲和浏览器自身开销，所以缓存上限可以按预算的 70% 到 80% 设置。我通常先定缓存预算，再反推最大瓦片数，而不是先定一个“缓存 200 张”的拍脑袋数字。

层级计算还有一个细节：不要直接把“当前缩放比例”当成层级，因为浮点缩放和瓦片层级不是一一对应。比较稳的做法是维护一个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?level=3&x=12&y=8，每个 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 常见问题速查表

6. 一套可抄的参数起点与压测方法

6.1 瓦片、缓存、并发与降采样参数

如果你现在就要搭一个可用的版本，我建议从这组参数起步：瓦片 512，缩略图最大边 1600，桌面缓存 96MB，移动端缓存 40MB，并发 4，预加载 1 圈，解码 Worker 2 个，DPR 上限 2。这套参数在大多数桌面浏览器上比较稳，移动端也能跑。等压测数据出来，再按实际瓶颈调。文字密集的扫描件可以把缩略图提高到 2048，但缓存要相应下调；地图类高频缩放场景可以把瓦片降到 256，换取更细的加载粒度。

层级策略上，优先保证“当前视口所在层级”先加载，其次是上一层作为过渡，最后才是预加载。用户快速拖拽时，取消视口外还没开始的请求，避免队列里堆满过期任务。缓存键要包含层级和坐标，不要只按图片 URL 缓存，否则同一张图的不同瓦片会互相覆盖。缩略图单独放一个固定键，不参与瓦片淘汰。

6.2 上线前的压测清单与验收口径

压测不要只拿一张“看起来很大”的图。准备三组样本：一组是超大像素但压缩率高的图，一组是文件几百MB的扫描件，一组是长宽比极端的长图。每组都记录首屏可见时间、峰值内存、缩放帧率、瓦片命中率、失败率和恢复情况。首屏可见时间以“用户看到低清全貌”为准，不以“高清瓦片全部加载完”为准；峰值内存要看整个交互过程，不只看加载完成那一刻。

验收时我重点看三个指标：第一，连续缩放 30 秒不崩、不白屏；第二，快速拖拽时旧瓦片不会盖住新位置；第三，关闭预览后内存能明显回落。前两个是体验底线，第三个是长期稳定性。很多页面首次打开没问题，反复开关几次后内存越来越高，最后整个页面变卡，这就是对象没释放的典型表现。把释放逻辑写进关闭流程，比事后靠垃圾回收靠谱。

最后分享一个我踩过坑后固定下来的习惯：任何大图预览功能，都先做一个“只显示尺寸和缩略图”的最小页面。这个页面能稳定跑通，再往上加瓦片、缓存和 Worker。大图问题往往不是某一个 API 用错，而是内存、并发、坐标系和生命周期一起出问题。先把最小链路压稳，后面的优化才有意义。