pprof必须显式启用并限制访问：导入_ "net/http/pprof"后需单独启动HTTP服务（如:6060），不可复用主端口；生产环境须限定IP或鉴权；CPU采样至少30秒，内存分析需多次比对heap快照，goroutine泄漏排查依赖/debug/pprof/goroutine?debug=2。
直接用 net/http/pprof，但别挂默认端口
绝大多数服务不需要额外写采集逻辑，net/http/pprof 开箱即用，真正低入侵——只加一行 import、启一个独立 HTTP server 就行。关键在于：不要把 pprof 挂在业务端口（比如 :8080），否则暴露敏感运行时信息，也容易被误触发或压垮主服务。
正确做法是单独监听一个运维专用端口（如 :6060），且绑定到 localhost 或内网地址：
go func() {
http.ListenAndServe("127.0.0.1:6060", nil) // 仅本地可访问
}()
这样既不影响主逻辑，又避免公网暴露风险。生产环境若需远程采集，应配合反向代理做 IP 白名单或 Basic Auth，而不是放开 0.0.0.0:6060。
runtime/pprof 适合 CLI 工具或短生命周期进程
如果你的模块是命令行工具、批处理任务或测试脚本，runtime/pprof 更合适——它不依赖 HTTP，完全由你控制采样时机和输出位置。
立即学习“go语言免费学习笔记（深入）”；
- 启动前开启 CPU profile：
pprof.StartCPUProfile(f)，结束后调pprof.StopCPUProfile() - 内存快照用
pprof.WriteHeapProfile(f)，注意它只拍当前堆快照，不是持续采样 - 别在循环里反复创建文件句柄；建议复用一个
*os.File，或用bytes.Buffer缓存再写盘
常见错误是忘记 defer pprof.StopCPUProfile()，导致程序退出时 profile 文件为空；还有人误以为 WriteHeapProfile 会自动刷新，其实它只写一次。
避免在热路径里调 pprof.Lookup("xxx").WriteTo()
有人想“动态触发” profile，于是把 pprof.Lookup("heap").WriteTo(w, 0) 塞进某个 API handler。这很危险：
- 每次请求都触发一次 heap dump，可能瞬间分配几百 MB 内存
- 阻塞式写入，拖慢整个请求链路
- 并发调用时可能因内部锁竞争导致 goroutine 阻塞
真正安全的做法是：只通过 /debug/pprof/xxx 路由提供标准接口，让外部工具（如 go tool pprof）按需拉取。内部代码绝不主动调 WriteTo 或 Lookup。
生产环境必须限制访问范围与采集频率
pprof 不是监控接口，它是诊断工具。放任随意访问等于交出进程控制权：
- 禁用
/debug/pprof/goroutine?debug=2这类高开销接口，除非明确排查协程泄漏 - CPU profile 默认采样 30 秒，期间该进程所有 goroutine 都会被周期性中断，影响实时性——线上慎用，优先用短时间（如
?seconds=5）+ 多次采样比对 - heap profile 会暂停 GC 扫描，大堆下耗时显著；生产环境建议只在低峰期、且确认有内存问题时才触发
最易被忽略的是：pprof 接口本身没有鉴权机制，哪怕绑在 127.0.0.1，容器内其他进程或 sidecar 也能访问。K8s 场景下务必配合 NetworkPolicy 或 init 容器做端口隔离。
