应采用分块流式加载+离屏解码+瓦片渲染方案处理超大图：用fetch获取readablestream，按range请求分块读取；通过offscreencanvas和createimagebitmap异步解码；按视口lod动态加载512×512瓦片，限制驻留数量并及时释放资源。
不能直接用 fetch().then(res => res.blob()) 加载超大超高清图片——内存会瞬间爆满，Chrome 很可能直接崩溃或卡死。真正可行的路径是：用 fetch 获取可读流，按需分块解码像素，再逐片绘制到 Canvas 上，实现“边下载、边解码、边渲染”的渐进式平滑展示。
用 ReadableStream 分块拉取原始图像数据
服务端必须支持 Range 请求头（如 Nginx 配置 add_header Accept-Ranges bytes;），前端才能按需请求图片的某一段字节：
- 发起 fetch 时禁用缓存和重定向：
cache: 'no-store', redirect: 'error' - 不调用
response.arrayBuffer()或response.blob()，直接取response.body - 用
getReader()循环读取Uint8Array块，每块建议控制在 64–256KB（太大易卡顿，太小 HTTP 开销高） - 遇到网络中断或超时，用
AbortController主动中止，并记录已接收字节数，支持断点续拉
用 OffscreenCanvas + createImageBitmap 实现无阻塞解码
主线程不能等大图 decode 完才渲染，否则页面冻结。应把解码工作卸载到离屏 Canvas 和 Web Worker 中：
- 将接收到的完整二进制数据（拼接后的
Uint8Array）传入createImageBitmap(bytes)，它会在后台线程异步解码 - 解码成功后返回
ImageBitmap，可直接用ctx.transferFromImageBitmap()高效绘制到主 Canvas - 若图片过大（如 >10000×10000），先用
ImageBitmap#resizeTo缩放为适合视口的尺寸（如 2048×2048），再绘制 - 避免反复创建
ImageBitmap，对同一张图只解码一次，后续缩放/裁剪复用
按视口+LOD 分片绘制，实现平滑渐进渲染
不是一次性画整张图，而是把超大图逻辑切分为网格瓦片（tile），结合用户当前可视区域与缩放级别动态加载和绘制：
- 定义瓦片大小（如 512×512 像素），计算当前视口覆盖哪些瓦片索引
- 优先加载并绘制中心区域瓦片；边缘瓦片延迟 200ms 后加载，避免争抢带宽
- 缩放层级高（细节多）时，用原始分辨率瓦片；层级低（概览）时，用预生成的低清瓦片（服务端提供 /tiles/{z}/{x}/{y}.jpg）
- 每片绘制后立即触发
requestAnimationFrame，保持 60fps 渲染节奏，避免跳帧
内存与生命周期管控要点
超大图渲染极易引发内存泄漏或 OOM，必须主动管理资源：
- 每片
ImageBitmap使用完后，显式调用imageBitmap.close() - 离屏 Canvas 不再需要时，调用
offscreenCanvas.transferToImageBitmap()后释放引用 - 监听
visibilitychange和pagehide，暂停拉取与解码，释放未渲染瓦片 - 限制同时驻留的瓦片数量（如 ≤16 张），超出时按 LRU 策略卸载最久未用的
