toBlob()比toDataURL()更适合上传前压缩，因其直接生成Blob对象、体积小、内存占用低、不触发Base64膨胀；而toDataURL()同步阻塞、生成字符串体积比原图大33%、易致卡顿或OOM。
canvas.toBlob() 比 toDataURL() 更适合上传前压缩
直接用 toDataURL() 生成 base64 字符串，体积比原始二进制大 33%，上传慢、内存占用高，大图（比如 8MB 手机原图）容易卡死甚至 OOM。而 toBlob() 直接产出 Blob 对象，可塞进 FormData 直传，不经过字符串中转。
常见错误现象：toBlob(callback, 'image/jpeg', 0.7) 对 PNG 文件无效——PNG 不支持质量参数，会忽略 0.7，仍输出无损图，体积几乎不变。
- 统一转成
'image/jpeg'再压缩，体积下降最明显；需保留透明通道时才选 PNG，并靠缩放降质 - 质量值建议设在
0.6–0.8：低于0.5易出明显色块，高于0.8体积减少微乎其微 - 调用必须写成
canvas.toBlob(blob => { /* 上传逻辑 */ }, 'image/jpeg', 0.7)，不能漏掉回调函数
按最长边等比缩放，不是固定宽高
硬写 canvas.width = 800; canvas.height = 600; 会导致人像拉伸、文字变形。正确做法是限制“最长边 ≤ 1200px”，保持原始宽高比。
计算方式很简单：const scale = Math.min(1200 / img.width, 1200 / img.height);，再用它算目标尺寸：canvas.width = img.width * scale;，canvas.height = img.height * scale;
立即学习“前端免费学习笔记（深入）”；
- 不缩放只调质量，4000×3000 图压缩后可能还有 2MB；缩到最长边 1200 后，同样质量通常压到 300KB 以内
- iOS 拍照带 EXIF 朝向信息，
img加载后宽高可能是旋转后的，需解析 EXIF 或用orientation标记处理，否则缩放错位 - Canvas 尺寸超浏览器限制（如 Chrome 最大 32767px）会静默失败，务必加
if (targetWidth > 1920 || targetHeight > 1920)安全兜底
FileReader 加载大图要防 OOM
FileReader.readAsDataURL() 会把整张图加载进内存，10MB 照片在低端安卓机上极易触发内存溢出。这不是代码写错了，是机制限制。
实操中必须做两件事：一是校验文件类型和大小，二是把压缩逻辑严格放在 img.onload 回调里。
- 监听
input[type="file"]的change事件后，先检查file.size < 10 * 1024 * 1024（10MB），超了就提示用户“请选小图” -
img.src = reader.result后，绘图操作必须等img.onload触发——过早调drawImage()，canvas 是空的 - 本地文件无跨域问题，但若后续改成加载远程图（如 URL 预览），得提前加
img.crossOrigin = 'anonymous'，否则 canvas 被污染无法导出
压缩后尺寸和体积必须双达标
很多工具只调质量或只缩尺寸，结果出现“压缩后比原图还大”的尴尬。规范要求：压缩后图片的像素尺寸和文件体积都必须小于原图。
尤其是 PNG，哪怕选“高质量 PNG”，也得强制走缩放路径——因为无损压缩本身不减体积，只有降低分辨率或转 JPEG 才真有效。
- 上传前用
file.size记下原图体积，压缩后用blob.size对比，不达标就重试（比如再降 0.1 质量或再缩 10%） - 输出格式选 JPEG 时，
toBlob()的 MIME 类型必须写成'image/jpeg'，写成'image/jpg'会被当成 PNG 处理，质量参数失效 - 移动端 Safari 对
toBlob()支持较晚，iOS 13.3+ 才稳定，老版本需 fallback 到toDataURL()+ 前端截断 base64 再转 Blob
