当前位置：首页 > 文章列表 > Golang > Go教程 > Golang数据库错误处理技巧与解决方法

Golang数据库错误处理技巧与解决方法

2026-02-05 17:36:36 0浏览收藏

Golang不知道大家是否熟悉？今天我将给大家介绍《如何在Golang中处理数据库错误_Golang数据库操作中的错误管理与解决》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

应使用 errors.Is(err, sql.ErrNoRows) 判断查询无结果，而非字符串匹配；区分数据库连接错误与业务错误需类型断言；事务中 Rollback() 和 Commit() 的返回值均须检查；日志中禁止打印原始 SQL 和敏感参数。

如何在Golang中处理数据库错误_Golang数据库操作中的错误管理与解决

判断 `sql.ErrNoRows` 而不是用字符串匹配错误信息

很多初学者看到查询无结果时 panic 或返回空结构体，就去检查 err.Error() 是否包含 "no rows" —— 这是脆弱且不可靠的。Go 标准库明确提供了导出变量 sql.ErrNoRows 用于判等，它在任何驱动（mysql、postgres、sqlite）下行为一致。

正确做法是直接比较错误值：

var name string
err := db.QueryRow("SELECT name FROM users WHERE id = ?", 123).Scan(&name)
if err != nil {
    if errors.Is(err, sql.ErrNoRows) {
        // 处理未找到
        return nil, fmt.Errorf("user not found")
    }
    return nil, err // 其他错误（如连接中断、类型不匹配）需向上抛
}

永远别用 strings.Contains(err.Error(), "no rows") —— 驱动可能本地化错误文本，或未来版本调整措辞
errors.Is() 比 == 更安全，能穿透包装错误（比如 fmt.Errorf("query failed: %w", err)）
sql.ErrNoRows 仅适用于 QueryRow 和 Scan 场景；Query 返回 *sql.Rows，需调用 rows.Next() 判断是否为空

区分数据库连接错误和业务逻辑错误

数据库操作失败原因差异极大：网络抖动、认证失败、语句语法错、约束冲突（如唯一键重复）、超时 —— 它们应对策略完全不同。Golang 的 driver.ErrBadConn 和 pgconn.PgError（PostgreSQL）等类型提供了分类依据，但标准 error 接口本身不暴露这些细节。

实操建议：

对 MySQL，用 mysql.MySQLError 类型断言获取 Number 字段（如 1062 是唯一键冲突）
对 PostgreSQL，用 pgconn.PgError 断言，检查 Code（如 "23505" 表示唯一约束违规）
通用兜底：用 errors.Is(err, driver.ErrBadConn) 判断是否需要重试（注意：该错误在 Go 1.19+ 已被弃用，应改用 driver.IsConnectionReset 或驱动专属判断）
不要把约束错误（如插入重复邮箱）当作系统故障记录 ERROR 日志 —— 它属于用户输入问题，应返回 400 和明确提示

使用 `tx.Rollback()` 后必须检查其返回错误

事务中发生错误后调用 tx.Rollback() 看似保险，但它的返回值可能非 nil：比如事务已提交成功、连接已断开、或底层驱动在回滚阶段又出错。忽略这个错误会导致误判事务状态。

典型反模式：

tx, _ := db.Begin()
defer tx.Rollback() // 错！这里无法捕获 Rollback 失败

正确写法是显式处理：

tx, err := db.Begin()
if err != nil {
    return err
}
defer func() {
    if r := recover(); r != nil {
        tx.Rollback()
        panic(r)
    }
}()
if _, err := tx.Exec("INSERT ..."); err != nil {
    tx.Rollback() // 先尝试回滚
    return err
}
return tx.Commit()

务必在 Commit() 失败后也考虑回滚（虽然多数驱动在 Commit 失败时自动回滚，但不保证）
避免用 defer tx.Rollback()，除非你确定后续一定会 Commit() 且能接受回滚失败被吞掉
如果业务允许部分失败，可考虑用保存点（SAVEPOINT）代替整事务回滚，但需驱动支持（如 pgx 支持，database/sql 原生不支持）

日志中避免打印完整 SQL 和参数

开发期用 log.Printf 打印 SQL 方便调试，但上线后若直接记录 err.Error() 或拼接后的查询语句，极易泄露敏感数据（如密码哈希、身份证号、邮箱）或违反 GDPR / 等保要求。

错误日志中只记录错误类型和影响行数（如 "INSERT into users failed: unique_violation (23505), rows affected: 0"），不出现原始 SQL
若需审计 SQL，应单独开启结构化慢查询日志（如 MySQL 的 slow_query_log），由 DBA 控制权限
使用 sqlmock 测试时，可通过 mock.ExpectQuery().WithArgs(...) 验证参数是否符合预期，而非检查 SQL 字符串内容

最常被忽略的一点：自定义错误包装（fmt.Errorf("failed to create user: %w", err)）时，如果底层 err 来自数据库驱动并包含原始 SQL，整个错误链都可能带出敏感信息 —— 务必在包装前剥离或脱敏。

终于介绍完啦！小伙伴们，这篇关于《Golang数据库错误处理技巧与解决方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！