Python递归深度限制是CPython为防C栈溢出设的防护机制，默认1000层，与线程栈大小相关而非物理内存；调高sys.setrecursionlimit不增加真实栈空间，多线程或隐式递归下易致段错误；安全做法是预估深度、检查栈限、尽早设置并兜底；DFS等场景应优先转迭代。
Python 的递归深度限制不是 bug，而是 CPython 解释器为防止 C 层栈溢出设的主动防护机制。默认 1000 层，超了就抛 RecursionError: maximum recursion depth exceeded，而不是等程序静默崩溃。
为什么默认是 1000？它跟内存有关吗
无关物理内存，只跟操作系统分配给线程的 C 栈大小有关（Linux 默认约 8MB，Windows 更小）。每层递归至少占 1–2KB 栈帧，1000 层 ≈ 1–2MB，留了足够余量防爆栈。设太高可能不报错就 Segmentation fault 或直接被 OS 杀掉（Killed: 9）；设太低又容易误伤正常嵌套结构（比如解析 500 层深的 JSON）。
sys.setrecursionlimit() 能不能随便调高
不能。调高只是改解释器的计数阈值，不增加真实栈空间。以下情况尤其危险：
- 在多线程环境里全局调用
sys.setrecursionlimit()，子线程栈更小，实际能撑的层数反而更低 - 没检查是否已有隐式递归（比如
__str__里打印自身、装饰器嵌套、日志钩子触发再进入同一函数） - 直接设成
sys.setrecursionlimit(100000)去硬扛 DFS 遍历——大概率还没报RecursionError就段错误了
哪些场景真需要调限？怎么安全操作
仅适用于：递归逻辑干净、深度可预估、且远低于系统栈上限的少数情况，比如解析用户提交的嵌套 YAML（已知最多 200 层）。
立即学习“Python免费学习笔记（深入）”；
- 先查当前限制：
sys.getrecursionlimit() - 用
resource.getrlimit(resource.RLIMIT_STACK)（Unix）或threading.stack_size()（跨平台）确认可用栈空间 - 按「每层 ≈ 1.5KB」估算安全上限，例如 4MB 栈 → 建议设
sys.setrecursionlimit(3000)，而非 10000 - 必须在
if __name__ == '__main__':里尽早设置，并加try/except RecursionError回滚兜底
比调限更靠谱的解法：什么时候必须转迭代
遇到以下任一情况，别碰 setrecursionlimit，直接重写：
- DFS 遍历树/图/目录：用
stack = [root]+ 循环 pop/push 替代函数调用 - 回溯类算法（N 皇后、全排列）：把路径状态存列表里，进/出栈由循环控制
- 解析 AST、JSON-like 结构：压入待处理子节点，而非递归调用
- 有多个递归分支（如二叉树中序遍历），或非尾递归（Python 不支持 TCO）
迭代版本内存开销明确、可调试、不依赖解释器栈管理——这才是生产环境该依赖的写法。
