应直接使用 gin-contrib/pprof，因其封装 net/http/pprof 所有 handler 并适配 gin 路由，避免手动注册导致路径映射错误、多端口暴露、endpoint 遗漏及超时中断等问题。
直接用 gin-contrib/pprof，别自己手写路由注册或起独立 HTTP 服务。 它封装了 net/http/pprof 所有 handler，并适配 Gin 的路由机制，省去路径映射、超时控制、goroutine 安全等隐性坑。
为什么 import _ "net/http/pprof" 在 Gin 里根本没用
因为 net/http/pprof 的 init() 函数只往 http.DefaultServeMux 注册路由，而 Gin 完全不使用它。你写了这行导入，/debug/pprof/ 依然 404 —— 不是 pprof 没加载，是它注册到了“另一个世界”。强行起 http.ListenAndServe(":6060", nil) 会暴露额外端口，生产环境权限难收敛，且无法共享 Gin 的中间件链（比如日志、鉴权）。
gin-contrib/pprof.Register() 必须在 router.Run() 之前调用
否则路由未生效，访问 /debug/pprof/ 还是 404。常见错误包括：
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 误写成
pprof.Register(r)却没import "github.com/gin-contrib/pprof" - 把调用放在
router.Run()后面，或塞进某个中间件里（它注册的是全局路由，不是中间件） - 想改路径前缀却传错参数：
pprof.Register(router, "admin/pprof")才生效，此时 endpoint 是/admin/pprof/，不是/debug/pprof/
生产环境必须加访问控制，不能只拦主页
/debug/pprof/ 主页只是索引页，真正泄露信息的是 /debug/pprof/heap?gc=1、/debug/pprof/profile?seconds=60 这类 endpoint —— 它们返回堆内存快照、CPU 采样原始数据，含源码路径、变量名甚至部分结构体字段。正确做法是用 Gin 的 Group + 认证中间件：
debugGroup := router.Group("/debug", basicAuthMiddleware)
pprof.RouteRegister(debugGroup, "pprof")
不要依赖 c.ClientIP() 做白名单校验 —— K8s Service Mesh 或 Nginx 反向代理后，拿到的常是内网地址，不可靠。
最易被忽略的一点：Gin 的 WriteTimeout 默认值（如 10s）若小于 CPU profile 的采集时长（默认 30s），请求会提前中断，导致 profile 文件损坏。务必确认 server.WriteTimeout >= 30 * time.Second，或显式传参 ?seconds=15 匹配超时设置。
