Canvas toDataURL 生成 JPEG 体积过大时，应显式传入 number 类型质量参数（如0.75），配合降采样缩放尺寸，并避免 CSS 缩放；跨平台需注意 Safari 预处理差异，超大图须降分辨率防内存溢出。
Canvas toDataURL 生成的 JPEG 图片体积爆炸
直接调用 canvas.toDataURL('image/jpeg') 默认用 0.92 质量压缩，但对高分辨率 canvas（比如 2000×1500 以上）依然可能产出 3–5MB 的 JPEG。这不是 bug，是浏览器按规范做的“尽力而为”——它不关心你网页要不要上传、有没有带宽限制。
真正可控的只有质量参数，且必须显式传入第二个参数：toDataURL 的第二个参数才是质量值（0–1），不传或传错类型（比如字符串 '0.8'）会被忽略，退回到默认质量。
- 错误写法：
canvas.toDataURL('image/jpeg', '0.8')→ 字符串被丢弃，实际还是 0.92 - 正确写法：
canvas.toDataURL('image/jpeg', 0.8)→ 显式 number 类型 - 低于 0.5 后体积下降变缓，但噪点和色块明显；0.6–0.75 是多数场景的甜点区间
toDataURL 质量参数在不同浏览器表现不一致
Chrome 和 Edge 对 0.7 的压缩结果接近，但 Safari（尤其 iOS 16+）会悄悄提亮、增强对比度，导致同参数下文件更大、观感更“锐”，这不是 bug，是 WebKit 渲染管线对 JPEG 编码前预处理的差异。
如果你需要跨平台输出一致体积，不能只靠调质量参数，得配合降采样：
立即学习“前端免费学习笔记（深入）”；
- 先用
ctx.drawImage()把原 canvas 绘制到一个更小尺寸的临时 canvas 上（比如缩到 80% 宽高） - 再对这个小 canvas 调
toDataURL('image/jpeg', 0.75) - 避免用 CSS 缩放 canvas 元素——那只是显示变形，
toDataURL仍读取原始像素数据
导出超大 canvas 时内存溢出或卡死
当 canvas 像素超过 1000 万（比如 3840×2160），toDataURL 可能触发浏览器内存保护机制，在低端 Android 或旧版 Safari 直接返回空字符串或抛 DOMException: The operation is insecure 错误。
这不是权限问题，是浏览器拒绝分配过多内存做编码。稳妥做法是分块导出或降分辨率：
- 用
canvas.getContext('2d').getImageData()手动读像素太重，别碰 - 优先走
OffscreenCanvas+transferToImageBitmap+createImageBitmap流水线（仅 Chrome/Firefox 支持） - 最兼容方案：用
canvas.width /= 2; canvas.height /= 2;硬缩，并用ctx.imageSmoothingQuality = 'low'关掉抗锯齿（减少模糊计算开销）
想控制文件大小而非质量？得自己估算
toDataURL 不提供“目标 KB 数”接口，但你可以用二分试探法逼近：
- 先试
0.7→ 得到 base64 字符串 →atob(str).length算字节数 - 若超限（比如 >500KB），试
0.5；若远低于，试0.75 - 最多 4 次试探就能收敛到 ±50KB 内，比盲目设 0.3 更靠谱
- 注意：base64 编码后体积 ≈ 原始二进制体积 × 1.37，所以 500KB base64 ≈ 365KB 二进制
真正难的不是调参，是得在“用户要高清截图”和“手机上传失败”之间做判断——这个边界得你根据业务定，浏览器可不管。
