缩略图应优先用ImageOps.fit()实现居中裁剪，避免变形；处理透明图需转RGB并设背景色；大图并发需draft降内存，EXIF方向须exif_transpose修正。
缩略图裁剪前必须明确尺寸策略
直接调用 thumbnail() 或 resize() 很容易产出变形图——因为 Pillow 默认不裁剪，只等比缩放并填满目标框。真正“裁剪式缩略图”得自己控制坐标，否则用户上传的头像、商品图会拉伸失真。
-
thumbnail()是就地缩放，修改原图对象，且只保证长边匹配目标尺寸，短边留白；它不返回新图，也不裁剪 - 需要居中裁剪时，得先算出源图中心区域：用
Image.size和目标宽高反推左上角坐标，再用crop() - 常见错误是先
resize()再crop()，结果精度丢失严重；正确顺序是先crop()（按原始分辨率算坐标），再resize()到目标尺寸
用 ImageOps.fit() 一步到位做居中裁剪缩略图
这是最省心的方案，底层已封装好“先等比缩放至覆盖目标、再居中裁剪”的逻辑，比手算 crop() 坐标更可靠，也避免浮点误差导致边缘多/少 1 像素。
- 参数顺序是：
ImageOps.fit(image, size, method=Image.LANCZOS, bleed=0.0, centering=(0.5, 0.5)) -
method推荐用Image.LANCZOS（高质量下采样），别用默认的Image.NEAREST，尤其处理小图时锯齿明显 -
centering=(0.5, 0.5)表示以图像中心为锚点裁剪；若要顶部居中，改用(0.5, 0.0) - 注意：
fit()返回新Image对象，原图不受影响
from PIL import Image, ImageOps
img = Image.open("upload.jpg")
thumb = ImageOps.fit(img, (200, 200), Image.LANCZOS)
Web 场景下必须处理透明通道和格式兼容性
用户上传 PNG（带 alpha）或 WebP，直接转 JPEG 缩略图会报错或变黑——JPEG 不支持透明。这不是 Pillow bug，是格式限制，必须显式处理。
- 判断原图是否含 alpha：检查
img.mode是否为"RGBA"、"LA"或"P"（且 palette 含透明） - 转 JPEG 前，用
Image.convert("RGB")并指定背景色：img.convert("RGB", background=(255, 255, 255)) - 保存时注意
quality参数：Web 场景下quality=85是清晰度与体积的合理平衡点，低于 75 易见压缩噪点 - 不要依赖
img.format判断来源格式，它可能为None；用文件扩展名或imghdr.what()更稳妥
并发缩略图生成时内存和性能踩坑点
单次处理大图（比如 5000×4000）+ 多并发请求，很容易 OOM 或响应延迟飙升。Pillow 的 Image 对象在内存里是未压缩的 RGB 数据，一张 24MP 图占约 60MB 内存。
- 用
Image.load()触发解码后，立刻调用img.draft()预设采样模式，例如img.draft("RGB", (1024, 768))，能大幅降低初始内存占用 - 避免在循环里反复打开同一张图做不同尺寸缩略；先
open()一次，再多次fit()或resize() - GIL 会让 CPU 密集型缩略图操作无法真正并行；考虑用
concurrent.futures.ProcessPoolExecutor拆分任务 - 临时文件路径别写死
/tmp，Docker 容器里可能无写权限；用tempfile.mktemp()或直接内存操作（io.BytesIO）更稳妥
实际项目里最容易被跳过的，是上传图的 EXIF 方向信息——手机拍的照片常带 Orientation tag，Pillow 默认不自动旋转，结果缩略图横着显示。得在 open() 后立刻调用 ImageOps.exif_transpose(img)。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
