Go语言错误处理与事务回滚方法

Go语言事务处理中，错误处理远比表面看起来更复杂且关键：tx.Rollback()绝非“无害操作”，其返回的错误必须显式检查，否则可能掩盖网络中断、连接关闭等严重问题，导致事务状态误判甚至panic；Commit与Rollback均需严谨的错误分支处理，避免defer无条件回滚引发的逻辑混乱；应统一使用errors.Is(err, sql.ErrNoRows)安全识别空查询，杜绝用== nil模糊判断；推荐采用goto统一错误出口模式保障rollback与error返回的原子性；所有数据库操作必须使用Context版本（如QueryRowContext），否则超时控制形同虚设，极易造成连接池耗尽和事务挂起——真正的健壮性不来自技巧堆砌，而源于对每处错误语义的敬畏和对环境不确定性的持续验证。

Go 事务中 tx.Rollback() 必须检查返回值

很多人以为 tx.Rollback() 只是“尽力而为”，失败了也无所谓——这是最危险的错觉。它可能因网络中断、连接已关闭或底层驱动 bug 而返回非 nil 错误，但如果你忽略它，就等于把事务异常状态当成了成功回滚，后续还可能复用该 *sql.Tx 对象（导致 panic）或误判业务逻辑。

正确做法是：无论 tx.Commit() 还是 tx.Rollback()，都必须显式检查错误，并且 Rollback() 的错误不能简单吞掉。

• 如果 tx.Commit() 失败，通常要立即 tx.Rollback()；但此时若 Rollback() 也失败，说明事务状态已不可信，应记录日志并拒绝后续操作
• 不要在 defer 中无条件调用 tx.Rollback()，除非你确保此时 tx 一定未提交且仍有效（比如刚 Begin() 就出错）
• Rollback() 在事务已提交后调用会返回 sql.ErrTxDone，这不是 bug，而是预期行为，需区分处理

用 errors.Is(err, sql.ErrNoRows) 判断查询为空，别用 == nil

事务里执行 QueryRow().Scan() 时，查不到数据会返回 sql.ErrNoRows，但它不是业务错误，而是控制流信号。直接和 nil 比较会掩盖真正的问题，比如数据库连接断开、字段类型不匹配等也会返回非 nil 错误，但语义完全不同。

Go 1.13+ 推荐用 errors.Is() 显式识别这类哨兵错误，避免误把数据库故障当成“没查到”。

• errors.Is(err, sql.ErrNoRows) 是安全判断“查无结果”的唯一方式
• 如果业务上“查不到 = 错误”，那就按需包装新错误；如果“查不到 = 正常分支”，就只处理 ErrNoRows，其余 err 必须向上抛或记录
• 注意：某些驱动（如 pgx）可能返回自定义错误类型，但只要实现了 Unwrap() 并包裹了 sql.ErrNoRows，errors.Is() 依然有效

事务函数里别提前 return，用 goto 或闭包统一收口

一个典型事务函数往往包含多个 DB 操作、条件分支、资源清理逻辑。如果每个地方都写 if err != nil { tx.Rollback(); return err }，不仅重复，还容易漏掉某处没 rollback，或者 rollback 后又 commit（panic）。

更可控的方式是让错误路径集中到一个出口，保证 rollback 和 error 返回原子发生。

• 用 goto rollback 是 Go 标准库和成熟项目（如 database/sql 自身）常用手法，清晰且零分配
• 也可以用匿名函数包裹事务体，用 defer 做 rollback，但要注意：defer 在函数 return 后才执行，无法捕获 panic，且 error 变量作用域易出错
• 避免在事务函数里调用另一个事务函数——嵌套事务在多数数据库（如 MySQL）不真正支持，实际是 savepoint 模拟，但 Go 的 *sql.Tx 不提供 savepoint API，强行嵌套极易混乱

context.Context 要传进 db.QueryContext()，别只传给业务逻辑

事务超时、用户取消、服务优雅下线，这些都靠 context.Context 传递信号。但如果只在业务层用 context 控制流程，而 DB 操作仍用无 context 版本（如 Query()），那数据库连接可能卡死在慢查询里，事务长时间挂起，连接池耗尽。

所有带 I/O 的 DB 方法都有 Context 版本，必须用它们，否则 context 就是摆设。

• 用 tx.QueryRowContext(ctx, ...) 替代 tx.QueryRow(...)
• context 超时触发时，底层驱动会尝试中断连接（取决于驱动实现，如 mysql 驱动支持 readTimeout，pgx 支持 cancel request）
• 注意：MySQL 的 SET SESSION wait_timeout 和 context timeout 是两回事，前者是连接空闲超时，后者是单次查询上限，两者都要设，且 context timeout 应略小于数据库侧 timeout

事务里最麻烦的从来不是写 rollback，而是判断“此刻到底该 rollback 还是 commit”。很多错误源于假设某个 err 一定可恢复，或默认某个操作一定不改变事务状态。真实场景中，网络抖动、驱动版本差异、数据库配置不同，都会让同一段代码在不同环境表现不一致。多打几行日志，少信“应该不会”，比任何模式都管用。

好了，本文到此结束，带大家了解了《Go语言错误处理与事务回滚方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！