异步任务写入事务体将导致连接池耗尽、锁长期持有及TPS断崖下跌；根本原因是网络I/O不可控，破坏事务确定性。正确做法是事务仅做DB操作，通过tx.AfterCommit触发异步动作，并用独立context和本地消息表保障可靠性。
异步任务写进事务体就完蛋了
所有 HTTP 调用、缓存更新、日志上报、消息推送，一旦塞进 db.Transaction 函数体内，就等于把事务拖进不可控的 I/O 泥潭。MySQL 连接池会迅速耗尽，PostgreSQL 快照锁长期不释放，TPS 断崖下跌——这不是性能问题，是架构级错误。
根本原因：事务必须在确定性时间内结束，而网络请求、外部服务响应时间完全不可控。哪怕只加一行 http.Post()，整个事务就失去原子性和可预测性。
- ✅ 正确路径：事务只做 DB 写操作；成功后立刻触发异步动作
- ❌ 典型错误：
tx.Create(&order); http.Post(...); tx.Commit() - ⚠️ 隐蔽陷阱：在
AfterCreate钩子里发 HTTP 请求，钩子本身运行在事务上下文中，等同于把 I/O 拖进事务
用 tx.AfterCommit() 做事务后置通知
tx.AfterCommit() 是 GORM 提供的唯一安全出口，它只在 tx.Commit() 成功后执行，且脱离事务上下文，不占用连接、不延长锁持有时间。
但要注意：它绑定的是当前 tx 实例，不是全局 db；注册必须在 db.Transaction 函数体内完成，且不能跨 goroutine 传参错用。
- ✅ 安全写法：
tx.AfterCommit(func() { go sendNotification(order.ID) }) - ❌ 失效写法：
db.AfterCommit(...)（钩子注册在非事务对象上） - ⚠️ 性能坑：钩子函数内不能做耗时操作；
sendNotification必须是轻量启动，真正逻辑放进新 goroutine
野生 goroutine 会吃掉 context canceled
直接 go func() {}() 启动的异步任务，如果用了请求级 context.Context（比如 Gin 的 c.Request.Context()），HTTP 响应一返回，context 就被 cancel，goroutine 里任何带 context 的 DB 操作都会立即失败，报 context canceled。
这不是 GORM 的问题，是 Go context 生命周期管理的基本规则。
- ✅ 安全做法：传入带 timeout 的独立 context，例如
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) - ✅ 必须 defer cancel：避免 goroutine 泄漏，尤其在异常路径下
- ⚠️ 高危模式：用
db.WithContext(c.Request.Context())在异步 goroutine 中查库 —— 请求结束即失效
更稳的方案：本地消息表 + 定时补偿
当异步任务失败率高、需幂等重试、或下游服务 SLA 不可靠时，AfterCommit 就不够用了。此时应该把“要做的事”先落库，再由独立 worker 拉取执行。
本质是把异步动作从内存态转为持久化状态，用数据库保证不丢不重。
- ✅ 表结构示例：
outbox_events(id, topic, payload, status, created_at, processed_at) - ✅ 事务内写：
tx.Create(&OutboxEvent{Topic: "payment.success", Payload: data}) - ✅ 独立 worker：定时扫描
status = 'pending'记录，成功后UPDATE ... SET status = 'done' - ⚠️ 注意点：worker 必须用主库连接（不能走读写分离从库），且需处理重复消费
go 就完事，关键在 context 控制、执行边界隔离、失败兜底能力。最容易被忽略的是：AfterCommit 注册时机和 goroutine 生命周期管理，这两处出错，事务看似成功，实际业务动作已静默丢失。 
