\_fork 和 spawn 是 python 多进程的两种核心启动机制：\_fork 仅限 unix 系统，快速克隆父进程内存但易引发状态污染；spawn 跨平台安全，重启解释器并重新导入模块，启动慢但隔离性强，推荐新项目优先使用。
Python多进程启动方式中，_fork 和 spawn 是两种核心机制，它们在子进程创建时机、资源继承行为、跨平台兼容性及适用场景上存在本质差异。理解它们的区别，是避免多进程程序出现意外崩溃、重复初始化或资源竞争的关键。
fork：基于内存快照的快速克隆
fork 方式仅存在于 Unix/Linux/macOS 系统，它通过系统调用直接复制父进程的整个地址空间（采用写时复制，COW），生成一个几乎完全一致的子进程。子进程从 fork() 调用点之后开始执行，但已继承了父进程中所有打开的文件描述符、socket、线程状态（注意：实际只保留调用 fork 的那个线程）、全局变量值，甚至未 flush 的 stdout 缓冲区内容。
- 优点：启动极快，适合频繁创建子进程的场景（如 Web 服务器预分叉）
- 风险：若父进程已启动了线程、打开了数据库连接、初始化了某些 C 扩展（如某些 GUI 或信号处理模块），子进程会继承这些不安全状态，导致死锁或崩溃
- 典型触发条件：在 Unix 系统上使用 multiprocessing 默认启动方式（如未显式设置 start_method），且主模块可被安全 import（即无顶层运行逻辑）
spawn：从零重建的干净进程
spawn 方式在所有平台（包括 Windows）都可用。它不复用父进程内存，而是启动一个全新的 Python 解释器进程，重新导入主模块（__main__），并仅执行目标函数（target）及其依赖代码。这意味着子进程不会继承父进程的文件句柄、线程、全局对象状态或未刷新 I/O 缓冲区。
- 优点：进程隔离性强，更安全稳定；天然支持 Windows；避免 fork 带来的“隐式状态污染”问题
- 缺点：启动较慢（需重新解析、导入、初始化）；要求主模块必须能被安全 import（不能有顶层副作用代码，否则每次 spawn 都会执行一遍）
- 典型触发条件：Windows 默认方式；Linux/macOS 下显式调用 multiprocessing.set_start_method('spawn')；或使用 multiprocessing.get_context('spawn')
如何选择与规避常见陷阱
多数现代 Python 项目推荐优先使用 spawn，尤其涉及第三方库、异步 I/O、数据库连接、日志配置或多线程时。若坚持用 fork，务必确保：
立即学习“Python免费学习笔记（深入）”；
- 主模块入口严格遵循 if __name__ == '__main__': 模式，防止子进程重复执行初始化逻辑
- 避免在 fork 前启动后台线程（如 threading.Timer、APScheduler）或持有不可 fork 的资源（如 psycopg2 连接、multiprocessing.Queue 在 fork 后可能失效）
- 调试时注意：print 输出可能因缓冲区未 flush 而在子进程中重复出现，可用 print(..., flush=True) 显式控制
- 可通过 multiprocessing.get_start_method() 查看当前方式，用 set_start_method() 在主模块最开头（import multiprocessing 后立即）设定，且只能设一次
实际应用中的建议
对于新项目或跨平台部署，统一显式指定 spawn 更稳妥：
- 在主脚本开头添加：multiprocessing.set_start_method('spawn', force=True)
- 确保所有全局初始化（如 logger 配置、DB 连接池创建）都在 if __name__ == '__main__': 块内，或封装为函数并在 target 中按需调用
- 测试时分别在 Linux 和 Windows 下验证行为一致性，特别关注子进程是否意外重连数据库、重复写日志或卡在信号等待中
