BeginTx(ctx, opts) 是唯一安全的事务起点，ctx 在此绑定并控制整个事务生命周期；后续 tx.Exec/Query 等方法隐式复用该 ctx，不接受额外 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 绑定的超时逻辑可能被绕过。
最稳妥模式是用 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"，属正常现象
嵌套事务或跨函数传递时，只传 *sql.Tx，别传 context
事务上下文已固化在 *sql.Tx 内部，函数之间只需传递该指针。额外传 context 不仅冗余，还可能引入不一致：比如外层用 5s timeout，内层函数又用另一个 10s ctx 调 BeginTx，就破坏了统一控制。
典型场景是 service 层拆分逻辑：
- ✅ 推荐：主函数开事务 → 传
tx给createUser(tx, ...)和sendNotification(tx, ...) - ❌ 危险：每个子函数自己调
BeginTx—— 这实际是多个独立事务，无法原子性保证 - ⚠️ 注意：子函数若需独立超时控制（如发通知允许更长等待），应改用非事务的
db实例，而非另起事务
context 的 cancel 或 timeout 信号对整个事务链是全局生效的，不需要、也不应该在各层重复注入。
