不能。Go 1.20 的 PGO 是实验性功能，默认关闭，必须手动提供 runtime/pprof 采集的原始 .pb.gz 格式 CPU profile 文件，且需与目标平台、Go 版本、构建标签完全一致。
Go 1.20 的 go build -pgo 能直接开箱即用吗？
不能。PGO 在 Go 1.20 中是实验性功能，默认关闭，且必须手动提供一个有效的 pprof CPU profile 文件（.pb.gz 格式），不能只写 -pgo=auto 或留空。
-
go build -pgo=foo.pprof是唯一合法用法；-pgo=on、-pgo=auto会报错unknown pgo mode - profile 文件必须由
runtime/pprof在真实负载下采集，用net/http/pprof抓的/debug/pprof/profile默认是 30 秒 CPU profile，但需加?seconds=60确保覆盖典型路径 - 采集时程序要跑满典型业务逻辑——比如 HTTP server 要真发请求、CLI 工具要跑完整命令链，否则 profile 空或偏斜，PGO 反而拖慢性能
为什么 go tool pprof 导出的文件不能直接给 -pgo？
因为 go build -pgo 只认 Go 运行时原生生成的二进制 profile（pprof.Profile 序列化格式），而 go tool pprof 默认导出的是可视化格式（如 PDF、SVG）或文本摘要，不是原始数据。
- 正确做法：用
curl -s "http://localhost:6060/debug/pprof/profile?seconds=60" > cpu.pprof直接保存原始.pb.gz文件 - 如果已有
pprof文件但不确定格式，用file cpu.pprof检查——输出含gzip compressed data才可用；若显示text/plain，说明已被pprof工具转成文本，不可用于 PGO - Go 1.20 不支持从 trace 文件（
trace.out）或内存 profile（/heap）生成 PGO 数据
-pgo 编译后二进制体积和启动时间会怎么变？
通常体积 +3%～8%，冷启动时间基本不变，但首请求延迟可能略升（因 inline 决策更激进，函数内联增多导致代码段变大）；热路径执行速度提升明显，实测 HTTP handler 吞吐常有 8%～15% 提升。
- PGO 不改变 ABI，老 binary 替换新 binary 无需重启服务（前提是没改接口）
- 开启 PGO 后
go test -run=xxx -bench=.结果可能波动变大——因为 profile 覆盖不均，某些 benchmark 子测试未被采样，编译器不会为它们优化 - 交叉编译不支持 PGO：
GOOS=linux GOARCH=arm64 go build -pgo=cpu.pprof会失败，profile 必须与目标平台一致（即在 arm64 机器上采集，再在 arm64 上编译）
线上服务启用 PGO 最容易漏掉哪一步？
忘了在构建环境里复现 profile 采集时的 Go 版本、构建标签（-tags）和链接器选项（-ldflags）。哪怕只差一个 -tags=production，PGO 生成的代码就可能跳过关键分支，导致 panic 或逻辑错误。
立即学习“go语言免费学习笔记（深入）”；
- 建议把 profile 采集命令固化进部署流程：
./myapp -mode=profile && sleep 60 && kill %1，并记录go version和go list -f '{{.StaleReason}}' .确保模块未变更 - CI 中不要用
go run main.go采集 profile——它绕过 build cache，生成的 profile 和最终go build产物不匹配 - PGO 不兼容
go:build ignore或条件编译块里被裁掉的代码；如果 profile 里没触发某段// +build linux代码，即使 Linux 下编译，那段也不会被优化
