Go 中 sql.Tx 不是 goroutine 安全的，必须单协程串行操作；多协程需共享只读查询、主协程统一提交写操作，并用 context 控制超时，高并发下优先最终一致性。
Go 中 sql.Tx 不是 goroutine 安全的，不能跨协程复用
这是最常踩的坑：很多人把同一个 *sql.Tx 对象传给多个 goroutine，然后并发调用 tx.Query、tx.Exec，结果出现 sql: Transaction has already been committed or rolled back 或随机 panic。根本原因是 sql.Tx 内部使用了非线程安全的状态机（比如标记是否已提交），且底层连接被独占——它只允许单个 goroutine 串行操作。
正确做法是：每个需要事务的 goroutine 必须独立开启自己的 *sql.Tx，或改用无事务的 *sql.DB 操作（如果业务允许）。若需协调多个写入，应由主 goroutine 统一控制事务生命周期。
- ❌ 错误示例：在 goroutine 中直接复用外部
tx - ✅ 正确思路：把事务逻辑封装成函数，在主 goroutine 中按需调用；或让每个子任务自行
db.Begin()+defer tx.Rollback() - ⚠️ 注意：频繁
Begin()+Commit()会增加数据库连接压力，需配合连接池调优（如db.SetMaxOpenConns）
用 sync.WaitGroup + 主事务控制多步骤原子性
当多个数据库操作必须“全成功或全失败”，但又涉及不同表/逻辑分支时，不能靠多个独立事务模拟。此时应放弃“并发执行事务”，转为“并发准备数据 + 主事务串行提交”。即：用 goroutine 并发计算/校验/查询，但所有 INSERT/UPDATE 都在同一个 *sql.Tx 中执行。
func processOrder(db *sql.DB, orderID int) error {
tx, err := db.Begin()
if err != nil {
return err
}
defer tx.Rollback()
var wg sync.WaitGroup
var mu sync.Mutex
var firstErr error
// 并发校验库存（只读）
wg.Add(2)
go func() {
defer wg.Done()
if err := checkStock(tx, "product_a"); err != nil {
mu.Lock()
if firstErr == nil {
firstErr = err
}
mu.Unlock()
}
}()
go func() {
defer wg.Done()
if err := checkStock(tx, "product_b"); err != nil {
mu.Lock()
if firstErr == nil {
firstErr = err
}
mu.Unlock()
}
}()
wg.Wait()
if firstErr != nil {
return firstErr
}
// 串行执行写操作（必须在主 goroutine）
if _, err := tx.Exec("INSERT INTO orders ..."); err != nil {
return err
}
if _, err := tx.Exec("UPDATE inventory ..."); err != nil {
return err
}
return tx.Commit()
}
使用 context.WithTimeout 防止事务 goroutine 卡死
事务一旦开启，就占着数据库连接；若某个 goroutine 因网络延迟、死锁或逻辑阻塞没及时完成，整个事务会一直挂起，最终拖垮连接池。必须对事务整体加超时控制，而不是只给单条 SQL 加。
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout(ctx, 5*time.Second)创建带超时的 context - 传给
db.BeginTx(ctx, nil)，这样底层驱动可在超时后主动中断事务初始化 - 注意：MySQL 的
innodb_lock_wait_timeout和 PostgreSQL 的lock_timeout是服务端参数，Go 层的 context 超时是客户端兜底，两者要配合设置 - 避免在事务中调用无 timeout 的 HTTP 请求或文件 IO —— 这些操作应前置到事务外
高并发下慎用事务，优先考虑最终一致性
真实场景中，强行用强一致事务扛高并发（比如秒杀扣库存），往往导致大量锁等待、死锁重试、连接耗尽。Go 的 goroutine 轻量，但数据库连接和锁资源并不轻量。
更可行的路径是：用 Redis 做预减库存（原子操作）、消息队列异步落库、数据库层面用乐观锁（WHERE version = ?）或补偿事务。Go 代码里只需保证单次 DB 操作的正确性，而非整个业务流程的 ACID。
例如：用户下单时先 redis.Decr("stock:123")，成功后再发 MQ 消息；消费端用普通 db.Exec 更新订单和库存，失败则重试或告警。这样既释放了数据库压力，又避免了 goroutine 和事务的耦合陷阱。
