spawn模式不优化fork开销，而是绕过fork副作用；它通过全新解释器启动确保状态干净、跨平台一致，但要求主模块无顶层副作用且进程创建必须置于if name == '__main__':块内。
spawn模式本身不解决“频繁 fork 的开销”，它压根就不用 fork —— 所以问题前提需要先校正：你不是在“优化 fork”，而是在**绕过 fork 的副作用，接受可预测的启动成本**。真正要减的不是 fork 开销，而是 fork 带来的资源冲突、死锁和跨平台不一致。
为什么显式用 spawn 能避开 fork 的坑
Linux/macOS 默认用 fork，但它的“快”是带毒的：子进程直接继承父进程内存快照，包括已打开的数据库连接、threading.Lock、日志 handler、甚至 C 扩展（如 PyTorch）内部状态。一旦父进程里有线程正在持锁，fork 后子进程里的锁就永远卡住——没报错，只 hang。
- 常见现象：
OSError: [Errno 24] Too many open files、子进程静默退出、cudaErrorInvalidValue - macOS 10.14+ 和 Python 3.8+ 已默认切到
spawn，说明官方也承认fork在现代运行时不够稳妥 - Windows 完全不支持
fork，靠猜平台行为写代码等于埋雷
spawn 下必须守死的两条铁律
spawn 启动时会起一个全新 Python 解释器，重新执行整个主模块（从第一行开始），所以任何顶层副作用都会重复发生。这不是 bug，是设计。
- 所有多进程相关代码（
Process、Pool创建）必须包在if __name__ == '__main__':块内，且该块不能被 import 触发 - 主模块顶部禁止写有副作用的代码：比如
logging.basicConfig()、open('config.json')、psycopg2.connect()、torch.cuda.set_device(0) - 如果要用全局配置，改用函数封装 + 显式传参，例如
worker(data, config=load_config())，而不是依赖模块级变量
怎么安全地切换到 spawn
不要依赖全局设置，用 get_context() 显式指定上下文，避免污染其他模块或测试环境。
- 在
if __name__ == '__main__':最开头调用：ctx = multiprocessing.get_context('spawn') - 后续全部用
ctx.Process、ctx.Pool，别混用multiprocessing.Process - 避免
multiprocessing.set_start_method('spawn')，它会修改全局状态，可能和第三方库（如 pytest-xdist）冲突 - 验证是否生效：在子进程中打印
os.getpid()和os.getppid()，确认不是父进程 PID 的简单复制
性能真慢吗？关键看你怎么用
单次启动慢是事实，但实际项目中几乎没人反复创建/销毁进程。重点在复用：
- 用
ctx.Pool复用子进程，启动开销摊薄到每个任务上，实测 4 进程池下spawn和fork总耗时差不到 5% - 避免在 worker 函数里做重初始化（如每次连 DB），把初始化提到
initializer回调里：ctx.Pool(..., initializer=init_db) - 如果 worker 需要大对象（如模型），别 pickle 传，改用
multiprocessing.shared_memory或文件映射
真正容易被忽略的是：spawn 不是“慢得不可接受”，而是“要求你把初始化逻辑理清楚”。那些在 fork 下侥幸跑通的脏代码，换 spawn 就暴露——这反而是好事。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
