cProfile.run()无法捕获Web接口调用，因其仅支持同步脚本快照，无法嵌入由WSGI/ASGI服务器控制的请求生命周期；需将Profiler实例注入处理路径，在handler中enable/disable并条件导出。
为什么直接用 cProfile.run() 无法捕获 Web 接口调用？
因为 Web 框架（如 Flask、FastAPI）的请求生命周期由事件循环或 WSGI/ASGI 服务器控制，cProfile.run() 只能对一段同步脚本做快照，没法挂钩进每次 HTTP 请求里。你看到的往往是空报告或只 profiling 了启动过程，不是实际 handler 的执行。
关键点：必须把 profiler 实例注入到请求处理路径中，且确保它只在目标接口被调用时启用、结束后立即导出结果。
- Flask 场景下，用
@app.before_request+@app.after_request容易漏掉异常路径，推荐改用装饰器包裹具体视图函数 - FastAPI 中不能直接用
async def函数套cProfile.Profile()，因为 profiler 不支持异步上下文，得用sync_to_async或在run_in_executor里启动，但那样 profile 会丢失 async 调用栈 - 真正有效的做法是：在 handler 开头
prof = cProfile.Profile(); prof.enable()，结尾prof.disable(); prof.dump_stats("profile.out")
如何给 Flask 视图加精准 profiling（含条件开关）
硬编码 dump_stats 很危险——上线后忘了删会导致磁盘写满。应该用环境变量或 query 参数动态控制，比如只在 ?profile=1 时触发。
from flask import request
import cProfile
import pstats
<p>@app.route("/api/data")
def get_data():
if request.args.get("profile") == "1":
prof = cProfile.Profile()
prof.enable()</p><pre class='brush:python;toolbar:false;'># ……你的业务逻辑，比如数据库查询、JSON 序列化……
if request.args.get("profile") == "1":
prof.disable()
prof.dump_stats(f"profile_{int(time.time())}.prof")
return {"result": "ok"}- 不要用固定文件名，否则并发请求会覆盖，用时间戳或 request id 区分
-
dump_stats是阻塞操作，高并发下可能拖慢响应，生产环境务必加开关限制（例如只允许特定 IP 或 header） - 如果想看火焰图，后续用
py-spy record -p <pid> --duration 30</pid>更安全，不侵入代码
分析 .prof 文件时最常忽略的三件事
很多人用 pstats 打开后盯着 tottime 最高的函数看，结果优化了半天发现只是 I/O 等待——那不是 CPU 瓶颈，是外部依赖问题。
立即学习“Python免费学习笔记（深入）”；
-
tottime是函数自身耗时（不含子调用），cumtime才是包含所有下游调用的累计时间；找瓶颈优先看cumtime高且tottime / cumtime比值低的函数（说明它在等别人） - 数据库操作通常显示为
execute或fetchall，但真实慢因可能在 SQL 本身，这时要配合EXPLAIN查执行计划，而不是优化 Python 层 - JSON 序列化（
json.dumps）在数据量大时会占很高cumtime，但替换为ujson或orjson前，先确认是不是字段嵌套过深或含不可序列化对象（比如 datetime），后者会导致反复 fallback 和类型检查
FastAPI 中避免 async profiling 翻车的底线操作
别试图在 async def 里直接 prof.enable() —— cProfile 是同步钩子，async 函数切换协程时 profiler 会丢失上下文，统计结果错乱甚至崩溃。
正确姿势只有两种：
- 把耗时逻辑拆到同步函数里，在里面启用 profiler，再用
loop.run_in_executor调用（适合 CPU 密集型，如计算、解析） - 完全放弃
cProfile，改用aiomonitor或trio-stats（仅限 trio），或者更通用的py-spyattach 到 uvicorn 进程 - 如果坚持用 cProfile，至少确保只 profile
def函数（非 async），并在 FastAPI 的BackgroundTasks或中间件里做条件触发，而非路由 handler 本身
真正卡住性能的往往不是 Python 代码行数，而是没意识到 ORM 查询 N+1、重复序列化、同步库混在 async 流程里——profile 文件只是线索，不是结论。
