GORM 的 tx.Begin() 在已有事务中不 panic 是因转为 SAVEPOINT 操作，返回同一 *gorm.DB 实例并记录保存点名；inner.Commit() 被忽略，仅 inner.RollbackTo("sp") 生效，外层提交或回滚后保存点失效。
Go 里没有嵌套事务，GORM 的 tx.Begin() 在已有事务中调用，只是创建一个 SAVEPOINT，不是新开事务；误以为能独立提交子事务，会导致数据不一致或静默失败。
为什么 tx.Begin() 在事务里不 panic 却也不生效
GORM 的 tx.Begin() 在已有事务上下文中不会调用底层 db.Begin()，而是执行 SAVEPOINT sp_xxx，并把保存点名记在返回的 *gorm.DB 实例上。这个实例和外层 tx 是同一个底层连接，只是多了保存点控制能力。
-
inner.Commit()被 GORM 忽略——保存点不支持“提交”，只支持回滚到它 -
inner.RollbackTo("sp")才真正触发ROLLBACK TO SAVEPOINT sp_xxx - 若外层已
Commit()或Rollback()，再操作保存点会报错（如 PostgreSQL 的current transaction is aborted） - 全局配置了
DisableNestedTransaction: true时，SavePoint()会静默失效，且无 warning
如何安全设置和使用保存点
保存点不是随便加的，得落在业务逻辑的“可局部失败”边界上，比如用户创建成功后，同步写入 profile、address、notification_setting 三张表，其中 address 校验失败，只该回滚 address 操作，不影响 user 和 profile。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 命名必须唯一：重复调用
tx.SavePoint("sp1")会覆盖前一个，导致RollbackTo("sp1")跳过中间状态 - 避免在循环里动态生成保存点名却不校验唯一性（并发下
uuid.NewString()[:8]仍有碰撞风险） - 不要每个
Create()前都设一个点——语义不清、命名难管理、易冲突 - 推荐按业务子单元命名：
tx.SavePoint("sp_profile_create")、tx.SavePoint("sp_address_upsert")
什么时候该用 db.Transaction()，什么时候必须手动管理
db.Transaction() 是一次性闭环，适合「全有或全无」场景；而需要局部容错（比如部分失败仍可继续）时，它完全不够用——它的回调一旦返回 error，整个事务就回滚，保存点没机会生效。
立即学习“go语言免费学习笔记（深入）”；
-
db.Transaction()内部调的是tx.Begin()，无法中途退出或挂起外层事务 - 若你在
db.Transaction()回调里调tx.SavePoint()，没问题；但回调返回 error 后，事务已终止，后续无法再利用那个保存点 - 真正需要局部回滚时，得自己用
db.BeginTx(ctx, nil)启动，之后全程用tx.Create()/tx.Exec()，并显式调tx.SavePoint()和tx.RollbackTo() - 别混用
tx.SavePoint("sp")和原生tx.Exec("SAVEPOINT sp")，容易报no such savepoint
容易被忽略的底层约束
保存点是数据库层面的机制，不是 GORM 的抽象糖衣。MySQL 和 PostgreSQL 行为基本一致，但有几个硬限制必须记住：
-
database/sql中，在已有*sql.Tx上调Begin()或BeginTx()必 panic，GORM 的“不 panic”是它自己兜底做了 SAVEPOINT 转换 - DDL 操作（如
CREATE TABLE）在保存点内执行，可能被 MySQL 隐式提交，直接破坏事务原子性 - context 超时绑定在
BeginTx()那一刻，后续所有tx.Query()都自动响应它；但若混用db.QueryRow()，就脱离了事务 context，超时和 cancel 都不生效 - 保存点只在当前事务生命周期内有效，跨事务复用名字不会报错，但行为不可预测
