sys.getrecursionlimit()返回Python层递归计数阈值，默认1000，对应CPython防栈溢出的安全边界；实际可用深度受系统线程栈限制，以二者最小值为准。
如何用sys.getrecursionlimit()确认当前限制值
直接运行sys.getrecursionlimit()就能看到解释器当前允许的最大递归深度，默认通常是1000。这个值不是凭空定的，它对应着CPython为防止C栈溢出设的安全边界——每层递归约占1–2KB栈空间，1000层≈1–2MB，已预留余量。
注意：sys.getrecursionlimit()返回的是Python层计数阈值，不等于真实可用栈大小。Linux下可用resource.getrlimit(resource.RLIMIT_STACK)查系统线程栈上限，Windows则需看threading.stack_size()。两者不一致时，以更小者为准。
为什么不能只靠try/except RecursionError捕获来兜底
RecursionError是解释器在压栈前做的计数拦截，但一旦触发，调用栈往往已接近崩溃边缘。此时再进except块本身又需要新栈帧，可能直接导致Segmentation fault或静默退出，尤其在macOS或某些PyPy构建中。
- 隐式递归（如
__str__里打印自身、装饰器嵌套、日志钩子）可能绕过你的try包裹，直接爆栈 - 多线程环境下，主线程调了
sys.setrecursionlimit()，子线程仍按默认栈大小运行，实际可承受深度更低 - 错误信息
RecursionError: maximum recursion depth exceeded while calling a Python object常意味着你已在递归链中，不是第一层就崩了
用显式深度计数器做主动守卫
比等报错再处理更可靠的方式，是在递归函数入口加一个可配置的深度参数，并在每次调用时递增检查。这能提前截断、打日志、降级或抛出自定义异常，便于定位问题源头。
示例：
def parse_nested_dict(d, depth=0, max_depth=500):
if depth > max_depth:
raise ValueError(f"Nested dict too deep at level {depth}")
result = {}
for k, v in d.items():
if isinstance(v, dict):
result[k] = parse_nested_dict(v, depth + 1, max_depth)
else:
result[k] = v
return result
关键点：
- 把
max_depth设为业务可接受的硬上限，比如解析用户JSON时设为200，而非盲目匹配sys.getrecursionlimit() - 避免用全局变量计数——线程不安全，且无法支持并发解析多个结构
- 若需跨函数传递深度，优先用参数而非闭包或类属性，减少隐式状态依赖
哪些场景真该放弃递归改用迭代
递归写起来简洁，但Python执行模型决定了它不适合“深”任务。以下情况必须转迭代，而不是调限或加守卫：
- DFS遍历树/图/目录：用
stack = [root]配合while stack:和pop()/append()，完全规避解释器栈管理 - 回溯类算法（N皇后、全排列）：把路径存
path = []，用append()/pop()模拟入栈/出栈，状态清晰可控 - 解析AST、深层嵌套JSON/YAML：压入待处理子节点元组（如
(node, current_depth)），循环展开，可随时根据current_depth截断 - 有多个递归分支（如二叉树中序遍历）或非尾递归逻辑：Python不支持TCO，所有分支都压栈，迭代版内存开销明确
真正难处理的，是那些既深度大、又无法缓存、还依赖纯递归语义的场景——这时候得重新评估需求是否合理，而不是在栈上赌运气。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
