用python -m cProfile -s cumulative your_script.py可快速定位最慢函数，-s cumulative按累计时间排序，-s tottime看自身耗时；需运行5秒以上保证统计可靠，避免用纯Python的profile模块。
怎么用 cProfile 快速定位最慢的函数
直接跑一次带统计的脚本，比猜半天快得多。核心就一行命令：python -m cProfile -s cumulative your_script.py。加 -s cumulative 是为了按累计时间排序，一眼看到哪个函数拖了后腿——不是它自己耗时多，而是它调用的整条链路耗得多。-s tottime 则看函数自身纯执行时间（不含子调用），适合排查计算密集型瓶颈。
常见错误是只跑几秒就结束，结果统计样本太少，cProfile 报出的耗时抖动大、不可信。建议让脚本至少稳定运行 5 秒以上，或者用循环多跑几次再统计。
- 别用
profile模块——它是纯 Python 实现，开销比cProfile高 5–10 倍，会严重干扰真实耗时 - 避免在 Jupyter 里用
%prun查复杂逻辑：它默认不显示完整模块路径，同名函数容易混淆 - 如果脚本依赖命令行参数，记得把参数一起传进去：
python -m cProfile -s cumulative main.py --input data.json
cProfile 输出里哪些字段真正关键
输出表格有六列，但盯紧三个就行：tottime（函数自身耗时）、cumtime（含所有子调用的累计耗时）、ncalls（调用次数）。重点看 cumtime 最高的那几行——比如某 process_items() 函数 cumtime 占总时间 73%，但它自己的 tottime 只有 2%，说明问题在它内部反复调用的某个子函数上。
容易忽略的是 filename:lineno(function) 这一列。如果看到 <built-in method> 或 <method 'join' of 'str' objects> 占比高，说明瓶颈在标准库操作，得检查是不是在循环里反复做字符串拼接、或没用 list.extend() 而用 +=。
立即学习“Python免费学习笔记（深入）”；
-
tottime高 +ncalls低 → 函数单次执行太重，比如没用缓存的正则匹配、重复加载大文件 -
cumtime高 +ncalls高 → 典型“小操作被调太多次”，比如循环里查数据库、或反复调用json.loads() - 同一行出现多次（如
__init__）且ncalls异常高 → 对象创建/销毁开销过大，考虑对象复用或改用__slots__
怎么把 cProfile 结果导出成可交互分析的文件
命令行输出刷屏太快，真正要深挖必须导出二进制文件，再用工具可视化。两步搞定：
第一步生成文件：python -m cProfile -o profile_output.prof your_script.py；
第二步用 pstats 交互分析：python -c "import pstats; p = pstats.Stats('profile_output.prof'); p.sort_stats('cumtime').print_stats(20)"。
更直观的方式是转成火焰图：装 pip install py-spy，然后 py-spy record -o profile.svg --pid $(pgrep -f your_script.py)（需脚本正在运行）。火焰图能清晰看出调用栈深度和每层占比，比文本列表更容易发现“意外的深层调用”。
- 别直接用
print_stats()不加参数——可能输出上千行，根本找不到重点 - 导出的
.prof文件不是文本，不要用cat或编辑器打开，会乱码 - 如果脚本运行时间短于 100ms，
cProfile可能统计不到有效数据，此时该换line_profiler看单行耗时
优化后怎么验证效果是否真实
改完代码别急着庆祝，重新跑一遍 cProfile 对比原始 .prof 文件。用 pstats 加载两个文件，调用 p.diff_stats(other_p) 直接输出差异——它会标出哪些函数 cumtime 下降了、哪些反而升了，避免“修了一个坑，冒出两个新坑”。
特别注意 I/O 密集型优化：比如把多次 HTTP 请求合并成批量接口，cProfile 里 urlopen 耗时可能变少，但实际响应时间没变快，因为网络延迟还在。这时候得配合 time.time() 打点测端到端耗时，cProfile 只反映 CPU 时间。
- 优化前后必须用完全相同的输入数据，否则
cumtime对比无意义 - 如果用了缓存（如
@lru_cache），第二次运行cProfile会严重失真，务必清空缓存或重启进程再测 - 多线程脚本中，
cProfile默认只统计主线程，需手动为每个线程启用 profiler，否则看不到 worker 线程的瓶颈
性能优化最麻烦的从来不是找到慢函数，而是确认那个“慢”到底是 CPU 绑定、I/O 等待、还是锁竞争——cProfile 只管前一种，别的得换工具看。
