Go标准库sql.Tx不支持嵌套事务，所谓嵌套仅为逻辑分组；真正局部回滚需依赖数据库SavePoint（如PostgreSQL/MySQL 8.0+），通过tx.Exec执行SAVEPOINT/ROLLBACK TO SAVEPOINT手动管理，但需注意生命周期、命名冲突和驱动兼容性问题。
Go 的 sql.Tx 本身不支持嵌套事务
直接说结论：标准库 database/sql 的 sql.Tx 没有嵌套事务语义，所谓“嵌套”只是逻辑分组，底层仍是单层事务。你调用两次 db.Begin()，第二个会阻塞或报错（取决于驱动），不是真正嵌套。
常见错误现象：sql: transaction has already been committed or rolled back，或者程序卡在第二次 Begin() —— 因为前一个 tx 还没结束，而连接被独占。
- 所有操作必须在同一个
sql.Tx实例上完成 - 不能靠“新开事务”来隔离子逻辑；得靠应用层控制流程和错误分支
- 如果真需要局部回滚效果，唯一可行路径是 SavePoint（前提是底层数据库支持）
PostgreSQL/MySQL 8.0+ 中用 SavePoint 做部分回滚
SavePoint 不是 Go 标准库功能，而是通过原生 SQL 命令 + tx.Stmt() 或 tx.Exec() 手动管理。它依赖数据库能力，Go 层只负责发指令。
使用场景：比如转账中扣减 A 账户成功，但增加 B 账户失败，你想回滚 B 的操作而不影响 A 的扣减 —— 这时在 A 扣减后设一个 SavePoint，再执行 B 操作，出错就 ROLLBACK TO SAVEPOINT sp1。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- PostgreSQL 语法：
SAVEPOINT sp1、ROLLBACK TO SAVEPOINT sp1、RELEASE SAVEPOINT sp1 - MySQL 8.0+ 同样支持，但注意低版本不支持（5.7 及以前会静默忽略）
- SQLite 也支持，但并发下行为较弱，不建议生产用
- 别用
tx.QueryRow("SAVEPOINT ...")—— 它返回*sql.Row，而 SavePoint 是无结果命令，应统一用tx.Exec()
示例片段：
_, err := tx.Exec("SAVEPOINT sp_transfer")
if err != nil {
return err
}
_, err = tx.Exec("UPDATE accounts SET balance = balance - 100 WHERE id = $1", aID)
if err != nil {
return err
}
_, err = tx.Exec("UPDATE accounts SET balance = balance + 100 WHERE id = $1", bID)
if err != nil {
_, _ = tx.Exec("ROLLBACK TO SAVEPOINT sp_transfer") // 只回滚到 sp_transfer，A 的扣减仍生效
return err
}
SavePoint 的三个坑：生命周期、命名冲突、驱动兼容性
SavePoint 看似简单，但在 Go 实际使用中容易掉进三个隐性坑里，且错误不会立刻暴露。
- SavePoint 绑定在当前
sql.Tx上，事务提交或回滚后，所有 SavePoint 自动失效；但 Go 不校验你后续是否误用已失效的点 ——ROLLBACK TO SAVEPOINT xxx可能静默成功，也可能报错，取决于数据库状态 - SavePoint 名字是字符串，没有作用域；如果多个函数都用
sp1，后设的会覆盖先设的 —— 推荐用带上下文的命名，如sp_transfer_20240521或用uuid.NewShort()生成临时名 - 某些数据库驱动（比如老版本
lib/pq或go-sql-driver/mysqlv1.5 以下）对 SavePoint 返回的sql.Result处理不一致，导致Exec()报错或忽略；确认驱动版本并加简单测试用例
不用 SavePoint 时更稳妥的替代方案
SavePoint 是“补丁式”局部回滚，但多数业务逻辑其实更适合拆解成原子步骤 + 补偿操作，而不是强依赖数据库特性。
- 把“扣 A → 增 B”拆成两个独立事务：先持久化 A 的扣减（含幂等 key），再异步触发 B 的增加；失败则走补偿队列，而不是卡在同一个事务里
- 用状态字段代替部分回滚：例如订单表加
status字段，从 “created” → “a_deducted” → “b_credited”，每步更新状态并记录日志，可随时人工干预 - 如果只是想避免大事务锁表，优先考虑缩短事务时间、拆查询、用
SELECT ... FOR UPDATE NOWAIT避免阻塞，而不是引入 SavePoint 增加复杂度
SavePoint 真正该用的场景很少：必须保证多个 DML 在同一事务上下文中、且其中某几步失败不影响前面已生效的修改。这种需求本身就暗示了模型设计可能过重——先想想能不能扁平化。
