beego orm 必须显式调用 setmaxopenconns 和 setmaxidleconns，因默认值均为 0，不启用连接池控制，易触发 too many connections；需在 runsyncdb 前设 setmaxopenconns("default", 100) 和 setmaxidleconns("default", 60)，并配合 setconnmaxidletime、正确 dsn 及资源释放。
Beego ORM 的 SetMaxOpenConns 和 SetMaxIdleConns 必须显式调用
Beego ORM 默认不启用连接池控制：两个关键参数 MaxOpenConns 和 MaxIdleConns 初始值都是 0，等于“不限制连接数”——这在并发稍高时立刻触发 MySQL 的 too many connections 错误。
必须在 orm.RunSyncdb() 或首次 orm.NewOrm() 之前，手动设置：
-
orm.SetMaxOpenConns("default", 100)：设为数据库max_connections的 70%～80%，例如 MySQL 默认 151，生产建议 ≤ 120 -
orm.SetMaxIdleConns("default", 60)：推荐设为MaxOpenConns的 60%～80%，避免空闲连接长期占位却不释放 - 这两个调用只对已注册的 alias（如
"default"）生效，且只能执行一次，通常放在main.go初始化段
空闲连接不自动释放？SetConnMaxIdleTime 是 Go ≥ 1.15 才有的解法
RegisterDataBase 传入的 maxIdle 参数只是数量上限，不是“空闲多久就关掉”。哪怕设了 maxIdle=10，那 10 个空闲连接可能挂 2 小时也不释放，MySQL 端 Sleep 连接持续堆积，netstat -an | grep :3306 | wc -l 数值缓慢上涨。
真正控制空闲生命周期，得靠底层 *sql.DB 的 SetConnMaxIdleTime：
- 必须先调用
orm.GetDB("default")拿到*sql.DB实例，再调用db.SetConnMaxIdleTime(60 * time.Second) - 该方法仅在 Go ≥ 1.15 可用；低于此版本只能靠
SetConnMaxLifetime+ 合理maxIdle组合兜底 - 别漏掉
import "time"，否则编译失败 - 这个设置对当前所有已存在的空闲连接立即生效，无需重启服务
DSN 缺少 parseTime=true&loc=Local 会间接破坏连接池
即使 SetConnMaxIdleTime 配对成功，如果 MySQL DSN 里没带 parseTime=true&loc=Local，time.Time 字段解析失败可能导致 panic 或连接卡死——连接无法正常归还池中，最终堆积无效连接。
拼接 DSN 时务必包含：
-
?charset=utf8mb4：兼容 emoji 和四字节 UTF-8 -
&parseTime=true：让time.Time能正确解析 DATETIME -
&loc=Local：避免服务器 UTC 时区与业务本地时间错位
示例：root:pass@tcp(127.0.0.1:3306)/test?charset=utf8mb4&parseTime=true&loc=Local
事务或原生 SQL 后忘记释放资源，连接就永远卡住
Beego Controller 中用 DB.Raw().Rows() 或 DB.Begin() 时，常见错误是没调 rows.Close() 或 tx.Commit()/Rollback()。这不是连接泄漏，而是连接被长期持有、无法归还池中。
这类问题不会报错，但会悄悄耗尽连接池：
- 每个未关闭的
rows占用一个连接，直到超时或进程重启 - 未提交/回滚的事务会让连接一直绑定在事务状态，ORM 不会回收
- 务必在
defer或finally逻辑中确保释放，尤其嵌套 error 处理时
最危险的是：它不触发明显错误，只表现为“突然连不上库”，排查时容易忽略这一层。
