postgresql中savepoint在go需用sql.tx.exec手动执行，不可依赖不存在的rollbackto方法；必须复用同一事务实例、命名唯一、显式提交，并注意orm不支持精细控制。
PostgreSQL 中 SAVEPOINT 在 Go sql.Tx 里怎么用才不丢数据
Go 标准库 database/sql 不直接暴露 SAVEPOINT，必须靠原生 SQL 手动管理。很多人误以为调用 tx.Exec("SAVEPOINT sp1") 后就能用 tx.RollbackTo("sp1") —— 实际上 sql.Tx 根本没有这个方法，硬写会编译失败或 panic。
正确做法是：用 tx.Exec 发送 SAVEPOINT 和 ROLLBACK TO SAVEPOINT 命令，且所有后续操作必须复用同一个 *sql.Tx 实例，不能混用 db.Exec 或新建事务。
-
SAVEPOINT名字要唯一（建议带前缀如"sp_user_order_123"），避免嵌套冲突 - 每次
ROLLBACK TO SAVEPOINT后，该保存点之后的变更被丢弃，但事务仍处于活跃状态，可继续执行其他语句 - PostgreSQL 要求
ROLLBACK TO SAVEPOINT必须在当前事务内，跨 goroutine 或连接会失败 - 别忘了最后显式
tx.Commit()或tx.Rollback()，否则连接一直被占着
多表级联插入失败时，如何只回滚部分操作而不影响主记录
典型场景：插入用户 + 创建默认配置 + 关联角色。若配置表约束失败，你不希望用户记录也被撤回 —— 这正是 SAVEPOINT 的核心价值。
关键在于把“可选失败”的子操作包裹在独立保存点内，主流程继续推进：
_, err := tx.Exec("INSERT INTO users (name) VALUES ($1) RETURNING id", "alice")
if err != nil {
return err
}
// 主记录已落库，不可逆；但后续失败不影响它
_, err = tx.Exec("SAVEPOINT sp_config")
if err != nil {
return err
}
_, err = tx.Exec("INSERT INTO configs (user_id, theme) VALUES ($1, $2)", userID, "dark")
if err != nil {
// 配置失败，只回滚这部分
_, _ = tx.Exec("ROLLBACK TO SAVEPOINT sp_config")
// 继续尝试插入角色...
}
_, err = tx.Exec("INSERT INTO roles (user_id, name) VALUES ($1, $2)", userID, "member")
注意：这里没检查 ROLLBACK TO SAVEPOINT 的错误，因为 PostgreSQL 允许对不存在的保存点执行该命令（返回 warning 而非 error），但你得确保名字拼写一致。
为什么用 sqlx 或 gorm 就搞不定精细 SAVEPOINT 控制
sqlx 的 tx.MustExec 或 gorm 的 Session(&gorm.Session{NewTx: true}) 都封装了事务生命周期，但几乎都不提供 SAVEPOINT 接口。gorm v2 有 Session(&gorm.Session{Context: ctx}) 可传 context，但底层仍不透出保存点能力。
真正可控的方式只有两种：
- 放弃 ORM，用原生
*sql.Tx+Exec/Query组合，自己管理保存点生命周期 - 在 ORM 外层套一层事务代理，比如用
pgx.Conn（支持Savepoint方法）替代database/sql，再对接 gorm 的Config.Dialector
尤其注意：gorm 的 Transaction 函数内部会调用 tx.Commit() 或 tx.Rollback()，一旦你中途手动 ROLLBACK TO SAVEPOINT，后续 gorm 操作可能报 pq: current transaction is aborted —— 因为 PostgreSQL 已将整个事务标记为 failed 状态。
并发写入下 SAVEPOINT 的隔离边界在哪
SAVEPOINT 是事务级的，不是会话级或连接级。两个并发请求各自开启 *sql.Tx，它们的 SAVEPOINT sp1 完全隔离，互不影响。
但要注意实际约束冲突仍会发生：
- 唯一索引冲突、外键校验等仍由 PostgreSQL 在提交时统一检查
- 即使你在保存点内
INSERT了一条临时数据，另一事务在同个事务中 SELECT 也能看到（因为未提交，不可见），但若对方也开了事务并读取了同一行，可能触发锁等待 - 长时间持有保存点（比如中间 sleep 5s）会拖长事务，加剧锁竞争和 WAL 压力
真实项目里，SAVEPOINT 不是用来“绕过”ACID 的，而是缩小回滚粒度。该加锁的地方还得加锁，该拆分事务的地方不能硬塞进一个事务里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
