事务必须用 tx 对象操作，db.begin() 返回新实例，原 db 不受影响；嵌套事务实为 savepoint；推荐用 db.transaction 自动管理生命周期；关闭默认事务可提效但需自行兜底。
事务必须用 tx，不能继续用 db
很多人写完 db.Begin()，后面还用 db.Create()，结果操作完全没走事务——因为 Begin() 返回的是一个全新的、带事务上下文的 *gorm.DB 实例，原 db 对象不受影响。
- 错误写法：
tx := db.Begin(); db.Create(&u)→ 这条Create走的是无事务的默认连接 - 正确写法：
tx.Create(&u)，所有 CRUD 必须链在tx上 - 嵌套事务也一样：外层
outer和内层inner是两个独立事务对象，inner的操作不会自动反映到outer - 事务对象不复用：
tx提交或回滚后不可再调用tx.Create，会 panic 报"invalid transaction"
Transaction 函数比手写 Begin/Commit 更安全
手动管理事务要自己写 defer + recover + Rollback，漏掉任何一环都可能造成连接泄漏或数据不一致。而 db.Transaction() 内部已封装完整生命周期，出错自动回滚，成功自动提交。
- 推荐场景：单次原子操作（如“创建用户 + 初始化默认地址”）
- 示例：
db.Transaction(func(tx *gorm.DB) error { return tx.Create(&u).Error }) - 它不支持提前退出事务（比如想中途
return但不触发回滚），所以复杂流程仍建议用显式Begin - 注意：函数内若 panic，
Transaction会捕获并回滚；但若你用os.Exit或直接调用runtime.Goexit，它就拦不住了
嵌套事务不是“子事务”，而是 SavePoint 模拟
GORM 的嵌套事务（如 tx.Begin() 在另一个 tx 内）底层并非数据库真正的嵌套事务（MySQL 本身不支持），而是通过 SAVEPOINT 实现的局部回滚能力。
- 这意味着：内层
Rollback()只回滚到 savepoint，不影响外层已执行的操作 - 但外层
Rollback()会连带清除所有 savepoint，整个事务失效 - 如果内层 commit 失败，要手动
inner.Rollback()，再决定是否让外层也Rollback() - 别指望靠嵌套事务实现“部分提交”——GORM 不提供跨事务的数据可见性控制
禁用默认事务能提 30%+ 写入性能，但得自己兜底
GORM 默认对每个 Create/Update/Delete 都包一层事务，确保单条语句原子性。如果你确定这些操作彼此无关、失败可单独处理，关闭它确实快得多。
- 配置方式：
gorm.Config{SkipDefaultTransaction: true} - 代价是：单条语句失败时不再自动回滚（本来也没啥可回滚的），但你也失去了隐式一致性保障
- 典型适用场景：日志写入、埋点上报、缓存刷新等“尽力而为”型操作
- 切记：一旦关了，默认的
db.Create()就真成裸 SQL 了，遇到约束冲突、主键重复等错误，不会自动 rollback 其他并行操作
tx 对象背后绑着一个数据库连接，用完不 commit/rollback，这个连接就一直占着，高并发下容易耗尽连接池。别只盯着数据一致性，先管住连接。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
