Go Web事务需手动控制，无自动回滚；必须在HTTP handler中显式Begin/Commit/Rollback，绑定单次请求，避免锁持有和连接池耗尽。
Go Web 中事务必须手动控制，没有自动回滚机制
Go 标准库 database/sql 不提供声明式事务（比如 Spring 的 @Transactional），所有事务都得显式调用 Begin()、Commit() 或 Rollback()。一旦出错没手动 Rollback()，连接会一直持有锁，甚至导致连接池耗尽。
HTTP handler 里开启事务的典型结构
事务生命周期应严格绑定到单次 HTTP 请求，不能跨请求复用 *sql.Tx。常见错误是把 tx 当成全局变量或塞进 context 后忘了清理。
- 在 handler 开头调用
db.Begin()，立即检查 error - 所有数据库操作改用
tx.Query/Exec/Prepare，而非db.Query/Exec - 成功时调用
tx.Commit()；任意环节 panic 或 error 都必须触发tx.Rollback() - 推荐用
defer+ 布尔标记避免重复Rollback()
func transferHandler(w http.ResponseWriter, r *http.Request) {
tx, err := db.Begin()
if err != nil {
http.Error(w, "tx begin failed", http.StatusInternalServerError)
return
}
defer func() {
if r := recover(); r != nil {
tx.Rollback()
panic(r)
}
}()
fromOK := updateBalance(tx, "alice", -100)
toOK := updateBalance(tx, "bob", +100)
if !fromOK || !toOK {
tx.Rollback()
http.Error(w, "balance update failed", http.StatusBadRequest)
return
}
if err := tx.Commit(); err != nil {
http.Error(w, "commit failed", http.StatusInternalServerError)
return
}
}
使用 sqlx 或 gorm 时事务写法差异
sqlx 是标准库增强，事务 API 与原生一致，只是多了 struct scan 支持；gorm 提供了 Session 和 Transaction 封装，但默认不自动 rollback——仍需显式处理。
-
sqlx：用tx := db.MustBegin()后，所有tx.Select/Get/Exec方法行为同原生 -
gorm：推荐用db.Transaction(func(tx *gorm.DB) error { ... })，它会在函数返回非 nil error 时自动Rollback() - 注意：
gorm.DB.WithContext(ctx).Transaction(...)中的ctx仅控制超时，不影响事务本身
并发请求下事务隔离级别与死锁风险
PostgreSQL/MySQL 默认隔离级别是 READ COMMITTED，但转账类场景常需 SELECT FOR UPDATE 加行锁。若两个请求按不同顺序更新同一组记录（如 A→B 和 B→A），极易触发死锁。
立即学习“go语言免费学习笔记（深入）”；
- 统一加锁顺序：例如总是按用户 ID 字典序先锁小 ID 再锁大 ID
- 避免在事务中做 HTTP 调用、文件读写等长耗时操作
- 设置
context.WithTimeout传给db.BeginTx，防止事务卡死 - MySQL 报错
ERROR 1213 (40001): Deadlock found when trying to get lock时，应用层需重试（最多 2–3 次）
真正难处理的不是语法，而是事务边界和锁粒度——一个 handler 里混着 Redis 更新、消息发送、DB 写入，就很难定义“原子性”。这时候得靠业务拆分或最终一致性补偿，而不是硬塞进一个 SQL 事务里。
