sys.setrecursionlimit() 在自动化脚本中极危险，因它仅修改 python 层计数器而不调整底层 c 栈，易致静默崩溃（如 segmentation fault）、多线程不一致、docker/不同解释器失效，且掩盖真实逻辑错误；应优先用迭代替代递归、加深度防护、缓存优化及明确错误反馈。
别急着调 sys.setrecursionlimit()，它大概率会让脚本从报错变成静默崩溃。
为什么 sys.setrecursionlimit() 在自动化脚本里特别危险
自动化脚本常运行在不同环境（CI/CD、Docker、云函数），而 sys.setrecursionlimit() 只改 Python 层计数器，不碰底层 C 栈。Linux 默认线程栈约 8MB，Windows 约 1MB——设成 50000 后，每层压入 200 字节局部变量，40 层就吃掉 8MB，直接 Segmentation fault 或 Killed: 9，没 traceback，连日志都留不下。
- 多线程下该设置全局生效，但子线程栈空间独立，主线程调大了，worker 线程照样崩
- Docker 容器默认栈更小，本地能跑的脚本上线就挂
- PyPy/Jython 不认这个设置，换解释器即失效
- 自动化任务常带用户输入或外部数据（如嵌套 JSON、XML、YAML），深度不可控，设固定值等于埋雷
先确认是不是真需要深递归：查终止条件和问题规模
90% 的 RecursionError: maximum recursion depth exceeded 来自逻辑错误，不是“不够深”。打开 sys.settrace 打几行日志，或加个简单计数器：
def my_recursive_func(data, depth=0):
if depth > 100:
raise RuntimeError(f"Recursion too deep at depth {depth}, data={type(data)}")
# ... 你的逻辑
return my_recursive_func(new_data, depth + 1)
- 检查是否漏写 base case（比如
if not node:忘了判空） - 确认每次递归后输入规模是否真在缩小（
factorial(n-1)✅，process(data)不变 ❌） - 观察调用链是否重复进入同一分支（比如图遍历没去重、JSON 解析循环引用）
用显式栈替代隐式调用栈：以树遍历为例
几乎所有 DFS 类自动化任务（目录扫描、AST 遍历、配置合并）都能转迭代。关键不是“能不能”，而是“要不要留退路”——迭代版本内存可控、可中断、可加超时。
递归写法（易崩）：
def walk_dict_recursive(d, path=""):
for k, v in d.items():
new_path = f"{path}.{k}" if path else k
if isinstance(v, dict):
walk_dict_recursive(v, new_path) # 深度随嵌套层数线性增长
else:
yield new_path, v
迭代写法（推荐）：
def walk_dict_iterative(d):
stack = [(d, "")]
while stack:
current_dict, path = stack.pop()
for k, v in current_dict.items():
new_path = f"{path}.{k}" if path else k
if isinstance(v, dict):
stack.append((v, new_path)) # 先压右后压左，顺序可调
else:
yield new_path, v
- 用
list做栈比deque更轻量，除非你频繁pop(0) - 栈里只存必要状态（字典引用 + 路径字符串），不复制数据
- 可在
while循环开头加if time.time() - start > timeout: break防卡死
缓存 + 迭代组合：对付重复子问题
像解析带重复键的嵌套配置、模板渲染这类场景，光转迭代还不够，得砍分支。用 functools.lru_cache 配合参数哈希化：
from functools import lru_cache
import json
<p>@lru_cache(maxsize=128)
def hashable_key(s):
return json.dumps(s, sort_keys=True, separators=(',', ':'))</p><p>def process_config_section(section_key: str, config: dict):
key_hash = hashable_key(config)</p><h1>后续逻辑基于 key_hash 做缓存判断</h1><pre class="brush:python;toolbar:false;"># ...
-
lru_cache对减少调用次数极有效，但不能降低单次最坏深度 - 避免缓存大对象（如整个
dict），改用结构哈希或 ID - 若需跨进程缓存，换成
diskcache或 Redis，但要权衡序列化开销
真正难处理的是那些“不得不深”的场景——比如符号微分、超深 AST 重写。这时优先试 PyPy（栈管理更松），再考虑 threading.stack_size()（仅 Linux/macOS 有效），而不是无脑调 setrecursionlimit。自动化脚本的生命力不在能跑多深，而在出错时能否说清哪一层、为什么卡住、有没有 fallback 路径。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
