uni-app 的 compressImage 仅在 App 端有效，H5 和微信小程序需用 canvas 手动压缩；App 端 quality 参数表示最大边长而非质量，误用会导致压缩失败或文件变大。
uni-app 里 compressImage 压缩不生效？先看平台限制
uni-app 的 compressImage API 在不同端行为差异极大，不是“调了就压缩”。H5 端完全不支持该 API；App 端（iOS/Android）依赖原生能力，但 iOS 上若图片宽高超过 4096，可能直接跳过压缩；微信小程序端则根本不存在这个 API——它用的是 wx.compressImage，而 uni-app 的封装并未透出压缩参数控制权。
所以别一上来就调 compressImage，先查运行环境：
-
uni.getSystemInfoSync().platform是"app"才能放心用compressImage - H5 必须自己用 canvas +
toDataURL手动压缩 - 微信小程序得走
uni.chooseImage→uni.uploadFile，中间用canvas或第三方库（如jpeg-js）做压缩
canvas 压缩在 H5 和小程序都可用，但质量参数别写死
手动 canvas 压缩是跨端最稳的方案，但 toDataURL("image/jpeg", 0.8) 这个 0.8 不是“压缩率”，而是“质量系数”，且仅对 JPEG 生效。PNG 不认第二个参数，强制转成 JPEG 才能压，但会丢透明通道。
实操建议：
- 先用
uni.getImageInfo拿到原始width/height，按目标尺寸（比如 1200px 宽）等比缩放 canvas，再 drawImage - 压缩质量建议动态设：大图（>2MB）用 0.6，中图（500KB–2MB）用 0.75，小图直接传原图
- 注意 H5 下
canvas.toBlob兼容性差，优先用toDataURL转 base64，再用uni.uploadFile上传（别忘了header["Content-Type"] = "image/jpeg"）
App 端用 compressImage 传参不对，压缩后反而更大
很多人传 {quality: 30}，以为数字越小越小，结果文件变大。因为 quality 在 App 端实际是“最大边长”（单位 px），不是质量值。官方文档写得模糊，但实测：传 1000 就是把长边缩到 1000px，系统自动选 JPEG 格式和默认质量（约 0.8），此时文件大小取决于原图分辨率，不是你想要的“高压缩比”。
正确做法：
- 明确目标：是要控尺寸（用
quality当 maxDimension），还是要控体积（必须自己 canvas 处理） - 如果真要体积小，App 端也得 fallback 到 canvas 方案，别迷信
compressImage - 调用前加判断：
if (platform === 'app') { uni.compressImage(...) } else { useCanvas() }
上传前没校验压缩结果，导致服务端拒收或二次处理失败
压缩不是目的，上传成功才是。常见坑是：canvas 压缩后还是超 5MB（微信限制），或者格式变成 webp（部分安卓机返回 webp，但服务端不认），又或者 base64 字符串太长，uni.uploadFile 的 filePath 参数误传成 data URI 而非临时路径。
关键检查点：
- 压缩后用
uni.getFileInfo查最终 size（H5 下需 base64 → blob →size） - 强制统一输出格式：canvas draw 后用
toDataURL("image/jpeg")，避免 webp 或 png - 上传时
filePath必须是临时路径（H5 下用uni.uploadFile({filePath: 'data:image/jpeg;base64,...'})是错的，得转 blob 再 createObjectURL）
跨端图片压缩没有银弹。canvas 是最可控的，但得自己管尺寸、格式、质量、体积；compressImage 看似省事，只在 App 端有效，且参数含义反直觉。最容易被忽略的是：上传前不验证压缩产物的真实 size 和 mime 类型，结果卡在服务端校验那一关。
