Go sql.DB.BeginTx 的上下文取消后事务会怎样

传给 sql.DB.BeginTx 的 context.Context 不只控制“开始事务”这一刻，而是一直管理事务，直到 Commit 或 Rollback。如果这个 context 被取消或超时，database/sql 会回滚事务；之后调用 Tx.Commit 会返回错误，业务代码不能把它当成提交成功。

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

BeginTx 的 context 管整个事务生命周期

官方文档对 DB.BeginTx 的语义写得很明确：传入的 context 会一直使用到事务提交或回滚；如果 context 被取消，sql 包会回滚事务，Tx.Commit 也会返回错误。这和只在函数入口检查一次 ctx.Err() 完全不同。

Tx 还会绑定一条底层连接。事务正常 Commit 或 Rollback 后，这条连接才会返回连接池。取消触发的自动回滚不仅是业务状态保护，也是资源释放机制的一部分。

最小安全写法是先 defer Rollback

事务函数应只有一个成功出口：所有语句都成功后调用 Commit。其他路径统一返回错误，由延迟的 Rollback 做兜底。Commit 成功后，延迟 Rollback 会发现事务已经结束；这也是 Go 官方示例采用的结构。

func transfer(ctx context.Context, db *sql.DB, fromID, toID int64, amount int64) error {
	// 给整个事务设置上限；超时后 sql 包会回滚尚未结束的事务。
	txCtx, cancel := context.WithTimeout(ctx, 3*time.Second)
	defer cancel()

	tx, err := db.BeginTx(txCtx, &sql.TxOptions{Isolation: sql.LevelSerializable})
	if err != nil {
		return fmt.Errorf("begin transaction: %w", err)
	}

	// 覆盖所有提前返回路径；Commit 成功后再次 Rollback 只会得到 ErrTxDone。
	defer func() { _ = tx.Rollback() }()

	// 使用事务 context 执行扣款，取消会传递到支持取消的驱动。
	result, err := tx.ExecContext(txCtx,
		"UPDATE accounts SET balance = balance - ? WHERE id = ? AND balance >= ?",
		amount, fromID, amount,
	)
	if err != nil {
		return fmt.Errorf("debit account: %w", err)
	}

	// 检查受影响行数，避免余额不足时继续执行入账。
	rows, err := result.RowsAffected()
	if err != nil {
		return fmt.Errorf("read debit result: %w", err)
	}
	if rows != 1 {
		return fmt.Errorf("debit rejected: account missing or balance insufficient")
	}

	// 只有前一步成功，才在同一事务中执行入账。
	if _, err := tx.ExecContext(txCtx,
		"UPDATE accounts SET balance = balance + ? WHERE id = ?",
		amount, toID,
	); err != nil {
		return fmt.Errorf("credit account: %w", err)
	}

	// Commit 错误必须向上传递，不能记录为转账成功。
	if err := tx.Commit(); err != nil {
		return fmt.Errorf("commit transaction: %w", err)
	}
	return nil
}

这段写法的重点不是 SQL 本身，而是资源边界：tx 一旦创建成功，就立刻安装回滚兜底；每个错误都终止当前事务；只有最后的 Commit 成功，函数才返回 nil。

事务上下文和语句上下文不要混为一谈

自动回滚保证针对的是传给 BeginTx 的 context。单条 Tx.ExecContext、Tx.QueryContext 还可以接收自己的 context，用来限制某一条语句，但它们和事务 context 不是同一个责任层。

例如，事务允许持续 5 秒，其中一条慢查询只允许 500 毫秒。语句 context 超时后，这条语句会返回错误；此时不要继续执行下一条 SQL，也不要假设事务一定已经被自动回滚。最稳妥的处理是返回错误，让预先安装的 defer tx.Rollback() 结束事务。

tx, err := db.BeginTx(txCtx, nil)
if err != nil {
	return fmt.Errorf("begin transaction: %w", err)
}

// 无论单条语句在哪里失败，都由统一回滚路径结束事务。
defer func() { _ = tx.Rollback() }()

// 子 context 只限制这条语句，不替代 BeginTx 的事务 context。
stmtCtx, cancelStmt := context.WithTimeout(txCtx, 500*time.Millisecond)
defer cancelStmt()

if _, err := tx.ExecContext(stmtCtx, "UPDATE jobs SET state = ? WHERE id = ?", "done", jobID); err != nil {
	// 语句取消后直接返回，避免在不确定状态下继续复用事务。
	return fmt.Errorf("update job: %w", err)
}

// 只有语句成功才尝试提交，并把提交错误返回给调用方。
if err := tx.Commit(); err != nil {
	return fmt.Errorf("commit transaction: %w", err)
}
return nil

还要注意驱动能力。database/sql 文档说明，不支持 context 取消的驱动可能要等查询实际完成后才返回。因此 context 超时不代表所有数据库和驱动都能在同一瞬间停止服务端工作；事务代码仍应设置数据库侧超时、限制锁等待，并根据所用驱动的文档确认行为。

根据错误位置判断事务结果

排查时先记录失败阶段，而不是只记录一条“事务失败”。建议至少保存 begin、statement、commit 三种阶段，再记录 ctx.Err() 和原始错误链。

if err := tx.Commit(); err != nil {
	// context.Canceled 或 DeadlineExceeded 能说明事务上下文已结束。
	if ctxErr := txCtx.Err(); ctxErr != nil {
		return fmt.Errorf("commit after context ended (%v): %w", ctxErr, err)
	}

	// 非 context 提交错误也不能当成成功，需要按业务幂等策略复查。
	return fmt.Errorf("commit failed: %w", err)
}

sql.ErrTxDone 只说明事务已经提交或回滚，不能单独证明是哪一种结果。尤其在 context 取消后，自动回滚和调用方后续操作可能相邻发生；业务判断应以 BeginTx context、原始错误和最终 Commit 返回值为准。

取消后的重试要先考虑幂等性

如果 context 在事务中途取消，按文档该事务会回滚，通常可以由上层决定是否重试。但不要把“可以重试”写成无条件循环。转账、订单创建、消息投递等操作还可能涉及事务外系统；应使用业务唯一键、幂等令牌或状态查询，避免数据库事务回滚了，外部副作用却被重复执行。

对于 Commit 的非 context 错误，更不能直接重放整段业务。连接中断时，调用方可能无法仅凭错误判断数据库端最终状态，应该先查询业务唯一记录或让上层幂等机制裁决。

常见问题

context 取消后还需要手动 Rollback 吗？

database/sql 会回滚使用该 BeginTx context 创建的事务，但代码仍建议在 BeginTx 成功后立即 defer tx.Rollback()。它统一覆盖普通错误、语句子 context 失败和未来新增的提前返回路径。

Commit 返回 ErrTxDone 能说明事务已经回滚吗？

不能只靠 ErrTxDone 区分提交还是回滚。它表示事务已经结束；应结合 BeginTx context 是否取消、前序错误和 Commit 的实际返回值判断。

Begin 和 BeginTx 有什么差别？

DB.Begin 内部使用 context.Background；需要让请求取消或超时控制事务生命周期时，应使用 DB.BeginTx 并传入明确的 context。

语句 context 超时会自动结束整个事务吗？

不要依赖这种假设。BeginTx context 才有文档明确的自动回滚保证。单条语句 context 返回错误后，应停止继续操作，并通过统一的 Rollback 路径结束事务。

所以，sql.DB.BeginTx 的 context 取消后，正确理解是“事务生命周期已经被终止，sql 包负责回滚，Commit 必须失败”，而不是“这条 SQL 超时了但事务还能继续”。只要把事务 context、语句 context、统一回滚和 Commit 错误四个边界分清，取消场景就不会再留下悬空事务或错误的成功状态。