应避免全局30秒profile，改用单次高负载调用+精确采样窗口；pprof基于10ms定时采样，仅在goroutine执行用户代码时捕获栈帧，IO等待态无法覆盖业务逻辑。
直接上结论：别用全局 30 秒 profile，而是对目标模块触发单次高负载调用 + 精确采样窗口，否则 90% 的样本会落在 runtime.futex 或 syscall.Syscall 上，业务函数几乎为 0。
如何让 pprof 真正捕获到你的模块代码
pprof 的 CPU profiler 是 timer-based sampling（默认每 10ms 发一次 SIGPROF），它只在 goroutine 正在执行用户代码时才能抓到栈帧。如果你的模块被封装在 HTTP handler 里，而请求本身耗时短、中间大量等待（DB、RPC、channel receive），那 profile 就会“看不见”你写的逻辑。
- 必须确保采样期间模块处于持续 CPU 计算状态，不是 IO 等待态
- 不要依赖
<a href="https://www.php.cn/link/e0652a0045dbc0b14d016619158789ce">https://www.php.cn/link/e0652a0045dbc0b14d016619158789ce</a>这种粗粒度方式——它对空闲服务无效 - 最小可行做法：把模块逻辑包进一个 tight loop（比如重复执行 1000 次），再启动 CPU profile
示例：
func BenchmarkHotModule(b *testing.B) {
for i := 0; i < b.N; i++ {
YourBigModule.Process(...) // 确保这里不 sleep、不阻塞、不等 IO
}
}
然后运行：go test -bench BenchmarkHotModule -cpuprofile cpu.pprof怎么避免 profile 被 runtime 开销淹没
即使你跑的是纯计算逻辑，如果模块内部频繁分配内存或触发 GC，runtime.mallocgc、runtime.scanobject 也会挤占 top 函数排名，掩盖真实业务热点。
立即学习“go语言免费学习笔记（深入）”；
- 检查
go tool pprof -top cpu.pprof输出中是否大量出现runtime.前缀函数 - 若是，先加
-memprofile mem.pprof对比：如果mem.pprof中runtime.mallocgc占比也高，说明问题在对象分配，不是 CPU 算法本身 - 可临时禁用 GC 观察（仅调试）：
GOGC=off go test ...，但注意这会让内存暴涨，只用于验证是否 GC 干扰了采样
为什么 web 火焰图里看不到你的函数名
常见原因有两个：
- 源码未编译进二进制（如用了
go build -ldflags="-s -w"），导致符号表缺失 → 火焰图显示ExternalCode或十六进制地址 - 模块代码在 vendor 下且路径被 strip，pprof 无法映射回源文件
解决方法：
- 编译时去掉 strip：
go build -o app main.go（不加-ldflags） - 如果必须 strip，用
go tool pprof -symbolize=executable强制解析 - 确保
cpu.pprof文件和二进制在同一台机器生成，路径一致
真正卡点不在工具链，而在采样时机是否与业务执行严格对齐——模块再大，只要没在 CPU 上跑，pprof 就什么都看不到。
