Python性能回归需通过专用基准测试（如pytest-benchmark、asv）建立可重复基线，CI中嵌入阈值断言，聚焦关键路径，并排除环境噪声以实现可见、可追溯、可拦截。
Python 性能回归通常不会被常规单元测试自动捕获，必须通过专门设计的性能基准测试（benchmarking）和持续监控机制来发现。关键在于建立可重复、可对比、有基线的测量流程，而非依赖功能测试的断言逻辑。
用专用基准工具建立可比基线
仅靠 time.time() 或 time.perf_counter() 手动测一次耗时不可靠。应使用成熟工具如 pytest-benchmark 或 asv（Air Speed Velocity）：
-
pytest-benchmark支持在 pytest 流程中运行，自动统计多次运行的中位数、标准差，并与历史结果对比； -
asv更适合长期项目，能按 Git commit 历史自动跑基准、生成趋势图，明确标出某次提交是否引入了 5% 以上的性能下降； - 每次基准需固定输入规模（如处理 10k 条字典）、关闭干扰项（如 GC、JIT 预热未完成），否则数据波动大，无法判断是否真回归。
在 CI 中嵌入性能断言
把性能当作“可失败的条件”纳入流水线：
- 用
pytest-benchmark的--benchmark-compare参数比对上一次成功构建的 JSON 结果文件； - 设置阈值规则，例如：
--benchmark-min-time=0.1 --benchmark-max-time=0.5 --benchmark-autosave，并配合脚本检查新结果是否超过基线 10%； - CI 失败时直接输出耗时变化百分比和对应 commit，避免人工查原因。
聚焦关键路径，避免过度测量
不是所有函数都值得监控性能。优先覆盖：
立即学习“Python免费学习笔记（深入）”；
- 高频调用的底层函数（如 JSON 序列化、正则匹配、排序逻辑）；
- 用户感知明显的操作（如 Flask/FastAPI 接口首字节响应时间）；
- 已知存在优化空间或近期被重构过的模块——这些地方最易因小修改引发显著退化。
区分“慢”和“回归”，排除环境噪声
单次变慢不等于回归。可靠判断需满足：
- 同一台机器、相同 Python 版本、关闭 CPU 频率调节（
cpupower frequency-set -g performance）； - 至少 3 次独立运行取中位数，排除瞬时抖动；
- 确认是代码变更导致：用
git bisect run自动二分定位引入退化的提交。
不复杂但容易忽略——性能回归测试的核心不是追求极致精度，而是让退化变得可见、可追溯、可拦截。
