pprof服务未启动需检查net/http/pprof是否正确注册，确保下划线导入或手动注册路由；CPU采样时长应按需控制，避免默认30秒；火焰图需用go tool pprof生成并过滤噪声；生产环境应按需触发而非全量开启。
pprof 服务没起来？检查 net/http/pprof 是否已注册
Go 的 pprof 默认不自动暴露 HTTP 接口，必须显式导入并注册。常见错误是只 import 了 net/http/pprof 却没调用任何注册函数，导致 /debug/pprof/ 返回 404。
- 确保在 main 包中执行
import _ "net/http/pprof"（下划线导入会触发包 init 函数） - 如果用了自定义
http.ServeMux，需手动注册：mux.HandleFunc("/debug/pprof/", http.HandlerFunc(pprof.Index)) - 微服务常使用独立路由前缀（如
/metrics），别把/debug/pprof拦截或重写掉了 - 启动后 curl -v http://localhost:8080/debug/pprof/ 确认返回 HTML 列表，否则后续所有分析都无效
采样时间太短或太长？用 runtime/pprof 控制 CPU profile 时长
HTTP 接口 /debug/pprof/profile 默认采样 30 秒，对高并发微服务可能过长（阻塞请求）、对低频问题又可能错过热点。直接调用 runtime/pprof 更可控。
- 用
pprof.StartCPUProfile(f)+pprof.StopCPUProfile()手动启停，适合在特定 RPC 入口或慢请求路径中埋点 - 避免在 goroutine 中无保护地多次 Start/Stop ——
StartCPUProfile是全局单例，重复调用 panic - 采样文件建议用
os.CreateTemp生成唯一路径，防止多实例覆盖；临时文件记得 deferf.Close() - 生产环境慎用 30 秒默认值：一次采样可能吃掉数百 MB 内存，尤其 GC 频繁时 profile 数据膨胀明显
火焰图看不懂？用 go tool pprof 提取关键路径
原始 profile 文件是二进制格式，直接打开只能看到文本摘要。火焰图能直观定位热点函数，但需要正确生成和过滤。
- 生成 SVG 火焰图：
go tool pprof -http=:8081 cpu.pprof（自动启动本地服务，访问 http://localhost:8081） - 排除 runtime 和 stdlib 噪声：
go tool pprof -focus=YourServiceName cpu.pprof，比-ignore=runtime更精准 - 微服务常有大量 HTTP handler wrapper（如 middleware、trace 注入），用
-trimpath去掉 GOPATH 路径前缀，让函数名更干净 - 注意采样单位：CPU profile 显示的是“采样时正在执行的栈”，不是耗时绝对值；占比 5% 的函数未必是瓶颈，要看它是否被高频调用或阻塞下游
线上服务不敢开 pprof？用 pprof.Profile 按需触发
全量开启 /debug/pprof 有安全风险，且可能被恶意拉取堆内存数据。更稳妥的做法是按需启用，配合信号或管理端点控制。
- 监听
SIGUSR1信号触发 profile：signal.Notify(c, syscall.SIGUSR1); - 在健康检查端点（如
/health?profile=cpu）里加白名单校验，仅允许内网 IP 或带 secret token 的请求 - profile 文件写入前先检查磁盘空间：
stat, _ := os.Stat("/tmp"); if stat.Avail - 别依赖
pprof.Lookup("goroutine").WriteTo抓 goroutine dump —— 它会阻塞所有 goroutine，微服务中极易引发雪崩
pprof 不是开关一开就出答案的黑盒，CPU 瓶颈往往藏在锁竞争、channel 阻塞或低效序列化里，profile 只告诉你“哪段代码花时间”，不解释“为什么花时间”。盯着 runtime.chansend 或 sync.(*Mutex).Lock 占比高时，得去翻业务代码里的 channel 容量设置和 mutex 作用域。
