压测 QPS 和线上 QPS 对不上——性能优化到底该信压测，还是该信线上？

【背景】 我最近复盘一个案例：一个查询服务，压测环境稳跑 QPS 5000、P99 40ms，团队信心满满；一上线，真实流量才 1500 QPS，P99 就间歇性飙到 800ms+。团队第一反应是"压测数据不可信"，第二反应是"是不是线上有慢 SQL / 连接池 / GC 的问题"。我后来把两边的 trace 拉出来一对，发现压测和生产根本不是同一个系统：数据量、索引选择性、依赖服务、GC、网络路径全都不一样。所以我想借这个帖子把「性能优化到底该信压测还是信线上」这个争点摊开聊。

【常见分歧 / 几种做法】

1. 压测派：优化前必须先压测，没有压测数据就"不敢动"。压测能复现、能对照、能量化前后差异，是"科学优化"的地基。
2. 线上派：压测数据全是"实验室数据"，环境一换就失真；真正该信的是线上 trace、慢日志、APM，优化必须基于真实流量归因。
3. 折中派：两个都要——压测做"回归 / 容量上限"，线上做"归因 / 定位"。但现实里很多人分不清两者的职责边界，结果用压测数据去拍线上容量，或者拿线上噪音当优化目标，越调越偏。

【我的倾向与理由】 我这两年的结论是：压测和线上是两种不同用途的数据，别混用。我的判断原则：

• 归因（问题出在哪）：以线上真实 trace / 慢日志为准。因为压测的瓶颈经常和线上不是同一个——压测可能卡在算法，线上却卡在 DB、网络、GC。
• 验证（改完有没有变好、有没有变坏）：用压测做回归，因为它可控、可复现、能排除线上噪音。
• 容量（能扛多少）：压测给上限，但必须打折扣（我习惯打 5–7 折再留 buffer），因为生产的依赖、数据、GC 都会吃掉一部分余量。 一句话：信线上的"事实"，信压测的"对照"。把压测当唯一真理的团队，往往栽在"压测绿、线上红"；只信线上噪音的团队，又容易把 GC 抖动当代码问题去改，越改越乱。

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

• 你们的压测环境和生产，数据量 / 依赖 / GC 这些差异大吗？怎么弥合这个 gap（影子库？全链路压测？mock 依赖？）
• 有没有"压测数据完全不可信、被线上打脸"的具体案例？当时怎么定位的？
• 反过来，有没有"压测很稳、一上线就抖"的场景？最后根因是什么（连接池？GC？慢 SQL？）
• 你们团队做性能优化，第一手数据是压测报告还是线上 APM？为什么？
• 小团队没有全链路压测条件，怎么在"信压测"和"信线上"之间取平衡？

贴出你的场景 + 最终判断（最好带点数据：压测 QPS vs 线上 QPS、P99 差异、根因），大家一起对照，比"看情况"有用得多。