最稳妥方案是用 before_request 记录起始时间到 g 对象，after_request 读取并计算耗时，精确覆盖路由执行及响应处理全过程；异常时需用 teardown_request 兜底，日志须包含方法、路径、状态码等上下文。
用 before_request 和 after_request 配合记录耗时最稳妥
Flask 没有现成的“请求耗时钩子”，但 before_request 和 after_request 足够精确——前者在路由函数执行前触发，后者在响应生成后、发送前触发，中间时间差就是真实处理耗时（不含网络传输）。
常见错误是只用 before_request + 全局变量存开始时间，却在视图函数里手动计算，这会漏掉 after_request 中的逻辑（比如 header 注入、日志格式化）；或者误用 teardown_request，它可能在异常未捕获时才触发，导致耗时统计不全。
- 务必在
before_request中用g（Flask 的请求上下文对象）存起始时间：from flask import g import time <p>@app.before_request def record_start_time(): g.start_time = time.time()
-
after_request中读取并计算：@app.after_request def record_response_time(response): if hasattr(g, 'start_time'): elapsed = time.time() - g.start_time app.logger.info(f"Request to {request.endpoint} took {elapsed:.3f}s") return response - 注意：如果视图函数抛出异常且未被捕获，
after_request不会执行，此时需配合teardown_request补充记录（但仅用于兜底，不替代主逻辑）
用 flask-talisman 或自定义装饰器会破坏请求链路
有人想给每个视图函数加装饰器（比如 @measure_time），看似灵活，但实际绕过了 Flask 的中间件机制，无法统一覆盖静态文件、错误处理器（@app.errorhandler）、甚至蓝图中未显式装饰的端点。更麻烦的是，装饰器嵌套顺序容易和 login_required 等其他装饰器冲突，导致耗时统计值偏小（只测了业务逻辑，漏了权限校验）。
flask-talisman 是安全加固库，和耗时无关；强行塞进它的钩子里不仅语义错乱，还会因它内部重写响应而干扰时间测量点。
立即学习“Python免费学习笔记（深入）”；
- 不要用装饰器替代钩子——除非你明确只要测某几个接口，且能保证所有调用路径都被装饰
- 避免在
before_request里做耗时操作（如查数据库），否则它本身会被计入总耗时，污染数据 - 若需区分“业务耗时”和“框架耗时”，可把计时起点往后挪到视图函数第一行（用装饰器），但必须接受统计口径不一致的风险
耗时日志要带关键上下文，否则查问题时等于没记
只记 "took 0.234s" 毫无意义。生产环境必须附带请求方法、路径、状态码、用户标识（如 request.headers.get('X-User-ID')）和 trace_id（如果有分布式追踪）。
- 推荐日志格式：
app.logger.info( "REQ %s %s %s | %.3fs | status=%d | user=%s | trace=%s", request.method, request.path, request.endpoint, elapsed, response.status_code, request.headers.get('X-User-ID', '-'), request.headers.get('X-Trace-ID', '-') ) - 状态码必须从
response.status_code读，不能用200硬编码——否则 404/500 接口的耗时永远显示为成功状态 - 避免在日志里拼接敏感信息（如完整 token、密码参数），用
request.args.to_dict()前先过滤键名
异步视图（async def）下 time.time() 仍可用，但要注意事件循环
Flask 2.0+ 支持 async 视图，但 before_request 和 after_request 仍是同步函数。这意味着 g.start_time 在 async 视图中依然准确，因为请求上下文在进入 async 函数前就已建立。
真正的问题在于：如果你在 async 视图里用了 await asyncio.sleep(1) 这类挂起操作，time.time() 测的是 wall-clock 时间（含挂起），符合“用户感知耗时”的需求；但若想排除 I/O 等待，得用 asyncio.get_event_loop().time()，不过 Flask 钩子不支持 await，无法直接用。
- 结论：保持用
time.time()，它对 async 视图也有效，且结果更贴近真实体验 - 不要试图在
before_request里await任何东西——Flask 会报错，钩子必须是同步的 - 如果项目重度依赖异步（如大量 HTTP client 调用），考虑迁移到 FastAPI，它的中间件原生支持 async
Flask 的耗时统计难点不在代码量，而在钩子执行时机与请求生命周期的咬合精度——尤其当项目引入蓝图、错误处理器、WSGI 中间件后，after_request 是否一定被执行，得靠实测验证，不能只看文档。
