GORM v2连接管理本质是复用底层sql.DB连接池，gorm.Open仅初始化gorm.DB句柄并绑定池，真实TCP连接在首次查询时按需建立；需通过db.DB()获取原生句柄配置MaxOpenConns等参数，避免重复Open导致连接泄漏。
GORM v2 的连接管理本质是“连接池 + 懒初始化”，不是每次 Open 都新建一个物理连接，而是复用底层 sql.DB 的连接池。你调用一次 gorm.Open 得到的 *gorm.DB 实例，背后已自带可配置的连接池 —— 这就是它能扛住高并发的关键。
gorm.Open 返回的是连接池句柄，不是单次连接
很多人误以为 gorm.Open 是“连一次数据库”，其实它只做两件事：解析 DSN、初始化 *gorm.DB 并绑定一个底层 *sql.DB（由驱动提供）。真正的 TCP 连接是在第一次执行查询（如 db.First()）时才按需建立的。
-
*gorm.DB是**轻量、线程安全、可复用**的；可以全局复用，无需每次请求都Open - 底层
*sql.DB自动维护空闲连接、最大打开数、最大空闲数、连接生命周期等，GORM v2 不再需要你手动封装sql.DB - 如果你在 HTTP handler 里反复
gorm.Open，会快速耗尽文件描述符或触发数据库连接数上限，这是典型反模式
如何配置连接池参数（MaxOpen/MaxIdle/ConnMaxLifetime）
连接池行为由底层 *sql.DB 控制，必须通过 *gorm.DB 的 DB() 方法拿到它，再调用原生方法设置：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
panic(err)
}
// 获取底层 *sql.DB
sqlDB, err := db.DB()
if err != nil {
panic(err)
}
// 设置连接池参数（单位：秒）
sqlDB.SetMaxOpenConns(100) // 默认 0（无限制），生产环境务必设上限
sqlDB.SetMaxIdleConns(10) // 默认 2，建议设为 MaxOpenConns 的 10%~20%
sqlDB.SetConnMaxLifetime(time.Hour) // 超过该时间的连接会被主动关闭并重建
- 不调用
SetMaxOpenConns容易被突发流量打垮数据库（尤其 MySQL 默认 max_connections=151） -
SetConnMaxLifetime对云数据库（如 AWS RDS、阿里云 PolarDB）很重要：它们可能主动断开空闲长连接，不设此值会导致后续查询报invalid connection - 这些参数不能在
gorm.Open时传入，必须调用db.DB()后设置
为什么不能全局共享一个 *gorm.DB 却又要在多库场景下避免 Open 多次
在 Revel + GORM 多库分片场景中，常见误区是为每个分片都创建独立 *gorm.DB 实例并全局存储 —— 这没问题；但更关键的是：这些实例必须在应用启动时一次性 Open，而非每次请求动态 Open。
- 多个
*gorm.DB实例各自持有独立的*sql.DB连接池，互不影响 - Revel 的 filter 或中间件里，应从上下文或全局 map 中取已初始化好的
*gorm.DB，而不是现场Open - GORM v2 不支持运行时切换全局 DB，所以“动态切换”本质是请求路由到预置好的不同
*gorm.DB实例 - 若用
db.Session(&gorm.Session{NewDB: true})创建新 session，它仍复用原*sql.DB池，只是隔离了 Hooks 和 Config，不是新建连接池
真正容易被忽略的点是：连接池参数和 DSN 中的 timeout（如 readTimeout、writeTimeout）作用域不同——前者管连接生命周期，后者管单次 SQL 执行超时，两者必须协同配置，否则会出现连接池健康但查询频繁超时的情况。
