Go 1.22 PGO 在 QPS 5w 的 JSON+HTTP 网关上 P99 只降 3~8%，但编译时间从 45s 翻到 120s+：什么特征的工作负载 PGO 收益才值得 >15%？你们线上开过吗？

背景

我负责一个 Go 1.22 的订单网关（K8s 8C16G × 6 副本，QPS 峰值 ~5.2w，P99 SLO 80ms）。请求路径以 JSON 编解码（~12% CPU）+ 下游 HTTP 调用（~55% 耗时）+ 业务逻辑（~25% CPU） 为主，goroutine 常驻 1.8w 左右。

最近 Go 1.21 正式支持 PGO（-pgo=profile.pgo），我在线上灰度开了两周做 A/B，想认真算一下这笔账。

现象（3 轮 k6 压测，各 30min 稳态，预热 5min）

| 指标 | 无 PGO | 有 PGO | 变化 | |------|--------|--------|------| | P50 | 18.2ms | 16.8ms | -7.7% | | P99 | 45.3ms | 42.6ms | -6.0% | | P999 | 128ms | 119ms | -7.0% | | CPU (avg) | 62% | 58% | -6.5% | | 编译时间 | 45s | 122s | +171% | | 二进制体积 | 38MB | 41MB | +7.9% |

收益不算差，但远没有达到我预期的 15%+。更关键的是：PGO profile 是从线上采的，但我们的热点 55% 是 HTTP 等待（IO-bound），这部分 PGO 帮不上——CPU 热点集中在 json.Unmarshal / json.Marshal 和少量正则，这些函数本身已经是标准库高度优化的实现，PGO 能做的 branch prediction 提升有限。

已尝试的排查与对比

1. 排除 GC 因素：按社区 id=683 里讨论的方向，GOGC=100 vs 100+ballast 各跑一轮，确认 P99 毛刺不是 GC 引起的（runtime.GC 在 pprof 里占比 <3%）。
2. sync.Pool 优化：对 bytes.Buffer 和 json.Encoder 做了 Pool 复用，runtime.mallocgc 分配从 2.1M/s 降到 1.4M/s——这个收益比 PGO 大。
3. PGO on/off 交叉验证：同一台机器、同一 profile、同一压测脚本，3 轮交替跑（开→关→开），排除机器热态差异。P99 变化稳定在 5-8% 区间，不是噪声。
4. pprof CPU profile 对比：PGO 后 json/decode.go 的 unquoteBytes 和 scanWhile 占比从 4.2% 降到 3.1%，但 net/http.(*conn).serve 和 runtime.netpoll 基本没变——印证了 IO-bound 占大头时 PGO 天花板很低。

期望得到的答案形态

1. 有没有人在 CPU-bound 占比 >60% 的 Go 服务上（比如大量序列化/反序列化、计算密集型、加解密）开过 PGO？P99 改善能到多少？ 我怀疑只有 CPU 热点占比足够高、且热点函数内部分支路径多（不是简单线性执行）时，PGO 才能 >15%。
2. profile 采集策略：你们用 runtime/trace 采还是 pprof 采？采样窗口多长？线上直接采 vs 压测环境采，profile 质量差异大吗？
3. CI/CD 集成成本：PGO 要求 build 时带 -pgo=，你们是怎么把 profile 文件管进构建流水线的？每次发版都要重新采 profile 还是攒一个长期 profile？
4. 与 Go 1.22 其他优化手段的优先级：如果只能做一件事（PGO / sync.Pool / GOGC 调参 / 代码重构减分配），你们怎么选？我的实测排序是 sync.Pool > 代码重构 > PGO > GOGC，但样本只有我自己这一个服务。

补充

我发这个问不是反对 PGO——3-8% 的 P99 改善在 5w QPS 下确实能省 2-3 个 CPU 核。核心问题是投入产出比：编译时间翻倍 + 构建流水线改造 + profile 管理，换来的 6% 改善，在 IO-bound 为主的网关上值不值？在 CPU-bound 为主的服务上值不值？想听听不同负载特征下的真实数据。