Beego ORM的SetMaxIdleConns仅限制空闲连接数量，不控制超时；需手动调用db.SetConnMaxIdleTime()（Go≥1.15）或组合SetConnMaxLifetime与合理maxIdle（Go<1.15）来释放空闲连接，否则Sleep状态连接持续累积。
Beego ORM 的 SetMaxIdleConns 只控数量，不控时间
调用 orm.RegisterDataBase("default", "mysql", dsn, 10, 100) 中的第 4 个参数（maxIdle），只是限制连接池最多保留 10 个空闲连接——超出的会立刻关闭，但留下的这 10 个可能永远不释放。
常见错误现象是：QPS 很低，MySQL 的 SHOW PROCESSLIST 却看到大量 Sleep 状态连接，netstat -an | grep :3306 | wc -l 持续上涨。这不是连接没复用，而是复用了却“赖着不走”。
-
maxIdle设太小（如 2）会导致低并发下也频繁建连、销毁，徒增开销 -
maxIdle设太大（如 100）又无法解决空闲连接滞留问题，纯粹靠数量压不住泄漏 - 它和
SetConnMaxLifetime是正交策略：一个管“最多活多久”，一个管“空闲多久就清理”
Go ≥ 1.15 必须手动调 db.SetConnMaxIdleTime()
Beego ORM 不封装 SetConnMaxIdleTime，必须自己从 ORM 拿到底层 *sql.DB 实例再设置。否则空闲连接永不释放，哪怕只有一两个请求，池子里的连接也会越积越多。
初始化数据库后立即加这段代码：
db, _ := orm.GetDB("default")
db.SetConnMaxIdleTime(60 * time.Second)
- 该设置对已存在的空闲连接立即生效，无需重启服务
- 推荐值：30–60 秒；设太短（如 5s）会导致刚空闲就被杀，反而增加建连压力
- 若用的是 Go < 1.15，
SetConnMaxIdleTime不可用，只能靠SetConnMaxLifetime+ 合理maxIdle组合兜底
DSN 缺少 parseTime=true&loc=Local 会间接破坏连接池
MySQL 驱动 go-sql-driver/mysql 默认不解析 time.Time，若 DSN 漏掉这两个参数，读取 datetime 字段时可能 panic 或返回零值，导致连接无法正常归还池中，最终堆积无效连接。
错误 DSN：root:pass@tcp(127.0.0.1:3306)/test?charset=utf8
正确 DSN：root:pass@tcp(127.0.0.1:3306)/test?charset=utf8&parseTime=true&loc=Local
- 这个不是超时配置本身的问题，但它是连接池稳定运行的前提
- Beego 官方示例里其实写了它，但很多人复制时漏掉
&parseTime=true&loc=Local - 一旦出现 time 类型字段读取异常或连接卡死，先检查 DSN 是否完整
多租户场景下不能靠注册多个 database 切换
MySQL 下为每个租户单独注册一个 database（如 tenant_001、tenant_002），会导致 Beego ORM 彻底失能：每个 RegisterDataBase 创建独立 *sql.DB 实例，连接池完全隔离，1000 租户就是 1000 套池子。
更严重的是：orm.QueryTable("users") 默认查 default，你得在每处 DAO 手动写 o.Using("tenant_123")，漏一处就跨租户。
- 字段级租户隔离（如加
tenant_id字段）+ 数据库层 RLS 是唯一可行路径 - Beego ORM 本身不感知 RLS，需 DBA 配合强约束，且
Raw()查询无法覆盖 - 别指望 ORM 自动帮你切换 database，它没这个设计
Beego ORM 对连接池的控制非常轻量，它把核心行为全交给 database/sql，而 SetConnMaxIdleTime 这种关键参数又没做封装——这意味着你必须亲手去拿底层 *sql.DB 并设置，漏掉这一步，连接数上涨就是时间问题。
