context.WithTimeout启动事务后必须手动回滚，因db.BeginTx的ctx仅控制开启事务耗时，不管理事务生命周期；需在Commit前检查ctx.Err()并显式Rollback，或用goroutine监听ctx.Done()安全触发回滚。
context.WithTimeout 启动事务后必须手动回滚
Go 的 database/sql 本身不感知 context.Context，即使你传了带超时的 ctx 给 db.BeginTx，事务也不会自动回滚——超时只影响“开启事务”这一步，后续 tx.Query、tx.Exec 等操作仍会阻塞或成功，除非你自己检查 ctx.Err() 并调用 tx.Rollback()。
常见错误现象：context deadline exceeded 报错后程序继续执行，最终 tx.Commit() 成功，导致脏数据写入。
- 务必在所有数据库操作后、
Commit()前检查ctx.Err() != nil - 推荐把事务逻辑封装进函数，用
defer+ 显式判断做兜底回滚 -
db.BeginTx(ctx, &sql.TxOptions{})中的ctx仅控制BeginTx自身耗时，不是事务生命周期上下文
用 defer + ctx.Done() 监听超时并触发 Rollback
最稳妥的做法是在 BeginTx 后立刻起一个 goroutine 监听 ctx.Done()，一旦触发就尝试 Rollback()。但要注意：多个并发调用 Rollback() 是安全的（sql.Tx 内部有状态保护），但必须避免对已 Commit() 或已 Rollback() 的事务重复操作。
使用场景：长事务（如批处理、跨服务协调）、外部依赖响应不可控（如调用下游 HTTP 接口后再更新 DB）。
立即学习“go语言免费学习笔记（深入）”；
- 不要直接在
defer tx.Rollback()里不做判断——这会导致正常提交也被回滚 - 监听
ctx.Done()时，用select { case 避免阻塞 - 如果事务中调用了可能阻塞的外部 I/O（如 HTTP、RPC），它们也得接受同一
ctx，否则超时逻辑形同虚设
tx, err := db.BeginTx(ctx, nil)
if err != nil {
return err
}
defer func() {
if ctx.Err() != nil {
tx.Rollback()
}
}()
// ... 执行查询/更新
if err := tx.Commit(); err != nil {
return err
}
sql.Tx 不支持 Cancel，别指望 QueryContext 自动中断事务
*sql.Tx 上的 QueryContext、ExecContext 确实会响应 ctx 超时并返回 context.DeadlineExceeded，但这只是中断当前语句，**不会终止整个事务**，也不会自动回滚。事务仍处于 open 状态，后续还能继续执行其他操作，直到你显式 Commit() 或 Rollback()。
性能影响：频繁用短超时 context 调用 QueryContext 可能导致连接池中连接被长时间占用（尤其 MySQL 默认不支持真正的 query cancel），建议配合连接级 timeout（如 readTimeout DSN 参数）使用。
- MySQL 驱动（
go-sql-driver/mysql）需开启clientFoundRows=true和高版本才较可靠支持QueryContext中断 - PostgreSQL 驱动（
lib/pq或pgx）对QueryContext支持更好，但仍不等于事务级 cancel - 永远不要假设 “一次 QueryContext 失败 = 事务已失效”，它只是单条语句失败
嵌套事务或 Savepoint 场景下 Context 超时更难处理
Go 标准库不支持 savepoint，若用第三方驱动（如 pgx）手动建 savepoint，context 超时后 rollback 到 savepoint 依然要自己判断和调用，且 ctx.Err() 发生时机可能在 savepoint 创建之后、释放之前，容易漏掉清理。
容易踩的坑：在事务内启新 goroutine 并传入子 context，但父 ctx 超时后子 goroutine 仍在跑，造成资源泄漏或重复写库。
- 子 goroutine 必须监听同一个事务生命周期的
ctx，而不是新建WithTimeout - savepoint 名称要用唯一变量（如
fmt.Sprintf("sp_%d", time.Now().UnixNano())），避免并发冲突 - rollback 到 savepoint 后，仍需确保后续不再调用
Commit()，否则会提交 savepoint 之后的部分变更
