sqlTx封装可回滚事务

在 Go 中，多个写操作需要“要么全部成功、要么全部撤销”时，应该把它们放进同一个 *sql.Tx，而不是分别调用 *sql.DB。一个实用的封装是：用 BeginTx 开始事务，先登记 Rollback 兜底，再把事务对象交给回调，回调成功后才调用 Commit。

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

事务封装的关键不是把几行 SQL 包进函数，而是固定“开始、业务操作、失败回滚、成功提交”这条边界；回调内部不要再绕回 sql.DB。

• 事务入口使用 db.BeginTx(ctx, opts)，让取消信号能够传到数据库操作。
• 业务回调只接收 *sql.Tx，所有读写使用 ExecContext、QueryContext 等 Tx 方法。
• 先 defer tx.Rollback()，成功提交后它会变成无操作；失败路径则自动回滚。
• Commit 返回错误时不能继续把业务结果当成已落库。

先把事务边界放在一个函数里

database/sql 的事务由 Begin 或 BeginTx 创建，并且必须以 Commit 或 Rollback 结束。封装时，最稳定的边界是“一个回调对应一个事务”：调用方负责描述业务，辅助函数负责生命周期。

下面的关系图是静态说明图，重点看请求上下文、事务对象、业务回调和提交/回滚边界之间的归属关系。

用 WithTx 统一提交和回滚

辅助函数可以把业务错误原样返回，让调用方继续决定错误码或日志内容。defer 中的回滚不需要判断错误：如果已经提交，驱动会让这次回滚成为无效操作；如果回调返回错误或函数提前退出，它就是最后一道兜底。

package store

import (
    "context"
    "database/sql"
    "fmt"
)

// WithTx 让一个业务回调在同一个事务中完成，并统一处理生命周期。
func WithTx(ctx context.Context, db *sql.DB, opts *sql.TxOptions, fn func(*sql.Tx) error) error {
    // BeginTx 绑定调用方上下文，取消请求时数据库可以结束事务。
    tx, err := db.BeginTx(ctx, opts)
    if err != nil {
        return fmt.Errorf("begin transaction: %w", err)
    }

    // 业务出错或中途返回时回滚；提交成功后这次调用是无操作。
    defer func() { _ = tx.Rollback() }()

    // 回调只能拿到 Tx，避免误用 db 把 SQL 执行到事务之外。
    if err := fn(tx); err != nil {
        return fmt.Errorf("transaction body: %w", err)
    }

    // Commit 失败时不能把结果当成已经持久化。
    if err := tx.Commit(); err != nil {
        return fmt.Errorf("commit transaction: %w", err)
    }
    return nil
}

这个实现刻意没有吞掉业务错误，也没有在回调里调用 db.ExecContext。如果事务中混入 db 方法，那条语句可能使用连接池中的另一条连接，读到不一致的状态，甚至在连接资源紧张时形成等待。

在回调里完成一组原子写入

以“扣减库存并创建订单”为例，两个动作必须共享同一事务。下面的代码只展示封装的使用方式；实际项目还应根据数据库方言调整占位符，并通过数据库约束防止库存变成负数。

func (s *Store) CreateOrder(ctx context.Context, albumID, customerID int64) error {
    return WithTx(ctx, s.db, nil, func(tx *sql.Tx) error {
        // 读取与写入都走 Tx，保证它们属于同一个事务边界。
        var stock int
        if err := tx.QueryRowContext(ctx,
            "SELECT stock FROM albums WHERE id = ? FOR UPDATE", albumID,
        ).Scan(&stock); err != nil {
            return fmt.Errorf("read stock: %w", err)
        }
        if stock 

当查询、扣减或插入任意一步返回错误时，fn 返回错误，WithTx 不会调用提交。只有回调返回 nil 且 Commit 也成功，订单和库存变化才作为一次原子变更生效。

业务错误、提交错误和上下文取消要分开看

BeginTx 的上下文会影响事务直到提交或回滚；上下文取消时，database/sql 会尝试回滚，提交也可能返回错误。因此超时设置应覆盖整个数据库工作，而不是只包住第一条 SQL。

如果业务需要指定隔离级别，可以传入 sql.TxOptions，例如 Isolation: sql.LevelSerializable。但隔离级别是否受支持取决于驱动和数据库，不能只凭 Go 代码保证效果。

封装时最容易踩的几个坑

• 把 defer tx.Rollback() 去掉，只在部分分支手写回滚，容易漏掉新加的返回路径。
• 在事务回调里调用外部 HTTP、消息队列或长时间计算，让数据库连接被长时间占用。
• 把 Commit 错误记录后仍返回成功。提交结果不确定时，应按项目的幂等和补偿策略处理。
• 把所有错误都改成一个固定字符串，导致调用方无法用 errors.Is 或 errors.As 判断根因。

落地时可以按这个顺序检查：事务边界是否覆盖完整业务、回调是否只使用 Tx、每条操作是否带 context、回调返回错误时是否能回滚、提交错误是否会被上层看见，以及隔离级别是否得到数据库驱动支持。

常见问题

为什么提交后还要 defer Rollback？

这是兜底写法，避免新增返回路径忘记回滚。提交成功后事务已经结束，后续 Rollback 不会撤销已提交的数据。

可以在 WithTx 的回调里继续使用 sql.DB 查询吗？

不建议。这样查询可能走另一条连接，不属于当前事务；需要读写事务状态时统一使用回调收到的 *sql.Tx。

Commit 返回错误一定代表数据库没有写入吗？

不能简单这样判断。Go 文档要求把提交失败后的查询结果和更新视为无效，实际重试还要结合数据库和驱动的幂等策略，不能盲目重复提交。

总结：用 BeginTx 建立边界，用回调限制操作对象，用延迟 Rollback 覆盖失败路径，再把 Commit 错误向上返回，就能把可回滚事务封装成稳定的业务组件。真正需要额外设计的，是隔离级别、超时范围、外部副作用和提交失败后的幂等处理。