如何在Golang中处理数据库操作错误_Golang数据层错误处理方案

go数据库错误需分层处理：先判sql.ErrNoRows，再用Errors.As识别驱动错误（如pq.Error码“23505”），网络错误需重试，事务须显式Rollback并防panic，超时需应用层与数据库级协同配置。

Go 的 database/sql 错误不是一次性判空就完事的

很多刚写 Go 数据库代码的人会直接写 if err != nil 然后 panic 或 log 后返回，但这在生产环境极不可靠。因为 database/sql 的 err 可能是连接中断、事务已提交失败、SQL 语法错、主键冲突、超时、甚至 driver 自定义错误（如 pq.Error），它们的处理策略完全不同。

真正该做的是：先判断是否为 sql.ErrNoRows 这类预期错误；再用类型断言识别 driver 特定错误；最后才兜底处理其他非预期错误。

• sql.ErrNoRows 是常见且安全的“查不到”，通常不需报警，业务可按默认值或空结构体继续
• postgresql 驱动（github.com/lib/pq）的错误需断言为 *pq.Error，再检查 Code 字段（如 "23505" 表示唯一约束冲突）
• mysql 驱动（github.com/go-sql-driver/mysql）错误要断言为 *mysql.MySQLError，看 number（如 1062 是重复键）
• 网络类错误（如 net.OpError、driver.ErrBadConn）往往意味着连接池需重建或重试

用 errors.As 判断驱动错误比类型断言更健壮

Go 1.13+ 推荐用 errors.As 而非直接类型断言，因为它能穿透多层包装错误（比如 fmt.Errorf("query failed: %w", pqErr)）。直接断言会失败，而 errors.As 可以递归解包。

var pqErr *pq.Error if errors.As(err, &pqErr) {     switch pqErr.Code {     case "23505": // unique_violation         return fmt.Errorf("用户名已被注册：%w", err)     case "23503": // foreign_key_violation         return fmt.Errorf("关联资源不存在：%w", err)     default:         return fmt.Errorf("数据库操作异常：%w", err)     } }

注意：必须传入指针地址 &pqErr，否则 errors.As 无法赋值；若使用 MySQL，对应换成 *mysql.MySQLError 即可。

立即学习“go语言免费学习笔记（深入）”；

事务中出错必须显式 tx.Rollback()，且要检查 Rollback 错误

很多人只记得 tx.Commit() 成功与否，却忽略 tx.Rollback() 也可能失败（比如连接已断）。一旦 Commit 失败后没 Rollback，连接可能卡在“in transaction”状态，后续从连接池取到该连接的请求会直接报 pq: current transaction is aborted。

• 所有事务函数结尾必须有 defer func() { if r := recover(); r != nil { tx.Rollback() } }() 防 panic 导致漏 rollback
• Commit 失败后立即 Rollback，并检查其返回的 err —— 若 rollback 也失败，说明连接已不可用，应记录并标记连接池需刷新
• 不要在 Rollback 后继续用该 tx 对象，它已失效

tx, err := db.Begin() if err != nil {     return err } defer func() {     if p := recover(); p != nil {         tx.Rollback()         panic(p)     } }() _, err = tx.Exec("INSERT INTO users(name) VALUES($1)", name) if err != nil {     tx.Rollback() // 必须立刻回滚     return err } return tx.Commit()

超时和上下文取消不能只靠 context.WithTimeout

仅给 db.QueryContext 传带超时的 ctx 不够。底层 driver 可能仍卡在 socket read，或数据库端执行未中断（尤其 PostgreSQL 的 long-running query）。必须配合数据库级 timeout 设置：

• PostgreSQL：在连接字符串加 connect_timeout=5 和 statement_timeout=30000（单位毫秒）
• MySQL：连接参数设 timeout=5s&readTimeout=30s&writeTimeout=30s
• 应用层 context.WithTimeout 应略短于数据库 timeout（比如设 25s），留出网络往返和 driver 处理余量
• 对 db.PingContext 也要设超时，避免健康检查阻塞整个服务启动

最易被忽略的一点：sql.DB 的 SetConnMaxLifetime 和 SetMaxOpenConns 配置不当，会导致大量 “connection refused” 或 “too many connections”，这类错误不会出现在单条 SQL 的 err 中，而是在 db.Ping 或连接获取阶段暴露。