gin默认不暴露/debug/pprof端点，因其路由系统独立于net/http.defaultservemux，下划线导入"net/http/pprof"仅向默认mux注册路由，对gin无效；必须显式注册pprof handler（如用gin-contrib/pprof）或通过gin.wraph桥接，否则访问返回404。
为什么Gin默认不暴露/debug/pprof端点
Gin本身不自动注册pprof路由，和标准库net/http不同——它不会因为导入_ "net/http/pprof"就生效。这个包只对http.DefaultServeMux起作用，而Gin用的是自己的路由树，所以必须显式挂载。
常见错误现象：启动服务后访问http://localhost:8080/debug/pprof返回404，但curl http://localhost:6060/debug/pprof能打开（如果单独起了http.ListenAndServe(":6060", nil)）。
- 正确做法是把pprof handler注册到Gin的路由上，而不是依赖下划线导入
- 推荐用
github.com/gin-contrib/pprof，它封装了安全、可配置的注册逻辑 - 若手动集成，需用
gin.WrapH(http.DefaultServeMux)桥接，但要注意路径前缀和中间件顺序
gin-contrib/pprof怎么安全启用
直接暴露/debug/pprof到公网等于交出程序内部状态，生产环境必须加访问控制。
示例代码中容易踩的坑：pprof.Register(r)会把所有pprof端点挂在根路径，没做鉴权；而pprof.RouteRegister(adminGroup, "pprof")才是正确姿势。
- 使用
gin.BasicAuth时，账号密码不能硬编码，应从环境变量或配置中心读取 - 路径前缀建议带版本或环境标识，比如
/admin/v1/pprof，避免和业务路由冲突 - 上线前检查是否启用了
pprof——可通过go list -f '{{.Imports}}' ./cmd/yourapp确认是否引入了相关包
采集CPU profile时?seconds=30参数失效怎么办
在Gin + pprof组合下，有时curl "http://localhost:8080/debug/pprof/profile?seconds=30"返回快照但时间远小于30秒，甚至立刻结束。根本原因是：Gin的HTTP handler未设置足够长的超时，或反向代理（如Nginx）主动中断了长连接。
典型表现：go tool pprof加载后显示采样数极少，top命令看不出热点函数。
- 临时解决：改用
go tool pprof http://localhost:8080/debug/pprof/profile（不带?seconds），它会走默认30秒，且绕过部分中间件拦截 - 长期方案：在Gin启动时设置
http.Server.ReadTimeout和WriteTimeout大于30秒 - 验证方式：用
curl -v "http://localhost:8080/debug/pprof/profile?seconds=30"看响应头Content-Length是否明显增长
火焰图里看不到自己写的函数名
生成的火焰图顶部全是runtime.mcall、syscall.Syscall或空白宽条，你自己的handler函数没出现——这不是数据丢了，而是编译优化抹除了符号信息。
Go 1.20+ 默认开启-ldflags="-s -w"（剥离调试信息），导致pprof无法映射源码行号。
- 构建时显式禁用：用
go build -ldflags="-w" -o app main.go（保留符号表，只去strip） - 更稳妥的做法：开发/预发环境用
go build -gcflags="all=-l" -o app main.go关掉内联，让函数边界清晰 - 注意：火焰图宽度反映CPU时间占比，高度反映调用栈深度；如果某函数被内联进
runtime，它的时间会被合并到父调用里，此时得看go tool pprof -focus yourFuncName聚焦分析
