1. 性能回归对比基础
大家好，我是老张。今天咱们聊聊性能回归对比这件事。
说实话，我见过太多团队在性能测试上踩坑了。有的上线前才发现接口慢了10倍，有的优化完代码反而把吞吐搞崩了。这些问题的根源，往往就是没做好性能回归。
什么是性能回归
性能回归，说白了就是：代码改了，性能变差了。
你想想看，昨天接口还能扛1000 QPS，今天改了一行代码，就只剩800了。这就是性能回归。它不像功能bug那么明显——功能还能跑，只是跑得慢了。
核心定义：性能回归是指系统在功能保持不变或增加新功能的情况下，性能指标出现明显下降的现象。
我在项目中遇到过最典型的例子：一个支付接口，开发同学只是加了个日志打印，结果TP99从50ms飙到了200ms。嗯，这就是性能回归。它往往藏得很深，不专门测根本发现不了。
回归测试的价值
为什么要做性能回归测试？我总结了三句话：
- 守住底线——确保每次变更不会让系统变慢
- 提前发现——在测试环境就暴露问题，别等到线上
- 量化影响——知道每次改动到底带来了多少性能变化
我曾经有个血的教训。某次大版本发布，团队赶工期，性能回归测试只跑了10分钟就过了。结果上线后，核心交易接口的响应时间从50ms涨到了800ms。用户投诉电话打爆了。那次之后，我定了个规矩：没有性能回归报告，不准上线。
我的建议：性能回归测试应该纳入CI/CD流水线。每次代码合并前，自动跑一遍关键接口的性能回归。跑不过？那就别合。
对比实验设计原则
做性能回归对比，不是随便跑两遍就行的。我踩过太多坑了，总结出几个关键原则：
原则一：控制变量
这是最基础也最容易忽略的。对比实验，必须保证除了被测代码，其他一切不变。
- 同样的硬件环境（CPU、内存、磁盘）
- 同样的数据量（数据分布也要一致）
- 同样的并发模型（线程数、连接池大小）
- 同样的压测工具和参数
我见过有人拿开发环境的机器和测试环境对比，结果差了50%。这能说明代码有问题吗？不能。环境都不一样，对比个啥？
原则二：多次采样
单次测试结果，我从来不信。为什么？因为性能测试本身就有波动。
我习惯的做法是：每个场景至少跑3次，取中位数或P50。如果3次结果差异超过10%，那就再跑3次，直到稳定为止。
注意：不要取平均值。平均值容易被极端值带偏。中位数和百分位数（P50、P90、P99）才是你的好朋友。
原则三：基线先行
做对比之前，先建立基线。基线就是你的参考点。
我通常会在每次大版本发布后，重新跑一遍全量性能测试，把结果存下来作为新基线。下次改代码，就跟这个基线比。
| 指标 | 基线（v2.0） | 当前（v2.1） | 变化 |
|---|---|---|---|
| QPS | 1200 | 1150 | -4.2% |
| TP50 | 45ms | 48ms | +6.7% |
| TP99 | 120ms | 135ms | +12.5% |
| 错误率 | 0.01% | 0.02% | +0.01% |
你看这张表，TP99涨了12.5%。虽然QPS只掉了4%，但尾延迟已经明显恶化了。这就是对比实验的价值——让你看到数字背后的真相。
原则四：冷热分离
这个很多人会忽略。系统刚启动和运行一段时间后，性能表现完全不同。
我建议的做法：
- 冷启动测试——系统刚启动，缓存未预热，模拟首次访问
- 热运行测试——预热5-10分钟后，模拟稳定运行状态
两个结果都要记录。我曾经遇到过，冷启动时接口慢3倍，但热运行时表现正常。如果只看热运行，就会漏掉这个启动性能问题。
核心总结：性能回归对比不是玄学，是科学。控制变量、多次采样、基线先行、冷热分离——把这四点做到位，你的对比结果才有说服力。
知识体系结构图
下面这张图，是我梳理的性能回归对比知识体系。你可以把它当作本章的思维导图：
这张图把本章的核心内容串起来了。从什么是性能回归，到回归测试的价值，再到对比实验的设计原则，最后落到关键指标和常见陷阱。你可以在后续章节中反复对照这张图。
一个小技巧：我习惯在每次性能回归测试前，先画一张这样的知识结构图。它能帮你理清思路，避免漏掉关键环节。
好了，关于性能回归对比的基础，就聊到这儿。记住一句话：没有对比，就没有伤害；没有基线，就没有真相。