导语：
截至 2026 年 4 月 6 日，Python 3.15 虽然还没进入 beta，但围绕性能的讨论已经很热。3 月 23 日，Python Insider 明确写出 Python 3.15's JIT is now back on track；3 月 10 日的 Python 3.15.0 alpha 7 则给出了更具体的数字：在 x86-64 Linux 上相对标准解释器几何平均提升 3%-4%，在 AArch64 macOS 上相对 tail-calling interpreter 提升 7%-8%。
我真正关心的不是这些数字本身，而是它们逼团队面对一个老问题：我们现在测 Python 性能的方法，很多时候太粗了。
1. 为什么“跑一组 benchmark”已经不够
Python 性能实验最容易犯的错，就是拿一两组熟悉脚本跑完，然后得出一个很笼统的结论：快了、没快、差不多。
3.15 这一轮不适合这么干，原因非常简单：
- JIT 的收益有明显的架构差异；
- 3.15 同时还引入了新的 profiler 和 lazy imports 等变化；
- 真实系统的性能问题，往往不体现在平均值上，而体现在 warmup、冷启动、P95 和资源抖动上。
如果实验方法不升级，最后很可能出现一种局面：你能拿出一张漂亮的对比图，但根本解释不了线上体验为什么没同步变好。
2. JIT 回正以后，该怎么重写实验方法
第一，按架构分层。
不要再用一台开发机代替全部生产现实。既然官方自己都给出不同架构上的不同收益，团队至少该在主要生产架构上分别建基线。
第二，按阶段分层。
JIT 相关优化最容易在 warmup 和稳态之间出现差异。第一次请求、前 100 次调用、长时间运行 10 分钟后的表现，很可能不是同一回事。
第三，按负载类型分层。
CLI、Web API、批处理、数据脚本，对 JIT 的受益方式完全不同。有的更看重启动，有的更看重热点循环，有的更看重稳定吞吐。
第四，把 profiler 当长期工具。
3.15 新 profiler 真正有价值的地方，不是为了做一轮演示，而是让性能观测更适合固定进 CI 和例行回归。
3. 一套更靠谱的实验流程
第一步，挑三类真实工作负载。
一个 Web 服务、一个 CLI 或运维脚本、一个批处理或数据任务。不要只拿微基准自我安慰。
第二步，固定实验矩阵。
写清楚 Python 版本、平台、架构、容器规格、是否启用 JIT、样本数量、warmup 次数。没有矩阵，实验就不可复现。
第三步，把 profiler 输出保存成工件。
别只比一个总耗时。热点函数是否变化、调用路径是否变化，同样重要。
第四步，区分启动面和稳态面。
JIT 的收益可能主要在稳态，lazy imports 则更偏向启动。两者必须拆开看，不能糊成一个“整体快了没有”。
第五步，把依赖兼容一并检查。
监控 SDK、C 扩展、profile hook、类型检查工具，都会影响观察结果。别把所有波动都甩锅给解释器本身。
4. 现在最常见的错误判断
一个错误是“看见提升就准备默认开”。
没有分架构、分负载、分阶段的数据支撑，这种结论很容易变成误判。
另一个错误是“没看到明显提升，就说明不值得跟”。
很多时候问题不在版本，而在你的实验压根没对上真实热点。
5. 建议本周执行的动作
- 为主要生产架构建立独立实验矩阵。
- 把 warmup 和稳态指标分开统计。
- 在 CI 里固定保留 profiler 工件。
- 选 3 类真实负载做 3.15a7 对照实验。
- 在版本评估会上只讨论可复现数据，不讨论“感觉快了”。
6. 结语
Python 3.15 这轮性能更新最大的价值，不只是让 JIT 终于重新站稳，而是逼团队承认：过去那种“一次 benchmark 定输赢”的做法已经不够用了。真正成熟的团队，会借这次机会把实验方法做扎实。方法先变好，后面的结论才值得信。
参考资料
- Python Insider: Python 3.15’s JIT is now back on track
https://blog.python.org/ - Python Insider: Python 3.15.0 alpha 7
https://blog.python.org/2026/03/python-3150-alpha-7/
