Go无真正嵌套事务，Echo框架不提供事务管理，所谓“嵌套”实为误用BeginTx()创建多个隔离事务；唯一可行方案是复用同一*sql.Tx并用SAVEPOINT实现局部回滚。
事务嵌套在Echo中根本不存在——别被“嵌套”误导
Go 语言本身没有运行时事务上下文传播机制，Echo 作为轻量 HTTP 框架也不提供事务管理能力。所谓“嵌套事务”，其实是开发者误用 db.BeginTx() 在同一请求链路中多次开启独立事务导致的幻觉。每个 BeginTx() 都创建全新事务，彼此隔离、无法感知对方状态。外层回滚不影响内层已提交的数据，这是典型的数据不一致根源。
常见错误现象：tx1.Commit() 成功后，tx2.Rollback() 仍执行失败报错；或更隐蔽地，tx2.Commit() 已生效，但业务逻辑认为它该被外层回滚。
- 所有事务必须显式传递，不能依赖“当前上下文”
- 禁止在 service 层或 handler 内部调用
db.BeginTx()—— 只能在最外层（如 middleware 或顶层 handler）开始一次 - 后续所有数据库操作必须复用同一个
*sql.Tx实例，而非重新获取*sql.DB
如何把事务安全地传进 handler 和 service
Go 没有 ThreadLocal，但可以用 context.Context 携带事务对象。关键不是“注入”，而是显式传递 + 类型断言，避免隐式依赖。
实操建议：
- 在中间件中调用
db.BeginTx(ctx, nil)，将返回的*sql.Tx存入 context：ctx = context.WithValue(ctx, txKey{}, tx) - handler 中通过
ctx.Value(txKey{}).(*sql.Tx)取出并传给 service 方法，不要直接从全局*sql.DB执行 - 定义私有 key 类型（如
type txKey struct{}），避免与其他 context key 冲突 - 务必在 defer 中检查
tx != nil再调用tx.Rollback()，防止 panic
示例片段：
// middleware
tx, err := db.BeginTx(ctx, nil)
if err != nil {
return err
}
ctx = context.WithValue(ctx, txKey{}, tx)
defer func() {
if r := recover(); r != nil || err != nil {
tx.Rollback()
}
}()
// handler
tx := ctx.Value(txKey{}).(*sql.Tx)
userRepo := NewUserRepo(tx) // 构造时传入 tx，非 *sql.DB
userRepo.UpdateBalance(ctx, 1, -100)
Savepoint 是唯一接近“嵌套”的可行方案
MySQL（InnoDB）、PostgreSQL 等支持 SAVEPOINT，它允许你在单个事务内设标记点，然后局部回滚。这比伪造多个事务安全得多，且真正满足“部分失败不影响整体”的业务需求。
使用前提与限制：
- 必须确保底层 driver 支持（
database/sql标准接口不抽象 savepoint，需原生 SQL） - MySQL 要求显式执行
SAVEPOINT sp1和ROLLBACK TO sp1，PDO 或 pgx 可封装，但database/sql原生不提供方法 - 不能跨 goroutine 使用同一个 savepoint；必须在同一线程/协程内完成设置与回滚
- 频繁建 savepoint 会轻微增加日志开销，但远小于启新事务的代价
典型场景：订单创建中，先写订单主表 → 设 savepoint → 写订单明细 → 若明细失败，只回滚明细部分，主表保留。
为什么不用 ORM 自动事务包装？
像 GORM 的 Transaction() 方法看似方便，但它内部仍是调用 BeginTx() + defer Rollback()，本质没解决上下文传递问题。更危险的是，它鼓励你在任意位置调用，导致事务边界模糊、嵌套假象加剧。
真实风险点：
- GORM 的
Session(&session.Options{NewDB: true})会新建 DB 实例，彻底脱离你手动管理的事务 - 任何未显式传入
*gorm.DB（带事务）的调用，都会回退到自动提交模式 - 日志中间件、metrics 收集若偷偷查库，可能触发隐式提交，破坏原子性
结论：坚持手写 BeginTx + 显式传递，比依赖 ORM 封装更可控。复杂度不在代码行数，而在责任归属是否清晰。
最后提醒：事务生命周期必须严格绑定 HTTP 请求生命周期。不要试图在 goroutine 中异步提交或回滚——context cancel、panic、超时都可能让事务悬空，最终靠 MySQL 的 idle timeout 回滚，不可控且延迟高。
