性能回归测试是围绕关键路径建立可重复、可对比、可归因的质量守门机制，聚焦高频核心接口、资源敏感操作和数据库关键路径三类场景，通过自动化嵌入ci/cd、环境可控的轻量级基准测试与关联用例执行，结合火焰图、sql分析、内存快照等根因定位手段，由开发自测担责并遵循《性能红线手册》。
性能回归测试不是“跑一遍压测脚本”，而是围绕关键路径建立可重复、可对比、可归因的质量守门机制。核心目标是：在每次代码变更后，快速识别性能退化，定位到具体提交或模块，避免慢接口、高延迟、内存泄漏等问题流入生产。
明确测什么：聚焦有业务意义的性能指标
不追求全链路压测，优先覆盖以下三类场景：
- 高频核心接口：如登录、下单、商品详情页渲染，关注 P95 响应时间、吞吐量（QPS）、错误率；
- 资源敏感操作：如批量导出、定时任务、数据同步，监控 CPU 占用峰值、内存增长趋势、GC 频次；
- 数据库关键路径：含 JOIN 多、数据量大的查询，记录执行计划变化、慢查询日志触发情况。
每个用例需绑定明确的基线值（如“订单创建接口 P95 ≤ 320ms”），基线应来自稳定版本线上真实流量采样或压测结果，而非开发环境空跑数据。
怎么测：自动化 + 小步快跑 + 环境可控
把性能验证嵌入 CI/CD 流水线，但不强求每次 PR 都全量压测：
立即学习“Python免费学习笔记（深入）”；
- 每日凌晨对主干分支执行一次轻量级基准测试（5 分钟，100 并发），生成趋势图并告警突变点；
- PR 提交时，仅对本次修改涉及的模块或接口运行关联性能用例（例如改了用户服务，就跑 login / profile 接口）；
- 统一使用容器化测试环境（Docker Compose），隔离 DB、缓存、依赖服务版本，避免环境差异干扰结果；
- 压测工具推荐 Locust（Python 原生，易定制逻辑）或 pytest-benchmark（适合单函数级微基准）。
结果怎么看：拒绝“看数字”，要“找根因”
发现性能下降后，不能只报“P95 +15%”，必须提供可下钻线索：
- 自动比对前后两次火焰图（使用 py-spy 或 perf record），标出热点函数变化；
- 输出 SQL 执行耗时对比，标记新增/变慢的查询，并附 EXPLAIN 分析结果；
- 内存快照（用 tracemalloc 或 objgraph）识别新增的大对象分配源头；
- 关联 Git 提交，高亮本次引入的代码行（如某次 for 循环未加 limit 导致 N+1 查询）。
谁来负责：开发自测是第一道防线
性能不是测试团队的专属责任：
- 开发提交前，需本地运行关联 benchmark 用例（pytest test_perf_user.py --benchmark-only），失败则禁止合入；
- CR（Code Review）清单中增加“性能影响”条目：是否新增循环、是否误用同步调用、是否遗漏缓存等；
- 团队共用一份《性能红线手册》，列明各模块响应时间、DB 查询行数、内存增幅等硬性阈值，写进 MR 检查项。
