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"
<p>func isUniqueViolation(err error) bool {
if pqErr, ok := err.(*pq.Error); ok {
return pqErr.Code == "23505"
}
return false
}</p><p>func isLockTimeout(err error) bool {
if pqErr, ok := err.(*pq.Error); ok {
return pqErr.Code == "55P03"
}
return false
}</p><p>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）。
立即学习“go语言免费学习笔记（深入）”；
Github 1.0.0
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
轻量级重试策略：带退避的有限次重试
重试不是越多越好。推荐最多 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
}
<p>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
}
<p>func (e <em>AppError) Error() string { return e.Message }
func (e </em>AppError) Unwrap() error { return e.Err }
基本上就这些。核心是分清错误性质：临时的就等一等再试，逻辑错的就别硬刚，网络断的就重连，约束炸的就改数据。不复杂但容易忽略。
