单个GORM实例的SetMaxOpenConns应设为floor(max_connections / instance_count × 0.6～0.8)，例如max_connections=200、4个实例时取40；须配SetMaxIdleConns（为Open值的0.5～0.65）和SetConnMaxLifetime（云环境2～3分钟），并启动时立即执行db.Session(&gorm.Session{}).Ping()验证连通性。
SetMaxOpenConns 怎么按实例数和数据库总容量算
单个 GORM 实例的 SetMaxOpenConns 不能直接等于数据库 max_connections，必须除以部署实例数后，再乘以安全系数。比如 MySQL 的 max_connections=200，你部署了 4 个服务实例，那每个实例最多只能分到 50 连接；再打个 80% 折（防毛刺+留监控余量），最终设为 40。
常见错误是所有实例都设成 100——4 个实例瞬间就冲到 400 连接，MySQL 直接报 Too many connections，P99 延迟飙升。
- 查数据库上限：
SHOW VARIABLES LIKE 'max_connections'; - 确认当前部署实例数（K8s Pod 数 / 机器上进程数）
- 计算公式：
floor(max_connections / instance_count * 0.6～0.8)，结果向下取整 - 云数据库（如阿里云 RDS）建议更保守：按每核 ≈20 连接估算，再除以实例数
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对调
只设 SetMaxIdleConns 不设 SetConnMaxLifetime，空闲连接会在 NAT 网关或云防火墙超时后静默断开，下次复用直接报 read: connection reset by peer。
推荐组合（以单实例 SetMaxOpenConns=40 为例）：
-
SetMaxIdleConns设为20～26（即40 * 0.5～0.65） -
SetConnMaxLifetime设为2m～3m（云环境主备切换快，别信“设 1 小时更稳”这种过时建议） - 千万别设
0或time.Hour：前者导致频繁建连，后者让连接长期 idle in transaction，占 DB 内存还锁资源
为什么 db.Ping() 必须在启动时立刻执行
gorm.Open() 只初始化结构体，不建真实连接；db.DB().Ping() 才真正拨号。漏掉这步，首请求才会暴露网络不通、密码错、DNS 失败等问题，用户看到的就是白屏或 500。
注意 GORM v2 已弃用 db.Ping()，必须用：
if err := db.Session(&gorm.Session{}).Ping(); err != nil {
log.Fatal("failed to ping DB:", err)
}
- 必须紧接在
gorm.Open()后执行，不能放到中间件或懒加载逻辑里 - 如果用 Revel 或其他框架做多 DB 初始化，每个
*gorm.DB实例都要单独Ping() - 日志里看到 “DB initialized” 不代表可用，只有
Ping()成功才算通
多个 GORM 实例共用底层 sql.DB 的坑
默认每个 *gorm.DB 都有独立 *sql.DB 连接池，但如果你误调了全局 sql.Open() 或手动共享 sql.DB，多个 GORM 实例就会共用同一套连接池参数。一个分析查询把连接占满，API 接口就全卡住。
验证是否隔离：打印每个实例的 db.DB().Stats()，观察 OpenConnections 是否随各自负载独立升降。
- 每个数据库连接必须由独立
gorm.Open()创建，变量名分开（如userDB、logDB） - 避免在
func init()里初始化 DB：失败难捕获，且无法控制执行顺序 - 若用依赖注入（fx/wire），务必为每个 DB 绑定唯一类型（如
type UserDB *gorm.DB）
实际部署时最容易被忽略的是：连接池参数不是“设一次就完事”，它必须和你的扩缩容节奏同步更新。Pod 数变了，没改配置，第二天半夜流量高峰就爆连接。
