Canvas压缩图片需按原始宽高比缩放，用naturalWidth/Height获取真实尺寸，限制长边缩放；iOS需解析EXIF Orientation并旋转校正；读取文件须在onload回调中处理；JPEG压缩优先于PNG以控体积。
Canvas 压缩图片时宽高设错导致模糊或拉伸
用 canvas 绘制并导出压缩图，最常踩的坑是没按原始宽高比缩放。比如直接把 img.naturalWidth 和 img.naturalHeight 硬设为 800×600，原图是竖构图就必然变形。
正确做法是先计算目标尺寸：保持比例的前提下，限制长边不超过指定值（如 1200px），再用 ctx.drawImage() 按新尺寸绘制。
- 用
img.naturalWidth和img.naturalHeight获取真实尺寸，别用img.width/img.height（可能被 CSS 或属性修改过） - 缩放后调用
canvas.toBlob(callback, 'image/jpeg', 0.8)，第三个参数控制质量，0.7–0.9 是画质和体积较平衡的区间 - 注意 iOS Safari 对
toBlob支持不一致，可 fallback 到toDataURL再转为 Blob
FileReader 读取失败或只读到空字符串
选中文件后调用 reader.readAsDataURL(file)，但回调里 reader.result 是空或 undefined，多数情况是没监听 load 事件，或者在事件外直接读取了 result —— 此时读取还没完成。
必须等 reader.onload = function() { ... } 触发后才能安全使用 reader.result。另外，FileReader 无法读取 file:// 协议下的本地路径（浏览器安全限制），仅适用于用户通过 选取的文件。
立即学习“前端免费学习笔记（深入）”；
- 务必在
reader.onload回调内处理结果，不要写成同步逻辑 - 读取大文件时可加
reader.onprogress显示加载状态，避免用户误以为卡死 - 读取失败时检查
reader.error，常见错误码如DOMException: Failed to execute 'readAsDataURL' on 'FileReader'通常意味着文件已被释放或权限问题
压缩后体积不降反升？JPEG 转 PNG 或元数据残留
用 canvas.toBlob(..., 'image/jpeg', 0.8) 导出，结果比原 PNG 还大，大概率是原图是 PNG（含透明通道），而 JPEG 不支持透明，浏览器会自动填充黑色背景并保留大量冗余像素；另一种可能是原图带 EXIF 信息（如拍照方向、GPS），canvas 绘制后默认不继承这些元数据，但若用 toDataURL 再手动构造 Blob，容易忽略清除。
更稳妥的方式是：明确目标格式 + 主动丢弃无用元数据。例如，只要缩略图，就强制转 JPEG；需要透明则用 PNG，但质量参数对 PNG 无效，得靠尺寸压缩和 canvas 像素处理来减体积。
- 原图是 PNG 且无需透明 → 转 JPEG，设置质量 0.7–0.8
- 原图是 JPEG 但体积大 → 先检查是否含大量 EXIF，可用
exif-js或服务端剥离，前端 canvas 本身不保留 EXIF - 避免用
toDataURL后再atob+Uint8Array构造 Blob，易引入编码错误和额外开销
移动端 iOS 图片旋转方向错乱
用户手机拍的照片上传后在 canvas 里横着或倒着，不是代码逻辑错，而是 iOS 默认把旋转信息写在 EXIF 的 Orientation 字段，而 canvas 绘制时完全忽略它，直接按原始像素阵列渲染。
必须手动读取并修正。可用 exif-js 解析 file 的 EXIF 数据，拿到 Orientation 值（常见 6=顺时针90°，8=逆时针90°），然后在 drawImage 前对 canvas 做 rotate() 和 translate() 变换。
- 不处理 Orientation 的后果：用户看到的是“歪”的预览图，压缩后依然歪
-
exif-js体积小（约 4KB），解析是同步的，适合前端轻量集成 - 注意 rotate 后 canvas 坐标系变化，需配合 translate 调整原点，否则图像会画到画布外
