Canvas + localStorage 极限压测崩溃临界点需分层验证：先测toDataURL生成能力（≤200万像素安全），再测localStorage写入稳定性（≤2MB/item），最后验跨会话读取还原完整性，受画布尺寸、格式、浏览器版本及设备内存动态影响。
识别 Canvas + localStorage 极限压测表现与崩溃临界点，核心在于分层验证：先测单次 toDataURL 生成能力，再测 localStorage 写入稳定性，最后看跨会话读取还原是否完整。这不是一个固定数值，而是受画布尺寸、图像格式、浏览器版本、设备内存共同影响的动态边界。
一、Canvas.toDataURL 的实际崩溃阈值
toDataURL 不是“越大越慢”，而是存在明确像素量级断点：
- 安全区间：≤ 200 万像素（如 1280×1560）——多数浏览器可稳定生成 PNG，耗时
- 风险区间：200–800 万像素（如 2560×3000）——Chrome 可能卡顿 1–3 秒，Firefox 易返回空字符串 ""，Safari 常静默失败
- 崩溃临界点：＞ 800 万像素（如 4000×2500）——Chrome 触发 “Aw, Snap!”；Edge 直接抛 DOMException；移动端 Safari 多数直接白屏或 tab 崩溃
⚠️ 注意：该阈值与是否跨域污染强相关。一旦 canvas 被污染（drawImage 过未带 CORS 的远程图），即使 100×100 像素也会返回空字符串，必须前置检测：canvas.toDataURL() === "data:," 或捕获异常。
二、LocalStorage 存储的隐性瓶颈
表面看是“5MB 限制”，但真实瓶颈更早出现：
- Base64 膨胀：PNG 原始像素数据经 base64 编码后体积扩大约 33%，一张 3MB 的原始 PNG 存入 localStorage 后实际占 ~4MB 字符串
- 写入延迟突增点：当单个 key 值 > 2.5MB 时，Chrome 的同步写入可能阻塞主线程超 500ms；Firefox 在 > 3MB 后开始丢帧
- 实际可用上限建议：≤ 2MB / item（即推荐 canvas 尺寸控制在 1600×1200 PNG 或 2000×1500 JPEG@0.8）
验证方法：用 performance.now() 包裹 setItem，连续写入不同大小快照，记录耗时跳变点；同时监听 window.onstorage 确认是否真正落盘（部分低端安卓 WebView 会静默截断）。
三、还原绘制阶段的失效信号
即使存成功，读取还原也可能无声失败：
- Image 加载失败：base64 字符串过长（> 1.5M）时，
img.src = 'data:image/...'在 iOS Safari 中会触发img.onerror，但无具体错误码 - drawImage 渲染异常：若还原时 canvas 尺寸大于原始绘制尺寸，且未重设
ctx.imageSmoothingEnabled = false，会出现模糊或偏移，误判为“数据损坏” - 最可靠验证方式：还原后立即调用
ctx.getImageData(0,0,1,1)，检查左上角像素 RGBA 是否非全零；再比对还原前后canvas.toDataURL().length差值是否
四、压测建议操作路径
不靠猜测，用代码实测：
- 构造渐进式画布：从 512×512 开始，每次 ×1.3 倍宽高，生成纯色噪点图（避免压缩干扰）
- 逐档执行：
toDataURL→ 记录长度与耗时 →localStorage.setItem→localStorage.getItem→ 创建 Image → onload 中drawImage→ 校验像素 - 关键断点标记：首次出现
toDataURL() === ""、首次setItem耗时 >800ms、首次img.onload不触发、首次还原后getImageData报错
真实压测中，90% 的“崩溃”其实发生在第 2 步（存储）和第 4 步（还原），而非第 1 步（生成）。重点盯住控制台 warning：如 “Failed to execute ‘toDataURL’ on ‘HTMLCanvasElement’: Tainted canvases may not be exported.” 或 “The provided value is too large” —— 这些就是临界已到的明确信号。
