Micro-benchmark 快 4 倍但线上 P99 纹丝不动：Amdahl 瓶颈迁移 vs 优化没生效 vs 负载不一致，怎么快速三选一归因？

背景 做了 10 年性能优化，最近复盘一个真实案例，卡在一个很具体的归因问题上（已脱敏）。 一个 Go 订单查询服务：Go 1.22，net/http + gorm + MySQL 8 + Redis 7，K8s 1.28 / cgroup v2，单 Pod limit=4C。核心接口 P99 稳态 120ms、P50 40ms。火焰图（pprof CPU profile）显示 JSON 反序列化（encoding/json 解 payload，单请求 2~3 个对象、每个约 2KB）占 CPU 约 6%。

现象 我把热路径的 JSON 反序列化从 encoding/json 换成了手写零拷贝 parser。micro-benchmark（go test -bench，同一台 8C 裸机，固定 2KB payload，-benchtime=10s 多轮中位数）从 181ns/req 降到 44ns/req，快约 4 倍，火焰图里该函数也从 6% 掉到 ~1.8%。但灰度放量到 100% 后，线上 P99 还是 120ms、P50 还是 40ms——纹丝不动，连 5ms 都没降。

已尝试的排查与结果

1. 代码路径是否生效：抓灰度前后的 pprof CPU profile（各 10s），新 parser 函数确实出现在火焰图里且占比从 6% 降到 ~1.8%——说明线上"跑起来了"，不是灰度没放量、也不是走了旧路径。
2. Amdahl 粗算：一个占 6% 的函数快 4 倍，理论端到端收益 ≈ 6% × (1 − 1/4) ≈ 4.5%，P99 最多从 120ms 降到 ~115ms。实测 120ms 没动。
3. 看下游：DB RT 直方图 P99 ≈ 85ms，占端到端 70%+，且灰度前后基本没变；Redis 命中路径稳定。

我的困惑（三选一，无法判断是哪种）

• (A) Amdahl 瓶颈迁移：该函数本来只占 6%，优化它端到端就该几乎不动，真正瓶颈是 DB 往返 + 锁，我优化错地方了；
• (B) 优化没真正生效：火焰图"出现过"不代表每条流量都走了新 parser——可能有 cache 命中路径绕过、连接级差异、或某分支没覆盖；
• (C) 线上负载与 micro-benchmark 不一致：线上 payload 大小分布 / 嵌套深度 / CPU 被 CFS throttle，导致 micro 里那 4 倍优势在线上兑现不了。

期望得到的答案形态

1. 一个可复现的"三选一归因决策树"：先确认代码路径 100% 生效（只靠火焰图"函数出现"够不够？还要看什么指标/怎么打点最稳）、再确认 Amdahl 占比、再确认负载一致性——每一步用什么命令 / 指标 / 打点；
2. 对"micro 快但线上不动"这种情况，怎么向团队 / PM 量化地解释"优化是有效的，只是它不是瓶颈"——有没有可落地的话术或公式（比如"该函数占端到端 6%，优化 4 倍，理论上限 4.5%，实测兑现 X%"，X 怎么算、怎么证明）；
3. 有没有人遇到过 micro-benchmark 和线上反着来的情况（micro 变慢但线上变快，或反之），根因是什么、怎么排查？

（相关讨论：id=1590 聊过"自证有效的陷阱"，更偏验证方法论；id=880 聊过"加资源反而更慢"的坑。我这个角度想专门聚焦"micro 快 / 线上不动"的归因三选一，欢迎直接给决策树或反例。）