如何在 Go 中利用 context 管理数据库事务-Golang-PHP中文网

BeginTx(ctx, opts) 是唯一安全的事务起点，ctx 在此绑定并控制整个事务生命周期；后续 tx.Exec/Query 等方法隐式复用该 ctx，不接受额外 context 参数。

如何在 go 中利用 context 管理数据库事务

context 传入 `BeginTx` 是唯一安全的起点

Go 的 database/sql 本身不直接支持 context 透传到事务开启阶段，但标准库从 Go 1.8 起为 DB.BeginTx 提供了 context.Context 参数。这意味着你**必须**用 BeginTx 而非 Begin，否则后续所有操作都脱离 context 控制，超时或取消将完全失效。

常见错误是先调 Begin() 再想“后面加 context”，这毫无意义——事务句柄 *sql.Tx 本身不携带 context，它的所有方法（Exec、Query 等）也都不接受 context。

BeginTx(ctx, &sql.TxOptions{}) 是唯一入口，ctx 在此处即绑定到事务生命周期
若 ctx 已取消，BeginTx 会立即返回 error，不会创建无效事务
传入的 sql.TxOptions 可设 Isolation 和 ReadOnly，但不影响 context 行为

事务内所有 DB 操作必须用 `*sql.Tx` 方法，且不额外传 context

*sql.Tx 的 Exec、Query、QueryRow 等方法签名里**没有 context 参数**——它们隐式复用 BeginTx 时绑定的 context。这是易混淆点：有人试图写 tx.QueryContext(ctx, ...)，但该方法不存在；正确做法就是直接调 tx.Query(...)。

注意：这些方法内部会检查绑定的 context 是否已取消，并在必要时中断执行（如网络等待中收到 cancel）。但前提是事务确实由 BeginTx 创建。

✅ 正确：tx.Query("SELECT ...") —— 自动响应原始 ctx 状态
❌ 错误：db.QueryContext(ctx, "...") —— 这走的是普通连接池，和事务无关
⚠️ 隐患：若在事务中混用 db 实例（如日志写入单独 db 查询），那些操作不受事务 ctx 约束

手动 rollback/commit 不影响 context 生命周期，但需防 panic 中断

调用 tx.Commit() 或 tx.Rollback() 只是释放资源，不会主动触发 context 取消（context 取消是单向的，不可逆）。真正关键的是：**必须确保无论成功或失败，都执行其中一者**，否则连接泄漏，且 context 绑定的超时逻辑可能被绕过。

使用Go语言搭建家庭相册系统-相关课件

下载

最稳妥模式是用 defer + panic 恢复，避免因中间 panic 导致 rollback 被跳过：

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

tx, err := db.BeginTx(ctx, nil)
if err != nil {
    return err
}
defer func() {
    if r := recover(); r != nil {
        tx.Rollback()
        panic(r)
    }
}()

// 执行业务 SQL
_, err = tx.Exec("INSERT ...")
if err != nil {
    tx.Rollback()
    return err
}

return tx.Commit()

panic 时 defer 仍会执行，但需显式恢复并 rollback，否则 panic 向上传播前 tx 未关闭
不要依赖 defer tx.Rollback() 无条件执行——它会在 commit 成功后错误回滚
context 超时后，tx.Commit() 或 tx.Rollback() 可能返回 "sql: transaction has already been committed or rolled back"，属正常现象