必须在gorm.Open()后立即通过db.DB()设置SetMaxOpenConns、SetMaxIdleConns和SetConnMaxLifetime等参数，否则无效；三者须严格按先设最大打开、再设最大空闲（≤前者）、最后设连接生命周期的顺序配置，且重启才是唯一可靠生效方式。
配置必须在 gorm.Open() 之后立即设置，否则无效
连接池参数（SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime 等）作用于底层 *sql.DB 实例，而该实例直到 gorm.Open() 返回 *gorm.DB 后才真正创建。若在 gorm.Open() 前尝试设置，或在中间件/函数里延迟调用，参数根本不会绑定到任何池上。
常见错误包括：
- 把
db.DB().SetMaxOpenConns(20)写在某个 handler 里，每次请求都执行一次 → 实际只对当前 goroutine 拿到的*sql.DB生效，但该对象是全局复用的，重复设无害也无用，且掩盖了初始化缺失问题 - 用 config struct 传参方式误以为
&gorm.Config{...}能控制连接池 → 它只影响 ORM 行为，和池无关 - 在单元测试中每次 new 一个
*gorm.DB却忘了配池 → 测试通过，上线后Too many connections
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对使用，顺序不能错
Go 1.12+ 对空闲连接数做了硬校验：SetMaxIdleConns(n) 若大于当前 MaxOpenConns 值，运行时直接 panic，报错信息为 "max idle conns exceeds max open conns"。
所以必须严格按顺序操作：
- 先调
sqlDB.SetMaxOpenConns(100) - 再调
sqlDB.SetMaxIdleConns(50)（≤ 上一步值） - 最后设
sqlDB.SetConnMaxLifetime(5 * time.Minute)
漏掉 SetConnMaxLifetime 是高频隐患：空闲连接长期滞留，在云环境 NAT 超时（通常 3～5 分钟）后被静默断开，下次取出就报 read: connection reset by peer 或 i/o timeout。
配置生效后不会动态刷新，重启才是唯一可靠方式
*sql.DB 的连接池参数是只读初始化属性，运行时修改（如热更新配置中心拉取新值后重设）不会影响已建立的连接或正在归还/获取的连接行为。所谓“刷新”，只是改了后续新建连接的约束条件。
更关键的是：已存在于池中的连接，其生命周期仍由旧的 SetConnMaxLifetime 控制，不会因新设置而提前关闭；InUse 和 Idle 计数器也不会重置。
因此生产环境遇到连接池异常，不要指望 reload 配置，应优先检查：
- 是否所有服务实例都完成了重启（尤其 k8s rolling update 时旧 pod 是否彻底退出）
- 是否存在多处初始化逻辑（如 test/main/init.go 各自调了一次
gorm.Open()）导致部分池未被配置 -
db.Stats()中WaitCount持续上涨，说明新配置没起作用，连接获取阻塞仍在发生
验证配置是否真正生效，别只信日志
光看 “DB initialized” 日志没用，得用 db.DB().Stats() 和真实查询行为交叉验证：
- 启动后立刻执行
fmt.Printf("%+v", db.DB().Stats())，确认MaxOpenConnections和MaxIdleConns是你设的值，不是 0 或默认值 - 跑一段并发压测（比如 50 goroutine 同时
db.First(&u)），观察db.DB().Stats().InUse是否稳定在设定上限内，而非一路飙到几百 - 连续快速执行
db.Raw("SELECT CONNECTION_ID()").Scan(&id)5 次，若返回的id有重复，说明连接复用成功；全不同则池未生效，大概率是gorm.Open()被重复调用了
最容易被忽略的一点：连接池参数生效 ≠ 连接一定健康。MySQL 的 wait_timeout 和 Go 的 SetConnMaxLifetime 必须错开 5～10 分钟，否则连接会在归还前就被 DB 主动 kill，池里堆满“僵尸连接”，等着第一次 Query 时才暴露错误。
