Go语言事务处理详解

Go语言事务的核心陷阱在于“看似开启实则失效”——所有数据库操作必须严格绑定同一*sql.Tx实例，混用db.Exec()或GORM的db.Create()会立即脱离事务并提交，而真正的事务控制力取决于连接归属、上下文超时与SQL执行的解耦、Savepoint的手动SQL实现，以及优先选用db.Transaction()这类panic安全的自动管理方式；理解这些边界条件，远比记住Begin()语法更能避免生产环境中的数据一致性灾难。

Go 语言事务不是“开了就自动生效”，关键在操作是否绑定到同一个 *sql.Tx 实例上。用 db.Begin() 或 db.BeginTx() 启动事务后，所有 SQL 执行必须调用 tx.Query()、tx.Exec() 等方法；一旦混用 db.Exec()，语句就脱离事务、立即提交。

为什么 db.Exec() 在事务里不生效

事务对象 *sql.Tx 和数据库句柄 *sql.DB 是两个独立实例。*sql.Tx 内部持有一个独占的底层连接，而 *sql.DB 操作走连接池，每次调用都可能分配新连接。

• db.Exec() 绕过事务连接，直接从连接池取空闲连接执行，语句自动提交，无法回滚
• 哪怕你刚调完 tx.Exec()，下一行写 db.QueryRow()，这条查询也不在事务中
• GORM 中同理：db.Create() ≠ tx.Create()，后者才是事务内操作

BeginTx 传 context 超时但 SQL 还在跑

context.WithTimeout 只控制 BeginTx 阻塞等待连接的时长，不影响已发出的 tx.Exec()。事务开启成功后，SQL 执行是否中断，完全由数据库侧决定。

• PostgreSQL：需在 DSN 或会话级设置 statement_timeout（单位 ms）
• MySQL：用 SET SESSION max_execution_time = 5000，或在 DSN 加 timeout=5s（驱动支持）
• tx.Rollback() 不会中止正在运行的 SQL，只标记后续操作无效；真正释放连接要等语句自然结束 + 连接池回收

Savepoint 必须手写 SQL

database/sql 标准库不提供 Savepoint 接口，所有保存点操作都得用原生 SQL 字符串手动执行。

• 创建：tx.Exec("SAVEPOINT sp_123")
• 回滚到：tx.Exec("ROLLBACK TO SAVEPOINT sp_123")
• 释放：tx.Exec("RELEASE SAVEPOINT sp_123")
• 名字别重复——建议用 uuid.NewString() 或带业务前缀的字符串（如 "order_create_sp"）
• 注意 MySQL 5.7 不支持命名 savepoint，只认 SAVEPOINT a 这种单字母名

GORM 中 Transaction 闭包 vs Begin 的选择

95% 的业务场景该用 db.Transaction()，而不是裸调 db.Begin()。前者是 panic 安全、自动 commit/rollback 的封装；后者是底层原语，容易漏处理。

• db.Transaction(func(tx *gorm.DB) error { ... })：闭包返回非 nil error 自动 rollback，panic 也会被捕获并 rollback
• tx := db.Begin()：必须自己写 defer tx.Rollback() + 显式 tx.Commit()，漏写就卡死连接
• 嵌套“事务”本质是 savepoint：用 tx.Session(&gorm.Session{AllowGlobalUpdate: true}).Begin()，不是新开事务
• 别在 Transaction 闭包里再调一次 db.Transaction()——它会新建事务，破坏外层一致性

事务真正的复杂点不在语法，而在执行路径是否全程受控：任何一次误用 db.Xxx()、跨 goroutine 复用 tx、忘记释放 savepoint 名字，都会让事务语义失效。边界清晰比写对第一行 Begin() 更难也更重要。

以上就是《Go语言事务处理详解》的详细内容，更多关于的资料请关注golang学习网公众号！