python 3.11 的调用栈帧优化显著提升递归性能，因每层递归节省约80字节内存并加速帧创建/销毁，深度越大收益越线性；该优化依赖纯递归路径，遇try/yield/frame.f_back等会失效。
Python 3.11 的调用栈帧优化对递归程序影响巨大，根本原因在于：**每层递归都省下约 80 字节内存 + 更快的帧创建/销毁路径，深度越大，收益越呈线性放大**。这不是微调，而是解释器底层结构的重构。
为什么递归特别吃帧对象大小？
每次函数调用（包括递归）都会新建一个 PyFrameObject。在 Python 3.10 中，这个结构体是“全量预分配”的：哪怕你只写 def f(n): return n if n ，帧里也提前预留了 <code>f_exc_info、f_trace、f_gen 等字段空间（约 240 字节）。递归 10000 层，就多占近 1MB 冗余内存。
3.11 改为“最小基础帧 + 按需扩展”：只保留 f_code、f_localsplus、f_lasti 等核心字段（约 160 字节），其他非常规字段仅在真正触发时才附加。
- 纯递归函数几乎从不进
try、不设breakpoint()、不含yield—— 所以绝大多数递归帧始终维持最小形态 - 帧分配更快：少了大量字段初始化和内存清零操作
- GC 压力更小：更小的对象 + 更少的指针域，提升垃圾回收效率
哪些递归场景受益最明显？
不是所有递归都一样快。以下场景在 3.11 中提速显著：
-
fibonacci(35)这类纯计算递归：实测耗时从 3.10 的 ~1.7s 降到 ~0.85s（约 50% 加速） - 深度 > 5000 的树遍历或回溯算法：内存占用下降直接避免
RecursionError或 OOM - FastAPI/Starlette 路由中高频中间件链（如 auth → logging → validation → handler）：每请求触发数十次短生命周期递归调用，帧轻量让整体堆分配压力明显缓解
注意：一旦递归函数里加了 try 块、用了 yield、或手动访问 frame.f_back，该帧就会被“拉满”到接近 3.10 的体积 —— 优化失效。
为什么 sys._getframe() 看不出帧变小？
因为 sys._getframe() 是调试接口，它会强制触发帧的“完全初始化”：为了让你能安全读取 f_back、f_trace 等字段，解释器会立刻补全所有可选字段。你看到的是“已破功”的帧，不是真实运行中的轻量帧。
验证真实效果，得看：
- 用
python -m pyperf timeit对比同一递归函数在 3.10 和 3.11 下的耗时与内存 RSS - 在无调试、无异常、无生成器的纯递归路径中观察
sys.getsizeof()返回值（但注意：它返回的是当前帧实际占用，非预估） - 用
tracemalloc统计递归过程中的总内存分配峰值
真正关键的不是“单帧省了多少”，而是“递归深度 × 单帧节省”带来的线性收益。只要你的递归不主动触发扩展条件，3.11 就默默帮你扛住了调用栈的膨胀压力 —— 这种优化藏在解释器深处，你不用改代码，但它就在那儿。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
