GORM v2 生产初始化必须用 mysql.Open(dsn) 并显式设置连接池三参数：SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime，且紧接调用 db.Session(&gorm.Session{}).Ping() 验证真实连接，缺一不可。
直接上生产环境的 GORM 初始化代码，90% 的连接失败、超时、P99 延迟飙升，不是模型写错了，是 gorm.Open() 后没做健康检查、连接池参数没对齐 MySQL 实例上限、驱动没装对。
gorm.Open() 必须传 mysql.Open(dsn)，不能传字符串
GORM v2 彻底废弃了 v1 的字符串驱动模式。传 "mysql" 或 "postgres" 会 panic：unknown driver "mysql" (forgotten import?)。
- 必须先
go get -u gorm.io/driver/mysql - 初始化时用
mysql.Open("user:pass@tcp(127.0.0.1:3306)/dbname?parseTime=true&loc=Local") - 如果混用多个数据库（如 MySQL + PostgreSQL），每个驱动都得单独
go get，缺一个就 runtime panic
连接池三大参数必须成套设置，单设 SetMaxIdleConns 是无效的
只调 db.SetMaxIdleConns(50) 不设 SetConnMaxLifetime，空闲连接会在 NAT/云防火墙静默断连后继续留在池里——下次复用直接报 read: connection reset by peer。
-
SetMaxOpenConns：设为 MySQLmax_connections的 60%～80%，查法：SHOW VARIABLES LIKE 'max_connections';（云 RDS 更保守，按每核 ≈20 连接估算） -
SetMaxIdleConns：设为SetMaxOpenConns的 1/2～2/3，例如最大 120 → 空闲设 40～60 -
SetConnMaxLifetime：必须设，推荐2 * time.Minute（云环境主备切换快）或5 * time.Minute（自建 MySQL），严禁设为0或time.Hour
启动时必须用 db.Session(&gorm.Session{}).Ping() 验证真实连接
gorm.Open() 只建结构体，不拨号。服务日志显示 “DB initialized” ≠ 数据库通了。首请求才真正建连，此时 DNS 解析失败、密码错、安全组拦截全堆在接口上，导致 500 或白屏。
- v2 中
db.Ping()已弃用，必须用db.Session(&gorm.Session{}).Ping() - 必须紧接在
gorm.Open()后执行，并显式检查 error；失败应log.Fatal或panic，不可忽略 - 本地开发可能侥幸通过（localhost 网络快），但上线后因 VPC、RDS 白名单、TLS 配置等立刻暴露
多数据源场景下，每个 DB 实例都要独立配池、独立 Ping
别用一个 *gorm.DB 对象切不同库——GORM 不支持运行时动态换库。读写分离或多租户需显式初始化多个实例，各自管理连接池和健康状态。
- 例如主库
dbMaster和从库dbSlave，要分别调SetMaxOpenConns、SetConnMaxLifetime、Session(...).Ping() - 配置项建议拆开：YAML 里定义
mysql.master和mysql.slave两组 Host/Port/User/Pool 参数 - 漏掉任一实例的 Ping，等于埋了个定时炸弹：某个库挂了，服务照常启动，直到某次查询命中它才崩
最易被跳过的其实是 SetConnMaxLifetime 和 Session(...).Ping() ——它们不报编译错误，也不阻塞启动，但线上故障率最高。别信“先跑起来再优化”，连接池参数一旦错，流量一上来就是雪崩。
