“不失真”是伪命题，uni-app前端压缩必有信息损失，但可控制至肉眼难辨且体积≤200kb；compressimage的quality非统一质量值，ios仅影响jpeg、android常忽略、小程序强制转jpeg丢透明通道，maxwidth仅为最大允许宽而非目标宽，实际输出不等比且尺寸不确定；canvas压缩须按dpr设物理尺寸并正确配置style与draw参数；base64上传会增大体积，应使用临时文件路径；双pass缩放+高平滑质量可改善细节发虚；失真验证需真机放大对比边缘与灰阶。
“不失真”是伪命题，uni-app 前端压缩必然有信息损失；但你可以控制损失程度，让肉眼几乎看不出差别，同时把体积压到 200KB 以内。
uni.compressImage 的 quality 和 maxWidth 到底怎么设？
很多人以为 quality: 80 就是“80% 质量”，其实它在不同端行为差异极大：iOS 可能只影响 JPEG，Android 可能忽略 quality 直接按固定比例缩放，微信小程序甚至会把 PNG 强制转成 JPEG 导致透明通道丢失。
-
maxWidth不是目标宽，而是“最大允许宽”——实际输出可能更小，且不保证等比（比如原图 4000×3000，设maxWidth: 1200，结果可能是 1200×900，也可能是 1197×898） -
compressedWidth/compressedHeight是压缩后真实尺寸，但不能用来做质量判断——它只是结果反馈，不是可控参数 - 别用
sizeType: ['compressed']依赖系统压缩，它常返回和原图一样大的“假压缩”文件
canvas 压缩必须手动处理 DPR，否则必糊
直接用 CSS 像素画图，在 iPhone 14 Pro 这类 3x 屏上会严重模糊——因为你画的是 800px 宽的 canvas，但设备需要 2400 物理像素来渲染，浏览器只能插值放大。
- 先调
uni.getSystemInfoSync().pixelRatio拿当前 DPR - 创建 canvas 时，
width/height设为「目标 CSS 尺寸 × DPR」，比如要输出 800×600，DPR=3 就设 canvas 为 2400×1800 - 再设置
canvas.style.width/style.height为'800px'/'600px' -
drawImage传入的宽高必须是 CSS 尺寸（800/600），不是 canvas 物理尺寸 -
uni.canvasToTempFilePath的destWidth/destHeight必须填 CSS 尺寸，否则输出图会被二次缩放
base64 上传反而更大？那是没用对路径
很多项目用 uni-image-compress 插件后上传体积不降反增，根本原因是把 base64 字符串当 filePath 传给了 uni.uploadFile —— 这会触发额外编码开销，体积增大 30%。
- 插件默认输出的是 base64 字符串，但你必须让它生成临时文件路径（如
uni-file://xxx.jpg） - 检查插件文档是否支持
returnPath: true或类似选项，确保 resolve 出来的是文件路径，不是 base64 - 上传时传
filePath: res.tempFilePath，而不是filePath: 'data:image/jpeg;base64,...' - H5 端若必须用 base64，应走
Blob → FileReader → result链路，避免 canvas.toDataURL 二次编码
双 pass 缩放 + 高平滑质量才能保住细节
单次缩放到目标尺寸，边缘容易发虚、灰阶断层。真机放大看边缘锯齿和色阶过渡，才是失真验证的唯一标准。
- 第一遍缩放到目标尺寸的 1.5 倍（比如目标 800px，先缩到 1200px），用
ctx.imageSmoothingQuality = 'high' - 第二遍再缩到最终尺寸（800px），同样启用高平滑
- 避免直接从 4000px 一步缩到 800px —— 插值误差会累积
- JPEG 格式下，
quality设 0.75～0.85 是性价比拐点，再往上体积陡增但观感提升极小
真正难的不是写压缩逻辑，而是每次改参数都要真机放大对比边缘与灰阶——模拟器和开发工具看不到真实失真。
