直接结论：别用 uni.compressImage 做主压缩逻辑，它跨端行为不可控；优先用 Canvas 手动缩放 + DPR 适配，再配合质量参数微调，才能稳定压到 200KB 内且肉眼难辨失真。uni.compressImage 在各端 quality 含义不一，iOS 影响 JPEG 量化表、安卓常忽略、小程序强制转 JPEG 丢透明，且 compressedWidth/compressedHeight 仅为最大值而非目标尺寸；Canvas 必须按 DPR 设置物理像素宽高并匹配 drawImage 和 destWidth/destHeight 参数，否则高屏模糊；base64 直传 uni.uploadFile 会增大体积 30%，应传临时文件路径或转 Blob；“不失真”需真机放大验文字边缘与渐变过渡，体积目标建议 ≤200KB 并采用双 pass 缩放提升细节保留。
直接结论：别用 uni.compressImage 做主压缩逻辑，它跨端行为不可控；优先用 Canvas 手动缩放 + DPR 适配，再配合质量参数微调，才能稳定压到 200KB 内且肉眼难辨失真。
uni.compressImage 为什么不能当主力用
这个 API 表面简单，实际是黑盒：iOS、Android、微信小程序各自调用原生压缩引擎，quality 参数含义不一致。比如传 quality: 80，安卓可能直接忽略、按固定比例缩放，微信小程序会把 PNG 强制转 JPEG 导致透明丢失，iOS 则只影响 JPEG 的量化表。
-
sizeType: ["compressed"]返回的“压缩图”常和原图一样大，不是真压缩 -
compressedWidth/compressedHeight是最大允许值，不是目标尺寸，也不保证等比 - 返回路径可能是临时文件，但没做 DPR 适配，在高像素屏上画出来就是模糊块
Canvas 压缩必须处理 DPR 才不糊
在 iPhone 14 Pro（DPR=3）上直接画 800px 宽的 canvas，浏览器要靠插值放大到 2400 物理像素，必然发虚。关键不是“画多大”，而是“物理像素画多少、CSS 尺寸设多少、drawImage 传什么”。
- 先调
uni.getSystemInfoSync().pixelRatio拿当前 DPR - 创建 canvas 时，
width和height设为「目标 CSS 尺寸 × DPR」，例如目标 800×600 → canvas 物理尺寸设 2400×1800 - 同时设置
canvas.style.width = "800px"、canvas.style.height = "600px" -
ctx.drawImage(img, 0, 0, 800, 600)—— 这里传的是 CSS 尺寸，不是 canvas 物理尺寸 -
uni.canvasToTempFilePath的destWidth/destHeight必须填 800/600，否则输出图会被二次缩放
base64 路径传给 uni.uploadFile 会变大 30%
很多插件（如 uni-image-compress）默认返回 base64 字符串，如果直接把 base64 当作 filePath 传给 uni.uploadFile，H5 端会触发额外的 base64 → Blob 编码，体积反而更大。
- 错误写法：
compressImage().then(base64 => { uni.uploadFile({ filePath: base64 }) }) - 正确做法：确认插件是否支持生成临时文件路径（如
uni-file://xxx.jpg），只传这个路径 - H5 端若必须用 base64，得先转成 Blob：
dataURLtoBlob(base64)，再构造File对象传给自定义上传逻辑
压缩后怎么验证是不是真“不失真”
“不失真”是伪命题，所有前端压缩都有信息损失。所谓“肉眼难辨”，得在真机上放大看边缘锐度和灰阶过渡，不能只看缩略图。
- 重点对比区域：文字边缘、毛发/树叶纹理、渐变色过渡带
- 避免只在开发工具模拟器里验收，iOS 和安卓对 YUV 转 RGB 的实现差异会导致色偏（比如安卓上图片发紫）
- 体积目标建议设为 ≤200KB，再结合双 pass 缩放（先缩到 1.5× 目标尺寸，再缩到目标尺寸）提升细节保留度
