canvas 处理大图片性能瓶颈在于内存与渲染压力，需分块绘制、缩略图先行、dpr适配、离屏分层：分1024×1024块加载绘制并释放引用；先生成1024px缩略图交互，再反向映射裁剪坐标；canvas内在尺寸按devicepixelratio缩放并调用ctx.scale；静态内容预渲染，动态元素分层叠加；导出前revokeobjecturl，批量设置绘图状态。
Canvas 处理大图片时，性能瓶颈往往不是“画不出来”，而是“画得慢、卡顿、甚至崩溃”。关键不在 canvas 本身，而在如何规避浏览器内存限制和渲染压力。核心策略是：不加载全图、不分帧就崩、不缩放就糊。
分块绘制：避免内存溢出的硬性手段
几千万像素的图片（如 8000×6000）直接 drawImage 到单个 canvas，极易触发 OOM（Out of Memory）。分块处理不是“锦上添花”，而是必须执行的降载步骤：
- 将原图按固定尺寸（如 1024×1024）划分为多个区域，逐块加载、绘制、导出
- 每块绘制完成后，显式释放 img 对象引用：img = null，防止内存累积
- 使用 createObjectURL(file) 获取临时地址，而非 base64 字符串，减少内存拷贝开销
- 块间坐标需统一映射——所有分块共享同一套逻辑坐标系，避免拼接断层
缩略图先行：交互与裁剪分离
用户看到的不是原图，而是一张可控尺寸的缩略图。所有拖拽、框选、缩放操作都在这张图上完成，大幅降低实时渲染压力：
- 加载后立即计算缩放比：const scale = Math.min(1024 / img.naturalWidth, 1024 / img.naturalHeight, 1)
- 用中间 canvas 绘制缩略图（如 1024×1024），后续所有 UI 交互基于此图
- 真实裁剪坐标需反向映射回原图：sx = x / scale，sw = width / scale，确保精度不丢失
- 最终输出只拉取原图中目标区域，不加载其余像素
DPR 适配与渲染节流
高分屏（iPhone、MacBook Pro）下，canvas.width/height 若未按 devicePixelRatio 缩放，要么模糊，要么爆内存：
- CSS 尺寸设为逻辑像素（如 canvas.style.width = '100%'），内在尺寸按 DPR 计算：canvas.width = rect.width * Math.min(dpr, 2)
- 绘图前调用 ctx.scale(dpr, dpr)，让坐标系统自动适配物理像素
- 鼠标/触摸事件坐标换算后仅用于定位，真正传给 drawImage 的源坐标仍基于原图分辨率，与 DPR 无关
- 高频操作（如连续拖拽）用 requestAnimationFrame 节流，避免重复重绘
离屏与分层：结构化提升吞吐效率
把“画什么”和“怎么画”拆开，是高性能图像处理的底层逻辑：
- 用 offscreenCanvas 或动态创建的临时 canvas 预渲染静态内容（如背景、网格、文字），再一次性 drawImage 到主 canvas
- 对动态元素（如选区框、实时预览）单独建一层 canvas 叠加，避免整画布重绘
- 导出前清理资源：URL.revokeObjectURL(url)，防止临时地址长期驻留内存
- 避免在循环中反复设置 ctx.fillStyle、lineWidth 等状态，批量设置后再统一绘制
