Flask请求钩子需通过app.before_request()和app.after_request()注册：before_request函数无参无返回，适合权限检查；after_request必须接收并返回response，适合修改响应头；多钩子按LIFO/FIFO顺序执行。
怎么注册 before_request 和 after_request 钩子
Flask 的请求钩子不是装饰器链式调用，也不是写在路由函数里——它们得通过 app.before_request 或 app.after_request 方法注册成普通函数。函数本身不能带参数（before_request 函数可以无参，after_request 必须接收一个 response 参数），也不能返回 None（after_request 必须返回 response）。
常见错误是直接写 @app.before_request 却忘了下面跟函数定义，或者在钩子里调用了 return redirect() ——这会抛出 RuntimeError: Response object required。
-
before_request函数不接受参数，也不需要返回值；适合做权限检查、日志记录、全局变量注入 -
after_request函数必须声明response参数，并且必须原样或修改后返回它；适合加响应头、统一格式包装、清理资源 - 多个钩子按注册顺序执行：
before_request是先进后出（LIFO），after_request是先进先出（FIFO）
before_request 里怎么安全中断请求流程
钩子本身不能用 return 中断流程，但你可以抛出异常或调用 abort()，再配合 @app.errorhandler 统一处理。别在 before_request 里写 return render_template() 或 return jsonify()，那会直接让 Flask 报错：「The view function did not return a valid response」。
典型场景是登录态校验：检查 session.get("user_id") 不存在时，应该 abort(401) 而不是试图返回 JSON。
- 用
abort(401)/abort(403)是最干净的中断方式 - 如果要用自定义异常，记得提前注册
@app.errorhandler(YourCustomError) - 别在钩子里调用
redirect()—— 它返回的是Response对象，而钩子不期望返回值
after_request 修改响应头为什么有时不生效
因为 after_request 的执行时机在视图函数返回之后、响应真正发出之前，但它**不保证能修改所有响应字段**。比如视图函数里用了 make_response() 并手动设置了 Content-Type，后续又在 after_request 里改 response.headers["Content-Type"]，可能被忽略——某些底层 WSGI 层已锁定头部。
更隐蔽的问题是：如果视图函数返回的是字符串，Flask 会自动包装成 Response，此时 response.headers 可写；但如果返回的是 Response 实例本身（比如 return jsonify(...)），它的 headers 是只读代理，直接赋值会静默失败。
- 安全写法是始终用
response.headers.set("X-Trace-ID", "xxx")而不是response.headers["X-Trace-ID"] = "xxx" - 避免在
after_request里修改response.data或response.response，容易触发编码/流式响应冲突 - 调试时可加
print(response.status, list(response.headers.keys()))确认是否真被修改
钩子函数里访问请求上下文要注意什么
before_request 和 after_request 都运行在请求上下文中，所以能安全用 request、session、g。但注意：after_request 执行时，视图函数已经结束，g 里的内容还在，但如果你在视图里删了 g.xxx，它就没了；而 request 对象此时仍是可用的，只是不能再调用 request.get_json() 这类可能消耗流的方法。
- 别在
after_request里调用request.form或request.files—— 请求体可能已被读取并关闭 - 想传数据给
after_request，推荐用g：在before_request里设g.start_time = time.time()，然后在after_request里算耗时 - 钩子函数不能跨请求复用状态，每次请求都是全新上下文；别试图在钩子里缓存
request引用到全局变量
钩子看着简单，但一旦混入异步操作、流式响应或中间件叠加，行为就容易失控——尤其是 after_request 返回的 response 如果被多次修改，底层 WSGI 可能直接丢弃后写的 header。
