Go语言Gin框架中数据库事务在多协程下的正确使用-Golang-PHP中文网

db.transaction回调内禁止起goroutine，因*gorm.db绑定的sql.tx非并发安全，跨协程操作会触发事务已提交/回滚错误或丢数据；所有db操作须同步完成，异步任务需提取参数后在事务提交后再执行。

go语言gin框架中数据库事务在多协程下的正确使用

db.Transaction 回调里不能起 goroutine

事务对象 tx 不是并发安全的，一旦在 db.Transaction 的回调函数里启动 goroutine 并在里面调用 tx.Create 或其他 DB 操作，大概率触发 sql: Transaction has already been committed or rolled back，或者静默丢数据。

根本原因：GORM 的事务实例（*gorm.DB）底层绑定的是 sql.Tx，而 sql.Tx 明确不支持跨 goroutine 使用

典型错误写法：

db.Transaction(func(tx *gorm.DB) error {
    go func() {
        tx.Create(&Order{...}) // ❌ 危险！
    }()
    return nil
})

正确做法：所有 DB 操作必须在回调内同步完成；异步任务（如发消息、写日志）应提取参数后，在事务提交成功后再由外部协程处理

事务内禁止传递 context 跨协程使用

你在事务回调里拿到的 context.Context（比如从 gin.Context 提取的）一旦被传进 goroutine，就可能在事务结束、连接释放后还被访问，导致 context canceled 或 panic。

Gin框架 1.9.0

Gin框架 1.9.0版本源码包下载，版本号 1.9.0，适合需要 sonic JSON 支持、路由修复和内容协商改进的 Go Web 开发场景。

下载

gin.Context 是请求级生命周期，和事务生命周期不重合；事务结束 ≠ 请求结束，但 gin.Context 可能已被回收

不要这样写：

db.Transaction(func(tx *gorm.DB) error {
    ctx := c.Request.Context()
    go doAsync(ctx, tx) // ❌ ctx 和 tx 都不可靠
    return nil
})

如果真要异步，先拷贝必要数据（如用户 ID、订单号），再用干净的 context.Background() 启动 goroutine

嵌套事务不是真嵌套，Savepoint 名称冲突会报错

GORM 的 tx.Transaction（即嵌套调用）本质是 SAVEPOINT，不是独立事务。它依赖数据库驱动支持，且名称管理很脆弱。

PostgreSQL 和 MySQL 5.7+ 支持 SAVEPOINT，但 SQLite 默认关闭，需确认驱动配置启用
错误现象：ERROR: savepoint name already exists —— 多层嵌套时若未手动指定唯一 savepoint 名，GORM 默认用固定名 gorm_savepoint_1，重复调用就炸
避免方式：不用嵌套，把逻辑压平；非要嵌套，显式传入唯一名称：
```
tx.SavePoint("sp_order_create").Create(...)
```
关键认知：外层事务失败，所有 savepoint 自动失效；内层失败只回滚到 savepoint，但不会“隔离”错误——这不是 ACID 嵌套，只是回滚锚点