Go标准库database/sql不支持嵌套事务，所谓“嵌套”实为通过SAVEPOINT模拟局部回滚；直接调用db.Begin()在已有事务中会panic或报错，必须用SAVEPOINT sp_name与ROLLBACK TO SAVEPOINT sp_name手动管理。
Go 里没有真正的嵌套事务
Go 标准库
和主流驱动（如
、
）都不支持 SQL 层面的嵌套事务。所谓“嵌套”，实际是应用层模拟——用保存点（
）实现回滚局部操作，而非开启新事务。直接调用
在已有事务内会 panic 或返回错误（取决于驱动），比如
报
，而
默认行为是阻塞或 panic。
用
模拟嵌套回滚
PostgreSQL 和 MySQL 5.7+ 支持
，这是最贴近“嵌套事务语义”的方案。核心思路：主事务中创建保存点 → 执行子逻辑 → 出错时只回滚到该保存点，不影响外层事务状态。
实操建议：
使用
（
v5+）或手动执行
+
（兼容所有驱动）
保存点名必须唯一，建议用
或带上下文前缀的字符串，避免重名冲突
不能对保存点调用
，它不提供提交能力，只用于回滚隔离
MySQL 中保存点在事务提交/回滚后自动失效；PostgreSQL 同样遵循事务边界
示例（
）：
封装成可复用的
辅助函数
重复写
/
容易漏掉清理或命名冲突。推荐封装一个带错误传播的 helper：
接收
或通用
（需适配驱动）和闭包函数
自动生成唯一保存点名，避免手动管理
闭包返回 error 时自动
，否则继续
注意：不要在闭包里调用
或
，会破坏外层事务
关键片段（
）：
为什么不用
的
做嵌套？
直接对已有
调用
会触发
错误。标准库设计上禁止嵌套
，因为底层连接已处于事务状态，无法再启动新事务。强行绕过（如新建连接）会丢失事务上下文，导致数据不一致。
常见误解场景：
在 HTTP handler 中，外层用
，子 service 又调
→ 必然失败
用
传事务对象，但子函数仍试图自己开事务 → 违反单事务原则
误以为 ORM（如 GORM）的
是嵌套事务 → 实际是新连接，无事务继承
真正需要跨函数传递事务控制权时，只传
或封装后的
接口，且所有 DB 操作都基于它，别碰
。
保存点不是银弹：它不解决并发更新冲突，也不替代业务层的幂等设计；出错后继续执行需确保后续逻辑能处理中间态数据。最易被忽略的是保存点名作用域——同一事务中重复使用相同名字，第二次
会覆盖前一个，导致回滚错位。
database/sqlpgxmysqlSAVEPOINTdb.Begin()pgx"pq: SAVEPOINT can only be used in transaction blocks"database/sqlSavepointSAVEPOINTtx.Savepoint(name)pgxSAVEPOINT sp_nameROLLBACK TO SAVEPOINT sp_nameuuid.NewString()Commit()pgxspName := "sp_user_create"
if _, err := tx.Exec(ctx, "SAVEPOINT "+spName); err != nil {
return err
}
defer func() {
if r := recover(); r != nil {
tx.Exec(ctx, "ROLLBACK TO SAVEPOINT "+spName)
}
}()
// ... 子逻辑，出错时显式 ROLLBACK TORunInSavepointSAVEPOINTROLLBACK TO*pgx.Txsql.TxROLLBACK TOtx.Commit()tx.Rollback()pgxfunc RunInSavepoint(ctx context.Context, tx pgx.Tx, fn func() error) error {
spName := "sp_" + uuid.NewString()
if _, err := tx.Exec(ctx, "SAVEPOINT "+spName); err != nil {
return err
}
if err := fn(); err != nil {
tx.Exec(ctx, "ROLLBACK TO SAVEPOINT "+spName)
return err
}
return nil
}sql.TxBeginsql.Txtx.Begin()"sql: transaction already in progress"Begindb.Begin()db.Begin()context.WithValueSession(&session.Options{NewDB: true})*sql.TxQuerierBeginSAVEPOINT