pprof需显式注册并独立监听，heap profile不反映rss上涨主因是goroutine泄漏、cgo/unsafe绕过gc或gc未释放内存；生产环境启用有安全风险，须限制访问且避免误采集。
怎么用 pprof 启动 Web 服务的性能分析
Go 标准库自带 net/http/pprof，但默认不生效——它只是注册了一堆 HTTP handler，得你自己把它们挂到路由上。最常见错误是只 import 了包却没触发注册，或者注册了但监听地址没暴露（比如只绑 127.0.0.1:6060，而你从外部访问）。
- 确保在 main 包里执行
import _ "net/http/pprof"（下划线导入触发 init） - 启动一个独立的 HTTP server，比如
go func() { http.ListenAndServe("localhost:6060", nil) }() - 不要把它塞进主业务 router（如 gin/echo 的 engine），除非显式调用
http.DefaultServeMux或手动注册 handler - 如果用
http.ServeMux自定义 mux，需手动添加：mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))
为什么 heap profile 看不到增长，但 RSS 持续上涨
pprof 的 /debug/pprof/heap 默认返回的是「正在被引用的对象」快照（allocs vs inuse），不是进程总内存。RSS 上涨但 heap profile 平稳，大概率是：
goroutine 泄漏（堆积的阻塞 goroutine 占用栈内存，
/debug/pprof/goroutine?debug=2查看）-
unsafe操作或 cgo 调用绕过 Go GC（比如 C malloc + 忘 free）立即学习“go语言免费学习笔记（深入）”；
大量小对象触发 GC 频繁但未回收（检查
GOGC是否被设得过高，或runtime.ReadMemStats中HeapReleased长期为 0）访问
/debug/pprof/heap?gc=1强制 GC 后采样，排除 GC 延迟干扰对比
/debug/pprof/heap?debug=1和/debug/pprof/allocs?debug=1，看分配总量是否远大于 inuse用
go tool pprof <a href="https://www.php.cn/link/fd7d20b9c2863af38093925e27205843">https://www.php.cn/link/fd7d20b9c2863af38093925e27205843</a>进入交互模式，执行top和peek定位具体函数
生产环境开启 pprof 有哪些实际风险
pprof endpoint 本身不加密、无鉴权，暴露即等于开放内存/调用栈读取权限。线上误开等于交出应用“X 光片”。
- 不要通过反向代理（如 nginx）简单加个 basic auth 就上线——pprof 返回的 profile 是二进制数据，某些 proxy 会破坏 content-encoding
- 避免监听公网地址；推荐绑定
127.0.0.1:6060，再通过 ssh port forward 临时调试：ssh -L 6060:localhost:6060 user@prod-server - 若必须对外提供，用中间件做 IP 白名单（如只允运维跳板机）+ 路径随机化（比如把
/debug/pprof/改成/debug/xyz7a2/），但别依赖路径隐藏作为安全手段 - 某些云平台（如 AWS ECS、GKE）会自动采集
/metrics，注意别把 pprof 路径写进 prometheus scrape config，否则持续拉取 heap profile 会拖慢服务
goroutine 泄漏时 pprof 显示大量 runtime.gopark，怎么定位源头
runtime.gopark 是 goroutine 进入等待状态的通用标记，本身不说明问题。真正要盯的是它上面一级调用——谁调用了 chan receive、time.Sleep、sync.WaitGroup.Wait 却永远等不到信号。
- 用
go tool pprof <a href="https://www.php.cn/link/286313479c3c890d2aebb38af6375722">https://www.php.cn/link/286313479c3c890d2aebb38af6375722</a>获取文本堆栈，搜索created by行，找到启动 goroutine 的函数 - 在 pprof 交互界面中执行
top -cum，看累计时间最长的非 runtime 函数 - 常见泄漏点：HTTP handler 里启 goroutine 但没处理 client disconnect（
req.Context().Done()未监听）、ticker 未 stop、channel 写入端关闭后读端还在 range
有些泄漏不会立刻体现在 goroutine 数量上，而是表现为“活跃 goroutine”里大量卡在 select 或 chan send，这时候得结合代码里 channel 的生命周期和 close 时机来交叉验证。
