事务对象 tx *gorm.DB 不可并发共享，只能通过函数参数显式传递；每个 goroutine 应独立开启事务（如 db.Transaction()），禁止存入全局变量、context.Value 或跨协程使用，否则引发数据竞争与 panic。
并发中事务上下文不能“共享”，只能“传递”
事务对象 tx *gorm.DB 本身不是全局可共享的资源，它绑定着当前 goroutine 的连接、隔离级别和状态。多个 goroutine 同时操作同一个 tx 实例会导致数据竞争、连接复用错乱，甚至 panic：“invalid transaction”。GORM 的事务不是 context.Context 那种线程安全的只读传播载体，而是一个带状态的、有生命周期的句柄。
常见错误是：在主 goroutine 创建 tx := db.Begin() 后，把它塞进全局变量、结构体字段或 context.WithValue()，再被其他 goroutine 取出调用 tx.Create()——这等于让 10 个协程共用 1 条数据库连接+1 个事务上下文，必然崩溃。
- ✅ 正确做法：每个需要事务逻辑的 goroutine，必须自己从原始
db *gorm.DB开启独立事务（如db.Transaction()），或由上游显式传入专属tx - ❌ 禁止把
tx存到包级变量、sync.Map或结构体里供并发读写 - ⚠️ 即使加了
sync.Mutex锁住tx，也无法解决连接归属混乱问题；GORM 内部不保证锁住后调用的安全性
跨 goroutine 传递事务必须用参数，不能靠 context.Value
context.Context 是并发安全的，但它的 Value() 方法只适合传只读元数据（如 traceID、userID），**不适合传事务句柄**。GORM 官方文档和源码都明确反对这种用法：事务对象含可变状态、非线程安全，且生命周期与 context 不对齐（context 可能超时取消，但 tx 还没 Commit）。
典型反模式：ctx = context.WithValue(parentCtx, txKey, tx) → 在子 goroutine 中 tx := ctx.Value(txKey).(*gorm.DB) → 调用 tx.Save()。
- ✅ 推荐方式：函数签名显式接收
tx *gorm.DB，例如func ProcessOrder(ctx context.Context, tx *gorm.DB, orderID uint) error - ✅ 若需多层调用（service → repo），保持
tx沿调用链向下透传，不包装、不缓存、不转换类型 - ⚠️ 如果硬要用
context.WithValue，务必确保：仅限单 goroutine 内使用；调用前检查tx != nil；绝不跨 goroutine 读取该值
db.Transaction() 是并发安全的入口，但别在它里面 spawn goroutine
db.Transaction() 回调函数内部是事务作用域，但它本身运行在调用它的 goroutine 中。如果在里面直接 go 启动新 goroutine 并传入 tx，就回到了上一节的问题——tx 被并发访问。
比如：在下单事务里并发校验库存、发通知、写日志，若都用同一个 tx，会破坏事务边界；若各自开新事务，又失去原子性。
- ✅ 安全方案：所有需事务保护的操作，必须同步执行在
db.Transaction()回调内，不离开该闭包 - ✅ 替代方案：把非关键路径（如发消息、打日志）移出事务，用最终一致性（如本地消息表 + 异步消费者）
- ⚠️ 禁止在回调里写
go func() { tx.Create(&log) }()—— 这是高危行为，Go runtime 无法保证执行时机，tx 可能在 goroutine 运行前已 Commit 或 Rollback
真正需要“并发事务”的场景，得靠业务拆分或 SavePoint
有些业务看似要“并发执行事务”，比如批量创建订单并扣减对应库存。这不是靠一个事务撑住所有操作，而是靠设计：要么拆成多个独立事务（每单一个 db.Transaction()），要么在单事务内用 tx.SavePoint() 做局部回滚。
例如：处理 100 个订单请求，若第 50 个失败，你可能只想回滚它，而非整个批次。这时用 tx.SavePoint("sp_50") + tx.RollbackTo("sp_50") 是唯一合法方式，它不开启新事务，只是在当前事务内设锚点。
- ✅ 多订单并发处理：启动 100 个 goroutine，每个调用独立
db.Transaction()，互不影响 - ✅ 单事务内局部控制：用
SavePoint+RollbackTo，但注意它不解决并发，只解决嵌套失败回滚粒度 - ⚠️ 别幻想 “并发事务合并提交”——SQL 层面不存在这种机制；ACID 是单事务属性，不是多事务聚合属性
最易被忽略的一点：事务对象的生命周期完全由调用方控制，GORM 不做任何自动回收。一旦你把 tx 传给另一个 goroutine，就等于把责任交给了它——那个 goroutine 必须确保调用 Commit() 或 Rollback()，否则连接永远卡在事务中，连接池迟早耗尽。
