调高 sys.setrecursionlimit 无法真正避免栈溢出，仅推迟崩溃点；它不扩展系统线程栈，超限仍致进程不可捕获崩溃，多线程和跨实现下更不可靠。
不能靠 sys.setrecursionlimit 真正“避免”递归栈溢出——它只是把崩溃点往后挪，而真正的溢出风险和底层限制没变。
为什么调高 sys.setrecursionlimit 很危险
Python 默认递归限制（通常 1000）是保守值，主要为防止意外无限递归耗尽 C 栈。C Python 解释器本身依赖系统线程栈，而 sys.setrecursionlimit 只改 Python 层的计数器，不扩展实际栈空间。一旦超出系统栈容量（Linux 默认 8MB，Windows 更小），会直接触发 Segmentation fault 或 EXCEPTION_STACK_OVERFLOW，进程崩溃，无法捕获。
- 调到 10000 可能在 macOS 上跑通，但在某些 Docker 容器或低内存 Windows 机器上立即崩溃
- 多线程环境下，每个线程共享同一栈大小，但
sys.setrecursionlimit是全局生效，容易误伤其他线程逻辑 - PyPy、Jython 等实现对递归限制行为不同，设了也未必起效
什么场景下可以谨慎调用 sys.setrecursionlimit
仅适用于：已确认递归深度可预测、且远低于系统栈硬限；同时无法改写为迭代；且运行环境可控（如本地脚本、CI 单测）。
- 示例：解析深度 ≤ 500 的嵌套 JSON 或 AST 节点，原始递归写法清晰，又没时间重构成栈模拟
- 必须配合
try/except RecursionError做兜底，不能只设不限制 - 建议用
resource.getrlimit(resource.RLIMIT_STACK)（Unix）粗略估算可用栈余量，再决定设多少 - 设置后应立即用小深度测试是否真生效：
def f(n): return 1 if n + <code>f(2000)
比 sys.setrecursionlimit 更靠谱的替代方案
真正解决栈溢出，得绕开递归本身：
- 尾递归？Python 不优化尾调用，
return f(x)和f(x); return没区别，别信装饰器“优化” - 手动转迭代：用
list或deque模拟调用栈，把参数和状态存进去，循环处理 —— 这才是可控、可 debug 的做法 - 生成器 +
yield from：适合遍历类树结构，内存友好，但不减少调用深度 - 用
sys.settrace动态监控当前深度，提前抛异常，比等崩溃强
递归深度问题本质是算法结构问题，不是参数开关能修好的。系统栈边界模糊、跨平台差异大、错误不可恢复——这些才是你调试时最可能卡住的地方。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
