Go事务回滚不能只靠defer+tx.Rollback()，因panic或提前return可能导致tx已提交、关闭或连接断开，使rollback失效或panic；且混用多资源时需应用层协调，应使用幂等TxGuard状态机显式控制终态。
Go 事务回滚为什么不能只靠 defer + tx.Rollback()
因为 defer 在函数返回前才执行，而事务失败可能发生在多个嵌套调用深处；一旦中间某步 panic 或提前 return，tx.Rollback() 虽然会触发，但此时 tx 可能已 commit 过、或已被其他 goroutine 关闭、或底层连接已断开——导致 rollback 失效或 panic。
更常见的是：业务逻辑里混用多个数据库操作（比如先写 MySQL，再发 MQ 消息），单纯数据库事务无法覆盖跨系统操作，“回滚”必须是应用层协调行为。
- 不要在每个函数里都写
defer tx.Rollback()，它不解决“何时该 commit、何时该 rollback”的决策问题 - panic 不等于错误，有些 error 是预期的（如用户重复注册），不该触发 rollback
-
sql.Tx不是线程安全的，多个 goroutine 并发调用Commit()/Rollback()会 panic
用显式状态机控制事务生命周期（推荐模式）
把事务包装成带状态的对象，明确区分 “pending → committed / rolled back” 两个终态，避免多次调用 Commit/Rollback。核心是让 rollback 成为幂等、可重入的安全操作。
示例结构：
立即学习“go语言免费学习笔记（深入）”；
type TxGuard struct {
tx *sql.Tx
done bool
}
func (g *TxGuard) Commit() error {
if g.done {
return errors.New("tx already finalized")
}
g.done = true
return g.tx.Commit()
}
func (g *TxGuard) Rollback() error {
if g.done {
return nil // 幂等
}
g.done = true
return g.tx.Rollback()
}
- 所有业务逻辑必须通过
g.Commit()或g.Rollback()显式结束事务，禁止裸调tx.Commit() - 函数入口处统一初始化
g := &TxGuard{tx: db.Begin()}，出口处用defer g.Rollback()—— 它现在是安全的，因为 Rollback 幂等 - 遇到不可恢复错误（如 DB 级 constraint violation）立即
return err，让 defer 触发 rollback；遇到可恢复错误（如第三方服务超时），可自行决定是否重试或降级，再决定 commit/rollback
跨资源事务：用两阶段提交（2PC）还是 Saga？
纯 Go 模块内没有分布式事务协调器，sql.Tx 只管单库。若涉及 MySQL + Redis + Kafka，必须自己编排补偿逻辑。2PC 在 Go 生态中几乎没人落地（缺乏可靠 coordinator），Saga 是更现实的选择。
关键不是“怎么写 Saga”，而是“怎么让补偿动作不被遗漏”：
- 每一步正向操作后，立刻持久化对应的补偿指令（如写入
saga_log表，含 step_name、undo_sql、params） - 补偿动作必须幂等：Redis 删除用
DEL而非DEL + SET，MQ 重发需带 dedup ID - 不要依赖定时任务扫表触发补偿——延迟高、易漏；推荐用数据库变更捕获（如 Debezium）或 WAL 监听（pglogrepl）实时驱动补偿
- Go 中可用
github.com/google/uuid生成全局 saga_id，所有子步骤日志都带上它，便于追踪和人工干预
panic 场景下如何保底回滚？
Go 的 recover 机制能拦截 panic，但它无法区分“程序 bug 导致的 panic”和“业务主动 panic（如校验失败）”。盲目 recover 并 rollback 很危险——比如某个中间件 panic 后，业务数据其实已经部分落库，rollback 反而破坏一致性。
- 禁止在 handler 层全局 recover；只在明确知道 panic 来源且可控的地方做（如 SQL 执行封装层）
- 对
tx做 wrapper，记录其创建时的 goroutine ID（用runtime.GoID()非官方但实用），panic 时比对是否同 goroutine，避免跨 goroutine 错误 rollback - 生产环境开启
sql.DB.SetConnMaxLifetime()和SetMaxOpenConns()，防止连接泄漏导致 rollback 时连接已失效 - 最保险的做法：把事务入口函数用
recover()包一层，仅当 panic 发生在你信任的业务代码段内（比如processOrder()函数内部）才 rollback；其余 panic 记录日志并 crash，靠 k8s 重启恢复
真正难的不是写 rollback 代码，而是定义清楚“什么算失败”“谁有权决定回滚”“回滚后状态是否可对外暴露”。这些不在 Go 语法里，而在你的业务契约里。
