直接调高sys.setrecursionlimit()不是正解，多数情况说明算法缺陷或栈设计不合理；递归爆栈主因是CPython默认深度限1000，为防无限递归崩溃，真实瓶颈常为调用链过长、无尾递归优化或误用递归；应优先改迭代，显式维护状态栈，避免Segfault风险。
直接调高 sys.setrecursionlimit() 不是正解，多数情况下说明算法本身存在缺陷或栈空间设计不合理。
为什么递归会爆栈？不是代码写错了，而是Python默认限制太保守
CPython 默认递归深度上限是 1000（可通过 sys.getrecursionlimit() 查看），这个值不是硬件限制，而是为防止无限递归耗尽 C 栈导致解释器崩溃。但真实瓶颈往往在：函数调用链过长、尾递归未优化、或本该用迭代的地方硬套递归。
- 常见错误现象：
RecursionError: maximum recursion depth exceeded while calling a Python object - 典型场景：遍历深度超过 1000 层的树/嵌套字典、用递归实现快速排序处理万级数组、解析深层嵌套 JSON
- 注意：
sys.setrecursionlimit(10000)可能暂时“解决”报错，但可能引发Segmentation Fault（尤其在 macOS/Linux 上），因为 OS 级栈空间没跟着变
优先改写为迭代——不是为了炫技，是绕过解释器限制
几乎所有递归逻辑都能转成迭代，关键是把“待处理状态”显式存到栈或队列里。Python 的 list 做栈足够快，且不受递归深度限制。
- 示例：二叉树深度优先遍历（递归版易爆栈）→ 改用
stack = [(root, 0)]存节点+当前深度 - 嵌套字典扁平化：别写
flatten(d)递归调用自身，改用stack = list(d.items())+ 循环展开 - 优势：内存更可控、调试更直观、性能通常更好（省去函数调用开销）
必须用递归时，检查三个关键点
如果业务逻辑强耦合递归（如某些数学定义、语法树遍历），先确认是否真无法避免，再排查：
立即学习“Python免费学习笔记（深入）”；
- 有没有隐式递归？比如重载了
__getattr__或__getattribute__，访问属性时又触发自身，形成死循环 - 递归终止条件是否严格？
if n 比 <code>if n == 0: return更安全，避免负数输入失控 - 参数是否在收敛？比如每次递归传入
n//2是 OK 的，但传入n-0.5或未变化的n就会卡住
真的要调 limit？只在明确知道后果时才动
仅限以下情况可谨慎调整：sys.setrecursionlimit() 设置后需同步验证实际栈使用，且必须配合 try/except 防崩。
- 先测当前最大安全值：
import resource; resource.getrlimit(resource.RLIMIT_STACK)（Linux/macOS） - 临时提高仅对当前线程有效，多线程下每个线程需单独设
- 生产环境禁止无条件设成 100000 —— 这等于把问题从 Python 层推给操作系统，出事更难定位
真正难的不是把数字调大，而是判断哪一层调用在拖慢栈增长；有时候一个没清空的闭包变量，会让整个递归链多留 10 层帧，这种细节比 limit 数值重要得多。
