Go database/sql 怎样理解事务提交时的 context 取消

Go 的 database/sql 里，Tx.Commit() 没有接收 context.Context 参数。事务使用哪个上下文，取决于创建它时调用的 DB.BeginTx(ctx, opts)。这个上下文在事务提交或回滚前一直有效；如果它被取消，database/sql 会回滚事务，而随后调用 Commit 会返回错误。

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

最稳妥的判断方式是：把取消视为事务已经不能正常提交的信号，所有 SQL 错误和 Commit 错误都进入失败路径，并用 defer tx.Rollback() 兜底清理。

先把 Commit 的“上下文”关系说清楚

很多代码把提交想象成 tx.Commit(ctx)，然后困惑“提交时取消应该传哪个 context”。实际上，Commit 的签名只有一个接收者，没有参数：

// Commit 只负责提交当前事务，不接收新的 context。
if err := tx.Commit(); err != nil {
    // 提交失败时必须把错误交给上层，不能当成普通清理信息丢掉。
    return fmt.Errorf("commit transaction: %w", err)
}

上下文在 BeginTx 时绑定。它控制的是从开始事务到事务结束这段生命周期，而不是只控制某一条 SQL。事务结束后，Tx 也就不能继续使用；官方文档说明，提交或回滚之后继续操作会得到 sql.ErrTxDone。

旧写法为什么容易误判提交结果

常见的简化写法只检查每次 ExecContext，看到更新没有报错就认为事务已经成功：

// 这个示例的问题是忽略了最后的提交错误。
tx, err := db.BeginTx(ctx, nil)
if err != nil {
    return err
}

// 使用同一个 ctx 执行事务中的 SQL，取消信号会沿着调用链传入。
if _, err := tx.ExecContext(ctx, "UPDATE accounts SET state = ? WHERE id = ?", "paid", id); err != nil {
    // 失败时主动回滚，避免把事务清理留给调用者猜测。
    _ = tx.Rollback()
    return err
}

// 不能因为前面的 ExecContext 成功，就省略对 Commit 错误的处理。
_ = tx.Commit()

问题在于，执行 SQL 成功只说明那条语句在当时完成了。事务的最终状态要由 Commit 决定；而 BeginTx 绑定的上下文一旦取消，标准库会尝试回滚，并规定 Commit 在该上下文取消时返回错误。因此“最后一条 SQL 没报错”不等于“事务已经提交”。

新规则：取消会推动事务进入回滚路径

可以把状态关系压缩成三条：

这里要注意一个工程边界：调用方能确定的是“本次 Commit 返回了错误，不能把结果记为成功”；但在网络抖动或驱动故障下，外部数据库是否已经收到提交请求，可能需要结合数据库和驱动的语义另行判断。不要仅凭客户端错误就编造一个确定的业务状态。

推荐模板：defer Rollback，最后只认 Commit

标准库文档示例采用了“先登记回滚、成功后提交”的结构。Rollback 在已经提交的事务上会被忽略或返回事务已结束相关错误，因此把它放在 defer 中不会覆盖成功提交：

func settleAccount(ctx context.Context, db *sql.DB, id int64) error {
    // BeginTx 使用 ctx 绑定整个事务生命周期，而不是只绑定第一条 SQL。
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("begin transaction: %w", err)
    }
    // Commit 成功后这里的 Rollback 只会做无效清理，不会撤销已提交结果。
    defer tx.Rollback()

    // 每条事务内 SQL 都显式使用 ctx，便于取消及时传到驱动。
    if _, err := tx.ExecContext(ctx,
        "UPDATE accounts SET state = ? WHERE id = ?", "paid", id); err != nil {
        return fmt.Errorf("update account: %w", err)
    }

    // Commit 没有 ctx 参数，但仍受 BeginTx 使用的 ctx 取消状态影响。
    if err := tx.Commit(); err != nil {
        return fmt.Errorf("commit transaction: %w", err)
    }
    return nil
}

这个模板有两个关键点。第一，defer Rollback 只负责兜底，不把它的错误当成主错误覆盖掉；第二，Commit 的错误必须返回，因为它是事务成功与否的最后一个判断点。若需要区分清理错误，可在已知业务错误存在时把回滚错误加入日志，而不是把回滚失败伪装成提交成功。

驱动交互：上下文不是只停留在 database/sql

当驱动实现 database/sql/driver.ConnBeginTx 时，标准库会把开始事务的上下文和 TxOptions 交给驱动。官方接口还规定：如果用户取消上下文，database/sql 会在丢弃并关闭连接前调用驱动事务的 Rollback。

// 这是驱动侧接口形状，用来说明 context 的传递边界。
type ConnBeginTx interface {
    // 驱动应检查隔离级别和只读选项，并尊重 ctx 的取消。
    BeginTx(ctx context.Context, opts driver.TxOptions) (driver.Tx, error)
}

// 业务侧仍然只能通过 database/sql 的 Tx.Commit 判断最终调用结果。
// 不应绕过 database/sql 自行保存一个“已提交”标志。

同时，事务中的查询和更新应优先使用 ExecContext、QueryContext 等带上下文的方法。驱动文档要求这些带上下文的接口在取消或超时后返回；但驱动能否在特定数据库协议上精确中止一条已经发出的命令，仍是驱动和数据库的实现问题，业务代码不要把它夸大成跨驱动一致的强保证。

兼容注意：别把 ErrTxDone 当成新的提交成功

事务一旦提交或回滚，后续对 Tx 的操作都会失败。于是下面这些现象要分开理解：

• ExecContext 返回 context.Canceled 或超时错误：先处理这次 SQL 失败，再让回滚兜底。
• Commit 返回错误：本次调用不能按成功记账，是否可安全重试要由业务幂等键和数据库事实决定。
• Rollback 返回 sql.ErrTxDone：通常表示事务已经结束，不能据此推断它是提交还是回滚；主流程应保留真正的前置错误。

尤其不要在 Commit 出错后立刻创建新事务重复扣款。提交阶段的网络错误可能让客户端无法获知服务器最终状态，重试前应有幂等约束、业务查询或人工补偿方案。

落地清单：事务提交时只检查这五件事

1. 事务是否由带有明确生命周期的 ctx 通过 BeginTx 创建。
2. 事务内是否统一使用带上下文的 SQL 方法。
3. 创建事务后是否立即登记 defer tx.Rollback()。
4. 是否只在 Commit 返回 nil 时把本地事务结果标为成功。
5. 提交错误是否进入可观测日志，并由幂等和补偿策略决定后续动作。

常见追问

Commit 能不能换一个新的 context？

不能。Tx.Commit 没有 context 参数；需要控制事务生命周期，应在 BeginTx 时选择合适的上下文，并在事务内的具体操作上使用带上下文的方法。

Commit 返回错误后还能继续 Rollback 吗？

可以把 Rollback 作为清理动作调用，但不要据此推断最终数据库状态。若事务已经被标准库或驱动结束，回滚可能只返回 sql.ErrTxDone；应保留并上报原始提交错误。

为什么要在提交成功后仍然 defer Rollback？

它覆盖了中途每个返回路径，减少遗漏清理的机会。提交成功后事务已经结束，延迟回滚不会撤销已提交的数据。

context 取消后可以自动重试整个事务吗？

只有在业务操作具备幂等语义并且能接受取消原因时才考虑重试。事务提交阶段的错误可能无法证明服务器端没有提交，不能把“客户端收到错误”简单等同于“数据库一定没有变化”。

把 BeginTx 的上下文、事务内的上下文操作和最后的 Commit 当成同一条生命周期链，基本就不会再把提交时的取消误解成一个需要额外传参的 API 问题。