应使用 db.DB().Ping() 检测连接状态，而非判断 db.Error；因 GORM 错误是操作级而非连接级，Ping() 通过轻量心跳包验证连通性，首次稍慢但后续复用连接，开销最小。
不能靠 db.Error != nil 判断连接是否失效，GORM 的错误对象是操作级的，不是连接级的；真正要检查连接状态，得用 db.DB().Ping() 主动探测，或在查询失败后解析底层驱动错误码。
用 db.DB().Ping() 做主动连通性检测
这是最直接、开销最小的连接状态验证方式。它不依赖任何表结构或 SQL 执行，只向数据库发送一个轻量心跳包。
-
db.DB()返回的是底层*sql.DB实例，Ping()会从连接池中取一个可用连接执行测试 - 首次调用可能稍慢（需建连），后续基本是复用已有连接，耗时通常
- 如果返回 error，说明当前连接池里没有健康连接，常见原因包括：数据库宕机、网络中断、认证过期、防火墙拦截
- 注意不要在高频请求路径里频繁调用 —— 它不是无成本的，建议用于启动校验、健康接口（如
/health）或定时巡检
示例：
err := db.DB().Ping()
if err != nil {
log.Error("DB ping failed:", err)
// 可触发告警、标记服务不可用等
}
在查询失败后识别是否为连接类错误
GORM 查询返回的 result.Error 是封装后的错误，必须类型断言才能拿到驱动原生错误，再根据协议判断是否属于连接异常。
- PostgreSQL（
lib/pq）：检查*pq.Error.Code是否以"08"开头（如"08006"） - MySQL（
go-sql-driver/mysql）：断言为*mysql.MySQLError，检查Number()是否为1040（Too many connections）、2002（Can't connect to local MySQL server）、2013（Lost connection）等 - SQLite / SQL Server 等其他驱动同理，需查对应驱动文档确认错误标识方式
- 不要只看 error 字符串是否含 "connection" 或 "timeout" —— 这类字符串匹配极易误判（比如用户数据里真有 "connection refused"）
为什么 db.Error 不能直接用作连接判断依据
db.Error 是 GORM 在链式调用中累积的上一次操作错误，它可能是：
- 业务逻辑错误（如
gorm.ErrRecordNotFound） - SQL 构造错误（如字段名拼错、JOIN 条件缺失）
- 权限不足（
ERROR 1142 (42000): SELECT command denied） - 甚至根本没发请求（如
Where()后忘了First()，db.Error就是nil）
它和底层 TCP 连接状态完全解耦。即使数据库已彻底离线，只要还没执行真实查询，db.Error 依然为 nil。
连接池参数会影响“连接失败”的感知时机
database/sql 连接池的行为决定了你何时能发现连接问题：
-
SetMaxIdleConns(5)：空闲连接数上限。若设得太小，高并发下容易耗尽空闲连接，新请求需新建连接 —— 此时才暴露网络问题 -
SetConnMaxLifetime(1h)：连接最大存活时间。过长会导致失效连接滞留池中，后续请求仍可能复用并报错 -
SetMaxOpenConns(20)：活跃连接上限。设得太低会排队阻塞，看起来像“卡住”，实则不是连接失败
这些参数不改变连接本质，但会显著影响错误出现的频率和时机 —— 调试时务必核对实际配置值，别只看默认注释。
真正的连接状态检查永远发生在「与数据库实际通信」那一刻，无论是主动 Ping() 还是某次查询触发的底层 dial。所有静态判断（比如检查 db 变量是否为 nil）都不可靠。
