CPython解释器优化聚焦字节码生成、对象复用、缓存及执行路径精简，不进行编译器级优化；python -O仅移除assert和__debug__代码；3.11+引入自适应特殊化机制，但需预热且对I/O或Cython代码无效。
Python 解释器优化主要指 CPython 的运行时改进，不是编译器级优化
CPython 本身不进行函数内联、循环展开这类传统编译器优化。它核心的“优化”集中在字节码生成、对象复用、缓存机制和执行路径精简上，目标是降低解释开销，而非生成更高效的机器码。
常见误解是以为 python -O 会做激进优化——其实它只移除 assert 语句和 __debug__ 相关代码，不改变执行逻辑或性能。
字节码层面的典型优化：常量折叠与 None 检查简化
CPython 在编译阶段（compile()）会对字面量表达式做静态化处理，比如 2 + 3 * 4 直接编译成 LOAD_CONST 14，而不是保留四条操作码。
-
None比较被特化为IS_OP（3.12+）或COMPARE_OP == 8（旧版），比通用==快且不可被重载干扰 - 小整数（-5 到 256）和短字符串在创建时直接复用已有对象，避免重复分配
-
for x in [1, 2, 3]中的列表字面量会被转为元组常量，避免每次迭代都新建 list 对象
运行时热点优化：自适应解释器（PEP 659）在 3.11+ 的实际影响
3.11 引入的“快速调用协议”和“特殊化（specialization）”机制，让解释器能根据实际运行类型动态替换字节码指令。例如，连续多次对同一对象调用方法，会把 CALL_METHOD 替换为 CALL_METHOD_KW 或更专用的 CALL_METHOD_ADAPTIVE，跳过类型检查和查找开销。
立即学习“Python免费学习笔记（深入）”；
但这依赖于“预热”：前几次调用仍走通用路径；若类型不稳定（比如参数有时是 int 有时是 str），特殊化会失效并退回到通用指令。
- 可通过
sys._getframe().f_lasti和dis.dis()观察指令是否被替换 - 禁用该机制可用
PYTHONNOADAPTIVE=1环境变量，用于性能对比 - 对 I/O 密集或已用 Cython 加速的代码，收益几乎为零
容易被忽略的“伪优化”陷阱
很多看似优化的操作反而拖慢速度：比如手动缓存 len(seq) 却没考虑 seq 是 generator；或用 list.append 赋值给局部变量来“加速”，却忽略了属性查找本身也有开销（3.11+ 已对此做部分消除）。
-
from math import sqrt比math.sqrt快，但仅当高频调用且未启用自适应时明显；3.12 中两者差距大幅缩小 -
str.format在简单场景下比 f-string 慢，因为要解析格式字符串；而 f-string 编译期就固化了大部分逻辑 - 过度使用
__slots__可能破坏 pickle 兼容性，且对只有几个实例的对象几乎无内存优势
真正影响性能的往往是算法复杂度、I/O 阻塞或 GIL 争用，而不是解释器那几纳秒的指令差异。盯着 LOAD_FAST 和 LOAD_GLOBAL 的区别调优，通常意味着该看 profile 数据了。
