beego本身不导致内存泄漏，泄漏源在开发者代码中：websocket未close、sync.map堆积、context.value存大对象、orm.queryseter未reset。
Beego 框架本身不制造内存泄漏，泄漏源永远在你写的代码里——比如 WebSocket 连接未 Close、全局 sync.Map 堆积未清理、中间件中 context.Value 存大对象、或用 orm.QuerySeter 时忘了调 Reset。
Beego 中哪些写法最容易钉住内存不放
Beego v2（github.com/beego/beego/v2）虽模块化、性能更好，但内存管理责任完全落到开发者肩上。以下行为会直接导致对象长期驻留堆上：
-
WebSocket.OnMessage回调里启动 goroutine 但没传入ctx.Done()控制，连接断开后 goroutine 仍在跑，闭包捕获的*models.User就永远不回收 - 在
Controller.Init或Prepare中往全局sync.Map存map[string]*BigData，又没配过期清理逻辑 - 用
orm.NewOrm().QueryTable("user").Filter("status", 1).All(&users)后，users是切片指针数组，若后续存进全局变量或返回给前端前没做asArray()转换，整个对象树就钉住了 - 中间件里反复调
ctx.Input.SetData("payload", hugeStruct)，而没在Finish阶段DeleteData清理
怎么确认是 Beego 相关泄漏，不是 GC 滞后或缓存预热
别只看 top 或监控图里内存“缓慢上涨”。真泄漏必须同时满足：
- 稳定流量下，
runtime.ReadMemStats().HeapInuse持续线性增长（不是曲线先陡升后平缓） - 每次重启后归零，相同请求路径下 3–5 分钟内复现上涨趋势
- 执行
runtime.GC()后HeapInuse不回落，甚至更高
如果只是刚启动时内存飙升、10 分钟后稳定在 150MB，大概率是 Beego 的 server/web 内部连接池或模板缓存在预热，不是泄漏。
抓 heap profile 必须绕开的三个坑（Beego 线上实操版）
Beego 默认已注册 /debug/pprof/* 路由（只要导入了 _ "net/http/pprof"），但采样姿势不对，profile 就是废数据：
- 绝对不要加
?gc=1：比如wget "http://localhost:8080/debug/pprof/heap?gc=1" -O leak.heap—— 它强制 GC 后采样，会把本该泄漏的对象刷掉，profile 里只剩临时垃圾 - 文件名必须带
.heap后缀：用before.heap和after.heap，否则go tool pprof报错"unrecognized profile format" - 两次采样间隔 ≥30 秒，且服务已稳定运行 ≥5 分钟：刚启动时
MemStats.NextGC接近HeapAlloc，快照全是待 sweep 的垃圾，无法反映真实驻留对象
推荐命令流：wget http://localhost:8080/debug/pprof/heap -O before.heap
等 30 秒（确保有 WebSocket 连接建立、ORM 查询完成）wget http://localhost:8080/debug/pprof/heap -O after.heap
用 pprof 差分聚焦 Beego 泄漏源的关键操作
执行：go tool pprof -http=:8080 -base before.heap after.heap
浏览器打开后务必三步到位：
- 右上角 SAMPLE 切到
inuse_space（不是alloc_objects）——它反映当前实际占用内存的对象 - 点 View → Difference（不是 Top 或 Flame Graph）——只有差分才能看到净增长部分
- 在搜索框 Focus 输入你的可疑类型，比如
*models.Order或websocket.Conn，再点 Call graph 查谁在 new 它且没释放
重点盯调用链里夹着这些关键词的路径：
• (*Controller).Prepare → 检查是否存了大对象进 ctx.Input.Data
• orm.(*querySet).All → 看是否漏了 Reset() 或用了 ValuesList 却没转成原始 slice
• websocket.(*Conn).ReadMessage → 是否在 OnClose 里忘了 conn.Close() 和清理关联资源
Beego 的泄漏往往藏在“连接生命周期管理”和“ORM 查询边界”这两个地方，而不是框架核心代码——你写的那几行 conn.WriteJSON 和 o.Read，才是真正的内存钉子。
