17370845950

Go处理数据库错误需区分错误类型：连接类、锁超时等可重试，主键冲突、事务异常等不可重试；应使用驱动提供的错误谓词函数精准判断，并实施最多3次指数退避重试。

Go 语言中处理数据库错误，关键不是“捕获所有 error”，而是识别错误类型、区分可恢复与不可恢复错误，并对网络抖动、锁冲突等常见临时性问题实施有节制的重试。直接 if err != nil { log.Fatal(err) } 在生产环境极易导致服务雪崩。

SQL 错误的核心分类（基于 net/url、database/sql 和驱动行为）

Go 的 database/sql 本身不定义具体错误码，实际错误来自底层驱动（如 github.com/lib/pq、github.com/go-sql-driver/mysql）。需按驱动文档解析错误细节：

• 连接类错误：如 dial tcp: i/o timeout、connection refused、server closed —— 属于临时性故障，适合重试
• 语义类错误：如主键冲突（PostgreSQL 的 23505，MySQL 的 1062）、外键约束失败（23503）、空值违例（23502）—— 逻辑错误，重试无意义，应修正输入或业务逻辑
• 锁等待超时：PostgreSQL 的 55P03（lock_not_available），MySQL 的 1205（deadlock）或 1206（lock_wait_timeout）—— 可重试，但需退避
• 事务状态异常：如 pq: current transaction is aborted, commands ignored until end of transaction block —— 必须回滚后新建事务，不能继续执行

用错误谓词函数做精准判断（以 PostgreSQL 为例）

避免字符串匹配，优先使用驱动提供的错误检查函数：

import "github.com/lib/pq"
func isUniqueViolation(err error) bool {
if pqErr, ok := err.(*pq.Error); ok {
return pqErr.Code == "23505"
}
return false
}
func isLockTimeout(err error) bool {
if pqErr, ok := err.(*pq.Error); ok {
return pqErr.Code == "55P03"
}
return false
}
func isNetworkError(err error) bool {
return strings.Contains(err.Error(), "i/o timeout") ||
strings.Contains(err.Error(), "connection refused") ||
strings.Contains(err.Error(), "broken pipe") ||
errors.Is(err, io.EOF)
}

MySQL 驱动也提供类似能力：mysql.MySQLError 结构体含 Number 字段，可直接比对错误码（如 err.Number == 1062）。

轻量级重试策略：带退避的有限次重试

重试不是越多越好。推荐最多 3 次，配合指数退避（如 100ms → 300ms → 900ms），并排除不可重试错误：

func withRetry(fn func() error, maxRetries int) error {
    var err error
    for i := 0; i <= maxRetries; i++ {
        err = fn()
        if err == nil {
            return nil
        }
        if !shouldRetry(err) {
            return err // 不该重试，立即返回
        }
        if i < maxRetries {
            d := time.Duration(math.Pow(3, float64(i))) * time.Millisecond * 100
            time.Sleep(d)
        }
    }
    return err
}
func shouldRetry(err error) bool {
return isNetworkError(err) || isLockTimeout(err)
}

注意：不要在事务内部盲目重试整个事务块 —— 若已执行部分语句，重试可能造成重复写入。应在事务外重试“事务函数”本身。

业务层兜底：错误映射与用户友好反馈

数据库错误不应透传给前端。建议统一转换为业务错误码和提示：

• 主键冲突 → 返回 409 Conflict + "用户名已被注册"
• 外键不存在 → 返回 400 Bad Request + "指定的分类 ID 无效"
• 连接失败 → 返回 503 Service Unavailable + "服务暂时不可用，请稍后再试"

可用简单错误包装器实现：

type AppError struct {
    Code    int
    Message string
    Err     error
}
func (e AppError) Error() string { return e.Message }
func (e AppError) Unwrap() error { return e.Err }

基本上就这些。核心是分清错误性质：临时的就等一等再试，逻辑错的就别硬刚，网络断的就重连，约束炸的就改数据。不复杂但容易忽略。