应优先使用 Pool 或 ProcessPoolExecutor 而非手动管理 Process；Pool.map() 适用于独立、无状态、输入可序列化的批量任务，自动处理调度、异常和进程回收。
multiprocessing 能真正绕过 GIL、压满多核 CPU，但直接用 Process 类手动管理 10+ 进程极易出错——你应该优先用 Pool 或 concurrent.futures.ProcessPoolExecutor。
什么时候该用 Pool.map() 而不是手写 Process
当你有一组**独立、无状态、输入可序列化**的计算任务（比如对 1000 个参数组合分别跑一次 ODE 求解），Pool.map() 是最稳的选择。它自动分配任务、回收进程、处理异常、避免子进程卡死拖垮主程序。
手写 Process 只适合极少数场景：需要精细控制子进程生命周期、实时通信（如用 Queue 边算边传中间结果）、或必须在子进程中修改全局状态（不推荐）。
-
Pool默认复用进程，启动开销小；Process每次新建进程，开销大 -
Pool.map()会阻塞直到所有结果返回；若想“发完就继续”，改用Pool.apply_async()或ProcessPoolExecutor.submit() - Windows 下不加
if __name__ == '__main__':会无限递归 fork 子进程，报错信息通常是RecursionError: maximum recursion depth exceeded或直接崩溃
Pool 初始化时 processes 参数设多少才合理
别盲目填 os.cpu_count()。实际吞吐受 I/O、内存带宽、任务粒度制约。动力学仿真这类纯 CPU 密集型任务，设为 os.cpu_count() - 1 更稳妥——留一个核给系统调度和 Python 主进程响应。
立即学习“Python免费学习笔记（深入）”；
如果每个子任务耗时极短（5s 且内存占用高，进程数过多可能触发系统 OOM killer 杀掉子进程。
- 先用
processes=2测 baseline，再逐步加到4、8，观察 CPU 利用率（htop）是否稳定在 90%+，且无明显等待 - Linux 下可通过
ps -o pid,ppid,cmd -C python确认子进程是否真实运行，而非挂起 - 注意：子进程无法继承主进程的线程锁、文件描述符、GUI 上下文等资源，初始化逻辑必须在函数内部重做
为什么子进程总报 NameError 或找不到函数
根本原因是子进程启动时会重新导入模块，但函数定义若写在 if __name__ == '__main__': 块内，子进程就看不到它。
- 把待并行的函数（如
run_kinetics(p_O2, p_CO)）放在模块顶层，不要嵌套在 main 块里 - 避免使用 lambda、闭包、类实例方法——它们无法被 pickle 序列化，
Pool传参时会直接抛AttributeError: Can't pickle local object - 如果必须用类方法，改写为普通函数，把对象状态转成参数字典传入
- 第三方库（如
scipy.integrate.solve_ivp）在子进程中首次调用可能稍慢，这是正常现象，不是错误
如何捕获子进程里的异常并定位问题
Pool.map() 遇到子进程异常默认只抛 Exception，不带原始 traceback。要看到真实错误，必须显式处理：
- 用
Pool.apply_async(func, args).get(timeout=60)替代map，异常会在get()时原样抛出 - 在目标函数开头加
import traceback; try: ... except Exception: traceback.print_exc(); raise，强制打印到子进程 stdout - 设置
maxtasksperchild=1参数让每个进程只处理一个任务，便于复现问题（但性能下降） - 注意：子进程的
print输出可能乱序或缓冲，加flush=True或用logging写文件更可靠
真正麻烦的从来不是启动几个进程，而是确保每个子进程拿到干净的环境、能正确加载依赖、异常时不静默失败、结果不因共享内存误改而污染。这些细节不提前踩一遍，上线后只会更难 debug。
