Beego中DB实例应全局复用而非在Controller中反复gorm.Open()。需在main.go或models/init.go中一次性初始化并配置连接池参数，确保Rows及时Close、事务明确Commit/Rollback，避免混用Beego ORM，并通过DB.Stats()监控连接池状态。
Beego 中 db 实例不该在 Controller 里反复 gorm.Open()
直接在每个 Controller 方法里调用 gorm.Open() 是连接池枯竭的头号诱因。GORM 的 *gorm.DB 实例本身是并发安全的，内部封装了 *sql.DB 连接池句柄——它不是“一次一连”的轻量对象，而是应被当作全局资源复用。反复 Open 会导致：多个独立连接池并存、每个池都尝试抢占数据库连接上限、空闲连接无法跨实例共享。
正确做法是在 main.go 或 models/init.go 中一次性初始化，并导出为包级变量：
var DB *gorm.DB
<p>func InitDB() error {
dsn := beego.AppConfig.String("mysql.dsn")
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
PrepareStmt: true,
})
if err != nil {
return err
}
// 复用底层 <em>sql.DB 的连接池配置
sqlDB, err := db.DB()
if err != nil {
return err
}
sqlDB.SetMaxOpenConns(25)
sqlDB.SetMaxIdleConns(10)
sqlDB.SetConnMaxLifetime(1 </em> time.Hour)
sqlDB.SetConnMaxIdleTime(30 * time.Minute)</p><pre class="brush:php;toolbar:false;">DB = db
return nil}
- 务必调用
db.DB()获取底层*sql.DB，再设置连接池参数；仅对*gorm.DB设置无效 -
SetMaxOpenConns建议设为数据库侧允许的最大连接数的 70%～80%，避免其他服务或后台任务被挤占 - 不要在
InitDB后调用defer db.Close()—— 这会提前关闭整个连接池
事务中忘记 rows.Close() 或 tx.Commit() 会卡死连接
Beego Controller 中手动执行原生 SQL（如 DB.Raw().Rows()）或显式开启事务（DB.Begin()）时，若未正确释放资源，对应连接将一直被占用，直到超时或进程重启。这不是“泄漏”，而是连接被长期持有着无法归还池中。
典型错误写法：
func (c *MyController) Get() {
tx := c.DB.Begin()
// 忘记 tx.Commit() 或 tx.Rollback()
// 或者 rows, _ := tx.Raw("SELECT ...").Rows(); 忘记 rows.Close()
}- 所有
Rows必须在函数返回前调用rows.Close()，且建议放在defer中，但要确保rows非 nil - 事务必须有明确的
Commit()或Rollback()路径，推荐用defer func(){ if r := recover(); r != nil { tx.Rollback() } }()+ 显式判断逻辑分支 - 避免在事务中调用其他可能 panic 的函数，否则极易遗漏
Rollback()
Beego 的 orm.RegisterModel 不影响 GORM 连接池，但混用会埋坑
如果你项目里同时注册了 Beego ORM 模型（orm.RegisterModel(&User{})）和 GORM 模型，两者底层使用的 *sql.DB 实例若不统一，就会形成两套独立连接池。尤其当 Beego ORM 仍被某些旧模块调用时，它的 orm.RunSyncdb 或查询可能悄悄新建连接，加剧枯竭风险。
- 迁移期间，彻底禁用 Beego ORM 的自动初始化（注释掉
orm.RegisterDriver和orm.RegisterModel相关代码） - 检查
conf/app.conf中是否残留orm.开头的配置项，这些可能被 Beego 自动加载并触发 ORM 初始化 - 用
DB.Stats()定期打印连接池状态，确认InUse和Idle数值稳定，而非持续增长后卡在高位
高并发压测时连接池参数要按实际负载动态调优
开发环境配的 MaxOpenConns=25 到线上可能完全不够，但盲目调大又容易打爆数据库。关键不是固定值，而是建立反馈闭环：把 DB.Stats().InUse 作为核心指标，接入 Prometheus 或日志告警。
- 当
InUse >= MaxOpenConns * 0.9持续 1 分钟，说明连接已近饱和，需扩容或优化慢查询 - 若
Idle长期为 0，说明连接池太小或请求过于密集，可适当提高MaxIdleConns（但不超过MaxOpenConns） - 注意
SetConnMaxIdleTime（Go 1.15+）比SetConnMaxLifetime更精准控制空闲连接回收，避免“僵尸连接”堆积
连接池枯竭往往不是单点配置问题，而是连接获取、使用、释放三个环节中任一环松动导致的连锁反应。最隐蔽的破口常在事务和 Rows 生命周期管理上，而不是你最先怀疑的 MaxOpenConns 数值。
