不设SetConnMaxLifetime必然导致driver: bad connection；必须设为数据库wait_timeout的80%～90%（如3600秒则设30分钟），云环境需更保守（2～5分钟），且须与SetConnMaxIdleTime配对使用并紧接gorm.Open()后调用。
SetConnMaxLifetime 不设会直接报 driver: bad connection
不设 SetConnMaxLifetime 是线上最隐蔽的连接错误源头之一。MySQL 默认 wait_timeout=28800（8 小时），PostgreSQL 也有类似 tcp_keepalives_idle 机制，服务端会在空闲超时后主动断连；而 GORM 底层的 *sql.DB 默认不校验连接有效性，复用已断开的连接就会触发 driver: bad connection 或 i/o timeout。这不是偶发网络问题，是必然发生的连接老化故障。
- 必须在
gorm.Open()后、首次Query前调用，对已创建连接无效 - 值不能为
0（禁用）或time.Second（太激进），否则要么失效，要么频繁建连拖垮吞吐 - 推荐设为数据库
wait_timeout的 80%～90%，例如 MySQL 返回3600秒，则设30 * time.Minute - 若用了 ProxySQL / RDS Proxy，应以代理的空闲超时为准，不是后端 DB 的值
SetConnMaxLifetime 和 SetConnMaxIdleTime 必须配对用
只设 SetConnMaxLifetime 不设 SetConnMaxIdleTime，或者反过来，都会导致连接池行为失常。前者管「连接最大存活时间」，后者管「空闲多久就回收」——它们解决的是不同维度的老化问题：
-
SetConnMaxLifetime防止连接被 DB 主动断开后继续复用（哪怕它每秒都在用） -
SetConnMaxIdleTime（Go 1.15+）防止连接池里长期没人碰的“僵尸空闲连接”堆积 - 高并发下连接可能永远不空闲，
SetConnMaxIdleTime完全不起作用，此时全靠SetConnMaxLifetime拦截过期连接 - 典型安全组合：
SetConnMaxIdleTime(30 * time.Minute)+SetConnMaxLifetime(50 * time.Minute)，且SetConnMaxIdleTime必须 ≤SetConnMaxLifetime
云数据库场景下必须更保守
阿里云 RDS、腾讯云 CDB 等托管服务普遍启用 NAT 网关或 SLB，它们会在 3～5 分钟内静默关闭空闲 TCP 连接。即使 DB 侧 wait_timeout 是 3600 秒，客户端连接也早被中间设备掐断了——这时候 SetConnMaxLifetime 设成 1 小时毫无意义，反而增加复用失败概率。
- 云环境推荐设
2 * time.Minute～5 * time.Minute，主备切换快的集群优先选 2 分钟 - 不要照搬自建 MySQL 的配置（比如设
1 * time.Hour），那是给物理机留的余量 - 如果用 RDS Proxy，查它的
idle_timeout参数，而不是看后端 RDS 实例的wait_timeout - 设完务必配合
db.Ping()验证，否则启动时不会暴露中间链路断连问题
SetMaxIdleConns > SetMaxOpenConns 会 panic
这个错误在初始化时容易被忽略，但一旦发生就是启动失败。Go 1.12+ 版本中，如果 SetMaxIdleConns(n) 大于当前 SetMaxOpenConns 值，运行时直接 panic，错误信息为 "max idle conns exceeds max open conns"。而 SetConnMaxLifetime 的设置顺序和取值，又会影响你对 SetMaxOpenConns 的合理估算。
- 必须先设
SetMaxOpenConns，再设SetMaxIdleConns和SetConnMaxLifetime -
SetMaxIdleConns推荐为SetMaxOpenConns的 1/2 到 2/3（如最大 100 → 空闲设 40～60） - 若
SetMaxOpenConns按云数据库每核 ≈20 连接估算（如 4 核 RDS 设 80），那SetMaxIdleConns就别设 100 - 所有设置必须紧接
db, err := gorm.Open(...)后执行，不能延迟到第一次查询前才做
实际生效依赖三件事：参数设对、顺序写对、db.Ping() 跟上。漏掉任意一环，连接池就只是个纸糊的架子——看着能跑，压测一上就崩。
