Beego中pprof默认不生效，因Beego重写ServeHTTP导致net/http/pprof无法自动注册；需设beego.PprofOn = true或独立启动http.ListenAndServe并导入_net/http/pprof_，且生产环境须加IP访问控制。
Beego 项目里 pprof 默认不生效，必须手动注册路由
Beego 重写了 http.ServeHTTP，net/http/pprof 的 init() 函数只往 http.DefaultServeMux 注册，对 Beego 自己的路由系统完全无效。直接 import _ "net/http/pprof" 没用，访问 /debug/pprof/ 会 404。
正确做法是显式挂载：
- 在 main.go 启动前加 beego.PprofOn = true（Beego 1.12+ 原生支持）；
- 若版本较老或需自定义端口，改用独立 HTTP server：
go func() {
http.ListenAndServe("localhost:6060", nil)
}()并在
import 块中保留 import _ "net/http/pprof"；- 生产环境务必加访问控制，比如只允许内网 IP：
if !strings.HasPrefix(r.RemoteAddr, "10.0.0.") { http.Error(w, "Forbidden", 403); return }
CPU profile 抓不准？别信默认 30 秒，要短周期多次采样
Beego 接口常被 I/O 或 ORM 查询阻塞，runtime.futex 占比高不代表 CPU 真忙，而是采样机制没捕获到用户代码执行态。一次长采样容易错过真实毛刺。
- 用
wget "http://localhost:6060/debug/pprof/profile?seconds=5"抓 5 秒，重复 3 次，比单次 15 秒更稳 - 压测流量稳定后再采：先让 QPS 达到目标值并维持 1–2 分钟，再开 profile
- 确认
GOMAXPROCS设为 CPU 核数，否则火焰图里大量idle是调度失准，不是空闲 - 若怀疑是锁或 channel 阻塞，直接看
/debug/pprof/block和/debug/pprof/goroutine?debug=2，别硬等 CPU profile
heap profile 显示 allocs=0 或 inuse=2？说明 GC 还没触发或没抓对参数
/debug/pprof/heap 默认返回的是累计分配量（allocs），刚启动的 Beego 服务几乎不分配对象，数值低不等于内存健康；而真正反映堆压力的是 inuse_space，它依赖 GC 后快照。
- 必须加
?gc=1参数：访问/debug/pprof/heap?gc=1强制触发 GC 再采集 - 连续对比：用
/debug/pprof/heap?gc=1&next=1只返回比上次更大的样本，观察是否持续增长 - 查泄漏时，用
go tool pprof -http=:8081 heap.pprof启服务，点「Focus」输入结构体名（如*models.User），看是不是某个类型在不断累积 - Beego ORM 的
All()、ReadAll()容易导致对象逃逸到堆，优先改用Values()或ValueList()取字段子集
goroutine 泄漏藏得深？重点盯住 debug=2 输出里的非阻塞栈
/debug/pprof/goroutine?debug=2 返回的是全量调用栈文本，不是统计值。总数涨得慢没关系，关键是找“活着但不该活”的 goroutine。
- 无限循环没 sleep：栈顶是
runtime.gopark下一层就是你的for {}函数 - channel write 卡死：栈里有
chan send+ 你自己的 handler 行号，说明写入无缓冲 channel 且没人读 - HTTP handler 启了 goroutine 却没监听
ctx.Done()：请求结束，goroutine 还在跑，栈里有http.HandlerFunc+ 你写的异步逻辑 - Beego 中间件里用了同步 HTTP 调用又没设 timeout，整个中间件链卡死，所有后续请求的 goroutine 全堆积在
RoundTrip
Beego 的性能问题极少出在框架层，多数卡点藏在 ORM 加载策略、缓存穿透防御缺失、或中间件里没做 context 控制——pprof 只暴露现象，真要定位，得结合 RelatedSel 是否漏写、CacheSize 是否设限、以及每个中间件里有没有裸调 time.Now() 这类小动作。
