SetMaxOpenConns必须显式设为数据库max_connections的60%～80%（如200则设120～160），否则默认0将导致Too many connections；SetMaxIdleConns须≤前者且推荐设为1/2～2/3，否则Go 1.12+直接panic；SetConnMaxLifetime应设2～5分钟防僵尸连接，db.Ping()是启动必验项。
SetMaxOpenConns 必须显式设，不能依赖默认值
默认 SetMaxOpenConns(0) 等于不限制连接数，上线后 MySQL 很快报 Too many connections，P99 延迟可能从 50ms 拉到 800ms+。这个值不是拍脑袋定的，得和数据库服务端的 max_connections 对齐：
- 查 MySQL 当前限制：
SHOW VARIABLES LIKE 'max_connections';，假设返回 200，则SetMaxOpenConns应设为 120～160（60%～80%） - 云数据库（如阿里云 RDS）更保守：按每 CPU 核 ≈20 连接估算，别套物理机配置
- 设太低（比如 10）会导致 20 个 goroutine 并发查用户时全卡在等连接，QPS 上不去，平均延迟反而升高
SetMaxIdleConns 必须 ≤ SetMaxOpenConns，否则 panic
SetMaxIdleConns 不是独立参数，它受 SetMaxOpenConns 硬约束。Go 1.12+ 会直接 panic，错误信息是 "max idle conns exceeds max open conns"：
- 必须先调
sqlDB.SetMaxOpenConns(100)，再调sqlDB.SetMaxIdleConns(40)（推荐设为 Open 值的 1/2～2/3） - 如果
SetMaxOpenConns没设（即保持 0），SetMaxIdleConns(10)不会 panic，但空闲连接实际不可控，容易被中间件断连后滞留 - 默认值
defaultMaxIdleConns = 2在高并发下完全不够，每次请求都得新建连接，销毁开销大
SetConnMaxLifetime 是防“僵尸连接”的关键
数据库（如 MySQL）或中间件（ProxySQL、RDS Proxy、NAT 网关）会在 3～5 分钟后静默断连，而 GORM 不会主动探测。不设 SetConnMaxLifetime，连接池里就堆着一堆 read: connection reset by peer 的失效连接：
- 推荐设为 2～5 分钟：云环境主备切换快，设 2 分钟更安全；自建 MySQL 可设 5 分钟
- 别设成
0或time.Hour：长期存活连接易在 DB 侧积压idle in transaction，占内存、锁资源、触发上下文切换风暴 - 它不发心跳、不保活，只是计时器一到就关——这是唯一能强制淘汰老化连接的机制
db.Ping() 不是可选项，而是启动必验项
gorm.Open() 只初始化结构，不建真实连接；db.Ping() 才真正拨号。漏掉这步，首请求才暴露问题，常见表现是 HTTP 首屏白屏、gRPC 调用超时、k8s readiness probe 误判：
- v2 中
db.Ping()已弃用，必须用db.Session(&gorm.Session{}).Ping() - 只靠
Ping()不够：它只验证此刻能建一个连接并执行SELECT 1，不检查池中已有空闲连接是否还活着 - 真正健康检查得靠运行时行为：查
SHOW PROCESSLIST（MySQL）或pg_stat_activity（PostgreSQL），看活跃连接是否稳定在你设的SetMaxOpenConns附近，而非持续攀升
连接池参数之间有强依赖关系，调错顺序或漏掉任一环节，都会让整个池失效——不是慢一点，而是直接卡死或崩溃。
