RecursionError是因路由函数、请求钩子或装饰器中存在隐式循环调用所致，常见于before_request中触发新请求、errorhandler内再次抛异常、或登录装饰器未排除login路由导致无限重定向。
为什么Flask里会突然报RecursionError: maximum recursion depth exceeded
这不是Flask本身递归设计导致的，而是你在路由函数、请求钩子或自定义装饰器里无意中触发了循环调用。最常见的是：在before_request里又发起了一个requests.get()或url_for()调用当前应用的某个端点，而这个端点又触发了同一个钩子——形成死循环。另一个高频场景是自定义@app.errorhandler(500)里又抛出异常或调用了可能出错的逻辑，结果再次进入该handler。
检查before_request和after_request是否隐式触发新请求
这类钩子对所有请求生效，但容易被忽略其“全局性”。比如你在钩子里调用url_for('admin.index')，而admin.index路由本身又依赖某个需要鉴权的上下文——而鉴权逻辑又依赖钩子里的变量初始化……就可能绕回钩子开头。
- 临时注释掉所有
@app.before_request和@app.after_request函数，看错误是否消失 - 把钩子内所有
url_for()、redirect()、requests.get()替换成静态字符串或abort(404)做隔离测试 - 注意
g对象赋值本身不危险，但若赋值过程调用了依赖请求上下文的函数（比如从数据库查用户），就要确认该函数不会间接触发新请求
排查装饰器和重定向链中的隐式递归
自定义装饰器（如登录校验）如果写成“未登录就redirect(url_for('login'))”，而'login'路由又套了同一装饰器，就会无限跳转。Flask不会报HTTP重定向错误，而是不断重建请求上下文直到栈溢出。
- 检查所有装饰器是否对
login、static、health等免校验路径做了if request.endpoint in ['login', 'static']:短路判断 - 避免在装饰器里用
url_for(request.endpoint)——这会把当前endpoint再塞回去，极易形成闭环 - 用
print(f"→ {request.endpoint}")在装饰器开头加日志，启动时加app.config['DEBUG'] = True，观察控制台输出是否出现重复endpoint名
别盲目调高sys.setrecursionlimit()
这是最危险的“解决方式”。它只是把栈溢出延迟发生，掩盖真实调用链问题。Flask单次请求正常深度在100–200层之间，如果你看到错误提示里递归深度超过3000，基本可以断定存在逻辑闭环而非真需要深层递归。
立即学习“Python免费学习笔记（深入）”；
- 运行时打印当前调用栈：
import traceback; print(len(traceback.extract_stack()))，在疑似位置插入，看哪次调用后层数暴增 - 禁用所有第三方中间件（如Flask-Login、Flask-SQLAlchemy事件监听器），逐个启用排查
- 特别留意SQLAlchemy模型的
__repr__或@hybrid_property里是否访问了关联对象——而关联对象的__repr__又反向引用回来
递归错误本质是控制流失控，不是资源不够。盯住第一个非Flask原生的函数调用入口，顺着return路径反推，比堆栈顶部那行报错更有价值。
