NumPy2.1为什么开始支持Python3.13？

图 0：NumPy 2.1 适配 Python 3.13 的核心驱动维度概要

NumPy 在 2024 年 8 月发布的 2.1.0 版本中正式启动对 Python 3.13 的支持，其根本原因在于：Python 3.13 的 C-API 直到 2024 年 8 月初进入候选发布（RC）阶段才正式冻结，而此前 6 月发布的 NumPy 2.0 专注于自身的重大底层 ABI 重构，无法在解释器未定型时提前绑定；更关键的是，Python 3.13 引入了具有划时代意义的自由线程（PEP 703，即 no-GIL 构建 cp313t），作为整个数据科学与机器学习技术栈的基石，NumPy 必须率先完成线程安全改造并提供预编译二进制 Wheel 包，下游的 SciPy、Pandas 与 PyTorch 才能随之推进。

一、时间线与发布节奏：为何是 NumPy 2.1 而不是 2.0？

许多开发者会产生疑问：NumPy 2.0 是自 2006 年以来的第一次主版本大更新，既然 2.0 经历了数年打磨并重构了 C 扩展接口，为什么没有顺带直接提供对 Python 3.13 的正式支持？

要理清这个问题，需要对照两个项目的发布工程周期。NumPy 2.0.0 于 2024 年 6 月 16 日正式发布。在这个节点，Python 3.13 仍处于测试版（3.13.0b2）阶段。在 CPython 的工程规划中，Beta 阶段依然允许修改内部 C-API 结构与未公开的宏定义，底层 ABI 尚未冻结。如果 NumPy 2.0 贸然在解释器结构还在变动的阶段打包二进制轮子，一旦后续 Beta 或 RC 产生变动，所有已发布的 Wheel 都将直接段错误崩塌。

2024 年 8 月 1 日，Python 3.13.0rc1 正式发布，标志着 ABI 与公开 C-API 正式冻结。NumPy 维护团队随即在 8 月 19 日发布了紧跟节奏的特性版本 NumPy 2.1.0。因此，NumPy 2.1 承担了衔接新版 Python 运行时生命周期的使命。

图 1：NumPy 2.0、NumPy 2.1 与 Python 3.13 各发布阶段的技术交汇时间线

二、核心驱动力：为 Python 3.13 自由线程（PEP 703）铺路

除了常规解释器版本升级，NumPy 2.1 支持 Python 3.13 最大的技术变革在于：自由线程（Free-threaded CPython，即 PEP 703）。

过去三十年间，CPython 内部依靠全局解释器锁（Global Interpreter Lock, GIL）来保证内存管理（如引用计数递增递减）和内部字典操作的线程安全。这意味着纯 Python 多线程无法在多核 CPU 上实现并行加速。Python 3.13 第一次通过实验性配置 --disable-gil，构建出无 GIL 的可执行环境（在分发包中以 cp313t 标记）。

但移除了解释器层面的 GIL，并不代表原有的 C 扩展就能自然享有并发安全。相反，底层 C 扩展直接暴露在多线程数据竞争的风险中：

• 内存与引用计数风险： 过去由 GIL 保护的静态缓存、内部类型定义和数组全局状态，在无锁状态下可能触发并发读写破坏。
• 通用数学计算（ufunc）调度： NumPy 底层 ufunc 操作在释放 GIL 后执行密集运算早已成熟，但分配中间临时数组、查找内核签名等元数据操作原本依赖解释器状态。
• 生态下游死锁问题： SciPy、Pandas、scikit-learn 和 PyTorch 等项目无一不高度依赖 NumPy 暴露的 C 结构体指针。如果 NumPy 不先支持 cp313t，下游库根本无法在自由线程环境中进行测试和构建。

NumPy 2.1 引入了对自由线程模式的实验性兼容，引入了细粒度互斥锁（如 CPython 提供的 PyMutex）、重构了类型元数据查找机制，并为各主流平台编译并上传了实验性的 cp313t 预编译轮子。

图 2：GIL 单锁竞争机制与 NumPy 2.1 在自由线程环境下的并发改造对比

三、底层 C API 演进与构建工程的协同适配

支持 Python 3.13 并非修改几行代码即可完成，而是涉及底层 C API、编译系统和二进制打包工程的系统性协同。

1. 适配 Python 3.13 的 C-API 清理

Python 3.13 移除了大量在 3.11 和 3.12 中已被废弃的私有或过时 C-API（例如部分旧版 PyUnicode_* 接口及不再公开的内部结构体成员）。NumPy 2.0 对自身内部 C 源码进行过一次深度梳理，但针对 Python 3.13 新引入的稳定 API 规范与新的对象分配器，需要进一步在 NumPy 2.1 中实现合规转换，确保在严格启用编译器警告时不产生潜在符号冲突。

2. 编译工具链与 Cython 3.0+ 的全面协同

NumPy 自 2.0 起已全面弃用传统的 numpy.distutils，转而采用 Meson 作为默认构建系统。在 Python 3.13 下构建 C 扩展，依赖高版本的 Meson 以及 Cython（3.0.11 及以上版本）。NumPy 2.1 在持续集成（CI）流水线中正式配置了针对 cibuildwheel 的 Python 3.13 标准构建（cp313）与自由线程构建（cp313t）矩阵。

图 3：针对 Python 3.13 自由线程环境安装配置与校验 NumPy 2.1 的操作流程

四、实操示例：安装与验证 Python 3.13 上的 NumPy 2.1

下面给出在具备 Python 3.13 环境的开发机上，针对标准模式和自由线程模式的具体操作命令与结果验证方法。

1. 创建环境与安装依赖

假定系统已安装好支持自由线程的 Python 3.13 可执行文件（通常为 python3.13t）：

# 示例命令：创建基于 Python 3.13 自由线程的虚拟隔离环境
python3.13t -m venv .venv-py313t

# 激活虚拟环境（macOS/Linux）
source .venv-py313t/bin/activate

# 升级 pip 并安装 NumPy 2.1+
pip install --upgrade pip
pip install "numpy>=2.1.0"

2. 编写验证脚本

创建文件 verify_numpy_py313.py，检查 NumPy 的版本、C 扩展加载情况以及 GIL 状态：

import sys
import numpy as np

# 检查当前 Python 与 NumPy 版本
print(f"Python 核心版本: {sys.version}")
print(f"NumPy 库版本: {np.__version__}")

# 检测当前解释器是否启用了 GIL (Python 3.13+ 专用接口)
if hasattr(sys, "_is_gil_enabled"):
    gil_active = sys._is_gil_enabled()
    print(f"GIL 当前启用状态: {gil_active}")
    if not gil_active:
        print(">> 提示：当前正运行在 Python 3.13 自由线程（Free-threaded）模式下！")
    else:
        print(">> 提示：当前正运行在 Python 3.13 标准锁（GIL）模式下。")
else:
    print("当前 Python 版本低于 3.13，不支持 _is_gil_enabled() 探测。")

# 执行简单数组并行运算测试
data = np.random.randn(2000, 2000)
result = np.dot(data, data.T)
print(f"矩阵计算验证成功，形状: {result.shape}")

3. 示例输出参考

若在 python3.13t 虚拟环境中执行该脚本，终端将展示如下形式的验证结果（以下为示例输出）：

Python 核心版本: 3.13.0 experimental free-threading build (main, Oct 2024, 10:00:00) 
NumPy 库版本: 2.1.0
GIL 当前启用状态: False
>> 提示：当前正运行在 Python 3.13 自由线程（Free-threaded）模式下！
矩阵计算验证成功，形状: (2000, 2000)

五、总结：NumPy 2.1 适配 Python 3.13 的决策矩阵

NumPy 2.1 之所以在这个节点率先拥抱 Python 3.13，既是跟随 Python 官方 C-API 冻结周期的工程必然，也是为了承担起科学计算生态基础底座的先锋责任。

图 4：NumPy 2.1 针对 Python 3.13 两种解释器构建特性的技术决策全景图