性能回归门禁到底做多重：每次 PR 都跑压测，还是只信灰度期告警？聊聊取舍

背景

社区里关于「单点性能」的讨论已经很密——连接池怎么调、超时重试怎么配、慢 SQL 怎么治、Kafka 幂等怎么开，都写得很扎实。但我最近帮几个团队做性能复盘时，反复卡在同一条更前置的缝上：性能回归门禁到底该做多重。

我做了 10 年性能优化，带过的团队里至少有五种做法，没有一种是"标准答案"：

1. 完全不跑：靠 Code Review + 上线后 APM 告警兜底。便宜，但每次"上线才发现问题"都要回滚 + 复盘，隐性成本被低估；
2. 每次 PR 都跑一遍压测：JUnit 里挂 JMeter/k6，CI 30~60 分钟。最稳，但研发耐心被磨光，最后大家开始 @Ignore 或"本地跑过就行"，门禁形同虚设；
3. 只跑微基准（micro-bench）：JMH 测单方法 ns 级，进 CI。快，但抓不到连接池、GC、锁竞争、下游 RT 这类"系统级"毛刺；
4. 灰度期看 P99 告警：放量 1% → 5% → 50%，每档盯 30 分钟。贴近真实，但灰度桶本身有偏差（社区里已有帖讲过 uid 尾号分桶把 P99 虚高 220%），且灰度窗口内出事的爆炸半径不小；
5. 影子流量回放：拿线上 trace 重放，最贴近，但造数、脱敏、环境一致性都是坑。

我倾向的做法（不一定对，想听大家拍砖）：

• 门禁分层，不是二选一：PR 级只跑"快且稳"的微基准 + 一个 30 秒的"接口冒烟压测"（固定 50 QPS、看 P99 是否比基线劣化超过 20%）；
• 合并到主干后跑一次 10 分钟的"中压"（目标 QPS 的 30%~50%），产出 P99 / 错误率 / GC 时长三件套，作为发布卡点；
• 灰度期不再"盯告警"，而是把灰度桶的 P99 与同桶同时间段的对照桶 P99 做 delta 比较，避免桶偏差；
• 基线本身要版本化：每次发布记录 P50/P99/P999 + GC + 连接池占用，存到指标库，劣化超过阈值自动 block。

想听大家聊的几个具体问题：

1. 你们团队现在门禁做到哪一层？PR 级跑压测的，CI 时间预算给多少？
2. 微基准（JMH 之类）和"接口级冒烟压测"，你们怎么分？有没有"看起来是微基准、其实抓不到 GC"的坑？
3. 灰度期 P99 告警的阈值怎么定？用绝对值（<200ms）还是 delta（劣化 >20%）？
4. 基线版本化这件事，你们存哪儿？Prometheus recording rule？还是单独一张表？
5. 有没有人试过"AI 生成压测用例"？效果如何，还是纯噱头？

欢迎贴你们团队的真实配置（脱敏即可），尤其是"踩过的坑"——我这边攒了几个，比如"JMH 在 CI 里跑和跑在本地差 15%"、"k6 的 VU 模型和真实用户分布对不上"这类细节，可以单独再写一篇经验帖。