beego orm 的 registerdatabase 仅能设置连接数上限（maxidle、maxconn），无法配置空闲连接超时；真正控制空闲连接释放时间需在初始化后调用 orm.getdb("default").setconnmaxidletime()，且 go ≥ 1.15 才支持该方法。
Beego ORM 的 RegisterDataBase 只能设连接数上限，不能设空闲超时
调用 orm.RegisterDataBase("default", "mysql", dsn, maxIdle, maxConn) 时，maxIdle 参数仅控制池中最多保留多少个空闲连接，不是“空闲多久就释放”。比如设成 10，那池里永远挂着最多 10 个空闲连接——哪怕它们已闲置 2 小时，也不会自动关闭。
这会导致 MySQL 端 Sleep 连接持续堆积，netstat -an | grep :3306 | wc -l 数值缓慢上涨，最终触发 max_connections 拒绝新连接。
-
maxIdle是硬性数量截断：超出立即 Close，但留下的不淘汰 -
maxConn控制最大并发连接数，防 DB 过载，和空闲生命周期无关 - Go ≥ 1.15 才有真正管“空闲多久清理”的接口，Beego ORM 层没封装它
必须手动调用 db.SetConnMaxIdleTime() 才能释放长期空闲连接
Beego ORM 初始化后，需立刻从 ORM 获取底层 *sql.DB 实例并设置空闲超时：
db, _ := orm.GetDB("default")
db.SetConnMaxIdleTime(60 * time.Second)
这个调用对当前所有已存在的空闲连接立即生效，无需重启服务。设成 60 * time.Second 是较稳妥的起点；若业务 RT 普遍 > 3s，可放宽到 120s，避免频繁重连。
- 该方法仅在 Go ≥ 1.15 可用；低于此版本只能靠
SetConnMaxLifetime()+ 合理maxIdle组合兜底 - 必须在
orm.RunCommand()或首次orm.NewOrm()之后执行，太早拿不到有效*sql.DB - 别漏掉
import "time"，否则编译失败
MySQL DSN 缺少 parseTime=true&loc=Local 会间接破坏连接池
即使 SetConnMaxIdleTime() 配对了，DSN 若没带 parseTime=true&loc=Local，time.Time 字段解析失败可能引发 panic 或连接卡死，导致连接无法正常归还池中，最终堆积无效连接。
错误写法：root:pass@tcp(127.0.0.1:3306)/test?charset=utf8
正确写法：root:pass@tcp(127.0.0.1:3306)/test?charset=utf8&parseTime=true&loc=Local
-
loc=Local避免时区转换错误，尤其在跨时区部署时 -
parseTime=true是go-sql-driver/mysql解析DATETIME字段的必要开关 - Beego 不校验 DSN 参数完整性，错配后现象是偶发 panic 或查询返回零值，排查成本高
多租户场景下不要为每个租户注册独立 RegisterDataBase
MySQL 下为每个租户建单独 database 并调用多次 RegisterDataBase，会导致每个租户独占一套 *sql.DB 连接池。1000 租户 = 1000 套池子，每套都按 maxIdle 和 SetConnMaxIdleTime 独立运行，内存/CPU 开销爆炸，K8s 扩缩容时抖动剧烈。
Beego ORM 的 QueryTable("users") 默认查 default database，你得在每处 DAO 显式写 o.Using("tenant_123")，漏一处就跨租户读写。
- 字段隔离 + MySQL 8.0 的 ROW ACCESS POLICY 是唯一可行路径，但 Beego 不感知 RLS，Raw() 查询完全绕过
- 若真要 schema 级隔离，建议换 PostgreSQL，它原生支持
search_path和 schema 权限 - Beego 的
Using()是运行时切换，不是连接池级隔离，别把它当成多租户安全边界
真正起作用的空闲连接回收，只发生在 *sql.DB 层，Beego ORM 只是薄封装。很多人卡在“设了 maxIdle 为什么连接数还是涨”，问题从来不在数量上限，而在时间策略缺失。
