pprof 默认暴露在 /debug/pprof 且无鉴权，导入 net/http/pprof 即自动注册全部调试接口，生产环境必须隔离至独立端口（如 127.0.0.1:6060）并加基础认证，禁用公网访问。
pprof 默认暴露在 /debug/pprof 下，不加鉴权等于裸奔
Go 程序只要导入 net/http/pprof，就会自动注册一堆调试接口，比如 /debug/pprof/profile、/debug/pprof/heap，连带 CPU 采样、goroutine 栈、block 阻塞分析全开。这些接口不需要任何路由显式注册，也不校验请求来源 —— 只要服务端端口对外可访问，攻击者就能直接下载内存快照或触发 30 秒 CPU profile。
- 默认行为无法关闭：导入即启用，没提供 “禁用全部” 的开关
- 常见误操作是只删了
import _ "net/http/pprof"，却忘了检查是否还有手动调用pprof.Handler或pprof.ServeMux - 即使你用了自定义
http.ServeMux，只要没显式排除/debug/pprof路径，它仍会响应（因为 pprof 内部注册到了http.DefaultServeMux）
生产环境必须隔离 pprof 接口，推荐走独立监听地址 + 基础认证
别指望靠反向代理加 header 过滤或前端 Nginx 拦截 —— pprof 的 handler 是直接绑定到 Go 的 HTTP mux 上的，绕过中间层太容易。最稳妥的做法是让它跑在另一个不对外暴露的端口，并加一层最小化认证。
- 启动一个专用的 admin server：
http.ListenAndServe("127.0.0.1:6060", nil)，然后只在这个 server 上注册pprof.Handler - 避免复用主业务 mux，防止路径冲突或意外暴露；
nil表示用默认 mux，但该 mux 不会被外部请求命中 - 如需远程调试，用 SSH 端口转发：
ssh -L 6060:localhost:6060 user@prod-server，本地打开 http://localhost:6060/debug/pprof 即可 - 若真要 Web 访问，别用 cookie/session，用
http.StripPrefix+basicAuth中间件，且密码硬编码在二进制里（别读配置文件）
go tool pprof 连接失败？检查服务端是否启用了 HTTPS 或重定向
go tool pprof 默认走 HTTP，且不跟随 301/302 重定向。如果生产环境强制跳转 HTTPS，或者反向代理把 /debug/pprof 重写成其他路径，命令会卡住或报 failed to fetch profile。
- 先用
curl -v http://your-server:6060/debug/pprof/看响应状态码和 body，确认能返回 HTML 列表 - 不要依赖浏览器能打开就认为可用：浏览器会自动处理重定向，
pprof工具不会 - 若服务监听 HTTPS，必须用
https://协议连接，且确保证书可信（或加-insecure参数，仅限内网） - 注意 Go 1.21+ 对 HTTP/2 的默认行为变化：某些 TLS 配置下，HTTP/1.1 的 pprof 请求可能被静默拒绝
pprof 数据本身不加密，敏感信息可能泄漏
profile 文件里包含符号表、函数名、源码路径甚至部分变量值（如堆 profile 中的对象字段）。如果通过公网传输或存入共享存储，相当于把程序内部结构图送出去。
立即学习“go语言免费学习笔记（深入）”；
-
go tool pprof默认保存的profile.pb.gz是明文 protobuf，可用protoc --decode_raw < xxx.pb.gz直接解析 - 避免在日志系统或对象存储中长期保留 profile 文件；一次分析完立即
rm - 若需归档，用
gpg加密后再落盘，别依赖“文件名加随机串”这种弱防护 - heap profile 尤其危险：里面常有未脱敏的用户 ID、token 片段、数据库连接串残留 —— 不是所有字符串都会被 GC 立即擦除
localhost:6060，上线后忘记改监听地址，结果 admin 端口被映射到公网；或者用 Docker 部署时，把 EXPOSE 6060 写进了镜像，又没限制 host 绑定。 
