GORM的db.Error不等于连接失败，因其可能源于记录不存在、SQL错误或结构不匹配；真正连接错误需通过errors.As解包底层驱动错误并比对协议标识（如PostgreSQL的"08"码、MySQL的1040/2002等）。
连接失败报错不能只看 db.Error != nil —— 大部分时候它根本不是连接问题，而是业务错误或结构不匹配。
为什么 db.Error 不等于连接失败
GORM 的 *gorm.DB 是带连接池的会话管理器，不是单次连接。调用 First、Create 等方法时，db.Error 可能来自：记录不存在（gorm.ErrRecordNotFound）、SQL 语法错误、字段类型不兼容、外键约束冲突，甚至 AutoMigrate 时 struct tag 缺少 primaryKey 导致静默跳过——这些都不是连接断了。
真正连接失败的错误，藏在底层驱动里，GORM 默认做了包装，必须手动解包才能识别。
- PostgreSQL 驱动（
lib/pq）错误码以"08"开头（如"08001"、"08006"） - MySQL 驱动（
go-sql-driver/mysql）错误号为1040（Too many connections）、2002（Can't connect to local MySQL server）、2013（Lost connection）等 - SQL Server 驱动（
mssql）错误信息中常含"login failed"或"network-related"
如何准确判断是连接类错误
核心是做类型断言，提取原生驱动错误，再比对协议定义的连接异常标识：
PostgreSQL 示例：
import "github.com/lib/pq"
<p>func isConnectionError(err error) bool {
var pqErr *pq.Error
if errors.As(err, &pqErr) {
return len(pqErr.Code) >= 2 && pqErr.Code[0:2] == "08"
}
return false
}
MySQL 示例：
import "github.com/go-sql-driver/mysql"
<p>func isConnectionError(err error) bool {
var mySQLErr *mysql.MySQLError
if errors.As(err, &mySQLErr) {
switch mySQLErr.Number {
case 1040, 1042, 2002, 2013, 2026:
return true
}
}
return false
}
- 别用
strings.Contains(err.Error(), "connection")—— 日志翻译、中间件包装后关键词可能丢失或误判 - 别直接
err == driver.ErrBadConn—— GORM v2 已不直接暴露该错误，且它不覆盖所有连接场景（如 DNS 解析失败） - 类型断言必须用
errors.As，不是errors.Is或类型转换，否则在嵌套 error（如fmt.Errorf("wrap: %w", err)）下会失败
排查时先确认这三件事
很多“连接失败”其实是前置条件没满足，根本没走到驱动层：
-
gorm.Open返回的err是否被忽略？如果db是nil，后续所有db.First都会 panic 或静默失败 - DSN 字符串是否合法？比如 MySQL 中
v.GetString("db.port")返回空字符串，导致 DSN 变成user:@tcp(:)/dbname，报dial tcp: unknown port tcp/ - 数据库服务端是否真可达？用
telnet host port或nc -zv host port直接测 TCP 连通性，绕过 GORM 和驱动
如果连通性 OK，但首次请求就报 invalid connection，大概率是数据库 wait_timeout（如 MySQL 默认 8 小时）大于 GORM 连接池的生命周期，需同步设置：
sqlDB, _ := db.DB() sqlDB.SetConnMaxLifetime(3 * time.Hour) // 必须小于 wait_timeout sqlDB.SetMaxIdleConns(10) sqlDB.SetMaxOpenConns(100)
容易被忽略的细节
连接失败的错误往往只在第一次请求时暴露，之后连接池自动回收并重建，后续请求反而正常——所以本地测试通过不代表线上高可用。
更隐蔽的是：某些云数据库（如阿里云 RDS、腾讯云 CynosDB）会在连接空闲数秒后主动发 TCP RST 包，而 GORM 默认的 SetConnMaxIdleTime 是 0（不限制），导致连接池里长期存着已失效的连接。这种情况下，仅靠类型断言还不够，得配合健康检查或重试逻辑。
真正要稳住，得把「错误识别 + 连接池参数 + 网络探活」三者配齐，缺一不可。
