Python 3.11 的提速是自动触发的，无需修改代码，仅对高频执行的字节码（如 CALL_FUNCTION、LOAD_ATTR）优化，IO 和 C 扩展逻辑不受影响；需用 pyperf 验证，关注热点路径与特化状态。
Python 3.11 的提速不是“开关式”的，而是自动触发的
你不需要改代码、不用加装饰器、也不用调用新 API——只要把解释器升级到 3.11，大部分原有代码就能在热点路径上自动获得加速。关键在于：它只对真正高频执行的字节码生效，比如 CALL_FUNCTION、LOAD_ATTR、FOR_ITER 这些指令；IO 或 C 扩展主导的逻辑（如 requests.get()、numpy.dot()）基本不受影响。
常见错误现象：有人跑完 timeit 发现没提速，就以为“3.11 是营销噱头”。其实很可能测试样例太短、没形成热点，或者压根不在优化范围内。
- 验证前先关掉 ASLR：
setarch $(uname -m) -R python -m pyperf timeit "sum(range(1000))" - 避免单次运行：用
pyperf跑至少 5 轮 warmup + 10 轮测量 - 对比时确保环境一致：同一台机器、相同依赖版本、关闭后台干扰进程
哪些代码能明显受益？看这三类典型场景
提速最明显的不是“大计算”，而是“小而密”的操作模式。核心判断标准是：单位时间内某条字节码是否被反复执行上千次以上。
-
高频函数调用：比如
map(lambda x: x * 2, data)中的 lambda、sorted(items, key=lambda x: x.name)里的 key 函数 -
属性访问密集型：循环里反复读取对象字段，如
for user in users: name = user.full_name; email = user.email -
大量 try/except 包裹简单逻辑：比如解析 JSON 字段时写一堆
try: val = obj.get("x") except: val = None—— 3.11 的“零成本异常”让这种写法开销大幅下降
注意：except Exception as e: 后跟 str(e) 仍可能触发完整 traceback 构建，建议改用 logging.exception() 或直接 raise。
立即学习“Python免费学习笔记（深入）”；
别碰这些“伪加速点”，它们不归 Faster CPython 管
很多开发者误以为升级后所有地方都变快了，结果在不该花力气的地方折腾。Faster CPython 不负责以下环节：
- 磁盘 IO 或网络等待：
open("large.log").read()、httpx.get("https://api.example.com")的耗时不会因 3.11 改变 - 纯 C 实现的库运算：
numpy.array([...]).sum()、pandas.DataFrame.groupby(...)的瓶颈在底层 C/Fortran，不在 Python 解释器 - 你自己写的等效函数：
def my_mean(xs): return sum(xs) / len(xs)不会自动获得statistics.mean()那种内联加速 - 冷代码路径：启动阶段加载模块、一次性初始化逻辑，几乎不会被特化
一个易忽略细节：tomllib.load() 解析 TOML 确实比第三方 toml 包快，但仅限于标准语法；带注释或自定义扩展的文件仍得靠第三方库。
调试和确认是否真被特化了？用这两个命令
想看到解释器到底做了什么，不能只看最终耗时，得进字节码层观察特化状态。
- 查看某段代码是否被特化：
PYTHONDEVMODE=1 python -X dump_code -c "lambda x: x.a + x.b"，输出里出现SPECIALIZED表示成功 - 统计整个模块的字节码执行情况：
python -X show_opcode_stats -m your_module，重点关注LOAD_ATTR和CALL_FUNCTION的 hit rate 和 failure reason
真实陷阱：-X dump_code 输出极长，容易漏看关键行；建议配合 grep SPECIALIZED 或 less 分屏查看。特化失败常见原因是类型不稳定（比如同一个 obj.attr 有时返回 int、有时 str），这时解释器会退回到通用路径。
