SetConnMaxIdleTime是唯一控制空闲连接释放的参数，必须搭配SetMaxIdleConns使用、设为略小于MySQL wait_timeout（如DB设60s则Go设45s），且需在db.Ping()验证后生效。
SetConnMaxIdleTime 是唯一控制空闲连接释放的参数
Go 1.15+ 的 database/sql 才真正支持空闲连接超时，GORM 底层依赖它，所以必须用 db.DB().SetConnMaxIdleTime() 设置。DSN 里的 timeout、readTimeout 或 MySQL 驱动的 DialTimeout 都不作用于空闲连接——它们只管建连或单次 I/O。
常见错误是压测后 SHOW PROCESSLIST 看到大量 SLEEP 状态连接堆积，服务跑几小时就卡住，本质就是没设这个参数，连接一直赖在池里不释放。
-
SetConnMaxIdleTime必须显式调用，不设就等于无限期保留空闲连接 - 值不能大于数据库的
wait_timeout（查法：SHOW VARIABLES LIKE 'wait_timeout';） - 推荐设为比
wait_timeout小 10～15 秒，例如 DB 设了 60 秒，Go 端设45 * time.Second - 设太短（如
5 * time.Second）会导致频繁建连，CPU 和网络开销上升
SetConnMaxIdleTime 必须和 SetMaxIdleConns 配合才生效
空闲连接要先进入“空闲队列”，才能被 SetConnMaxIdleTime 管理。如果 SetMaxIdleConns 没设或设为 0，连接用完立刻销毁，根本不会空闲，自然也谈不上超时释放。
典型配置组合：
db.DB().SetMaxOpenConns(100)-
db.DB().SetMaxIdleConns(20)（建议为SetMaxOpenConns的 1/5～1/3） db.DB().SetConnMaxIdleTime(45 * time.Second)
注意：SetMaxIdleConns 不能大于 SetMaxOpenConns，否则会被静默截断；也不建议设得过高，否则空闲连接占着资源却不用，白白消耗 DB 侧线程和内存。
为什么只设 SetConnMaxLifetime 不解决空闲连接堆积
SetConnMaxLifetime 控制的是“连接从创建起最多活多久”，不管它空不空闲。一个连接刚被复用完，还剩 2 分钟寿命，但它立刻又空闲下来，那它仍会继续赖在池里，直到寿命耗尽或被 SetConnMaxIdleTime 清掉。
这两个参数分工明确：
-
SetConnMaxLifetime：防主备切换后旧连接失效、防长连接积累idle in transaction -
SetConnMaxIdleTime：专治“用完不走”的空闲连接，释放资源更及时 - 生产环境建议两个都设，且
SetConnMaxIdleTime≤SetConnMaxLifetime
启动时漏掉 db.Ping() 会让空闲超时配置“看起来生效”实则无效
gorm.Open() 只初始化结构，不建真实连接；db.DB().SetConnMaxIdleTime() 虽然执行了，但连接池里还没任何连接，参数只是挂在那里。第一笔查询才真正触发连接建立、放入空闲队列、开始计时。
这时候如果网络不通、DNS 失败或密码错，错误全堆在首请求上——而你可能以为是空闲超时没起作用，其实根本没走到那一步。
- 必须在设置完所有连接池参数后，立刻调用
db.DB().Ping() - 加重试逻辑更稳妥，比如指数退避 3 次，避免因短暂抖动导致服务启动失败
- 日志里看到 “DB initialized” 不代表可用，只有
Ping()成功才算真通
空闲连接的生命周期管理不是“设个参数就完事”，它依赖连接真实进入空闲状态、参数值与数据库侧 timeout 对齐、以及初始化阶段验证到位——三个条件缺一不可。
