db.Ping()仅验证单连接通路，不增加空闲连接数；真正预热需并发执行SELECT 1等轻量查询，使IdleConns达SetMaxIdleConns设定值。
为什么 db.Ping() 不等于预热连接池
很多人以为调了 db.Ping() 就完成了连接池“预热”，其实它只建一个连接并验证通路，对空闲连接数 SetMaxIdleConns 完全没影响。GORM 底层用的是 *sql.DB，而标准库没有 Preheat() 这种方法——预热必须靠“触发式填充”：主动发起足够多的并发空查询，把空闲连接撑到目标值。
怎么手动触发连接池预热（Go 1.20+）
在 gorm.Open() 后、服务接受请求前，用 goroutine 并发执行轻量查询，直到 sqlDB.Stat().Idle 达到预期。关键点：
-
sqlDB, _ := db.DB()先拿到原生连接池句柄 - 预热目标设为
SetMaxIdleConns值（比如你设了 40，就至少建 40 个空闲连接） - 用
SELECT 1这类无副作用查询，避免锁表或日志刷盘 - 加超时控制，防止预热卡住整个启动流程
示例代码片段：
SetConnMaxLifetime
-
SetConnMaxLifetime必须设为 2～5 分钟（推荐 3 分钟），不能是 0 或time.Hour -
SetConnMaxIdleTime推荐设为 30 秒～1 分钟，加速淘汰可能已断开的空闲连接 - 预热后别忘了再调一次
sqlDB.Ping()，确认池里至少有一个可用连接
GORM v2 中 db.Ping() 已废弃，得用 session 方式
v2 开始 db.Ping() 被移除，必须走 db.Session(&gorm.Session{}).Ping() 才能真正触达底层连接。但注意：这个调用仍只测单连接，不影响空闲池大小。
- 初始化后立刻做健康检查：
db.Session(&gorm.Session{}).Ping() - 预热逻辑仍必须基于
db.DB()返回的*sql.DB，GORM 层不参与连接生命周期管理 - 如果你用了
gorm.Config.PrepareStmt: true，预热时也要执行带参数的空查询（如SELECT ?），否则预编译语句池不会填充
预热不是“多建几个连接”那么简单——它得和 SetMaxIdleConns、SetConnMaxLifetime、NAT 超时窗口三者对齐，漏掉任一环，启动后前几十个请求照样会卡在连接建立上。
