用 python -m cProfile -s cumulative your_script.py 可快速定位最慢函数，按累计时间排序暴露调用链瓶颈，配合 pstats 交互式筛选、过滤和分析调用关系，避免被底层库干扰。
怎么用 cProfile 快速定位最慢的函数
直接运行 cProfile 就能拿到函数调用次数、总耗时、单次平均耗时，不用改代码，也不依赖外部工具。关键是要让输出聚焦在真正可疑的函数上，而不是被底层库调用淹没。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用命令行启动：
python -m cProfile -s cumulative your_script.py，-s cumulative按累计时间排序，一眼看出哪个函数拖累了整条调用链 - 避免只看
tottime（函数自身耗时）：比如json.loads()可能tottime很低，但它被调用 10 万次，cumulative就会暴露问题 - 加
-o profile.out输出二进制文件，后续用pstats交互分析，比纯文本更灵活
pstats 里怎么筛出高频/高耗时函数
原始 cProfile 输出太长，pstats 是唯一靠谱的后续处理方式。它不是装饰器、也不是实时监控，就是个离线分析器——这点必须明确，否则容易误以为能“热看”性能。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 进交互模式：
python -m pstats profile.out，然后用sort cumulative再top 20查前 20 行 - 过滤特定模块：
filter your_module.py，排除requests、numpy等第三方库干扰 - 看调用关系：
callers slow_function_name查谁在频繁调用它；callees slow_function_name查它内部又花了时间在哪
为什么 cProfile 的 tottime 和手动 time.time() 差很多
cProfile 统计的是 CPython 解释器级的函数执行时间，不包含 GC、线程切换、系统调用等待等开销；而手写 time.time() 测的是 wall-clock 时间，两者维度不同，不能直接对比。
常见错误现象：
- 某个函数
cProfile显示tottime=0.001s，但实际感知卡顿严重 → 很可能阻塞在 I/O（如数据库查询、HTTP 请求），这些在tottime里几乎不计时 - 多线程程序用
cProfile主线程跑，结果全是threading.Lock.acquire耗时 → 这是锁竞争，得结合threading.setprofile()单独抓子线程 - 用了
asyncio却只跑cProfile同步入口 → event loop 调度、await切换不会体现在函数级统计里
生产环境能不能直接上 cProfile
能，但必须控制粒度。全量开启会带来 5–10 倍性能下降，且生成的 .out 文件可能达百 MB，反而压垮服务。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 只对特定请求路径或任务加装饰器封装：
@profile_on_demand，通过环境变量或请求头触发，避免常驻 - 限制采样率：用
sys.setprofile配合计数器，每 100 次请求只 profile 第 1 次 - 别写死
print(pstats.Stats(...))：用Stats.stream = open('/tmp/profile.log', 'a')异步写入，防止阻塞主线程
最易忽略的一点：cProfile 对 C 扩展函数（如 pandas 内部、cv2）只能统计到 Python 层调用入口，看不到内部循环耗时——这时候得切到 perf 或 py-spy。
