Python多进程在Windows和Linux/macOS上行为差异显著，核心在于进程创建机制不同：Windows用spawn，类Unix系统默认用fork。这直接影响代码结构、性能、资源初始化逻辑和错误表现。
启动方法决定入口保护要求
Windows不支持fork，必须通过spawn方式新建进程——即重新导入主模块、执行新入口。若未加保护，子进程会重复运行主程序逻辑（如再次调用Process()或Pool()），导致无限递归创建进程、报错或卡死。
- 所有使用
multiprocessing的脚本，Windows下必须将进程启动代码放入if __name__ == '__main__':块中 - 即使只是导入含
Process定义的模块，只要该模块顶层有启动语句，也需加保护 - PyInstaller打包后仍需遵守此规则，否则exe在Windows双击运行时会崩溃
全局变量与模块状态不可继承
spawn方式下，子进程不共享父进程内存，也不复制已加载模块的状态。任何在主模块顶层初始化的全局对象（如数据库连接、日志器、缓存字典）在子进程中都是全新实例。
- 不能依赖“主进程初始化一次，子进程自动可用”——比如
logging.basicConfig()只影响主进程日志配置 - 需在子进程内显式初始化关键资源，或通过
initializer参数为Pool统一设置 - 避免在模块级创建不可序列化的对象（如文件句柄、线程锁），否则
spawn时会因pickle失败而报AttributeError
路径、环境与工作目录可能重置
Windows的spawn会以当前脚本所在目录为子进程工作路径，且不自动继承父进程的sys.path扩展或部分环境变量（尤其是IDE调试时）。
立即学习“Python免费学习笔记（深入）”；
- 子进程可能找不到相对路径下的配置文件或数据，建议用
Path(__file__).parent构造绝对路径 - 若依赖自定义
PYTHONPATH或动态添加的sys.path，需在子进程启动前手动同步 - 某些第三方库（如
torch）在Windows多进程下对CUDA上下文有额外限制，需显式设torch.multiprocessing.set_start_method('spawn', force=True)
调试与异常信息更难追踪
Windows子进程异常不会自动打印到主进程终端，常表现为进程静默退出、Process.is_alive()返回False，或Pool.apply_async().get()抛出TimeoutError而非真实异常。
- 务必为子进程任务包裹
try/except，并记录日志到文件（避免print丢失） - 用
Pool(..., maxtasksperchild=1)可强制每次任务用新进程，便于定位内存泄漏或状态污染问题 - 启用
multiprocessing.set_start_method('spawn')并在Linux/macOS上测试，能提前暴露平台相关缺陷
跨平台写多进程代码，本质是主动适配spawn模型——把每个子进程看作独立Python解释器实例，而非父进程的轻量副本。不复杂但容易忽略。
