pprof 服务未响应通常因未正确注册 handler：仅 import 不够，需 HTTP server 运行且显式挂载路由；内存泄露应重点关注 heap（inuse_space）和 goroutine 而非 allocs；本地分析失败时改用 top/svg；生产环境须鉴权、限频或动态启用。
pprof 服务没响应？检查 net/http/pprof 是否真注册了
很多人以为只要 import "net/http/pprof" 就自动生效，其实它只做了包初始化（注册 handler），但前提是得有 HTTP server 跑起来，并且显式调用 http.HandleFunc 或挂到路由上。最常见的情况是：开了 server，但没调 http.DefaultServeMux 相关逻辑，或者用了 gin/echo 等框架却没手动挂载 pprof 路由。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认是否调用了
http.ListenAndServe，且没有覆盖默认 mux；如果用了自定义http.ServeMux，需手动调pprof.Register(mux) - 在启动后 curl 一下：
curl http://localhost:6060/debug/pprof/，返回 404 就说明没注册成功 - Go 1.16+ 如果用
http.Serve且传入自定义 handler，必须自己把 pprof handler 加进去，例如：mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))
内存 profile 抓不到增长？别只看 allocs，重点盯 heap 和 goroutine
allocs profile 记录的是累计分配，不是当前内存占用；它会掩盖真实泄露——比如你每秒分配 1MB 但立刻释放，allocs 很高，heap 却几乎为零。真正反映“活对象”和潜在泄露的是 heap（尤其是 inuse_space）和 goroutine（泄露 goroutine 常伴随内存不释放）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 抓
heap必须在程序运行一段时间、疑似泄露已发生后再执行：curl -s "http://localhost:6060/debug/pprof/heap?debug=1" > heap.inuse - 对比两次
heap输出时，优先看inuse_space列，不是alloc_space - 加个
?gc=1参数（如/debug/pprof/heap?gc=1&debug=1）能触发 GC 再采样，避免误判临时对象 -
goroutine?debug=2可看到完整栈，比debug=1更容易定位卡死或忘记 close 的 channel / timer
本地分析 pprof 数据总卡在 web 命令失败？换用 svg 或直接看文本
go tool pprof -http=:8080 依赖本地浏览器和图形环境，在 CI、远程服务器或 WSL 下常失败，报错类似 failed to open browser: exec: "xdg-open": executable file not found。这不是配置问题，是工具链限制。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 跳过图形界面，用
top快速定位大头：go tool pprof mem.pprof; pprof> top10 - 生成 SVG 本地下载再打开：
go tool pprof -svg mem.pprof > mem.svg（注意：需系统装了dot，Ubuntu/Debian 上apt install graphviz） - 怀疑是 map 或 slice 泄露时，用
go tool pprof -source_path=. mem.pprof结合源码路径看具体行号 - 如果 pprof 文件是远程抓的，别用
curl | go tool pprof管道——部分版本会因 stdin 不可 seek 导致解析失败，先保存再分析
线上服务不敢开 /debug/pprof？用 runtime.SetMutexProfileFraction 和条件启用
默认 pprof 的 mutex 和 block profile 是关闭的，heap 和 goroutine 是开启的，但暴露整个 /debug/pprof/ 路径确实存在风险：攻击者可反复抓 profile 拖慢服务，或通过 goroutine?debug=2 看到敏感栈信息。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产环境不要用
http.DefaultServeMux直接挂 pprof；改用独立端口 + 鉴权中间件，例如监听:6061并校验 header 或 IP 白名单 - 降低 mutex 采样频率，减少性能扰动：
runtime.SetMutexProfileFraction(5)（默认 -1 关闭，设为 1 表示 100% 采样） - 按需开启：启动时不注册 pprof，出问题时通过信号（如
SIGUSR1）动态注册 handler，问题排查完再卸载 - 注意：Go 1.21+ 引入了
net/http/pprof.Server类型，支持更细粒度控制，但需手动集成，不是开箱即用
pprof 本身不难，难的是区分「分配多」和「没释放」，以及在线上敢用、会收口。很多泄露最后发现是 context 没 cancel、http.Client 没复用、sync.Pool 用反了——profile 只告诉你“哪堆对象多”，不告诉你“为什么还在”。
