Python 3.11 性能提升真实有效，平均提速约25%，核心在于自适应解释器对热点字节码（如CALL_FUNCTION、LOAD_ATTR）的运行时特化，以及零成本异常、内置函数内联和math/statistics模块优化，但仅当代码密集触碰这些优化路径时才显著生效。
Python 3.11 的性能提升不是幻觉，而是解释器底层被重写了关键路径——它确实能让你不改一行业务代码就提速 25% 左右，但前提是你的代码落在优化覆盖范围内。
自适应解释器如何让热点代码自动变快
Python 3.11 不再对所有字节码“一视同仁”。它会在运行时监控函数调用频次、循环执行次数等指标，一旦识别出某段代码是“热点”（hot），就会把原始字节码替换成特化版本，比如把 CALL_FUNCTION 替换为更轻量的 CALL_FUNCTION_EX 变体，跳过部分栈帧检查。
- 典型受益场景：高频小函数调用（如
map()、filter()内的 lambda）、内层循环中的方法调用 - 不生效的情况：IO 等待占主导的代码（如
requests.get()、open().read()）、C 扩展主导的计算（如 NumPy 向量化操作） - 验证方式：用
python -m pyperf timeit对比同一段逻辑在 3.10 和 3.11 下的耗时，注意关闭 ASLR（setarch $(uname -m) -R python ...）避免抖动干扰
零成本异常（zero-cost exception）的真实含义
“零成本”不是说 try 块完全没开销，而是指：当没有异常抛出时，try 块的进入和退出几乎不产生额外指令开销。这得益于 3.11 把异常处理元信息从栈帧中剥离，改用独立的表结构管理。
- 明显受益点：大量使用
try/except包裹简单操作的代码（如解析配置、读取可选字段） - 陷阱：如果
except块里做了复杂逻辑（比如日志序列化、网络上报），那“零成本”只到异常抛出那一刻，后续处理仍要算时间 - 对比错误写法：
except Exception as e: logging.error(str(e))—— 字符串化e可能触发完整 traceback 构建，3.11 虽优化了 traceback 生成，但不如直接用logging.exception()
内置函数内联与 math/statistics 模块的静默加速
3.11 对部分高频内置函数（如 len()、isinstance()、dict.get()）做了调用内联，同时重写了 math.comb()、statistics.mean() 等函数的底层实现，减少中间对象分配。
立即学习“Python免费学习笔记（深入）”；
- 可感知的提速点：
list.append()在扩容策略上更激进，减少了多次 realloc；dict对全 Unicode 键的内存占用下降约 12% - 需注意：这些优化对用户代码透明，但如果你手动实现了类似逻辑（比如自己写了个
my_mean()），不会自动获得加速 - 一个易忽略细节：
tomllib.load()解析 TOML 比第三方toml包快，但仅限于纯文本解析；若需支持注释或扩展语法，仍得用第三方库
真正决定你能否拿到“25% 加速”的，不是 Python 版本号本身，而是你的代码是否密集触碰了 3.11 重点优化的那些字节码路径和 C 函数入口——很多团队测完发现只快了 8%，回头一看，主力耗时都在数据库查询和 JSON 序列化上，而这部分早在 3.9 就已由 ujson 或 orjson 解决了。
