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），极易触发死锁。

• 统一加锁顺序：例如总是按用户 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 事务里。