cProfile能准确定位性能瓶颈，但必须结合正确使用方式、SortKey.CUMULATIVE排序查源头、pstats分析调用链，且需规避多worker/异步干扰及I/O盲区。
cProfile 能准确定位性能瓶颈，但必须结合使用方式、排序策略和结果解读三者——单独跑命令或只看默认输出，大概率漏掉真问题。
为什么直接 python -m cProfile app.py 常常无效
默认输出按函数名排序，满屏是 __import__、load_module、getattr 这类框架胶水代码，业务函数被淹没；更关键的是，它不告诉你“谁在调用谁”，也看不出哪个函数的耗时是被高频触发拖累的。
- 不加
-s参数 → 输出无意义，无法聚焦 - 用
-s tottime却忽略调用次数 → 可能盯着一个ncalls=1但tottime=0.5s的函数猛优化，而真正问题是它被循环调用了 1000 次 - 没导出文件 → 无法后续用
pstats过滤、查调用链、比对前后差异
怎么选 sort 策略：cumtime vs tottime
二者不是“哪个更好”，而是解决不同问题：
- 查“源头瓶颈”（比如哪个路由函数/主逻辑入口最拖时间）→ 用
SortKey.CUMULATIVE。例如app:main_handler的cumtime占总耗时 68%，那就从它开始往下挖 - 查“纯计算热点”（比如算法慢、正则没编译、列表反复 append）→ 用
SortKey.TIME（即tottime）。此时要盯住ncalls和percall：若ncalls=50000且percall很小，说明是高频低开销操作，可能该换数据结构；若ncalls=1但tottime高，优先检查它内部是否含未索引查询或重复 IO
别信默认排序，也别只看 top 1 —— 有时前五名加起来才占 12%，真正耗时分散在几十个中等 cumtime 函数里，它们共同被同一段循环触发。
立即学习“Python免费学习笔记（深入）”；
Web 服务里 profile 的正确姿势
Uvicorn/FastAPI 默认是多 worker + 异步模型，python -m cProfile -m uvicorn app:app 基本白跑：主进程不处理请求，子进程逃逸在 profile 外，async 调度和 IO 等待也不计入 tottime。
- 强制单同步 worker：
uvicorn app:app --workers 1 --loop sync --http httptools - 手动包裹核心逻辑：在路由函数里插
prof.enable()/prof.disable()，或把业务抽成独立同步函数（如def process_order(order_id): ...），再单独 profile 它 - 避免被 event loop 干扰：不要在
async def里直接启停 profile，cProfile 不跟踪协程切换，会漏掉大量时间
看到大量 threading.Lock.acquire 或 select.select 耗时？那是并发模型本身，不是你的代码问题 —— 此时该切到 py-spy top --pid XXX 看真实运行栈，而不是继续啃 cProfile 输出。
cProfile 看不见的盲区必须补上
它只统计 CPU 时间，对以下情况完全静默：
- 数据库查询（
cursor.execute在 cProfile 里可能只有 0.001s，实际网络+磁盘等待占了 900ms） - HTTP 外部调用（
requests.request的cumtime高，但tottime极低，优化它毫无意义） - 内存暴涨引发的 GC 停顿（CPU 使用率可能很低，但程序卡死）
一旦发现 cProfile 报告里没有明显高耗时函数，但接口就是慢，立刻停手——去跑 strace -p PID -e trace=network,io 看系统调用阻塞点，或用 tracemalloc 查内存分配源头。cProfile 是起点，不是终点。
