RecursionError 是程序直接崩溃而非警告，Python 默认递归深度约1000层且不支持尾递归优化；应优先用迭代替代递归，显式维护栈结构，并针对重复子问题使用@lru_cache优化。
RecursionError 不是警告，是程序直接崩溃。Python 默认递归深度约 1000 层，且不支持尾递归优化（TCO）——哪怕你把 return 写成纯尾调用形式，CPython 解释器仍会为每次调用分配新栈帧。
用迭代替代递归：最可靠、最通用的解法
递归本质是隐式维护一个“调用栈”，而你可以用 list 或 collections.deque 显式模拟它。这不是“代码变丑”，而是把控制权拿回来。
- 前序遍历二叉树：压栈顺序必须和递归调用顺序相反——先压右子节点，再压左子节点，才能保证左先处理
- DFS 路径搜索类问题：栈中存的不是单个节点，而是
(node, path_so_far, depth)这样的元组，把原递归中的局部变量显式带进去 - 避免用
sys.setrecursionlimit()“治标”：它只是把栈上限调高，但可能触发底层段错误（segmentation fault），且无法跨平台稳定生效
加 @lru_cache 缓存：专治重复子问题
像 fibonacci(n)、levenshtein(s1, s2) 这类有大量重叠子问题的递归，不加缓存就是指数级爆炸；加了之后，时间复杂度常能降到 O(n) 或 O(m×n)。
-
@lru_cache(maxsize=None)是最常用写法，缓存全量结果；若内存敏感，可设具体数值（如maxsize=128） - 函数参数必须是不可变类型（
int、str、tuple），否则抛TypeError - 注意：缓存不会自动失效，若输入依赖外部状态（如全局变量、文件内容），结果可能错而不自知
改写为尾递归形式：仅作逻辑整理，不解决栈问题
把 return n * factorial(n-1) 改成 return factorial_tail(n-1, n * acc)，能让递归结构更清晰、便于人工转迭代，但它在 Python 里完全不减少栈消耗。
立即学习“Python免费学习笔记（深入）”；
- 这种写法真正的价值是：帮你识别出“状态可线性展开”的模式，为下一步手动转循环铺路
- 别用第三方装饰器（如
tail_call_optimized）骗自己——它们靠抛异常+捕获+手动跳转模拟 TCO，行为不可预测，且破坏调试体验 - 如果函数本身不是单路递归（比如树的中序遍历），强行塞进尾递归框架只会让代码更难懂、更难维护
真正卡住多数人的，不是“会不会写迭代”，而是没意识到哪些递归能/该被替换。比如处理嵌套 JSON 深度达 500 层的对象时，用递归解析器几乎必然崩；但换成基于 stack 的状态机解析，既可控又可加超时和深度限制。这类细节，往往在日志报出第一个 RecursionError 前就被忽略了。
