Go事务不支持原生SavePoint，需手动执行SAVEPOINT和ROLLBACK TO SAVEPOINT并严格管理错误分支，避免事务状态混淆与并发误用。
Go 事务不支持原生 SavePoint，别直接调 SAVEPOINT
Go 标准库 database/sql 的 *sql.Tx 没有暴露保存点（SavePoint）接口，调用 tx.Exec("SAVEPOINT sp1") 虽然语法上能执行，但后续 ROLLBACK TO SAVEPOINT sp1 很可能失败——因为底层驱动（如 lib/pq 或 mysql）未将该语句与当前事务状态同步，tx.Rollback() 仍会全局回滚。
手动模拟 SavePoint 需自己管理 SQL 执行和错误分支
真正可行的做法是：在同一个 *sql.Tx 上，用原生 SQL 显式执行 SAVEPOINT 和 ROLLBACK TO SAVEPOINT，并严格控制后续操作是否继续、是否需要局部回滚。关键不是“封装成方法”，而是“显式分段 + 自己判错”。
常见错误现象：ROLLBACK TO SAVEPOINT 后继续往事务里塞 INSERT，结果报错 current transaction is aborted, commands ignored until end of transaction block（PostgreSQL 典型提示），说明你没重置事务状态。
- 必须在
ROLLBACK TO SAVEPOINT后，继续在同一事务中执行其他语句（不能认为“回滚完就安全了”） - MySQL 和 PostgreSQL 对 SavePoint 的行为基本一致，但
RELEASE SAVEPOINT不是必须的，不释放也不会泄漏 - 不要试图用 defer 注册多个 SavePoint 回滚——嵌套逻辑一复杂，顺序和条件极易出错
示例片段（PostgreSQL）：
立即学习“go语言免费学习笔记（深入）”；
_, err := tx.Exec("SAVEPOINT sp_inner")
if err != nil {
return err
}
_, err = tx.Exec("INSERT INTO users(name) VALUES($1)", "alice")
if err != nil {
_, _ = tx.Exec("ROLLBACK TO SAVEPOINT sp_inner") // 必须手动执行
// 此处可 log，可跳过，但不能忽略错误后继续用 tx 做别的 INSERT/UPDATE
return nil // 局部失败，整体事务仍可提交
}
用 struct 封装事务 + SavePoint 状态更可控
如果你真需要多层嵌套语义（比如函数 A 调 B，B 失败只回滚 B 的部分），推荐自己写一个轻量 wrapper，把 *sql.Tx 和当前有效 SavePoint 名字存起来，避免字符串硬编码和命名冲突。
- SavePoint 名建议用递增序号或
fmt.Sprintf("sp_%d", atomic.AddInt64(&spID, 1))生成，防止同名覆盖 - 每次
BeginSavePoint()记录名字，RollbackToLast()执行ROLLBACK TO SAVEPOINT xxx并清空最后记录 - 不依赖 driver 实现，所有 SQL 都走
tx.Exec()，兼容pgx、mysql、sqlite3 - 注意：wrapper 无法绕过数据库级限制——比如 PostgreSQL 中，
ROLLBACK TO SAVEPOINT后不能再执行 DDL（如CREATE TABLE），否则报错
真正该警惕的不是 SavePoint，而是事务生命周期混淆
多数人踩坑不是因为不会写 SAVEPOINT，而是把“事务对象”“连接对象”“上下文传播”混在一起。比如：
- 在 HTTP handler 里
db.Begin()，然后传给几个 service 函数，其中一个调了tx.Rollback()，其他函数还在用这个已关闭的tx—— 这比 SavePoint 错误严重得多 - 用
context.WithTimeout包裹事务，但没在tx.QueryContext等地方透传，导致超时后连接卡住 - 误以为
sql.Tx是线程安全的，多个 goroutine 并发写同一个tx，出现乱序或 panic
SavePoint 只是事务内部的一个标记点，它解决不了连接管理、超时控制、并发安全这些底层问题。先理清事务从哪来、到哪去、谁负责结束，再谈嵌套回滚。
