Beego项目数据库连接池需显式配置参数以避免too many connections和invalid connection问题：MaxIdleConns和MaxOpenConns必须手动设置且匹配数据库max_connections，ConnMaxLifetime须小于wait_timeout，事务必须确保连接释放。
Beego 项目里数据库连接池没调好，too many connections 和 invalid connection 就会高频出现，不是数据库扛不住，而是客户端连不上、不敢重用、不敢释放。核心问题不在 ORM 选型，而在连接池参数是否显式配置、是否与数据库服务端匹配。
Beego ORM 连接池参数必须手动设置
Beego ORM 默认 MaxIdleConns 和 MaxOpenConns 都是 0，等于关闭连接池、不限制连接数——这在压测或上线后必然触发 too many connections。不能依赖“默认够用”，必须主动设值：
-
orm.SetMaxIdleConns("default", 20)：空闲连接上限，建议设为MaxOpenConns的 60%~80% -
orm.SetMaxOpenConns("default", 100)：最大打开连接数，需 ≤ 数据库服务器的max_connections（如 MySQL 默认 151，生产建议留 20% 余量） - 调用位置必须在
orm.RunSyncdb()之前，且仅执行一次（通常放在main.go初始化段）
GORM 替代 Beego ORM 时连接池由底层 *sql.DB 管理
用 GORM 后，gorm.Open() 返回的 *gorm.DB 内部已封装 *sql.DB，但它的连接池参数不会自动继承 Beego 配置，必须显式获取并设置：
- 初始化后立即调用
db.DB().SetMaxIdleConns(20)和db.DB().SetMaxOpenConns(100) - 必须调用
db.DB().SetConnMaxLifetime(30 * time.Minute)：防止连接被数据库 server 主动断开后，客户端仍尝试复用（即invalid connection根源） - 注意：
SetConnMaxLifetime值必须 小于 数据库的wait_timeout（MySQL 默认 8 小时，但很多云数据库设为 30 分钟）
事务中连接不归还的典型陷阱
Beego ORM 和 GORM 都支持事务，但一旦开启，连接就从连接池中“借出”，直到显式 Commit() 或 Rollback() 才释放。漏写、panic 未 recover、超时未处理都会导致连接永久卡住：
- 所有事务操作必须包裹在
defer tx.Rollback()+ 显式tx.Commit()中 - GORM 推荐用带 context 的方式启动：
db.WithContext(ctx).BeginTx(ctx, &sql.TxOptions{})，其中ctx超时建议设为 5s - Beego ORM 的
o.Begin()没有 context 支持，务必在业务逻辑入口加超时控制（如用time.AfterFunc强制 rollback）
连接池参数不是设一次就完事——它必须和数据库服务端配置对齐，也必须随业务并发模型动态评估。最常被忽略的是 ConnMaxLifetime，它不解决连接数上限，但直接决定连接是否“健康可用”。线上跑一周后突然大批 invalid connection，八成是这个值没设，或设得比数据库 wait_timeout 还长。
