Python默认递归深度1000，遍历深度超限树会触发RecursionError；强行调高限制有崩溃和内存风险；应优先用栈迭代替代递归，并在树构建阶段校验深度。
Python默认递归深度只有1000，远不够深树遍历
Python解释器为防止无限递归耗尽内存，默认设了sys.setrecursionlimit(1000)。一棵高度为1200的退化链（即每个节点只有右孩子），递归遍历必然触发RecursionError: maximum recursion depth exceeded。这不是你代码逻辑错，是Python主动“叫停”——它连栈帧都懒得给你分配第1001个了。
常见误判是以为“加个sys.setrecursionlimit(10000)就万事大吉”，但实际会带来两个风险：一是C层栈溢出导致Python进程直接崩溃（Segmentation Fault）；二是内存占用线性增长，可能拖慢整个服务。
- 真实项目中，线上树高超过500就该警惕，别等报错才反应
- 调试时可用
sys.getrecursionlimit()查当前限制，用len(inspect.stack())看当前调用栈深度 - 不要在生产环境无条件调高限制——它治标不治本，还掩盖了结构隐患
用栈手动模拟递归是最稳的规避方式
递归本质是系统帮你维护一个调用栈，而迭代法就是你自己拿list或collections.deque来存“还没处理完的节点+上下文”。前序遍历为例，关键不是“能不能写出来”，而是三处细节必须对齐原递归语义：
-
stack里存的是待访问节点，不是节点值 - 压栈顺序要反着来：想先处理左子树，就得先压右、再压左（因为栈是LIFO）
- 每次
pop()后立刻处理当前节点，再把它的孩子按需入栈——这对应递归里“访问当前节点”那一步
示例（中序迭代）：
立即学习“Python免费学习笔记（深入）”；
def inorder_iterative(root):
stack = []
result = []
current = root
while stack or current:
while current:
stack.append(current)
current = current.left
current = stack.pop()
result.append(current.val)
current = current.right
return result
注意：current = current.right之后不会立即进入下一轮循环，而是由外层while控制是否继续压栈——这点和递归里“调用完左子树，自动回到当前节点执行右子树”完全等价。
递归写法本身也能加固，但有硬边界
如果你非得用递归（比如快速验证逻辑、算法原型），至少做三件事堵住常见漏洞：
- 终止条件必须是
if not node:，而不是if node is None——前者兼容node为False值（如数值0），后者在某些构造场景会漏判 - 所有递归调用前加空检查：
if node.left: dfs(node.left)，避免无效调用徒增栈深 - 对已知深度上限的场景（如BST插入），可在函数开头加深度计数器：
def dfs(node, depth=0): if depth > MAX_DEPTH: return
但请记住：加固递归只是延缓爆栈，不能突破Python解释器的底层栈空间限制。真正可靠的方案永远是切换到迭代。
最容易被忽略的点：树结构本身可能就是病态的
很多人排查半天，最后发现根本不是代码问题，而是输入树本身就是一条超长链。比如从数据库加载的父子关系数据没做层级校验，或者BST在频繁插入相同值后退化。这种情况下，哪怕你写了完美的迭代遍历，单次遍历耗时也会随深度线性增长，影响响应延迟。
建议在树构建/加载阶段就加保护：def validate_depth(node, max_depth=1000): return node is None or (validate_depth(node.left, max_depth-1) and validate_depth(node.right, max_depth-1))。宁可早期拒绝异常深的树，也不要让它流到遍历环节。
