Beego 默认不暴露 /debug/pprof 路由，设 beego.PprofOn = true 多数无效；因其 v2+ 重写路由分发逻辑，绕过了 net/http/pprof 向 http.DefaultServeMux 的自动注册，必须手动注册 ProfController 或启用独立 pprof 服务。
Beego 默认不暴露 /debug/pprof 路由，直接设 beego.PprofOn = true 多数情况下无效——这不是配置漏了，而是 Beego 2.x 之后重写了 HTTP 路由分发逻辑，net/http/pprof 的自动注册机制被绕过了。
为什么 beego.PprofOn = true 不生效
Beego 的 ServeHTTP 方法没有使用 http.DefaultServeMux，而 _ "net/http/pprof" 的 init() 函数只往默认 mux 注册 handler。所以即使开了开关，/debug/pprof/ 仍返回 404。
- 验证方式：启动后执行
curl http://localhost:8080/debug/pprof/，若返回 404 就确认未注册成功 - Beego v2+ 的正确做法是手动注册
ProfController，或改用更可控的独立 pprof 服务 - 不要依赖框架封装的开关，它在 v2.1+ 后基本处于维护状态，文档未同步更新
手动注册 ProfController 到 Beego 路由
需显式将 pprof handler 挂载到 Beego 的路由系统中，避免和默认 mux 耦合。
- 在
main.go或初始化位置 import："net/http/pprof"（不用下划线） - 添加自定义 controller（Beego v2 推荐写法）：
type PprofController struct { beego.Controller } func (c *PprofController) Get() { switch c.Ctx.Input.Param(":pp") { case "profile": pprof.Profile(c.Ctx.ResponseWriter, c.Ctx.Request) case "heap": pprof.Handler("heap").ServeHTTP(c.Ctx.ResponseWriter, c.Ctx.Request) case "goroutine": pprof.Handler("goroutine").ServeHTTP(c.Ctx.ResponseWriter, c.Ctx.Request) case "block": pprof.Handler("block").ServeHTTP(c.Ctx.ResponseWriter, c.Ctx.Request) default: pprof.Index(c.Ctx.ResponseWriter, c.Ctx.Request) } } - 注册路由：
beego.Router("/debug/pprof", &PprofController{})和beego.Router("/debug/pprof/:pp(*)", &PprofController{})
go tool pprof 分析时 top 全是 runtime.mcall 或地址
这是最常踩的坑：pprof 采样得到的是内存地址，没有原始二进制文件就无法符号化，交互界面里看不到函数名。
- 错误命令：
go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30 - 正确流程：先
go build -o myapp .，再运行./myapp &，最后go tool pprof myapp http://localhost:8080/debug/pprof/profile?seconds=30 - 验证是否成功：进入 pprof 交互后输入
top，第一列出现main.LoginHandler这类业务函数名才算加载成功；若全是runtime.mcall或十六进制地址（如0x456789），说明符号表缺失 - Beego 项目务必确保构建时未加
-ldflags="-s -w"，否则调试信息被剥离
/debug/pprof/heap 显示 inuse_space 持续上涨但 GC 后不降
/debug/pprof/heap 默认返回的是「分配总量」快照，不是存活对象——这容易误判为内存泄漏。
- 不加
?gc=1：返回alloc_objects，含已分配但可能已被 GC 回收的内存，数值天然偏高 - 加
?gc=1：强制触发一次 GC 后再采样，反映真实存活对象，适合排查泄漏，例如：curl "http://localhost:8080/debug/pprof/heap?gc=1" -o heap.out - 对比两个采样：如果
?gc=1后inuse_space仍随请求线性增长，且go tool pprof中top显示大量newobject或你的 model 构造函数，才真正指向内存堆积
pprof 不是开箱即用的“性能诊断仪”，它对 Beego 这类封装了 HTTP 层的框架尤其敏感——必须绕过默认注册路径、绑定符号完整的二进制、并明确区分 allocs/heap/inuse_space 的语义。漏掉任意一环，看到的就只是 runtime 的幻影。
