Go database/sql 怎样让事务回滚覆盖提前返回路径

在 Go 的 database/sql 里，事务函数最容易出问题的地方不是 BeginTx，而是中途的提前返回：第一条 SQL 成功、第二条 SQL 失败，或者业务校验不通过后直接 return，如果没有统一结束事务，代码就很难确认每条路径都执行了 Rollback。

一个实用的规则是：事务函数默认回滚，只有所有操作成功并且进入唯一成功出口时才提交。下面用命名返回值配合 defer，把普通错误、提前返回、panic 和 context 取消纳入同一套控制流。文中的路径数字是静态代码审查指标，不代表已经连接某个数据库做过压测。

官方文档：https://pkg.go.dev/database/sql

先画出事务结束路径

DB.BeginTx 成功后会得到一个 *sql.Tx。后续属于同一事务的查询和更新都应通过这个 tx 完成；不要在事务中途又调用 db.ExecContext，因为 db 是连接池句柄，拿到的连接可能不是当前事务使用的连接。

从控制流看，事务至少有四类出口：

官方文档明确要求事务最终调用 Commit 或 Rollback。因此，检查事务代码时，重点不是搜索有没有出现这两个词，而是确认每个提前返回是否都能到达回滚分支，以及提交是否只存在于成功出口。

让 defer 兜住提前返回

最小可用的写法是在成功开始事务后立即注册 defer tx.Rollback()。提交成功后，延迟的回滚会返回 sql.ErrTxDone，它不会把已经提交的事务再次回滚，所以这个习惯用法可以覆盖多个提前返回。

func updateProfile(ctx context.Context, db *sql.DB, id int64, name string) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    // 默认路径负责回滚；成功提交后，这个 Rollback 会被 database/sql 忽略为已结束事务。
    defer tx.Rollback()

    if name == "" {
        // 业务校验的提前返回也会先经过上面的 defer。
        return errors.New("name is required")
    }

    if _, err := tx.ExecContext(ctx,
        "UPDATE profiles SET name = ? WHERE id = ?", name, id); err != nil {
        // SQL 错误直接返回，defer 负责结束事务。
        return fmt.Errorf("update profile: %w", err)
    }

    // 只有前面的操作全部成功，才到达这个提交出口。
    return tx.Commit()
}

这个版本已经解决了“忘记回滚”的主要问题，但它仍有两个需要明确的边界：第一，Commit 的错误必须返回给调用方；第二，panic 时虽然 defer tx.Rollback() 会执行，但如果需要记录回滚错误或统一控制 panic，就应该使用带分支的 helper。

把 context 取消和连接边界算进去

优先使用 BeginTx，因为它接收调用方的 context.Context。如果这个 context 在事务仍然进行时被取消，database/sql 会回滚事务；之后再调用 Commit 可能返回错误。这个行为意味着业务代码不能把“请求已经取消”当成成功提交。

func reserve(ctx context.Context, db *sql.DB, userID, itemID int64) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    // 请求取消时，database/sql 也可能已经让事务失效；这里仍保持统一清理。
    defer tx.Rollback()

    var stock int
    // 查询也必须使用 tx，保证读取和更新属于同一事务连接。
    if err := tx.QueryRowContext(ctx,
        "SELECT stock FROM items WHERE id = ?", itemID).Scan(&stock); err != nil {
        return fmt.Errorf("read stock: %w", err)
    }
    if stock 

还要注意事务与连接池的关系：DB.BeginTx 返回的 Tx 会绑定一条连接，Commit 或 Rollback 后连接才回到池中。把事务操作改回 db.QueryContext，既不能获得当前事务的原子性，也会让代码审查很困难。

封装一个只在成功时提交的 helper

当多个业务函数都需要同样的“开始、执行、回滚、提交”结构时，可以把结束规则集中到一个 helper。这里使用命名返回值，是因为 defer 需要在函数返回前读取和修改最终错误。

func withTx(ctx context.Context, db *sql.DB, fn func(*sql.Tx) error) (err error) {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }

    defer func() {
        if p := recover(); p != nil {
            // panic 不能被当成成功返回；先回滚，再把原 panic 交给上层处理。
            _ = tx.Rollback()
            panic(p)
        }

        if err != nil {
            // 任意业务错误或 SQL 错误都走回滚分支。
            if rollbackErr := tx.Rollback(); rollbackErr != nil &&
                !errors.Is(rollbackErr, sql.ErrTxDone) {
                // 保留原始业务错误，同时补充回滚失败信息。
                err = fmt.Errorf("%w; rollback failed: %v", err, rollbackErr)
            }
            return
        }

        // 只有 fn 返回 nil 时才允许提交，Commit 错误也必须向外返回。
        err = tx.Commit()
    }()

    // fn 内部可以有多个 return；它们都会回到上面的 defer。
    err = fn(tx)
    return err
}

业务函数因此只负责描述事务里的操作：

func createOrder(ctx context.Context, db *sql.DB, userID int64) error {
    return withTx(ctx, db, func(tx *sql.Tx) error {
        // 事务内的所有读写都使用同一个 tx。
        var enabled bool
        if err := tx.QueryRowContext(ctx,
            "SELECT enabled FROM users WHERE id = ?", userID).Scan(&enabled); err != nil {
            return fmt.Errorf("load user: %w", err)
        }
        if !enabled {
            // 这个提前返回会触发 helper 中的 Rollback，而不是 Commit。
            return errors.New("user is disabled")
        }

        if _, err := tx.ExecContext(ctx,
            "INSERT INTO orders(user_id, status) VALUES (?, ?)", userID, "pending"); err != nil {
            return fmt.Errorf("create order: %w", err)
        }
        return nil
    })
}

这个封装的关键不是“把代码写短”，而是缩小提交权限：业务回调只返回错误或 nil，不直接调用 Commit。这样提交点只有一个，审查者可以直接检查 helper 的成功分支。

用路径指标检查是否真的覆盖

可以在代码评审中记录一组简单的静态指标。它们不需要连接数据库，也不替代测试，但能快速发现“新增了一个 return，却忘了清理”的问题。

如果业务代码必须返回多个值，可以把结果写入局部变量，再让回调返回错误；不要为了绕开 helper，在某个分支里自行提交。若提交失败，调用方应把它当作失败处理，因为官方文档要求丢弃该事务中查询和更新结果的成功假设。

常见问题

defer tx.Rollback() 会不会把成功提交撤销？

不会。提交后事务已经结束，延迟回滚只会得到已完成事务的结果；它的作用是覆盖中途的错误和提前返回。

为什么不直接执行 BEGIN 和 COMMIT SQL？

官方建议使用 database/sql 的事务 API。直接把事务控制语句当普通 SQL 执行，可能绕开连接池和驱动对事务连接的管理，尤其在并发程序中更难保证状态一致。

Rollback 返回 ErrTxDone 需要记录成错误吗？

如果事务已经因为提交或 context 取消而结束，ErrTxDone 表示状态已完成，不应覆盖原始业务错误。真正的回滚失败则应保留，因为它可能说明驱动或连接状态需要进一步处理。

Begin 和 BeginTx 应该选哪个？

不需要传递取消和截止时间时可以使用 Begin；请求处理、后台任务或需要超时控制的代码通常使用 BeginTx，让事务生命周期与调用方 context 对齐。

总结

要让 Go database/sql 事务覆盖提前返回，核心只有三点：事务成功开始后立即建立默认回滚；所有事务内读写都使用 tx；只有无错误成功出口才调用 Commit。再加上 panic 分支和 BeginTx 的 context 语义，事务结束路径就能被清楚地列出来、检查和复用。