db.transaction不报错因默认不校验函数返回值或panic，未commit又未rollback时事务静默丢弃；aftercommit钩子仅在commit成功后触发且绑定原始tx；嵌套事务实为savepoint模拟，需统一api并检查错误；http调用应移出事务外并用独立context。
事务没提交但程序退出了，db.Transaction 为什么没报错？
因为 db.Transaction 默认只负责执行传入的函数，不自动校验返回值或 panic 状态。如果函数里忘了 tx.Commit()，又没显式 tx.Rollback()，连接池归还时事务就静默丢弃了——既不报错，也不回滚，数据状态残留。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须用
defer tx.Rollback()开头兜底，再在成功路径上显式tx.Commit() - 避免在事务函数里直接
return，改用命名返回值或统一出口 - 检查
tx.Commit()的返回值：if err != nil { return err }，别忽略它
GORM 的 AfterCommit 钩子为什么有时不触发？
钩子只在 tx.Commit() 成功后调用，且仅对当前事务对象有效。如果你在事务内新建了另一个 *gorm.DB 实例（比如用 db.Session(...) 或跨 goroutine 传递），钩子就失效了——它绑定的是原始 tx 对象的生命周期。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 钩子注册必须在
db.Transaction函数体内，且在tx创建后立即调用tx.AfterCommit(...) - 不要在钩子里做耗时操作（如 HTTP 请求、写日志到远程服务），否则拖慢事务提交；可改用异步通知（如发消息到 channel）
- 注意并发：多个
AfterCommit注册会按注册顺序执行，但无原子性保证
嵌套事务（Savepoint）在 GORM 里怎么安全用？
GORM 不支持真正的嵌套事务，所谓“嵌套”其实是 Savepoint 模拟。用 tx.Session(&gorm.Session{AllowGlobalUpdate: true}) 或手动 tx.Exec("SAVEPOINT sp1") 都可能出问题：一旦外层事务回滚，所有 savepoint 自动失效，但你的代码可能还在尝试 ROLLBACK TO SAVEPOINT，导致 ERROR: no such savepoint。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用业务逻辑拆分事务，而不是依赖 savepoint
- 若必须用，统一用
tx.SavePoint("sp_name")+tx.RollbackTo("sp_name")，别混用原生 SQL - 每次
RollbackTo后要检查错误，失败则应降级为整体回滚 - PostgreSQL 和 MySQL 对 savepoint 的兼容行为略有差异，本地开发用和生产一致的数据库版本测试
事务中调用外部 HTTP 接口，怎么避免悬挂事务？
HTTP 调用超时、重试、网络分区都会让事务卡住，连接池耗尽，进而拖垮整个服务。GORM 本身不提供事务级超时控制，context.WithTimeout 传给 db.Transaction 只能中断函数执行，但不会自动触发 Rollback。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 事务函数入口加
defer func() { if r := recover(); r != nil { tx.Rollback() } }()，覆盖 panic 场景 - HTTP 调用必须带独立 context（如
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)），和事务 context 分离 - 把外部依赖移到事务外：先查库、生成待发数据，commit 后再异步发 HTTP；用幂等 ID + 状态机兜底重试
事务的边界比看起来更脆——一次未处理的 panic、一个被吞掉的 error、甚至一个没关掉的 goroutine，都可能让锁一直挂着。写的时候多想半秒：这个 tx 对象，到底在哪儿真正结束了？
