压测数据到底能不能信：全链路压测、下游 mock、从线上 P99 外推，你站哪个？

背景

热榜上「限流阈值怎么定」那两篇讨论把"阈值该卡 QPS 还是并发数""该放网关还是 SDK"讲得挺清楚了，我读完卡在再往上游一步的问题：用来定阈值的那份压测数据本身，可信吗？

上个月帮一个团队做容量评审，他们给的压测报告很漂亮：单接口 QPS 6200、P99 38ms，全程用 JMeter 单机打、下游服务全部用 mock 替身（固定 20ms 延迟返回）。我现场问了一句"线上这个接口的 P99 是多少"，答案是 210ms，因为真实链路里下游有两个远程 RPC、一次 Redis、一次 MySQL，还有周末批量任务在抢同一批资源。mock 压测出来的 6200 QPS，放到生产环境大概是虚高的 3 倍以上。

常见分歧，我看到的至少有四种做法

1. 全链路压测派：影子库 + 流量染色 + 全下游真跑。数据最可信，但成本极高，中小团队基本玩不起，而且"影子流量"和"真实流量"的分布差异本身又是一个坑。
2. 下游 mock 派：把下游全部 mock 成固定延迟，只测本服务的计算与连接池瓶颈。便宜、可复现，但测出来的天花板和真实系统差一个数量级，只能用来"找本服务自己的上限"，不能直接当容量。
3. 线上 P99 外推派：不压测，直接从生产监控的 P99 / GC / 连接池水位反推，"离打满还有多少余量"。零成本，但只反映"当前流量下的稳态"，突发流量、下游抖动、批量任务叠加这些非线性因素完全看不到。
4. 混合派：本服务 mock 压测找瓶颈点 + 线上 P99 反推稳态余量 + 关键接口做一次小规模真实压测校准。听起来最合理，但三套数据怎么拼、权重怎么给，我至今没看到一套被验证过的公式。

我的倾向与理由

我站第 4 种，但有个前提：任何一份压测数据，在写进容量报告之前，必须先回答"下游是什么状态"这三个字。mock 出来的数字只能回答"本服务离自身瓶颈还有多远"，回答不了"系统能扛多少"。我见过太多事故复盘，最后翻出来都是"我们压测过、QPS 达标"，但没一个人能说出当时下游是什么状态。压测报告里如果只有一张 QPS-P99 曲线、没有"下游延迟分布假设"，这份数据在我这里等于没测。

想听大家的

• 你们团队现在到底是哪种姿势？如果选 mock，下游延迟是按固定值还是按线上 P50/P99 分布采样？
• 有没有人在生产环境里真跑过全链路压测？影子流量和真实流量的分布差异，你们是怎么对账的？
• 对于下游不可控（第三方 API、跨团队服务）的场景，你们怎么给"能扛多少"这个数字兜底？直接打折？打折系数怎么定？
• 最后一个私货：你们团队里"压测报告"和"容量结论"是不是同一份文档？我越来越觉得这两件事应该分开写。