事务需显式调用tx.commit()，否则静默丢弃；嵌套transaction实为savepoint，非独立事务；i/o操作须移至aftercommit钩子异步执行。
事务不会自动提交，必须显式调用 tx.Commit()；漏掉这一步，数据就丢了，还不报错。
为什么 db.Transaction 里写了代码却没生效？
因为 db.Transaction 只是帮你开了个事务、传了个 tx *gorm.DB 进去，它不替你调 tx.Commit()，也不检查你有没有写。函数跑完就完事，连接归还池子时事务静默丢弃——既没提交，也没回滚，日志里连错误都没有。
- 所有数据库操作必须用传入的
tx实例，比如tx.Create(&u)，不能混用全局db.Create() - 成功路径上必须有一行
return tx.Commit()（或先err = tx.Commit()再return err） - 别在中间
return nil，否则Commit根本没机会执行 - 如果函数 panic，
defer tx.Rollback()会起作用；但逻辑错误（比如 if 判断跳过 commit）就真失效了
tx.Commit() 报错怎么办？
tx.Commit() 本身可能返回 error，比如网络断开、死锁、唯一约束冲突。这个 error 必须被接收并返回，否则上层无法感知失败。
- 写法要像这样：
if err := tx.Commit(); err != nil { return err } - 不能只写
tx.Commit()然后不管返回值 - 也不能写成
err = tx.Commit()却忘了在函数末尾return err - 若已调过
tx.Rollback()，再调tx.Commit()会 panic：「cannot commit transaction that has been rolled back」
嵌套 Transaction 是不是真嵌套？
不是。GORM 的 db.Transaction 套 db.Transaction 实际是 SAVEPOINT，不是独立事务。外层 rollback 会让所有内层 savepoint 失效，但如果你手动 tx.Exec("ROLLBACK TO SAVEPOINT ...")，运行时会报错：ERROR: no such savepoint。
- 别依赖「嵌套事务能各自回滚」的直觉
- SAVEPOINT 不等于事务隔离，内层失败不影响外层自动 rollback，得你自己判断和处理
- 真正需要隔离的逻辑，应拆到不同函数 + 显式
tx.SavePoint()/tx.RollbackTo()，且必须用同一tx实例 -
AfterCommit钩子只在tx.Commit()成功后触发，且不继承到tx.Session()或tx.WithContext()新建的实例
最容易被忽略的是：事务里做 HTTP 请求、发消息、写文件——这些 I/O 操作一旦超时或失败，不仅拖慢整个事务，还可能让锁持有太久，引发连接池耗尽。这类操作必须挪到 AfterCommit 钩子里异步触发，或者用 channel 投递出去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
