“不失真”是伪命题，uni-app压缩必有信息损失，但可控制至肉眼难辨且体积≤200KB；compressImage因多端实现差异易致糊、灰、色偏；canvas压缩须按DPR设置物理尺寸并正确配置style与draw参数；base64上传会增大体积，应使用临时文件路径；双pass缩放+高平滑质量可改善细节发虚；失真验证需真机放大对比边缘与灰阶。
“不失真”是伪命题，uni-app 前端压缩必然有信息损失；但你可以控制损失程度，让肉眼几乎看不出差别，同时把体积压到 200KB 以内。
uni.compressImage 压缩后图片糊、发灰、色偏？
这是最常被误用的 API。它底层调用的是平台原生压缩（iOS/Android 微信小程序各自实现），quality 参数在不同端行为不一致：iOS 可能只影响 JPEG，Android 可能忽略 quality 直接按固定比例缩放，而微信小程序甚至会把 PNG 强制转成 JPEG 导致透明通道丢失。
- 别依赖
compressed作为sizeType，它不可控 —— 真实场景中它常返回和原图一样大的“假压缩”文件 -
compressedWidth/compressedHeight不是目标尺寸，而是“最大允许宽高”，实际输出可能更小，且不保证等比 - 如果你传了
quality: 80，但在安卓上发现图片变紫/发亮，大概率是色彩空间转换出错（RGB → YUV → RGB 损耗）
canvas 压缩必须手动处理 DPR 才不模糊
直接用 canvas.drawImage 按 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 / height 为 '800px' / '600px'，再调用
drawImage时传入目标 CSS 尺寸（不是 canvas 物理尺寸） - 最后
uni.canvasToTempFilePath的destWidth/destHeight必须填 CSS 尺寸（如 800/600），否则输出图会被二次缩放
uni-image-compress 插件为什么上传后还是大？
这个 npm 包本质是封装了 canvas + Web Worker，但它默认输出的是 base64 字符串，不是文件路径。如果你直接把 base64 传给 uni.uploadFile，会触发额外编码开销，体积反而比原图还大 30%。
- 检查你是否用了
compressImage(...).then(base64 => {...})，然后把base64当作filePath传给上传 —— 这是错的 - 正确做法：插件内部生成的是临时文件路径（如
uni-file://xxx.jpg），必须等它 resolve 这个路径，再传给uni.uploadFile({ filePath: ... }) - 如果插件文档没明确说返回路径，大概率它只返回 base64，这时你应该改用
uni.getFileSystemManager().writeFile先落地为临时文件
压缩后尺寸达标但细节发虚？试试双 pass 缩放
单次 canvas 缩放到目标尺寸，尤其从 4000px 缩到 800px，高频细节会直接坍缩。更稳的做法是分两步：先缩到 1.5 倍目标尺寸，再缩到最终尺寸。
- 比如原始图 3840×2160，目标 800×450：第一遍缩到 1200×675，第二遍再缩到 800×450
- 每次缩放都用
ctx.imageSmoothingQuality = 'high'（H5 有效），小程序端需加image-rendering: -webkit-optimize-contrast到预览容器 - 对文字/线条图这类高对比内容，可尝试
ctx.filter = 'contrast(1.1)'在第二次 draw 前微调（仅 H5 支持）
真正难的不是“怎么压”，而是“压完怎么验”。上线前务必用真机拍一张带文字的图，压完后放大到 200% 对比原图，看“边缘锯齿”和“灰阶过渡”是否突兀 —— 这些才是失真的真实信号，不是文件大小说了算。
