Pool适合CPU密集型、无共享状态、可序列化的纯计算任务；不适合IO密集型、含全局变量、lambda或嵌套函数的任务。
直接用 multiprocessing.Pool 并不能自动加速所有任务——它只对 CPU 密集型、无共享状态、可序列化的函数有效；IO 密集型或带全局变量/类实例的任务反而可能更慢甚至出错。
Pool 适合什么场景？看三个硬性条件
能用 Pool 加速的前提是：函数纯计算、不依赖外部状态、参数和返回值都能被 pickle 序列化。
- ✅ 适合：数值计算（如矩阵运算、图像滤波）、文本解析（正则匹配、分词）、加密哈希生成
- ❌ 不适合：调用未加锁的全局计数器、操作
threading.local()、传入 lambda 或嵌套函数（无法 pickle）、读写同一文件句柄 - ⚠️ 警惕：含
numpy数组的函数通常没问题，但若函数内动态 import 模块或修改sys.path，子进程可能找不到模块
map() vs apply_async()：选错就卡死或失控
map() 是阻塞式批量提交，等全部完成才返回；apply_async() 是非阻塞单次提交，适合异步控制流，但不手动 .get() 就拿不到结果。
-
pool.map(func, iterable)：最常用，自动切分iterable给各 worker，但会一次性加载全部数据到内存——大数据量时用pool.imap()流式处理 -
pool.apply_async(func, args=(x,), kwds={'y': 1})：返回AsyncResult对象，必须显式调用.get(timeout=10)获取结果，否则主进程可能提前退出，子进程变僵尸 - 别混用：在循环里反复调
apply_async却不收集结果，会导致AsyncResult对象堆积，内存泄漏
常见报错和对应解法
错误信息如 PicklingError: Can't pickle <function ...> 或 BrokenProcessPool，基本都源于序列化失败或资源竞争。
立即学习“Python免费学习笔记（深入）”；
- 报
PicklingError：把函数移到模块顶层（别放在类方法或if __name__ == '__main__':块里），避免使用lambda、functools.partial（改用普通函数+默认参数） - 报
BrokenProcessPool：子进程崩溃（如除零、段错误），检查函数是否含未捕获异常；Windows 下必须用if __name__ == '__main__':包裹Pool创建逻辑 - 结果顺序错乱：用
pool.map()保持输入顺序；用apply_async时，手动存result = pool.apply_async(...)再按需result.get()，别依赖提交顺序
真正难的不是写几行 Pool 代码，而是判断任务是否真的适合并行——比如一个函数内部频繁访问 Redis 或数据库，开 8 个进程只会让连接池打满，反而拖垮整体响应时间。
