Python multiprocessing 怎样选择 spawn 和 fork

很多人第一次把 Python 进程池搬到另一台机器时，遇到的不是业务代码错了，而是启动方式变了：Windows 或 macOS 上子进程重新导入模块，Linux 上却可能继承了父进程的文件描述符或线程状态。标题里的 spawn 和 fork 不是两个可以随意互换的开关，它们决定子进程从哪里开始、拿到哪些资源，以及你的任务代码必须满足什么条件。

先给结论：跨平台项目、父进程已经启动线程或持有复杂客户端时，优先把任务写成可导入、可序列化的函数并显式使用 spawn；只在受控的 POSIX 环境、确认父进程没有不安全线程状态且确实需要继承只读内存时，才考虑 fork。Python 3.14 起，POSIX 的默认方式已改为 forkserver，更不能把“系统默认”当成稳定契约。

官方文档：https://docs.python.org/3/library/multiprocessing.html

下面做一个批量计算摘要的小工具：任务本身不依赖数据库连接或全局客户端，只接收字符串并返回结果。这样可以把启动方式的差异隔离出来，读者也能把同一套结构替换成真正的 CPU 密集型工作。

先把 spawn 和 fork 放到同一张选择表里

spawn 会启动一个全新的 Python 解释器，子进程只获得运行目标所需的资源，启动成本通常更高，但边界干净；它在 Windows 和 macOS 上是默认方式。fork 通过 os.fork() 复制父进程，子进程一开始几乎拥有父进程的状态，启动快，却会把线程、锁、文件描述符等继承问题带进来，而且只在 POSIX 上可用。

这张表的关键不是比较“谁更快”，而是先问任务是否允许子进程从干净环境启动。如果父进程已经使用线程库、网络客户端或日志后台线程，fork 的速度优势往往抵不过继承状态带来的偶发问题。

把任务写成两个启动方式都能理解的函数

使用 spawn 时，子进程需要重新导入主模块，所以目标函数不要藏在另一个函数内部，也不要把创建进程池的代码放在模块导入阶段。参数和返回值还应尽量保持可 pickle。下面的示例把业务计算、上下文选择和主入口分开，后续切换方式只改变一个参数。

import hashlib
import multiprocessing as mp


def digest_text(text: str) -> tuple[str, str]:
    # 任务只依赖显式参数，避免把数据库连接或线程锁带入子进程。
    digest = hashlib.sha256(text.encode("utf-8")).hexdigest()
    return text, digest[:16]


def run_batch(items: list[str], method: str) -> list[tuple[str, str]]:
    # get_context 只影响这一个池，不改变程序里的全局启动方式。
    ctx = mp.get_context(method)
    with ctx.Pool(processes=min(4, len(items) or 1)) as pool:
        # map 会等待全部任务完成，并按输入顺序返回结果。
        return pool.map(digest_text, items)


if __name__ == "__main__":
    # 入口保护让 spawn 重新导入本文件时不会再次创建进程池。
    sample = ["alpha", "beta", "gamma"]
    selected_method = "spawn"
    for value, digest in run_batch(sample, selected_method):
        print(f"{value}: {digest}")

这里没有直接调用 set_start_method()，是因为它只能设置一次，而且会影响整个进程。库代码或大型应用更适合接收一个方法名，再通过 get_context() 创建自己的 Pool、Queue 或 Process。需要注意，不同上下文创建的锁等对象不能随意混用。

什么时候才值得显式选择 fork

fork 适合的前提比“Linux 上运行”严格得多：运行环境必须是支持它的 POSIX 系统，父进程在创建子进程前没有需要保持一致的后台线程，继承的对象必须允许这种复制语义，而且团队能接受它与 Windows、macOS 的差异。它常见的合理场景是父进程已经准备好较大的只读数据，子进程可以在不修改共享状态的情况下读取。

如果父进程已经启动线程，或者打开了带内部锁的网络、日志、数据库客户端，复制出来的子进程可能带着“看起来已存在、实际上状态不完整”的对象。此时应把客户端创建移动到子进程内部，或回到 spawn / forkserver，而不是只因为启动速度快就继续使用 fork。

还要留意 Python 版本：Python 3.14 起，fork 已不再是任何平台的默认启动方式；POSIX 默认改用 forkserver，Windows 和 macOS 仍使用 spawn。如果文章、测试或部署脚本确实依赖 fork，就应该在代码和文档里明确写出来。

把平台和资源状态变成可检查的选择规则

不要把选择逻辑散落在业务函数里，可以集中成一个小函数，默认走更容易移植的 spawn，只有部署环境通过明确配置时才允许 fork。下面的规则不是替代测试，而是让选择理由能被代码审查和配置复用。

import os
import platform


def choose_method() -> str:
    # 配置只允许受控 POSIX 环境主动选择 fork，默认保持跨平台行为。
    requested = os.getenv("MP_START_METHOD", "spawn").lower()
    supported = {"spawn", "fork"}
    if requested not in supported:
        raise ValueError("MP_START_METHOD 只能是 spawn 或 fork")
    if requested == "fork" and platform.system() == "Windows":
        raise RuntimeError("Windows 不支持 fork，请使用 spawn")
    # 多线程父进程不应依赖 fork；生产配置可在启动前禁用该选项。
    if requested == "fork" and os.getenv("APP_HAS_THREADS") == "1":
        raise RuntimeError("父进程已启动线程，不能安全选择 fork")
    return requested

真实项目里还可以把“是否有线程”“是否依赖继承句柄”“是否运行在冻结可执行文件中”写进启动检查。检查失败时尽早报错，比子进程运行一段时间后卡在队列或锁上更容易排查。

最后按四个信号验收

1. 入口信号：主逻辑是否都在 if __name__ == "__main__" 保护下，目标函数是否位于可导入模块顶层。
2. 数据信号：传给进程的参数、锁、队列和返回值是否来自同一个上下文，是否能被序列化。
3. 资源信号：父进程是否已经有线程、打开连接、文件描述符或带锁的客户端；若有，优先避免 fork。
4. 平台信号：目标系统是否支持选定方式，Python 版本升级后默认方式是否发生变化。

如果只是做跨平台的 CPU 任务，显式 spawn 往往是最容易解释和维护的起点；如果在 Linux 上追求继承大型只读状态的启动效率，再单独评估 fork，并把“无多线程、可继承资源受控”写成部署前提。至于 Python 3.14+ 的 POSIX 应用，先查看默认的 forkserver 是否已经满足需求，再决定是否强行指定 fork。

常见问题

为什么本地能跑，换 Windows 就报子进程错误？通常是入口没有保护，或目标函数定义在交互环境、局部函数中，导致 spawn 无法重新导入它。先整理模块边界，再确认参数可序列化。

spawn 一定比 fork 慢吗？启动阶段通常更慢，但总体耗时还取决于任务数量、序列化成本和业务计算时间。不要用一次启动耗时替代完整工作负载的测量。

能在同一个程序里混用两种方式吗？可以通过多个 get_context() 创建不同上下文，但锁等上下文对象不能跨方式传递；除非有清晰边界，否则优先保持单一方式。

总结：选择 spawn 还是 fork，本质是选择“干净启动”还是“继承父进程状态”。先让任务可导入、参数可序列化，再根据平台、线程和资源生命周期显式决定，升级 Python 后也不会被默认值变化悄悄影响。