高清图失真主因是盲目调低quality值；JPEG下quality=95肉眼难辨失真，85为安全下限，低于75易现色块模糊；务必加optimize=True省5%–10%体积且不损画质。
用 PIL.Image.save() 的 quality 参数控制压缩强度
高清图失真主因是盲目调低 quality 值。JPEG 格式下，quality=95 通常肉眼不可辨失真，quality=85 是安全下限；低于 75 就容易出现明显色块和模糊。别信“自动优化”库默认值——很多工具默认设为 75 或更低。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
quality设为90～95，优先保画质；若文件体积仍超标，再微调到85 - 务必加
optimize=True，它会重排 Huffman 表，不损画质但能再省 5%～10% 体积 - 对 PNG 图，
quality无效，改用optimize=True+compress_level=1（避免默认9的过度耗时） - 不要对已压缩过的 JPEG 再次用 PIL 保存——重复编码会累积失真，先检查
exif或用im.format == 'JPEG'判断原始格式
批量处理前必须做尺寸预判：用 Image.size 避免无脑缩放
很多人一上来就 resize()，结果把 4K 图硬压成 1920×1080，细节直接砍掉。真正该压缩的是「冗余信息」，不是像素数。高清图往往宽高比一致、分辨率远超展示需求，应按目标用途定尺寸。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先读原图
im.size，若宽度 > 2560 且用途是网页，才执行等比缩放：im.thumbnail((2560, 2560), Image.LANCZOS) - 用
Image.LANCZOS（非BICUBIC或ANTIALIAS，后者在新 PIL 中已弃用） - 缩放只做一次，且必须在
save()前完成；thumbnail()是原地修改，别漏了这步 - 对印刷用途图，跳过缩放，只调
quality和optimize
绕过 Pillow 的 RGB 模式陷阱：处理 RGBA / P / CMYK 图时显式转换
直接 save(..., format='JPEG') 会报 ValueError: cannot write mode RGBA as JPEG，或静默转成低质量 RGB。这不是压缩问题，是模式不兼容导致的隐性画质崩坏。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 统一转为
RGB：im = im.convert('RGB')（对透明图，先paste(white_bg, (0,0), im)） - 遇到
mode='P'（如带调色板的 PNG），必须先convert('RGBA')再转RGB，否则颜色错乱 - CMYK 图（常见于印刷源文件）不能直存 JPEG，需转
RGB，但注意 Adobe RGB → sRGB 色域映射，加im = im.convert('RGB', intent=Image.CMS_INTENT_PERCEPTUAL)（需安装pyCMS）
用 os.scandir() + concurrent.futures 加速，但别并发开太多进程
单线程处理千张图太慢，但开 32 个 ProcessPoolExecutor 进程反而卡死——PIL 的图像解码是 CPU 密集型，且受 GIL 影响，纯多线程收益极低，而过多进程会挤爆内存。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
ThreadPoolExecutor处理 I/O（读/写），用ProcessPoolExecutor做resize和save，分工更稳 - 进程数设为
min(8, os.cpu_count())，别用max_workers=None - 每张图处理完立刻
del im，并手动gc.collect()，尤其处理 >10MB 的 TIFF 或 WebP 时 - 路径用
os.scandir()而非glob，快 3～5 倍，且能过滤.is_file()和.name.lower().endswith(('.jpg','.jpeg','.png'))
最易被忽略的一点：原图的 EXIF 方向信息（如手机竖拍标记）在 resize 后会丢失，必须用 PIL.ExifTags 提取并写回，否则批量压缩后所有竖图变横图——这个坑几乎没人提，但真实存在。
