测试中启用 pprof 需手动启动 HTTP 服务并注册路由，或使用 -test.cpuprofile 等 flag 生成离线文件；Benchmark 中应手动调用 pprof.StartCPUProfile 确保覆盖压测逻辑。
测试中启用 pprof 服务需要单独启动 HTTP 服务器
Go 的 pprof 默认绑定在运行时的 HTTP 服务上，但 go test 不会自动开启该服务。想在测试期间采集 CPU、内存等数据，必须手动启动一个 net/http 服务并注册 pprof 路由。
常见错误是直接跑 go test -cpuprofile=cpu.out 就以为能访问 /debug/pprof/ —— 实际上这些 flag 只触发采样写入文件，不开启 Web 接口。
- 测试中要交互式查看实时 profile，得在测试代码里加：
go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }() - 记得在
init()或TestMain中注册路由（1.16+ 默认已注册，旧版本需显式调用pprof.Register()） -
端口被占用时会 panic，建议用
net.Listen("tcp", ":0")动态选端并打印出来
用 -test.cpuprofile 等 flag 生成离线 profile 文件
如果只是想跑完测试就拿到一份 profile 数据用于后续分析，-test.cpuprofile、-test.memprofile、-test.blockprofile 是最轻量的方式。它们不依赖 HTTP，也不要求测试本身做任何修改。
注意这些 flag 属于测试二进制的参数，不是 go test 命令本身的 flag，所以必须写在 -- 后面或紧贴包路径之后：
- 正确：
go test -run TestFoo ./pkg -- -test.cpuprofile=cpu.prof - 错误：
go test -test.cpuprofile=cpu.prof -run TestFoo ./pkg（flag 被 go test 解析，无效） -
-test.memprofile只在测试结束时拍一次堆快照；如需追踪分配热点，应配合-test.memprofilerate=1（设为 1 表示每次分配都记录，仅调试用）
在 Benchmark 中使用 pprof 需主动控制采样周期
Benchmark 函数默认不触发 pprof 的 runtime hook，单纯加 -test.cpuprofile 可能采不到有效数据，尤其当函数执行太快、被内联或优化掉时。
可靠做法是在 BenchmarkXxx 内部手动启停 profiling：
func BenchmarkFoo(b *testing.B) {
f, _ := os.Create("cpu.prof")
defer f.Close()
pp := pprof.StartCPUProfile(f)
defer pp.Stop()
b.ResetTimer()
for i := 0; i < b.N; i++ {
Foo()
}}
这样能确保 profiling 覆盖实际压测逻辑，且不受 go test 自身初始化/清理阶段干扰。
- 避免在
b.ReportAllocs()之后才启动 memprofile，否则 alloc 统计和 profile 时间不一致 - 如果 benchmark 运行时间太短（StartCPUProfile 可能因采样频率不足而返回空数据
- 多个 benchmark 共享同一 prof 文件会导致数据混杂，建议按名称拼接文件名
分析 profile 文件时别忽略 symbolization 和焦点切换
用 go tool pprof cpu.prof 进入交互模式后，新手常卡在「看到一堆地址但找不到自己函数」——这是因为未加载符号表或未切换视图。
- 确保编译测试时没加
-ldflags="-w -s"，否则二进制无调试信息，pprof无法解析函数名 - 进入 pprof 后先输
top看热点函数，再用web生成调用图，或list Foo查看具体代码行耗时 - CPU profile 默认按“采样数”排序，但有时要看“累计时间”，需用
focus Foo缩小范围后再top - 内存 profile 中
inuse_space和alloc_space差异极大，前者反映当前存活对象，后者反映总分配量，选错会误判问题
profile 文件本身不包含源码，所有符号还原都依赖运行时二进制或测试产生的可执行文件。删了它，pprof 就只剩十六进制地址。
