【背景】 我做了 3 年技术产品，带过 2 个 0→1 的新服务从立项到上线。每次上线前压测，我收到的报告基本长这样：
"P99 = 45ms，QPS 峰值 3200，CPU 72%，结论：满足需求。"
然后三个月后流量翻了一倍，P99 飙到 180ms，团队才意识到——当初那个"满足需求"，其实是"满足那天下午 3 点那台 4C8G 机器上的需求"。环境换了、依赖版本升了、索引加了一个、连接池默认值没改，基线就废了，但没人知道它什么时候废的。
【常见分歧 / 几种做法】 我观察了至少 5 个团队，做法大致分三档：
第一档：一次性压测报告。 上线前压一轮，出个 P50/P99/P999 + 资源水位，贴到 wiki 就完事。没有复现脚本，没有基线快照，下次压测全靠"记得上次大概多少"。占比最大，我估计 60%+ 的团队停在这。
第二档：有基线但靠人盯。 有压测脚本（JMeter / k6 / wrk），基线数字记在文档里，每次发版前手动跑一轮，跟上次比。问题是：谁跑？谁比对？谁拍板"涨了 15% 能不能发"？答案通常是"看情况"。
第三档：基线进 CI/CD 门禁。 k6 或 Locust 脚本挂在 CI 流水线里，每次合并 PR 自动跑一轮核心链路压测，P99 超过基线 ±10% 就 block merge。环境用固定的 K8s 命名空间 + 固定版本的下游 mock。这个我见过 2 个团队在做，维护成本不低但确实拦住了 3 次回归。
【我的倾向与理由】 我倾向第二档半到第三档之间，具体说：
-
基线必须可复现：压测脚本进 Git，环境配置（JVM 参数、连接池大小、下游 mock 版本）锁死在脚本里，不依赖"那台测试机"。我上次推一个团队把 wrk 脚本从共享目录挪到仓库，光这一步就少了一半"上次压出来多少来着"的扯皮。
-
门禁只卡核心链路的 P99 + 错误率，不卡 QPS 上限。理由：QPS 上限是容量问题，跟代码变更关系不大；P99 和错误率才是"这次改动有没有让事情变慢/变坏"的信号。卡 P99 的阈值我建议设 基线 × 1.15（15% 容差），不是 10%——我见过一个团队设 5% 容差，结果 GC 抖动一次就 block 了三次，最后大家学会"压测前手动 warm up 两轮"，门禁就形同虚设了。
-
基线不是"建一次"，是"每次依赖变更自动刷新"。下游 mock 版本升级、JDK 小版本升级、K8s 节点内核升级——这些都会悄悄移动基线。我的做法是：依赖变更走独立 PR，CI 自动跑基线对比，P99 变化 >10% 就在 PR 里标注"基线已漂移"，由 owner 确认是预期变更还是回归。
-
投入产出算一笔账：一个 5 人服务，维护基线脚本 + CI 集成大约 2 人天初始 + 每次依赖变更 0.5 小时。换来的是：每次发版前不用"手动压一轮 + 人肉比对"（约 1 小时 × 发版频率），以及拦住回归的隐性收益（一次 P99 回归到线上，定位 + 回滚 + 复盘通常 2~4 人天）。按我们团队每月 4 次发版算，第 2 个月就回本了。
【想听大家怎么选】 想请不同场景的同学聊聊：
- 你的服务 QPS 量级是多少？ 100 和 10w 的基线策略应该完全不同，你觉得"值得上 CI 门禁"的 QPS 门槛大概在哪？
- 下游依赖怎么 mock？ 我见过用 wiremock 锁版本、见过用 contract test 保接口契约、也见过直接连 staging 的下游——你们线上怎么做的？mock 的保真度够吗？
- 基线漂移你们怎么处理？ 是"变化超阈值就 block"还是"变化超阈值就通知、人拍板"？哪种你们试过、哪种翻过车？
- 你们团队现在停在哪一档？ 如果要从第一档升到第二档半，你们觉得最大的阻力是技术（脚本 / 环境）还是流程（谁负责、谁审批）？
欢迎带具体数字来聊——你的 P99 基线是多少、容差设的多少、每月发版几次、基线脚本多少人维护。空谈"要做基线"的帖子我看过太多了，这次我想听"做了之后踩了什么坑"。