teardown_appcontext 在每次应用上下文结束时必然触发，无论请求成功、异常或中断；它确保数据库连接等资源安全释放，避免连接池耗尽。
teardown_appcontext 什么时候触发
它在每次请求生命周期结束时执行，不管请求成功、抛异常、还是被中断，只要 Flask 开始了请求上下文（比如通过 app.test_client() 或真实 WSGI 调用），就一定会走一遍注册的 teardown_appcontext 回调。
注意：它和 teardown_request 不同——后者只对「已进入请求上下文」的请求生效，而 teardown_appcontext 绑定的是应用上下文，哪怕你手动调用 app.app_context()（比如命令行脚本里），也会触发。
为什么不能只靠 try/finally 关闭数据库连接
Flask 的请求处理可能在多个地方崩掉：视图函数中途 raise、中间件拦截、WSGI 层超时、甚至信号中断。单纯在视图里写 try/finally 漏掉太多路径，尤其异步或长连接场景下，连接很容易滞留。
更关键的是，SQLAlchemy 等 ORM 常把连接绑在 g 或上下文局部变量上，这些对象只在上下文有效期内存在；teardown_appcontext 是唯一能安全访问并清理它们的钩子。
常见错误现象：sqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow 10 reached，基本就是连接没关干净。
怎么注册并安全清理 SQLAlchemy 连接
别直接关 engine.dispose()——那会干掉整个连接池，影响后续请求。正确做法是释放当前上下文持有的连接（比如 session 或 connection 对象）。
- 如果你用
session = Session(bind=engine)手动创建，确保在teardown_appcontext里调用session.close() - 如果用 Flask-SQLAlchemy，它已内置
teardown_appcontext清理，你不用额外注册；但若自己管理scoped_session，就得手动 close - 参数差异：
teardown_appcontext回调接收一个exception参数（None表示无异常），可据此做日志，但**不要用它来决定是否关闭连接**——无论有没有异常都必须关
简短示例：
def close_db(error):
if hasattr(g, 'db_conn'):
g.db_conn.close()
app.teardown_appcontext(close_db)
容易被忽略的兼容性细节
Flask 2.0+ 默认启用 app.teardown_appcontext 自动注册机制（比如 Flask-SQLAlchemy），但如果你自定义了 create_app 并禁用了扩展自动初始化，或者混用多个 ORM，就可能漏掉清理逻辑。
另一个坑：在测试中用 app.test_client() 发起请求时，teardown_appcontext 仍会触发，但如果测试用例提前 exit 或 pytest 捕获异常没 re-raise，可能导致回调不执行——建议测试里显式调用 app.do_teardown_appcontext() 验证清理行为。
最常被跳过的点：清理操作本身不能抛异常。一旦 teardown_appcontext 回调出错，Flask 会吞掉它（默认 log.warning），但后续上下文可能混乱。所以所有清理代码都要包 try/except，尤其是涉及网络或文件 I/O 的操作。
