在Python项目里写涉及树遍历、表达式解析或分治算法的代码时，深度递归几乎不可避免。当这些逻辑被放进pytest用例中执行，很多团队会突然遇到RecursionError，而同样的函数在手工脚本里却能正常运行。这种现象背后既有Python解释器栈帧设计的原因，也有测试框架调用链叠加的影响。理解清楚机制后，我们可以有针对性地在pytest环境中调大栈深度或改造递归写法。
为什么pytest里更容易触发递归深度限制
Python解释器对每个线程的调用栈帧数量有硬上限，默认值通常是1000，由sys.getrecursionlimit()返回。每当函数调用自身，就会在栈上压入一个新帧，达到上限解释器就抛出RecursionError。这个数字并不是为“真实递归深度”预留的，因为像pytest这样的框架在收集用例、执行fixture、包装断言时，本身已经占用了几十到上百个栈帧。
举例来说，一个业务函数递归深度达到900层，在终端直接运行脚本时离1000的上限还有余量；但经过pytest的runner、hook链和断言重写层包装后，实际栈帧可能多出两百层，于是用例执行到一半就报错。很多开发者误以为是算法写错了，其实只是测试环境的调用链更“重”。
使用sys.setrecursionlimit在pytest中调大栈深度
最直接的办法是在pytest的入口阶段调高递归上限。可以写一个conftest.py，在pytest_configure这个hook里设置，这样所有用例运行前都会生效。下面的示例把上限调到3000，并顺手打印确认：
import sys
def pytest_configure(config):
new_limit = 3000
sys.setrecursionlimit(new_limit)
print("当前递归上限已设为:", sys.getrecursionlimit())
这种方式的优点是改动极小、对所有用例全局有效。但风险在于setrecursionlimit只是告诉解释器“允许更深的栈”，底层操作系统线程栈大小并未同步扩大。如果递归真的走到两千层以上，可能在某些平台直接段错误而非优雅报错。因此设置值应略高于实际峰值，而不是盲目调到一万。
如果你只想让个别用例享受更大栈空间，也可以在测试函数内部临时修改并还原，避免影响其他模块：
import sys
def test_deep_recursion():
old = sys.getrecursionlimit()
sys.setrecursionlimit(5000)
try:
result = deep_calc(4500)
assert result is not None
finally:
sys.setrecursionlimit(old)
通过独立线程扩大栈空间更稳妥
比起全局调大递归限制，更安全的做法是把深度递归逻辑放到一个新线程里执行，并为该线程指定更大的栈尺寸。threading模块允许在创建时传入stack_size，配合setrecursionlimit使用，可以把“栈内存”和“帧计数上限”都放开，且不影响主线程和pytest框架本身。
import sys
import threading
def run_with_big_stack(fn, *args, stack_size=256 * 1024 * 1024):
threading.stack_size(stack_size)
result = {}
def target():
sys.setrecursionlimit(10000)
try:
result['value'] = fn(*args)
except Exception as e:
result['error'] = e
t = threading.Thread(target=target)
t.start()
t.join()
if 'error' in result:
raise result['error']
return result['value']
def test_in_thread():
val = run_with_big_stack(deep_calc, 8000)
assert val == expected_value
上面代码先把线程栈设为256MB，再在线程内放宽递归上限，从而让八千层的递归也能跑通。这种方案的隔离性很好，不会干扰pytest的fixture机制，也不会因为某个用例设太大而导致整个进程不稳定。代价是需要多写一点样板代码，并且跨线程异常要手动搬运。
需要注意的是，threading.stack_size在某些操作系统上有最小值限制，且必须在创建线程前调用。如果设置过小会被忽略，设置过大则可能线程创建失败，所以一般取64MB到512MB之间比较现实。
从算法层面减少栈帧消耗
调大栈深度只是缓兵之计。如果递归深度来源于算法设计，比如二叉树的先序遍历写成纯函数递归，可以考虑改成显式栈模拟，把本来压在调用栈的数据放到堆里的list中。这样既不受解释器限制，也更容易在pytest中断言中间状态。
def traverse_iterative(root):
stack = [root]
visited = []
while stack:
node = stack.pop()
if node is None:
continue
visited.append(node.val)
stack.append(node.right)
stack.append(node.left)
return visited
上面的迭代写法用list充当栈，深度一万的树也不会出现RecursionError。在单元测试中，它还能让你在循环里插桩、统计访问次数，比递归版本更好测。缺点是代码不如递归直观，对复杂回溯逻辑改写成本较高。
另一个常见误区是把尾递归当成Python的优化手段。CPython默认并不做尾调用消除，所以即使函数最后一步调用自身，栈帧仍然会累积。不要指望写成尾递归就能绕过限制，该用sys.setrecursionlimit或线程方案时还是要用的。
几种方案对比与选用建议
为了更清楚地看到差异，下面用表格列出不同做法的适用场景：
| 方案 | 改动成本 | 安全性 | 适用场景 |
|---|---|---|---|
| 全局setrecursionlimit | 低 | 中 | 递归深度略超默认、快速验证 |
| 用例内临时修改 | 低 | 中 | 个别深递归用例 |
| 独立线程+大栈 | 高 | 高 | 深度极大、需稳定CI |
| 显式栈改写 | 高 | 高 | 长期维护、算法可控 |
实际项目中，建议先用量化方式测出真实峰值递归层数，例如用计数器在递归入口累加并打印。拿到数据后，若只是略超一千，用conftest统一调大到两千即可；若涉及几千层且CI频繁失败，则优先采用线程方案或重构算法。这样既能让pytest平稳跑过测试，也不至于把解释器推到崩溃边缘。
最后提醒一点，RecursionError本身也是保护机制，盲目调大可能掩盖真正的无限递归bug。在pytest里放宽限制的同时，应为递归函数补上深度上限断言或循环检测，确保测试通过的代码在 production 环境也是安全的。
pytest递归栈深度sys_setrecursionlimit修改时间：2026-07-31 12:15:34