批量调整图片尺寸前必须检查的三个前提是：路径需用pathlib.Path处理以避免中文或空格导致的FileNotFoundError；文件扩展名须小写并显式过滤，因Linux区分大小写；含ICC配置或透明通道的图片需先convert('RGB')以防止变色或保存失败。
批量调整图片尺寸前必须检查的三个前提
Pillow 本身不直接支持“批量”操作，所有处理都基于单张图像对象。这意味着你得自己写循环或用 glob、os.listdir 遍历文件——但很多人卡在第一步：路径里有中文或空格，Image.open() 直接抛 FileNotFoundError 或 OSError: cannot identify image file。
真正要跑起来，得先确认：
- 图片路径用
pathlib.Path处理比字符串拼接更稳，尤其跨平台时 - 文件扩展名必须小写且显式过滤，
.JPG和.jpg在 Linux 下不是一回事 - 某些 Web 图片（比如带 ICC profile 的 PNG）在 resize 后可能变色，得加
im = im.convert('RGB')强制统一模式
resize() 和 thumbnail() 的关键区别在哪
做缩略图，别无脑用 resize()。它强行拉伸到指定宽高，会变形；而 thumbnail() 是按比例缩放并裁剪（不裁剪，只等比缩小至不超过目标尺寸），更适合封面类缩略图。
但注意：thumbnail() 是原地修改，不返回新对象，且会丢弃原始 exif 数据（比如拍摄方向），如果需要保留旋转信息，得手动读取 _getexif() 并调用 rotate()。
常见误用：
-
im.thumbnail((300, 300))后直接im.save()—— 此时im.size已变，但宽高比不确定，可能只有 300×180 - 想保持宽高比又填满容器？得先
resize()再crop()，不能只靠thumbnail()
保存时绕不开的 JPEG 压缩与透明通道陷阱
Web 缩略图多为 JPEG，但 Pillow 默认保存 JPEG 时不压缩（质量 75），上传后体积仍大；而 PNG 若含透明通道（alpha），直接存 JPEG 会报错：ValueError: cannot save mode RGBA。
解决方案必须显式处理：
- 对 JPEG：加
quality=85和optimize=True参数，体积能降 30%+ - 对 PNG 转 JPEG：先
im.convert('RGB')，否则 save 失败 - 保留透明背景？只能存 PNG，但记得关掉
optimize=False（PIL 的 PNG optimize 有时损坏 alpha） - 所有保存路径必须确保父目录存在，
Path(out_dir).mkdir(parents=True, exist_ok=True)别漏
并发处理图片时内存暴增怎么办
用 for 循环处理几百张图，容易 OOM——因为每张图加载后没显式 del im，Python 垃圾回收不及时。更稳妥的做法是：
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 每次打开 → 处理 → 保存 → 立即
del im - 或用生成器 +
contextlib.closing确保资源释放 - 真要提速？别用
threading（GIL 限制），改用multiprocessing.Pool，但要注意Image对象不能跨进程传递，得传文件路径，子进程里重新open - 单核 CPU 上开 4 个进程基本就是极限，再多反而变慢
实际跑起来最常被忽略的是：缩略图尺寸写死在代码里，但不同页面需要不同尺寸（比如列表页 200×150，详情页 600×400）。硬编码会让脚本复用性归零——把尺寸做成配置字典，按文件名前缀或目录结构自动匹配，才真正算“批量”。
