teardown_request未执行的最常见原因是应用未进入http请求上下文，如在cli命令、定时任务或单元测试中直接调用；它仅在真实http请求生命周期内触发。
teardown_request 为什么根本没执行？
最常见原因是：你注册了 teardown_request，但应用根本没有进入请求上下文——比如在 CLI 命令、定时任务、或单元测试中直接调用它，此时钩子不会触发。Flask 的请求钩子只在真实 HTTP 请求生命周期内运行，不适用于后台脚本或 shell 环境。
teardown_request 在异常时被跳过？
默认情况下，teardown_request 是“无论成功或失败都会执行”的，但有两个关键例外：
- 如果在
before_request中抛出未被捕获的异常（如abort(500)），且没有配置errorhandler，部分 Flask 版本（尤其是 2.2+）可能跳过teardown_request； - 如果你手动调用了
app.teardown_request(...)而非用装饰器@app.teardown_request，函数不会被自动注册进当前应用实例的钩子列表。
g 对象在 teardown_request 中为空或丢失数据？
g 是请求上下文局部对象，其生命周期与 request 一致，但在 teardown_request 执行时已接近销毁边缘。常见误操作：
- 在
before_request中给g赋值后，又在视图函数里重新赋值同名属性（如g.user = ...），导致引用被覆盖； - 试图在
teardown_request中对g进行写操作（如g.log = "done"），此时g已不可写，会静默失败或抛RuntimeError: Working outside of application context.； - 使用了多线程/协程（如
async def视图），而g不是线程安全的，数据可能被并发覆盖。
为什么 teardown_request 里读不到 request.json？
这是高频踩坑点：request.json 内部调用 request.get_data()，而该方法在视图函数返回后、after_request 执行前就已完成读取，底层 environ['wsgi.input'] 流已被关闭。到了 teardown_request 阶段再访问会直接报错：
ValueError: I/O operation on closed file 或 BadRequest: Failed to decode JSON object
正确做法是：在 before_request 或视图函数开头就解析并缓存到 g：
@app.before_request
def parse_json():
if request.is_json:
g.parsed_json = request.get_json(silent=True) or {}
后续所有钩子都可安全读取 g.parsed_json，无需重复触发流读取。
真正容易被忽略的是：teardown_request 不是“收尾保险箱”，它不保证 request 或 g 的完整性，也不适合做数据持久化主逻辑——它的定位只是清理资源（如关闭数据库连接、释放锁），而不是补救前期遗漏的数据提取。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
