Python 3.11 的速度提升源于解释器运行时字节码特化：调用约53次后，BINARY_OP等通用指令被原地替换为类型专用指令（如BINARY_OP_ADD_INT），跳过类型分发；Fast Call Protocol精简函数调用路径；类型突变时自动惰性去特化，全程透明且无需改代码。
Python 3.11 的速度提升不是靠你改代码，而是解释器在你运行时悄悄重写了字节码——只要某段逻辑被调用约 53 次，它就开始特化；类型一变，又自动回退。这过程完全透明，但效果真实可测。
特化指令怎么生成的？看 BINARY_OP 变成 BINARY_OP_ADD_INT
解释器不会一开始就用最快路径。它先让 BINARY_OP 这类通用指令跑一阵，同时监控操作数类型。一旦发现连续几次都是整数相加，就在内存里把这条指令原地替换成 BINARY_OP_ADD_INT——后者直接调用 C 层整数加法，跳过 PyNumber_Add 分发和类型检查。
- 替换发生在运行时，不修改源码、不重新编译
.pyc - 必须达到 warm-up 阈值（默认约 53 次调用），可通过
_PyCode_Warmup调整 -
dis.dis(func, adaptive=True)能看到特化后的指令名，但要确保模块已 reload，否则显示的是旧字节码
为什么小函数调用快了 50%？Fast Call Protocol 绕过了什么
老版本调用函数要建栈帧、拷贝参数、查 __call__、准备异常上下文——哪怕只是 lambda x: x+1。3.11 引入 Fast Call Protocol，对固定参数个数、无 *args/**kwargs 的函数，直接走精简路径。
- 预分配帧结构，减少 malloc 频次
- 跳过部分参数类型校验（类型已在特化阶段确认过）
- 递归场景下收益尤其明显，比如
fibonacci(35)在 3.11 耗时约 0.85 秒，3.10 是 1.7 秒
类型突变了怎么办？de-specialize 不是崩溃，而是懒回退
特化不是赌一把就完事。当 BINARY_OP_ADD_INT 突然收到字符串，解释器不会报错或卡死，而是立即触发惰性去特化（de-specialize），退回通用 BINARY_OP 路径继续执行。
立即学习“Python免费学习笔记（深入）”；
- 去特化只影响当前指令，不影响其他已特化的指令
- 整个过程无额外开销：没发生类型突变时，连判断逻辑都不执行
- 这也是为什么你不用加 decorator、不用改语法——安全边界由解释器 runtime 动态兜底
真正容易被忽略的点是：这些优化只对“热代码”生效，冷路径（比如只执行一次的初始化逻辑）几乎不受益；而热代码是否够热，取决于实际运行时的调用频次和类型稳定性，不是看代码写得多简洁。
