Go 中无嵌套事务，所谓“嵌套”实为 SAVEPOINT 模拟局部回滚；GORM 的 tx.Begin() 在已有事务中不 panic 是因转为 SAVEPOINT 操作，返回同一 *gorm.DB 实例并记录保存点名，inner.Commit() 被忽略，仅 inner.RollbackTo("sp") 生效。
Go 里没有嵌套事务，所谓“多表联合操作中的嵌套事务”本质是 SAVEPOINT 模拟的局部回滚，不是新开事务；直接在已有 *sql.Tx 或 *gorm.DB 上调 Begin() 必 panic。
为什么 GORM 的 tx.Begin() 在事务中不报错但也不起作用
GORM 的 tx.Begin() 在已有事务中不会 panic，是因为它压根没调底层 db.Begin()，而是悄悄执行 SAVEPOINT sp_xxx。它返回的仍是同一个 *gorm.DB 实例，只是内部记录了保存点名。你调 inner.Commit() 会被忽略，调 inner.RollbackTo("sp") 才真正执行 ROLLBACK TO SAVEPOINT sp_xxx。
- 如果外层事务已
Commit()或Rollback()，再对保存点做任何操作都会失败（PostgreSQL 报current transaction is aborted） -
SavePoint("sp1")多次调用同一名字 → MySQL/PostgreSQL 都会报错duplicate savepoint name - 若全局配置了
DisableNestedTransaction: true，SavePoint会静默失效，且无 warning
多表联合操作中该在哪设保存点
保存点应设在「可能独立失败、但又不该拖垮整个事务」的逻辑边界上。比如：用户创建成功后要同步写入 profile、address、notification_setting 三张表，其中 address 格式校验失败，只该回滚 address 相关操作，不影响 user 和 profile。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要在每个
Create()前都设一个保存点——命名冲突风险高，且语义不清 - 推荐按业务子单元设点：
tx.SavePoint("sp_profile_create")、tx.SavePoint("sp_address_upsert") - 避免在循环内动态生成保存点名却不校验唯一性（并发请求下
uuid.NewString()[:8]仍可能碰撞） - MySQL 不支持
RELEASE SAVEPOINT，PostgreSQL 支持但漏掉也不会出错；别把它当资源清理必需步骤
db.Transaction() 和手动 SavePoint 怎么选
db.Transaction() 是一次性闭环，适合「全有或全无」场景；而多表联合操作常需部分容错，此时必须跳出该封装，手动控制 *gorm.DB 或 *sql.Tx 上的保存点。
立即学习“go语言免费学习笔记（深入）”；
-
db.Transaction()内部调tx.Begin()→ 一旦开始就不能中途退出事务上下文，也无法嵌套另一个Transaction() - 若你在
Transaction()回调里调tx.SavePoint()，没问题；但回调返回 error 后，整个事务就回滚了，保存点没机会生效 - 真正需要局部回滚时，得自己用
db.BeginTx(ctx, nil)启动，之后全程用tx.Create()/tx.Exec()，并显式管理保存点 - 所有 SQL 操作必须走同一个
tx实例；混用db.Create()（走连接池）会导致部分操作游离于事务之外
容易被忽略的 context 与错误传播陷阱
事务的 context.Context 只在 BeginTx() 时绑定，后续所有 tx.Query()、tx.Exec() 都继承它——但 *sql.Tx 没有 QueryContext() 方法，你没法中途换 ctx。
- 辅助操作（如日志写入、埋点上报）若用了独立
*sql.DB，它们完全不受事务 ctx 控制，超时或 cancel 不会影响它们 - 封装
RunInSavepoint()辅助函数时，别用defer tx.Exec("ROLLBACK TO SAVEPOINT...")—— 如果闭包里已经 panic，defer 可能无法执行或执行失败却无感知 - 正确做法是：闭包返回 error 时显式
tx.Exec("ROLLBACK TO SAVEPOINT...")，成功则跳过；且保存点名必须由函数生成，不依赖调用方传入 - PostgreSQL 驱动（pgx）在事务中执行非事务语句（如
db.QueryRow()）会报ERROR: current transaction is aborted，MySQL 则可能静默走新连接
