真泄漏需同时满足：稳定负载下HeapInuse与HeapAlloc线性增长、重启归零且复现、GC后不回落；排查须用pprof差分分析inuse_space，聚焦context.Value未清理、全局sync.Map无过期、WebSocket未注销、定时任务缺cancel等活引用。
Beego 应用内存持续上涨、重启归零、GC 后不回落——大概率是代码里留了“活引用”，不是框架本身的问题。Beego v2 的模块化设计反而让泄漏点更易定位，关键在你写的 controller、middleware、全局缓存或 goroutine 里。
怎么确认是真泄漏，不是 GC 滞后或缓存膨胀
别光看 top 命令或监控图上内存“一直在涨”。真泄漏必须同时满足：
- 稳定负载下
runtime.ReadMemStats的HeapInuse和HeapAlloc随时间线性增长 - 每次重启后归零，且相同流量下再次复现
- GC 后
HeapInuse不回落，甚至越 GC 越高
如果只是压测刚启动时内存飙升、几分钟后就平稳，大概率是 GC 还没热起来，或框架内部缓存（如 http.Server 的 connection pool）在预热，不是泄漏。
抓 heap profile 必须避开的三个坑
线上 Beego v2 服务要抓有效快照，必须绕开这些常见错误：
- 启动时确保导入了
_ "net/http/pprof"，并在main()里起一个独立 pprof server：go http.ListenAndServe("localhost:6060", nil) - 等服务稳定运行 ≥5 分钟、流量打满后再采样；第一次采样前检查
runtime.ReadMemStats().NextGC是否远大于HeapAlloc，否则 GC 正在 sweep，快照失真 - 两次采样间隔 ≥30 秒，文件名必须带
.heap后缀，例如：wget http://localhost:6060/debug/pprof/heap -O before.heap，wget http://localhost:6060/debug/pprof/heap -O after.heap - 绝对不要加
?gc=1参数：它强制 GC 后采样，会把本该长期存活的对象“刷掉”，profile 里只剩临时分配，完全看不到泄漏源
pprof 差分分析时盯死这三类调用链
执行 go tool pprof -http=:8080 -base before.heap after.heap 打开界面后，只做三件事：
- 右上角 SAMPLE 切到
inuse_space（不是alloc_objects或alloc_space） - 点 View → Difference（不是 Top 或 Flame Graph）——只有差分才能看到净增长部分
- 在搜索框 Focus 输入你的可疑类型，比如
*UserConfig或model.Order，再点 Call graph 查谁在new它且没释放
重点盯调用链里夹着这些关键词的路径：
-
(*ConnPool).reaper、connectionOpener→ 检查数据库连接池未设SetMaxOpen或rows.Close()漏调 -
timerproc、time.AfterFunc→ 检查定时任务没传context.WithCancel，服务 reload 后 goroutine 还在跑 -
context.Value、Prepare、websocket.OnClose→ 检查中间件或 WebSocket 关闭回调里没清掉context.Value存的大结构体、session map 或 timer
Beego 中哪些写法最容易触发内存泄漏
Beego 本身不持有业务对象，但它的运行时环境会放大几类典型错误：
-
context.Value存大结构体且没清理：比如在Prepare方法里塞进一个*bytes.Buffer或map[string][]byte，后续 handler 没显式删掉，这个值会随 request context 一起被挂住；若用了长连接（如 WebSocket）或中间件提前返回，它可能卡在中间件链里出不去 - 全局
sync.Map或map不设过期/不清理：Beego v2 推荐用core/cache，但很多人直接 new 个sync.Map放在包变量里，往里塞*model.User却忘了调Delete或加 TTL - WebSocket 连接未注销就关闭：
websocket.OnClose回调里没清掉关联的 session map、timer、或用户状态缓存，goroutine 可能还在往已失效的 channel 发数据 - 定时任务用
time.AfterFunc或time.Ticker但没传 cancel 信号：比如在Init阶段启动一个每秒轮询的 goroutine，却没绑定context.WithCancel，服务 reload 或 shutdown 时它还在跑
最隐蔽的泄漏点往往不在框架层，而在你给 context 塞东西、往全局 map 写数据、或启 goroutine 时漏了退出机制——这些动作在 Beego 生命周期里会被反复放大。
