用pil（pillow）压缩最稳，因不依赖外部命令、跨平台且可控性强；上传与压缩必须分离，避免直接读取原图导致oom或超时——手机原图3–8mb经解码后内存可达100+mb，易触发容器被杀。
直接说结论：用 PIL（Pillow）做压缩最稳，不依赖外部命令、跨平台、可控性强；上传环节和压缩要分开处理，别在上传接口里直接读原始大图解码——容易 OOM 或超时。
为什么不能直接传原图再压缩？
用户上传的手机照片动辄 3–8 MB，request.files['image'].read() 会把整个二进制加载进内存，接着 Image.open() 解码成像素数组，内存占用可能飙到 100+ MB。线上服务常因这个操作触发容器 OOM kill。
实操建议：
- 先用
stream.read(1024)检查文件头，确认是 JPEG/PNG（避免恶意伪造 MIME） - 用
BytesIO包裹流，传给Image.open()，但立刻调用.load()前加img.draft('RGB', (1200, 1200))降低解码开销 - 压缩逻辑必须设硬性尺寸上限（如最大宽/高 1920）和质量上限（
quality=85），否则小图反而被拉伸模糊
Image.save() 的 optimize 和 progressive 到底要不要开？
这两个参数只对 JPEG 有效，且效果高度依赖输入图特征：
-
optimize=True：重排 Huffman 表，通常省 5–10% 体积，但耗 CPU；若已用quality=75–85，收益极小，可关 -
progressive=True：生成渐进式 JPEG，浏览器能边下边显示；但部分老旧 CDN 或微信客户端解析失败，生产环境建议关闭 - 务必显式指定
subsampling='keep'，否则 Pillow 默认转成'4:2:0'，导致色度抽样失真（尤其文字截图）
推荐写法：img.save(output, format='JPEG', quality=82, subsampling='keep')
上传前压缩 vs 上传后压缩？选哪个？
必须选「上传后压缩」。前端 JS 压缩（如 canvas.toBlob()）不可靠：iOS Safari 对大于 4096×4096 的 canvas 报错；Android WebView 色彩空间处理混乱；且无法校验用户是否绕过前端直接发原图。
正确链路：
- 后端接收 multipart/form-data，用
werkzeug.FileStorage或fastapi.UploadFile获取原始流 - 用
Image.open(BytesIO(file_bytes)).convert('RGB')统一转 RGB（PNG 透明通道要处理） - 按目标尺寸计算缩放比例，用
Image.LANCZOS重采样（比BILINEAR锐利，比LANCZOS快） - 输出前检查
output.getbuffer().nbytes，若仍 > 2MB，再降一次quality到 72 并重试
常见报错和绕过方式
DecompressionBombError：Pillow 默认限制解码像素数（防内存炸），遇到 12MP 以上图必报。解决方法是临时提高阈值：
from PIL import Image Image.MAX_IMAGE_PIXELS = 1000000000 # 允许 10 亿像素（谨慎设）
但更安全的做法是先用 img.size[0] * img.size[1] > 25000000 主动拒绝超大图，返回 400 Bad Request。
其他典型问题：
-
IOError: cannot write mode RGBA as JPEG→ 先img = img.convert('RGB')，或用Image.alpha_composite()合成白底 - 上传 GIF 动图被静帧化 → 显式判断
img.format == 'GIF'，跳过压缩或转为 APNG（需额外库） - EXIF 旋转信息丢失 →
ImageOps.exif_transpose(img)必须放在open之后、任何 resize 之前
真正麻烦的不是压缩算法本身，而是图像元数据、色彩空间、设备兼容性这些隐形坑。上线前一定拿 iPhone 实拍图、安卓截图、单反 RAW 导出图、微信转发图各测一遍。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
