【背景】
做了 8 年性能优化，我越来越觉得一个尴尬的事实：「把接口做快」和「证明它真的变快了」是两件完全不同的事。前者靠工程直觉，后者靠统计学，而大多数团队（包括我早期的团队）只有前者。
最近复盘了三个「优化后翻车」的真实案例，根因都不是优化本身错了，而是验证方法错了：
案例一：某 RPC 客户端把连接复用从短连接改成长连接，JMH 微基准跑出「吞吐提升 8 倍」。上线后压测 P99 反而从 12ms 抖到 35ms。最后查下来：JMH 跑的时候服务端连接池只有 4 个连接，长连接把 4 个槽全占满了，服务端侧反而排队。微基准的"干净环境"恰好掩盖了线上最典型的资源竞争。
案例二：一次 GC 调优（G1 → ZGC），压测报告 P99 降了 40%。但压测脚本的流量模型是均匀 Poisson，而线上是明显的「脉冲+长尾」分布（早高峰、整点批跑、用户重试叠加）。ZGC 在均匀流量下确实漂亮，脉冲流量下 Young GC 并发阶段被压垮，P999 反而恶化。验证用的流量分布和真实分布不一致，等于在考场外做卷子。
案例三：一次 SQL 加索引优化，慢查询日志里"慢 SQL 次数"从每小时 200 次降到 8 次，汇报很成功。但后来发现：加索引后执行路径变了，走的是覆盖索引 + 回表，单条快了，但总扫描行数涨了 6 倍，InnoDB buffer pool 的换页频率反而上升，凌晨批跑时段整体吞吐掉了 12%。只看「慢 SQL 条数」这个指标，把系统级退优化判成了成功。
【常见分歧 / 几种做法】
社区里我看到的验证方式大致分四类，各有坑：
- 微基准（JMH / go test -bench）驱动：可控、可复现，但和线上差太远——缺真实连接竞争、缺真实内存布局、缺真实调度干扰。我现在的原则是：微基准只用来"排除嫌疑"，不能用来"宣判有效"。
- 线上压测驱动：贴近真实，但流量分布、缓存状态、上下游配合都是变量。压测窗口内 cache 是热的还是冷的？上游 mock 的返回延迟分布和真实上游一致吗？
- 金丝雀 / A/B 灰度驱动：最接近真实，但"同机同流量"很难做到——金丝雀实例和基线实例在不同机器、不同 NUMA、不同邻居 Pod，本身就有 5–10% 的噪声。
- 上线后看监控：最诚实，但滞后，且归因最难——上线后 1 周 P99 降了，是优化起了作用，还是那天流量结构恰好变了？
【我的倾向与理由】
我现在的标准做法是「三把尺子同时量，且必须交叉印证」：
- 尺子一：受控压测。同一台机器、同一份数据、同一个流量模型，先跑 baseline 再跑 optimized，交替执行（A-B-A-B）消除时间漂移。流量模型必须用录制的真实流量回放，不是合成 Poisson。
- 尺子二：金丝雀对比。1% 流量切到新版本，但对比指标必须配对：不是比 P99 绝对值，而是比「同一请求」在新旧两组的延迟差（按 traceId 配对）。这样能消掉流量结构差异。
- 尺子三：系统级指标。不只看接口延迟，还要看 CPU 利用率、内存带宽（perf stat）、InnoDB buffer pool hit rate、GC 暂停分布、网络重传率。优化后这些系统级指标如果恶化，即使接口 P99 降了也要警惕。
三条都过了，我才敢下「有效」的结论。任何一条单独通过都不算数。
另外我坚持一条纪律：优化上线前必须先固化 baseline 数据，且 baseline 的采集窗口不少于 7 天，覆盖工作日/周末、高峰/低峰。没做这一步的，一律不算"有依据的优化"。
【想听大家】
- 你们团队有没有"微基准很漂亮、上线反而变慢"的翻车经历？根因一般是什么？
- 金丝雀对比时，你们怎么消除「机器差异」带来的噪声？有同事用「同一台机器上起两个 pod」的方式做对比，但担心 cgroup 资源隔离不完全，这个思路靠谱吗？
- 流量回放（如 goreplay / tcpreplay）在你们环境里落地得怎么样？有没有遇到回放本身改变系统行为的情况？
- 你们有没有「优化后系统级指标恶化、但接口 P99 下降」的案例？怎么说服团队回滚？
这个话题我其实没有标准答案，想收集大家的实战案例和验证清单。有具体数字、具体命令、具体配置的欢迎贴出来，比抽象方法论有用十倍。