ProfilerMiddleware 通过中间件方式为 Flask 请求生成 cProfile 报告，限制 restrictions=[30] 表示仅显示耗时 Top 30 的函数调用，不提供 Web 界面，输出默认到终端，需手动配置 stream 写入文件。
怎么用 Werkzeug.middleware.profiler 快速看 Flask 请求耗时
直接加中间件就能出报告，不用改业务代码。它会为每个请求生成一个 cProfile 报告，按函数调用时间排序，一眼看出哪块拖慢了响应。
实操建议：
- 只在开发/测试环境启用，生产环境禁用——它会显著拖慢每次请求（尤其高并发时）
- 把中间件加在
app.wsgi_app上，不是用@app.route那套装饰器 - 默认输出是纯文本到终端，想存文件或网页得自己接管
stream或重写profiler_output
from werkzeug.middleware.profiler import ProfilerMiddleware app.wsgi_app = ProfilerMiddleware(app.wsgi_app, restrictions=[30])
restrictions 参数到底限制什么？为什么设成 [30] 很常见
它不是限制“执行时间”，而是限制 pstats.Stats 输出里显示的函数数量。比如 restrictions=[30] 就是只打印耗时 Top 30 的函数调用行。
常见错误现象：设了 restrictions=[1] 却看不到数据库操作——因为 DB 调用可能排在第 5 名，被截掉了。
使用场景建议：
- 查整体瓶颈：用
[20]～[50]，兼顾可读性和覆盖度 - 定位某个模块：配合正则，如
restrictions=[r'.*sqlalchemy.*']（注意需传字符串列表，且 Werkzeug 7.0+ 才支持正则） - 避免日志爆炸：不设限制时，一个请求可能打出几百行，根本没法扫
为什么访问 /profiler 404？它根本不提供 Web 界面
ProfilerMiddleware 默认不注册任何路由，也不会启动额外服务。所谓“报告”只是标准输出（stdout）或你指定的文件流，不是 HTTP 接口。
容易踩的坑：
- 误以为访问
http://localhost:5000/profiler就能看图形界面——其实没有这个路径，那是老版本 Flask-Profiler 插件干的事 - 用 Gunicorn 启动时 stdout 被吞掉，导致啥也看不到；得显式指定
stream写入文件 - 多进程下（如
--workers 4）每个 worker 都会写自己的 profile 文件，别只盯一个
import pstats
from werkzeug.middleware.profiler import ProfilerMiddleware
app.wsgi_app = ProfilerMiddleware(
app.wsgi_app,
stream=open('profile.log', 'w'),
restrictions=[30]
)
比 ProfilerMiddleware 更轻、更准的替代方案有哪些
它适合快速摸底，但真要压测或线上观测，会有明显短板：无法聚合统计、不能采样、不支持异步（Flask 2.3+ 的 async route 会被跳过）、也不兼容 ASGI。
实操中更稳的选择：
- 单点深度分析：
cProfile.run('app.test_client().get("/")', 'flask.pstat')+pstats.Stats('flask.pstat').sort_stats('cumulative').print_stats(20) - 轻量级打点：
time.time()在关键函数前后埋点，用logging.debug记录，开销比 profiler 低两个数量级 - 生产就绪：
dd-trace-py或opentelemetry-instrument，能链路追踪、导出到后端，但配置成本高得多
复杂点在于：profiler 看到的“耗时”包含 Python 解释器开销、GIL 切换、甚至 GC 时间——它反映的是“这段代码让整个请求慢了多少”，而不是“这段代码本身花了多少 CPU”。这点常被忽略。
