Go PGO 怎样准备代表性性能剖析文件

Go PGO（Profile-Guided Optimization）不是“采一份 profile 就能变快”。真正决定结果的是这份 CPU profile 是否覆盖了线上主要工作负载：请求类型、实例分布、时间段和长耗时操作都要尽量接近真实情况。准备好代表性 profile 后，可以把它放进主包目录作为 default.pgo，也可以在构建时用 -pgo 显式指定。

官方地址：https://go.dev/doc/pgo

先把“代表性”说清楚

PGO 把程序运行得到的 profile 反馈给编译器，让编译器更有把握地选择内联等优化。它读取的是 CPU pprof，因此准备工作的核心不是追求文件数量，而是让样本回答一个明确问题：这份二进制在真实使用时，哪些函数持续消耗 CPU？

对长期运行的 HTTP 服务，代表性通常来自生产流量，而不是只调用一个函数的微基准。先列出接口类型、读写比例、租户或数据规模、峰值与低峰时段，再决定采样实例。若服务有周期性任务，也要让采样窗口覆盖完整操作，避免只记录到其中一半。

从不同实例采集同长度的 CPU profile

如果服务提供了 net/http/pprof，可以从正在承载真实请求的实例采集 CPU profile。下面的命令只演示采集入口和本地文件命名，实际环境还应通过内网访问、权限控制和采集窗口安排保护 pprof 端点。

# 中文说明：从一个正在承载代表性流量的实例采集 30 秒 CPU profile
curl -o instance-a-30s.pprof "http://127.0.0.1:6060/debug/pprof/profile?seconds=30"

# 中文说明：另一台实例使用同样的 30 秒窗口，便于后续按样本量合并
curl -o instance-b-30s.pprof "http://127.0.0.1:6060/debug/pprof/profile?seconds=30"

单个实例在被采样时可能正好处于空闲状态，或者只收到某一种请求。更稳妥的做法是跨多个实例、多个时间段采集；采集记录至少保留实例角色、工作负载范围、开始时间和时长。这样后续看到热点变化时，能判断是流量变化还是 profile 偏差。

合并前先统一采样窗口

go tool pprof -proto 可以把多份 profile 合成一份。它本质上按输入样本做汇总，并不会自动理解“这份采了 30 秒，那份采了 5 分钟”意味着不同权重。如果把不同长度的窗口直接相加，长窗口往往会在结果中被过度代表。

# 中文说明：把相同 30 秒窗口的样本合并成 PGO 输入文件
go tool pprof -proto instance-a-30s.pprof instance-b-30s.pprof > merged.pprof

# 中文说明：保留 profile 文件名，便于构建记录和后续替换
cp merged.pprof ./default.pgo

“同长度”只是起点，还要看样本是否来自相似的工作负载。如果一个 profile 主要来自读请求，另一个主要来自写请求，应该先决定要优化哪个业务版本；对多个业务都重要的服务，再考虑按整体流量权重合并，而不是简单平均。

把 profile 接入 Go 构建

最省心的目录约定是把 default.pgo 放在被构建二进制对应的主包目录。Go 构建会自动发现它；构建脚本也可以显式写出 -pgo=auto，让意图更清楚。若 profile 不在源码目录，可传入路径；-pgo=off 则用于明确关闭 PGO。

# 中文说明：main 包目录中的 default.pgo 会被自动选作 PGO 输入
go build -o bin/api ./cmd/api

# 中文说明：profile 在临时目录时显式指定，避免依赖当前工作目录
go build -pgo=/profiles/api.pprof -o bin/api ./cmd/api

# 中文说明：对照构建时关闭 PGO，便于比较相同源码的两种产物
go build -pgo=off -o bin/api-no-pgo ./cmd/api

显式路径会应用到这次命令涉及的所有主包。如果一条命令同时构建多个二进制，它们可能被错误地共用同一份 profile，通常更适合拆成多次 go build，为每个二进制绑定自己的工作负载数据。

让 profile 进入持续发布闭环

一次构建成功并不代表 profile 永远有效。更实用的闭环是：先发布没有 PGO 的初始版本，在线上收集 profile，下一次发布从最新源码和 profile 构建，再继续收集。Go PGO 对源码小幅变化和已经优化过的二进制具有一定稳定性，但大规模改名、跨包移动热点函数，都会降低旧 profile 的匹配效果。

新功能第一次上线时，旧 profile 里还没有这条路径，它不会立即得到针对性的 PGO 优化；等真实流量运行并重新采集后再更新。若一个二进制服务多种差异很大的工作负载，可以按工作负载分别构建，也可以选择最重要的工作负载，或按业务占比合并。

常见问题

只跑一个微基准能不能生成 PGO profile？

可以生成输入文件，但它通常只覆盖很小的代码区域，不适合代表完整服务。除非该基准确实等价于目标程序的主要工作负载，否则优先从生产流量采集。

不同采样时长的 profile 能不能直接合并？

技术上可以合并，但样本会按数量相加，较长窗口会被放大。若想让实例和时段贡献更可控，先统一采样时长，或在合并前明确权重策略。

profile 文件一定要提交到源码仓库吗？

不是强制要求，但把它与源码一起管理更容易复现构建，也能让发布记录明确使用了哪一版性能输入。涉及敏感运行信息时，应先按团队的数据管理规则处理。

准备 Go PGO profile 时，最值得优先检查的是“它代表谁”：代表哪类请求、哪批实例、哪个时间段以及哪个二进制。把采集上下文和文件一起管理，再用固定窗口合并，PGO 才能成为持续发布的一部分，而不是一次性的性能实验。