gorm.Open仅初始化*gorm.DB实例，真实连接池为空闲状态，首次db.First等操作才建连；必须调db.DB().Ping()验证连通性，并用db.DB().Stats()观察Idle/InUse值确认复用效果。
gorm.Open 返回后连接池还没真正建连
很多人以为 gorm.Open 执行完，数据库连接池就 ready 了，其实它只初始化了一个 *gorm.DB 实例，底层包装的 *sql.DB 连接池此时完全空闲——既没建任何连接，也没做连通性验证。真实连接是在第一次调用 db.First、db.Find 或 db.Exec 等操作时，才从池里按需获取或新建的。
这意味着：光靠 gorm.Open 不报错，完全不能说明数据库可达；不触发实际查询，你永远不知道连接池是否真能工作。
必须手动调 db.DB().Ping() 才能触发首次建连
db.DB().Ping() 是唯一可靠的方式，强制底层 *sql.DB 尝试建立并复用一个连接，同时验证网络与认证是否正常。它会阻塞直到成功拿到一个可用连接（或超时失败），是调试连接池是否“活起来”的第一道门槛。
- 如果
Ping()报错dial tcp: i/o timeout或access denied，说明 DSN 写错、网络不通、账号密码不对，得先修这些基础问题 - 如果
Ping()成功但后续查询仍慢或失败，大概率是连接池参数没设好，比如SetMaxOpenConns太小导致高并发时排队等待 - 别在
Ping()前调db.DB().SetMaxOpenConns(10)—— 必须先拿到*sql.DB实例，再配置，顺序不能反
如何观察连接池是否真的在复用连接
Go 标准库的 *sql.DB 提供了 Stats() 方法，返回实时连接状态，是调试复用行为最直接的手段。在几次查询后连续打印它，就能看出连接是否被复用：
fmt.Printf("Pool stats: %+v\n", db.DB().Stats())
// 输出类似：{MaxOpenConnections:10 OpenConnections:2 InUse:1 Idle:1 ...}
-
OpenConnections表示当前已建立（含空闲+使用中）的总连接数，首次Ping()后通常是 1，之后随并发增长 -
InUse是正在被 goroutine 持有的连接数；Idle是空闲待复用的连接数。如果每次查询都让InUse从 0 变 1、Idle从 1 变 0，说明连接在复用；如果OpenConnections持续上涨且不回落，说明连接没被释放或SetConnMaxLifetime没设，连接变“僵尸”了 - 注意：SQLite 的
:memory:模式每次Open都是新实例，Stats()永远显示 0 或 1，不适合用这个方式调试
容易忽略的 SQLite 特殊行为
SQLite 不走 TCP/IP，它的“连接池”本质是文件句柄复用，但 GORM 层仍套了一层 *sql.DB，所以 db.DB().Stats() 依然有效。不过有三个坑必须避开：
- 驱动没注册：必须
import _ "gorm.io/driver/sqlite"，否则gorm.Open直接 panicunsupported driver: sqlite - WAL 模式没开：默认 DELETE 模式下写锁是全表级，
db.Exec("PRAGMA journal_mode = WAL")要在Ping()后立刻执行，否则并发写会卡住，看起来像连接池“假死” - 路径写相对路径：比如
sqlite.Open("test.db")，若工作目录不固定（如测试时 vs 生产时），Ping()可能静默创建新文件，你以为连的是旧库，其实连的是空的新库
连接池的真实行为藏在 *sql.DB 里，GORM 只是壳；盯住 db.DB().Ping() 和 db.DB().Stats()，比看日志或猜错误更准。
