性能优化的验收标准之争：P99 降了就收工，还是必须追到根因？你们怎么区分「修好了」和「埋雷了」？

【背景】 做性能优化 8 年，复盘过不少「指标降了、大家鼓掌、三个月后又炸」的案子。最典型的一次：一个商品详情接口 P99 从 180ms 超 SLO（100ms），我第一反应是加 Caffeine 本地缓存。加完 P99 直接落到 30ms，曲线漂亮，评审通过，验收「达标」，收工。

但 DB 里那条缺索引的 JOIN 慢查询还在跑，每次缓存 miss 都实打实打 DB。三个月后热点 key 漂移、miss 率一上来，P99 又回 200ms，而且更糟——慢 SQL 把连接池也拖累了（这个坑和热榜那篇《连接池不是越大越好：一次 P99 抖动的排查与调参》是同一类病根）。

一句话复盘：我优化的是「指标」，不是「问题」。刷漆刷得再亮，屋顶还在漏水。

【常见分歧 / 几种做法】

• 指标派：P99 进 SLO 就是完成，别过度优化，ROI 优先（呼应热榜那篇「P99 降 1ms 值不值得花 3 天」的讨论，但那问的是「值不值得投」，我这条问的是「什么算投完」）。
• 根因派：指标达标但根因没动 = 埋雷，下次数据量一涨 / 缓存一 miss 必炸，债迟早要还。
• 折中派：核心链路追根因，长尾 / 一次性活动接口指标达标即可，别为一条慢 SQL 重构半天。

【我的倾向与理由】 我两派都不站死，按「收益的脆弱度」分：

• 脆弱收益——靠缓存命中、靠数据量还小、靠运气才达标 → 必须追到根因，否则那是借来的时间，迟早归还。
• 稳健收益——结构上消除了瓶颈（补了索引、拆了 N+1、把串行改并行）→ 可以收工。

判断口诀就一句：「如果把我加的那个优化手段拿掉，系统是不是就回到原点？」是 → 你在掩盖，不是在修好。

【想听大家在什么场景下怎么选】

1. 你们团队怎么区分「可以收工」和「埋雷了」？有客观判据还是凭感觉？
2. 有没有踩过「指标达标、后来炸了」的坑？当时是怎么发现根因没动的？
3. 你们给性能验收的 checklist，是写「P99 ≤ X」就完事，还是会附一条「根因已消除」的硬指标？
4. 资源永远不够时，「核心链路追根因」的边界怎么划——按 QPS？按用户可感知？还是按老板拍板？