Go PGO 没有加速怎么办：检查生产 profile 代表性与构建命中情况

“已经加了 PGO，线上却几乎没变快”通常不是先怀疑编译器，而是先核对两个边界：profile 是否覆盖了真实生产负载，以及最终二进制是否真的读到了它。Go PGO 使用 CPU pprof 作为输入；从 Go 1.20 起编译器支持这项能力，官方也明确建议优先从生产环境收集代表性 profile。

排查顺序应是“生产流量代表性 → 构建文件命中 → 同负载复测”。只看到构建命令成功，不能证明优化已经针对线上热点生效。

先判断 profile 是否真的代表生产负载

最容易误判的是“我有一份 pprof，所以 PGO 应该有效”。如果 profile 采集时实例正好空闲，或只在一天中的低峰抓了 30 秒，它描述的只是那一小段调用分布。长任务、读写比例不同的实例、只占少数的特殊请求，都会让热点偏离线上主路径。

优先从正在承载真实请求的实例采集 CPU profile，例如服务接入 net/http/pprof 后获取：

curl -o prod-a.pprof "http://127.0.0.1:6060/debug/pprof/profile?seconds=30"; curl -o prod-b.pprof "http://127.0.0.1:6060/debug/pprof/profile?seconds=30"; go tool pprof -proto prod-a.pprof prod-b.pprof > merged.pprof

合并时尽量让每份 profile 的采样时长一致，因为 pprof 合并本质上是样本相加，时间更长的文件会被过度代表。更稳妥的采集表至少覆盖不同时间段和不同实例；如果服务存在明显的读多写少差异，不要只拿其中一种流量当“全站 profile”。

再确认 go build 实际命中了哪个 profile

把最终使用的文件命名为 default.pgo 并放进被构建主包目录，是最容易复查的方案：

cp merged.pprof cmd/api/default.pgo && go build -o bin/api ./cmd/api

也可以把路径写在命令中：go build -pgo=cmd/api/merged.pprof -o bin/api ./cmd/api。-pgo=auto 对应自动发现 default.pgo，-pgo=off 则明确关闭。排查时把构建日志、profile 的提交记录和产物哈希一起留存，避免 CI 在另一个工作目录里读取了旧文件。

注意一个边界：同一次 go build -pgo=/tmp/foo.pprof ./cmd/api ./cmd/worker 会把同一 profile 应用于所有 main package。两个二进制的工作负载不同，就应拆成两次构建，分别使用各自的 profile；否则“某个服务没有收益”可能只是输入错配。

用同一负载做 PGO 前后对比

先保存不带 PGO 的基线，再用完全相同的请求样本、实例规格和并发配置测试带 PGO 的产物。至少记录吞吐、端到端延迟和 CPU 使用率，不能只盯某个函数是否更容易内联。

# 基线构建：go build -pgo=off -o bin/api-nopgo ./cmd/api；PGO 构建：go build -pgo=cmd/api/merged.pprof -o bin/api-pgo ./cmd/api

如果两次结果接近，先检查 profile 是否真的来自线上主流量，再确认带 PGO 的构建命令没有被脚本覆盖成 -pgo=off。如果服务刚加入一条新路径，旧 profile 中根本没有它，第一次带 PGO 的版本也不会立刻针对这条新路径优化；应在新代码稳定运行后重新采集。

哪些情况说明该重新采集 profile

profile 不是永久配置。大量重命名或跨包移动热点函数会降低旧样本与新源码的匹配度；工作负载从读请求切到写请求、流量时段发生变化，或者发布了大块新逻辑，也都应重新采集。Go PGO 对源码和已优化二进制存在一定稳定性设计，但这不等于可以无限期复用旧输入。

• 代表性不足：增加实例、时段和请求类型，再按相同采样时长合并。
• 单二进制多工作负载：性能敏感场景优先拆分产物，否则按业务占比合并并接受折中。
• 源码漂移明显：先发布新代码，再收集反映新调用结构的 CPU profile。
• 构建时间变长：PGO 会影响整个依赖图，首次使用 profile 可能重建更多包；后续仍可受构建缓存帮助。

相关问题

微基准能不能直接拿来做 PGO？

可以作为没有生产环境时的替代，但微基准通常只覆盖程序很小的一部分，应用到完整服务时收益可能很有限。

同一份 profile 能用于不同架构吗？

Go 官方说明 profile 格式可跨 GOOS/GOARCH 使用，但平台特有源码如果与 profile 不匹配，就不会得到同等优化；跨平台发布仍要单独复测。

PGO 没加速是不是一定会变慢？

不一定。非代表性 profile 可能把优化机会放在冷路径，官方预期不应让热点路径因此变慢；若实际变慢，应保留可复现数据进一步定位。

把“没有加速”拆成 profile、构建和复测三个问题，通常比反复调整编译参数更快找到原因。下一轮发布前固定采集窗口、profile 文件、构建命令和对比负载，PGO 才会从一次性的优化尝试变成可复查的闭环。