Python 3.13 提供实验性的 free-threaded CPython 构建，让解释器可以在不启用全局解释器锁的模式下运行多个 Python 线程。它不是默认安装，也不表示“Python 已经全面移除 GIL”。正确姿势是把它当作需要单独环境、兼容性审查与实际测量的运行时变体，而不是给现有服务加一个开关就获得线性加速。

先确认运行的确是自由线程构建

官方安装方式会因平台而异，解释器通常带有区别于常规构建的标记。测试程序应在启动时记录 Python 版本、实现、构建标志与 GIL 状态，而不是仅凭可执行文件名猜测。部署时把普通与 free-threaded 环境完全分开，锁文件和二进制 wheel 也要分别验证。

import sys
import sysconfig

def runtime_report() -> dict[str, object]:
    enabled = getattr(sys, "_is_gil_enabled", lambda: True)()
    return {
        "version": sys.version,
        "implementation": sys.implementation.name,
        "gil_enabled": enabled,
        "py_gil_disabled": sysconfig.get_config_var("Py_GIL_DISABLED"),
    }

print(runtime_report())

这一报告适合写进基准产物，具体探测接口仍要按 Python 3.13 文档核对。某些扩展模块在导入时可能重新启用 GIL 或根本不提供兼容 wheel，因此“解释器支持”不等于依赖树支持。

选择真正受益的工作负载

自由线程最值得测试的是可拆分的 CPU 密集 Python 工作，并且线程之间共享的数据较少，例如对独立文档执行纯 Python 解析。大量时间在网络、磁盘或数据库等待的应用，本来就可以借助异步 I/O 或普通线程隐藏等待；移除 GIL 未必改变瓶颈。大量工作在已经自行释放 GIL 的原生库里，也可能收益有限。

进程池仍是重要基线。它有序列化和内存成本，却提供故障与地址空间隔离，而且生态成熟。比较对象应至少包括：常规 CPython 单线程、常规 CPython 线程、进程池，以及 free-threaded 线程。不要只比较最慢旧方案和最优新方案。

没有 GIL 不代表容器操作成为业务原子操作

内建类型为解释器安全采取了内部同步措施，但应用不能因此依赖复合操作的偶然原子性。“如果键不存在就写入”、读取后递增、遍历同时修改都包含多个语义步骤，需要锁、队列、不可变快照或每线程所有权。过去被 GIL 掩盖的数据竞争，在自由线程下更容易出现。

把共享可变状态缩小通常比添加许多细锁更可靠。让工作线程接收不可变输入、返回独立结果，再由一个所有者合并；跨线程通信使用 queue.Queue 等明确原语。第三方对象是否线程安全必须看其文档，不能从 Python 对象外观推断。

扩展兼容是迁移门槛

C 扩展可能使用过去由 GIL 隐含保护的全局状态、缓存和引用计数假设。先生成完整依赖清单，在隔离环境安装与导入，再运行扩展自己的测试和项目高并发场景。缺少 free-threaded wheel 时不要在生产机器临时编译未知配置；固定编译器、ABI、源码与构建日志。

若导入某个模块导致 GIL 被重新启用，基准必须记录这个事实。一个“能启动”的程序可能实际没有以预期方式并发运行。替换依赖也要评估功能与维护成本，不能只为追逐模式标签。

建立可重复的测量

固定数据集、线程数、预热、CPU 亲和条件、Python patch 版本和依赖版本。分别测吞吐、尾延迟、CPU 利用率、内存与正确性。线程数从 1 开始逐步增加；超过核心数后的退化同样重要。多次运行并报告分布，不挑最快一次。

性能测试必须包含结果校验与压力测试。错误答案跑得更快没有价值。使用 ThreadSanitizer 需要适合的原生构建且会改变性能，因此它用于发现问题，不用于发布跑分。

结论

Python 3.13 自由线程构建是一次有价值的实验入口，不是普遍加速承诺。先确认环境和依赖真的处于目标模式，选择 CPU 并行工作负载，以进程池作基线，重新审查所有共享状态，并在代表性硬件上同时测性能与正确性。只有收益稳定、扩展兼容且运维能够回退时，才适合把实验逐步扩大。