应优先选spawn以确保跨平台兼容性和初始化逻辑清晰，fork虽快但易因复制父进程状态导致资源冲突或死锁，spawn则通过重新执行模块保证干净启动但需严格遵循if name == '__main__':规范。
fork 和 spawn 在 multiprocessing 中怎么选
Python 的 multiprocessing 默认行为取决于平台，但你不能靠猜——Linux/macOS 默认用 fork，Windows 只能用 spawn，macOS 从 Python 3.8+ 也默认改用 spawn。选错会导致程序在某个平台跑不起来，或者行为诡异。
关键不是“哪个更好”，而是“哪个匹配你的初始化逻辑”。fork 复制当前进程内存快，但会把父进程里已初始化的全局状态（比如已连接的数据库连接、已启动的线程、日志 handler）一股脑带进子进程；spawn 则像重新运行一次脚本，只导入模块、执行 if __name__ == '__main__' 下的代码，干净但慢。
- 如果你的主模块顶部有副作用（比如调用了
logging.basicConfig()、打开了文件、初始化了全局requests.Session），用fork可能导致子进程中复用这些资源，引发并发冲突或 ResourceWarning - 如果子进程需要访问父进程里通过非顶层代码创建的对象（比如函数内定义的类实例），
spawn会失败——它不继承局部作用域，只走模块重载流程 - 想强制统一行为，启动前加
multiprocessing.set_start_method('spawn')或'fork'，但必须在if __name__ == '__main__':里且早于任何Process/Pool创建
fork 导致子进程卡死或报错的典型场景
最常见的表现是子进程 hang 住、无响应，或者抛出 OSError: [Errno 24] Too many open files、AssertionError: can only join a started process 这类看似无关的错误。根本原因往往是 fork 时复制了父进程里处于中间状态的资源。
- 父进程用了
threading.Lock或threading.Condition，fork 后子进程里的锁状态是“被父线程持有着”，但那个线程并不存在，锁永远无法释放 - 父进程开了数据库连接（如
psycopg2.connect()）、HTTP 连接池（如urllib3.PoolManager），fork 后子进程拿到的是同一套 socket fd，但父进程可能随时关闭它们，子进程 read/write 就会出错 - 用了某些 C 扩展库（如 OpenCV、PyTorch），其内部状态（尤其是多线程/显存管理）不支持 fork，常见报错包括
free(): invalid pointer、cudaErrorInvalidValue
这类问题在开发机（Linux）上可能正常，一上 macOS 或 CI 环境（默认 spawn）就崩，或者反过来。
立即学习“Python免费学习笔记（深入）”；
spawn 模式下 import 和 if __name__ == '__main__' 必须严格
spawn 启动子进程时，会用一个全新的 Python 解释器实例，重新执行你的脚本——但它只执行顶层代码，且要求入口清晰。一旦漏掉保护条件或 import 放错位置，子进程直接报 ModuleNotFoundError 或 NameError。
- 所有进程创建代码（
Process(target=...)、Pool()）必须包在if __name__ == '__main__':块里，否则 spawn 会递归启动新子进程，形成 fork bomb - 目标函数（
target参数指向的函数）必须在模块顶层定义，不能嵌套在另一个函数里；也不能是 lambda 或局部变量绑定的函数 - 如果主脚本依赖相对路径导入（如
from .utils import helper），spawn 时工作目录可能不是你预期的，建议用绝对路径或确保sys.path正确 - 避免在模块顶层做耗时操作（如加载大模型、读大文件），spawn 每次都会重复执行，拖慢启动
如何检测和验证当前启动方法
别靠文档或平台猜测，运行时查最准。尤其当你封装了库或部署到未知环境时，主动检查能省掉大量排查时间。
- 打印当前方法：
print(multiprocessing.get_start_method()) - 检查子进程是否真按预期启动：在 target 函数开头加
print(f"PID: {os.getpid()}, PPID: {os.getppid()}")，fork 下 PPID 是父进程 PID，spawn 下 PPID 通常是 shell 或 init 进程（如 1） - 用
ps auxf或htop观察进程树结构：fork 出的子进程是父进程的直属子进程；spawn 出的子进程常显示为独立分支，有时还带python -c启动痕迹 - 注意：
get_start_method()在未显式设置且未创建过进程时可能返回None，安全写法是先set_start_method再查
真正麻烦的从来不是选 fork 还是 spawn，而是混合使用——比如主流程用 spawn，但某个第三方库内部悄悄调用了 fork（通过 os.fork()），这种隐式耦合会让调试变成拼图游戏。
