python 中 `@lru_cache` 的底层 c 实现会额外消耗 c 栈空间，导致即使 python 层递归深度相同，c 层栈仍可能溢出；而纯 python 递归在 3.11+ 已通过内联调用优化避免 c 栈增长，因此能安全处理数十万级深度。
在解决树形动态规划（如 CSES “Subordinates” 问题）时，你可能会惊讶地发现：逻辑完全一致的递归代码，仅因是否使用 @lru_cache，就从稳定运行变为直接崩溃（exit code 0xC00000FD）。这并非算法或复杂度差异所致，而是 Python 运行时底层机制的关键区别。
? 根本原因：Python 栈 vs C 栈
-
普通递归（无装饰器）：
自 Python 3.11 起，解释器引入了 Inlined Python Function Calls。当一个 Python 函数调用另一个 Python 函数时，不再进入 C 层解释循环（PyEval_EvalFrameDefault），从而几乎不消耗 C 调用栈空间。你的 dfs() 即使递归 20 万层，也只占用 Python 堆上的帧对象（受 sys.setrecursionlimit 管控），而 C 栈保持极浅。 -
@lru_cache 递归：
functools.lru_cache 在 CPython 3.11/3.12 中是 C 实现（_functoolsmodule.c）。每次缓存命中或未命中，都会触发 C 函数调用链（如 lru_cache_wrapper_call → 你的 dfs → 再次 lru_cache_wrapper_call…）。这意味着：
✅ Python 层递归深度 = N
❌ C 层递归深度 ≈ 2×N（每层 Python 调用夹带一层 C 包装器调用）
而主流操作系统默认 C 栈大小仅约 8 MB，对应 C 递归深度通常仅 数千至一两万层 —— 20 万层必然触发 SIGSEGV（Windows: 0xC00000FD，Linux: SIGSEGV 或 SIGABRT）。
? 验证与对比（Python 3.11 行为）
import sys
sys.setrecursionlimit(2 * 10**6) # 尝试设极高限制
# ✅ 安全：纯 Python 递归（C 栈几乎不增长）
def dfs_safe(v):
if v >= 200000: return 0
return 1 + dfs_safe(v + 1)
# ❌ 崩溃：lru_cache 引入 C 层递归
from functools import lru_cache
@lru_cache(None)
def dfs_crash(v):
if v >= 200000: return 0
return 1 + dfs_crash(v + 1)
? 提示：在 Python 3.12 中，sys.setrecursionlimit() 仅作用于 Python 层，C 层递归由独立保护机制截断（抛出 RecursionError 而非崩溃），但依然无法突破 C 栈物理限制。
✅ 解决方案：绕过 C 层，用纯 Python 缓存
若必须缓存且需超深递归，可替换为纯 Python 实现的简易 lru_cache：
def simple_cache(_):
def decorator(func):
memo = {}
def wrapper(x):
if x not in memo:
memo[x] = func(x)
return memo[x]
return wrapper
return decorator
# 替换 @lru_cache(None) 为 @simple_cache(None)
@simple_cache(None)
def dfs(v: int) -> int:
if not graph[v]:
return 0
return sum(dfs(u) + 1 for u in graph[v])
此版本完全运行在 Python 层，享受 3.11+ 的内联优化，20 万层递归毫无压力。
