不能只靠调高阈值，因为强行突破 recursion limit 可能导致 C 层栈溢出、Segmentation fault 或静默崩溃；应优先改写为迭代，必要时再结合栈空间评估与实测谨慎调限。
为什么 RecursionError: maximum recursion depth exceeded 不能只靠调高阈值？
直接调用 sys.setrecursionlimit(10000) 确实能绕过报错，但这是在掩盖栈溢出风险——Python 的默认限制（通常 1000）是 CPython 解释器为防止 C 层栈崩溃设的安全边界。强行拉高后，可能触发 Segmentation fault 或静默崩溃，尤其在递归深度接近系统线程栈上限（Linux 默认 8MB，Windows 更小）时。
真正该做的是：先确认是否真需要深层递归；如果不是尾递归且无状态累积，优先改写为迭代；如果必须递归，再评估是否值得调限。
调限前必须检查的三个条件
盲目调限等于埋雷。执行 sys.setrecursionlimit() 前，请确认：
- 当前递归实际深度是否已远超业务合理范围（比如遍历 10 万节点的树，却用朴素递归）
- 目标平台是否允许足够大的线程栈（
ulimit -s在 Linux 查看，Windows 需改启动参数） - 是否已用
sys.getrecursionlimit()和len(inspect.stack())实测过当前调用链深度，排除意外嵌套（如装饰器、异常处理、日志钩子引入的隐式递归）
安全调限的实操步骤
若确认必须调限，按以下顺序操作，缺一不可：
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
- 用
resource.getrlimit(resource.RLIMIT_STACK)（Unix）或threading.stack_size()（跨平台）预估可用栈空间 - 按「每层递归约 1–2KB 栈开销」粗略估算安全上限，例如 4MB 栈 ≈ 2000–4000 层，设为
sys.setrecursionlimit(3000)而非 10000 - 在
if __name__ == '__main__':块内尽早设置，避免被第三方库提前触发递归 - 加兜底保护：
import sys old_limit = sys.getrecursionlimit() try: sys.setrecursionlimit(3000) # your recursive code except RecursionError: sys.setrecursionlimit(old_limit) raise
比调限更可靠的替代方案
90% 的 RecursionError 场景，改用迭代或生成器更稳妥：
- 树/图遍历：用显式栈（
list）或队列（collections.deque）替代函数调用栈 - 分治算法（如快排）：手动维护待处理区间列表，避免左右子递归嵌套
- 需要回溯的状态：把局部变量转为循环内的可变容器（如
path = []），用append()/pop()模拟入栈/出栈 - 无法改写的纯递归逻辑（如某些数学定义）：考虑用
functools.lru_cache缓存中间结果，减少重复递归分支
真正难处理的，是那些既深度大、又无法缓存、还依赖调用栈隐式状态的递归——这时候调限不是捷径，而是最后手段，且必须配合栈大小调优和压力测试。
