SetConnMaxIdleTime是控制空闲连接存活时长的唯一有效参数，需显式设置且应略小于MySQL的wait_timeout；SetMaxIdleConns是其生效前提，决定空闲连接上限；GORM无动态缩容，仅靠参数组合与定时回收实现连接自然回落。
SetConnMaxIdleTime 是空闲连接回收的唯一可控开关
Go 1.15+ 的 sql.DB 提供了 SetConnMaxIdleTime，它是真正控制“空闲连接存活多久后被主动关闭”的参数。它不依赖 GC，也不靠等待复用失败才清理——连接一旦空闲超时，就会被池子自己关掉。
常见错误是把它和 DSN 里的 timeout 或 MySQL 驱动的 DialTimeout 混为一谈。那些只管建连阶段，建完就失效了；而 SetConnMaxIdleTime 管的是连接进池之后的“保质期”。
- 必须显式调用：
db.DB().SetConnMaxIdleTime(45 * time.Second) - 值要略小于 MySQL 的
wait_timeout（比如 DB 设 60s，Go 就设 45s），否则连接先被 DB 断开，下次复用报invalid connection - 设太短（如 5s）会导致频繁重连；设太长（如 1h）又和 DB 侧 timeout 冲突，堆积大量 SLEEP 连接
SetMaxIdleConns 是回收的前提，不是缩容动作本身
SetMaxIdleConns 控制的是“最多允许多少个连接进入空闲队列”。它不决定何时删，但决定了有没有资格被 SetConnMaxIdleTime 删。
如果 SetMaxIdleConns 是 0 或没设，连接用完立刻销毁，根本不会进空闲队列——那 SetConnMaxIdleTime 就完全无效。
- 推荐设为
SetMaxOpenConns的 1/4～1/2（例如最大 100 → 空闲上限设 20～50） - 不能大于
SetMaxOpenConns，否则无意义 - 云数据库建议更保守：阿里云 RDS 等环境，
SetMaxIdleConns设 10～20 更稳
GORM 没有“动态缩容”概念，只有被动回收 + 手动限流
GORM 底层用的是 database/sql 连接池，它不支持运行时调整 SetMaxOpenConns 或 SetMaxIdleConns。所谓“缩容”，其实是通过参数组合让连接自然回落：
- 连接用完后，若空闲数已满（
SetMaxIdleConns达到上限），新空闲连接会被直接关闭，不进池 - 已有空闲连接，超
SetConnMaxIdleTime后被定时器触发关闭 - 没有“主动把正在空闲的连接从 50 干到 10”这种操作，只能靠参数压住上限 + 时间驱动释放
想实现近似动态效果，得靠外部指标驱动重启或滚动更新配置——比如监控到 db.Stats().Idle 长期 WaitCount 为 0，再发信号重建 *sql.DB 实例。
漏掉 db.Ping() 和 Stats 监控，等于放弃连接池健康感知
gorm.Open() 或 sql.Open() 只是初始化结构，不验证真实连通性。线上首屏白屏、接口批量超时，往往是因为第一笔查询才暴露 DNS 失败、密码错、网络不通等问题。
必须紧接在 db, err := gorm.Open(...) 后加 db.Ping()，并检查 error。
长期运行中，靠 db.DB().Stats() 观察才是关键：
-
InUse > 95%持续几分钟？说明SetMaxOpenConns太低或 SQL 有长事务堵着 -
Idle长期接近 0？可能SetMaxIdleConns设太小，或连接没被正确归还（比如 defer db.Close() 错误地关了整个池） -
WaitCount持续上涨？连接池已成瓶颈，请求在排队，该扩容或查慢 SQL 了
这些数字不打点，你永远不知道连接池是不是在“假装健康”地缓慢腐烂。
