multiprocessing.Pool 更稳因 Python 3.12 中异常传播与资源回收更可靠，能正确抛出 cv2.error/MemoryError，而 ProcessPoolExecutor 可能静默吞错致任务卡死。
为什么 multiprocessing.Pool 比 concurrent.futures.ProcessPoolExecutor 更稳？
Python 3.12 中 multiprocessing.Pool 对子进程异常传播和资源回收更可靠，尤其在图像处理这种易因内存或 OpenCV 版本引发崩溃的场景。而 concurrent.futures.ProcessPoolExecutor 在某些情况下会静默吞掉子进程的 cv2.error 或 MemoryError，导致任务卡死却不报错。
- 必须用
if __name__ == "__main__":包裹主逻辑，否则 Windows/macOS 上会反复 fork 主模块 - 避免在
Pool外部定义处理函数——它无法被子进程序列化；要么放模块顶层，要么用functools.partial绑定参数 - 不要把
cv2.imread的完整路径列表一次性传给map()，大图多时易触发 IPC 缓冲区溢出；改用imap()流式处理
灰度化函数必须显式释放 OpenCV Mat 内存
OpenCV 的 cv2.cvtColor 返回的 np.ndarray 在子进程中若未显式 del 或覆盖，可能因引用计数延迟导致内存累积。实测 3.12 下单个 8MP 图片不释放，跑满 8 进程后常触发 OSError: [Errno 12] Cannot allocate memory。
- 函数内务必用
img = cv2.imread(path)→gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)→del img→return gray - 写入磁盘前加
cv2.imwrite(out_path, gray)后立即del gray，别依赖 GC - 禁用
cv2.IMREAD_UNCHANGED——灰度化不需要 alpha 通道，多读一个通道徒增内存压力
如何安全传递输入/输出路径并避免文件名冲突？
多个进程同时写入同一目录时，若输出路径仅靠 os.path.basename() 改后缀（如 xxx.jpg → xxx_gray.jpg），遇到同名但不同路径的文件（/a/x.jpg 和 /b/x.jpg）会相互覆盖。
- 输出路径应保留原始目录结构：用
os.path.relpath(path, input_root)获取相对路径，再拼到output_root - 提前用
os.makedirs(os.path.dirname(out_path), exist_ok=True)创建嵌套目录，避免进程间 mkdir 竞态失败 - 对每个
out_path做os.path.exists()检查并跳过已存在文件——省重复计算，也防意外中断后重跑冲突
怎样限制并发数又不让 CPU 一直 100%？
设 processes=8 不等于“8 个进程永远满载”，OpenCV 的灰度化是纯 CPU 密集型，但 cv2.imread 和 cv2.imwrite 涉及磁盘 I/O，实际瓶颈常在硬盘吞吐。盲目拉高进程数反而因上下文切换和 I/O 等待拖慢整体速度。
立即学习“Python免费学习笔记（深入）”；
- 推荐起始值设为
min(8, os.cpu_count() or 4)，然后用time.perf_counter()测 100 张图耗时，再调优 - 在
Pool.map()外围加try/except KeyboardInterrupt，捕获 Ctrl+C 后调用pool.terminate()，否则子进程可能残留成僵尸 - Windows 用户注意：
spawn启动方式下，cv2必须在子进程里重新 import，不能靠主进程导入后共享
最麻烦的其实是路径编码——如果输入路径含中文或 emoji，Windows 默认 cp1252 会崩，必须确保所有 path 变量是 str 类型且由 pathlib.Path 构造，别用 bytes 拼接。
