django的imagefield不自动压缩图片，需在模型save()中用pillow干预：仅新上传时重绘压缩为jpeg（quality=85），重置文件指针并保留扩展名，避免clean_image或pre_save处理。
Django 的 ImageField 本身不压缩图片，上传原图会直接存到存储后端——想减小体积，必须在保存前干预原始文件流。
用 Pillow 在 model save() 中覆盖 image 字段内容
这是最可控、兼容性最好的方式：在模型实例保存时，用 Pillow 重绘并压缩图片，再写回 image 字段的 InMemoryUploadedFile 或 ContentFile。
- 只对新上传生效（
instance.pk is None或not instance.image），避免重复压缩已有图片 - 务必指定
format='JPEG'和quality=85（或 75–90 区间），否则 PNG 不压缩，JPEG 可能丢 alpha 通道 - 调用
image.seek(0)重置文件指针，否则 Django 读不到内容，保存后文件为空 - 示例中用
BytesIO构造新文件对象，name属性必须保留原扩展名（如img.name.replace('.png', '.jpg')），否则ImageField可能拒绝保存
注意 upload_to 路径和 storage 后端的影响
压缩后的文件仍走 Django 默认的 FileSystemStorage 或自定义 storage，但路径生成逻辑不受影响；关键点在于：如果用了云存储（如 boto3），压缩必须在上传前完成——因为 save() 阶段文件还没发到 S3，仍有操作窗口。
-
upload_to返回的路径不影响压缩逻辑，但建议保持扩展名一致（如统一转 JPEG 后用.jpg后缀），避免 CDN 或浏览器解析异常 - 若使用
django-storages，确认其_save()方法不会绕过你构造的ContentFile，某些旧版本会强制读取原始文件句柄 - 本地开发用
FileSystemStorage时，压缩后文件体积下降明显（实测 2MB → 200KB），但要注意磁盘 I/O 增加，高并发上传需加锁或异步处理
别依赖表单 clean_image() 或 signal（比如 pre_save）
这两个位置做压缩容易出问题：表单 clean_image() 拿到的是原始 InMemoryUploadedFile，但模型保存时可能被其他逻辑覆盖；pre_save signal 中修改 instance.image 字段值，在 Django 4.2+ 中可能触发 ValueError: The 'image' attribute has no file associated with it。
-
clean_image()适合校验（如尺寸、格式），不适合改写文件内容——改了也白改，后续model.save()还是用原始文件 -
pre_save里调instance.image.save(...)会引发递归或状态错乱，Django 对字段赋值 + save 的耦合很紧 - 唯一稳妥时机就是重写模型的
save()方法，并确保只在必要时压缩（比如仅当self.image是新上传且未处理过）
真正难的不是压缩本身，而是判断“该不该压”——比如用户编辑已有记录时重新上传一张图，要压；但如果只是改了个标题，image 字段没变，就不能动。这个判断逻辑一旦漏掉，老图会被反复压缩变糊，或者新图被跳过没压。务必在 save() 开头加明确的条件检查，而不是靠 try/except 捕获。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
