本文选自 Horizon 2026年9月2日技术简报。
摘要
Python 指导委员会要求，在相关标准流程 PEP 获得接受之前，CPython 主分支暂停 JIT 编译器的新功能开发，只接收缺陷和安全修复。Python 3.15 仍保留实验性 JIT，正式版计划于 2026 年 10 月 1 日发布；若约六个月内没有形成可接受的长期方案，JIT 代码可能移出主仓库。争议的核心并不是“Python 要不要更快”，而是实验机制何时成为受支持功能：性能收益如何衡量，平台覆盖到什么程度，调试、构建与维护成本由谁承担，兼容性承诺如何兑现。
CPython 为什么需要 JIT
CPython 通常先把源代码编译为字节码，再由解释器循环执行。每条字节码都要完成分派、类型检查和对象操作，灵活性很强，但会产生额外开销。NumPy、PyTorch 等库把重计算放到 C、C++ 或 GPU 中，因此受到影响较小；大量纯 Python 循环、动态对象操作和服务端业务逻辑更容易受解释器吞吐限制。
即时编译器会在运行期间识别热点代码，把一段字节码转换为更接近机器执行的形式。它可以利用当前观察到的类型和控制流做专门化，再在假设不成立时回退。理论上，这能消除部分解释器分派成本；现实中还要付出编译时间、机器码内存、守护条件和去优化成本。
Python 的高度动态特性使 JIT 很难照搬 Java 或 JavaScript 的路线。对象类型可能变化，属性可被猴子补丁修改，调试器和跟踪工具需要观察执行过程，C 扩展又依赖 CPython 行为。一个微基准加速，并不保证大型应用端到端变快。
实验性 JIT 是怎样进入主线的
CPython 的新 JIT 在 Python 3.13 周期以实验形式进入主线，PEP 744 主要记录实现与构建方式，属于信息类 PEP，而不是正式提出长期语言或运行时承诺的标准流程 PEP。实验阶段允许开发者积累数据，但随着代码规模、构建矩阵和维护负担增加，项目必须决定它是否会成为官方支持能力。
指导委员会此次暂停的是新开发，不是立即删除 JIT。现有代码仍可进行安全与缺陷修复，Python 3.15 也继续提供实验版本。PEP 836 随后提出从实验走向受支持 JIT 的路径，试图明确范围、成功指标、平台支持和维护责任。
这是开源项目常见的治理节点。一项实验功能可以依靠少数核心开发者快速推进；一旦成为默认或受支持特性，发布经理、构建平台、调试工具、发行版和下游用户都会承担长期成本。是否接受不能只看最好成绩，还要看最坏回归、可移植性和维护者可持续性。
性能要用什么口径衡量
评估 JIT 至少需要四类指标。第一是稳态性能：热点充分运行后快多少。第二是启动和预热：短命脚本可能还没收回编译成本就结束。第三是内存：机器码、分析元数据和额外运行时状态会增加常驻集。第四是尾延迟：服务请求中突然编译或去优化可能造成抖动。
基准也不能只选有利于 JIT 的纯 Python 循环。真实工作负载包含 C 扩展调用、文件和网络 I/O、对象分配、正则表达式、JSON 处理和框架调度。JIT 对等待 I/O 的程序几乎没有直接帮助，对大量时间已在本地扩展中的科学计算也可能收益有限。
更严格的方案应给出明确门槛，例如官方基准套件的几何平均提升、内存增长上限、无显著回归的平台比例，以及失败时如何禁用。结果还需覆盖 Linux、macOS、Windows、不同架构与编译器，而不是只在开发者机器上成立。
PEP 不是行政手续
PEP 的价值在于把隐含决策写成可评审契约。JIT 的 PEP 应回答：哪些平台属于首要支持范围；构建时和运行时如何启用；调试、性能分析和覆盖率工具能看到什么；安全更新如何处理生成代码；谁是长期维护者；达到哪些指标后可以默认开启。
没有这些约束，新功能容易形成“代码已经合入，所以项目必须继续维护”的既成事实。暂停开发让社区先决定目标，再决定实现，是对主分支稳定性的保护。它也会损失短期开发速度，甚至让贡献者感到受挫，但比在默认启用后才发现维护能力不足更可控。
Python 3.15 RC2 已进入 ABI 稳定阶段，官方鼓励第三方项目测试并构建 wheel。对普通包维护者而言，当前更紧迫的任务是验证 3.15 兼容性，而不是假设 JIT 一定在 3.16 默认启用。
对 Python 用户意味着什么
短期内，普通用户不应因 JIT 规划暂停而推迟升级。3.15 的语言和运行时改进仍会按发布节奏推进，实验 JIT 也可以用于测试。生产团队若想评估，应使用自身工作负载，分别测启动、稳态、内存和高分位延迟，并保留快速关闭开关。
追求性能时仍需从剖析开始。若瓶颈在数据库、网络或 GPU，JIT 不会解决问题；若集中在纯 Python 热循环，可先尝试算法改进、批处理、NumPy、Cython、Rust 扩展或 PyPy。未来 CPython JIT 的优势在于无需迁移解释器即可获得透明加速，但前提是兼容性与维护成本可接受。
结语
CPython JIT 的暂停不是性能路线退场，而是从实验代码走向公共基础设施前的一次治理校准。Python 社区真正需要的不是一个能在少数基准上“跑得飞快”的开关，而是一套可以跨平台发布、可诊断、可关闭、可长期维护的运行时能力。PEP 836 能否把目标和责任讲清楚，比某次微基准提高几个百分点更重要。
参考资料
- PEP 836, JIT Go Brrr: The Path to a Supported JIT Compiler for CPython
- PEP 744, JIT Compilation
- Python Steering Council, JIT Development Decision
- Python.org, Python 3.15.0rc2 Release
- CPython Developer Guide, Changing CPython’s Runtime