uni.compressImage三端行为不一：H5静默失败，微信小程序无实现需用wx.compressImage（无质量参数），App端quality实为最大边长；canvas压缩是唯一跨端可控方案。
别直接调 uni.compressImage，它在 H5 和微信小程序根本不管用，App 端的 quality 参数还容易被误解为“压缩率”，实际是最大边长——不加判断就用，上传后文件反而更大。
uni.compressImage 在各端到底怎么 behave
这个 API 表面统一，实则三端分裂严重：
- H5 端：
uni.compressImage完全无实现，调了就静默失败（不报错也不走 success） - 微信小程序端：压根没这个 API，uni-app 的封装只是空函数，必须用
wx.compressImage，但该接口不暴露质量参数，只能靠尺寸缩放 - App 端（iOS/Android）：
quality: 80不是质量值，而是“长边最大像素”，比如传1000就等价于把宽或高缩到 1000px，系统自动选 JPEG + 默认质量（约 0.8），无法精准控体积 - iOS 特别坑：原始图宽高任一超过 4096px，
compressImage可能直接跳过压缩，返回原图路径
canvas 压缩才是跨端真正可控的方案
手动 canvas 绘制 + toDataURL 是目前唯一能同时兼顾 H5、小程序、App 且参数可精确控制的方式：
- 先用
uni.getImageInfo拿到原始width/height，按目标宽度（如 1200px）等比缩放画布尺寸 -
ctx.drawImage时传入缩放后的宽高，避免拉伸失真 -
canvas.toDataURL("image/jpeg", quality)的quality仅对 JPEG 生效；PNG 忽略第二个参数，若强制转 JPEG 会丢透明通道 - H5 下
toBlob兼容性差，优先用toDataURL得 base64，上传时记得设 header：{"Content-Type": "image/jpeg"} - 质量系数建议动态设置：原图 >2MB →
0.6；500KB–2MB →0.75；
上传前必须校验压缩结果，否则服务端拒收
压缩不是目的，上传成功才是。很多线上 bug 都源于没验证压缩输出：
- 用
uni.getFileInfo检查压缩后临时文件大小，若仍超限（如 >2MB），需降 quality 或再缩尺寸 - 不要假设
compressedWidth和compressedHeight一定生效——App 端只认quality作为 max dimension，其他参数被忽略 - 微信小程序里，
uni.chooseImage({sizeType: ["compressed"]})返回的所谓“压缩图”，其实是系统相册自带的低清缩略图（常只有 300px 宽），不能当质量压缩用 - 上传前把 base64 字符串长度粗略换算成字节数（
base64.length * 0.75），避免 header 超长或服务端解析失败
最易被忽略的一点：canvas 压缩必须等 ctx.draw 完成后再调 uni.canvasToTempFilePath，而小程序中 draw 是异步的，不加 setTimeout 或 Promise 包装，大概率拿到空白图。App 和 H5 虽然部分支持同步 draw，但写法不统一，建议一律按异步流程处理。
