go无内置事务回滚，需手动编排逆操作或依赖数据库事务；db操作须用sql.tx显式控制，非db资源需自定义幂等补偿；defer仅延迟执行，不替代回滚；分布式场景宜用saga模式。
Go 本身没有内置的“事务回滚”抽象，error 也不是可回溯的状态容器；所谓“错误回滚”，本质是**手动编排副作用的逆操作**，或依赖底层资源（如数据库）自身的事务能力。
数据库操作必须用 sql.Tx 显式控制事务
Go 的 database/sql 包不提供自动事务。任何需要原子性的多步 DB 操作，都得自己调用 Begin()、Commit() 和 Rollback()。
常见错误是：只在成功路径调 Commit()，却忘了在 defer tx.Rollback() 前加判断，导致失败时也回滚了已提交的事务。
- 正确做法：获取
tx后立即defer func() { if err != nil { tx.Rollback() } }()，并在所有成功逻辑走完后显式tx.Commit() - 别在事务内直接用
db.Exec()，必须用tx.Exec()，否则操作不在事务上下文中 - 注意
tx不是线程安全的，不能跨 goroutine 复用
非数据库资源（如文件、HTTP 调用）需自定义补偿逻辑
比如先写文件再发通知，若通知失败，就得删文件——这不是数据库 rollback，而是业务层的补偿动作（Compensating Transaction）。
立即学习“go语言免费学习笔记（深入）”；
这类逻辑容易遗漏清理步骤，或忽略清理本身也可能失败。
- 把“正向操作”和“逆向操作”配对封装，例如
createUser() / deleteUserByID()，并确保逆向操作幂等 - 避免在 defer 中做关键补偿（如
defer os.Remove(tmpFile)），因为 defer 执行时机不可控，且无法返回错误供上层处理 - 如果补偿操作也失败，需记录日志或落库标记为“待人工干预”，不能静默吞掉
defer 不是回滚机制，只是延迟执行
很多人误以为 defer 能自动“撤销”前面的操作，但 defer 只保证函数返回前执行，不区分成功/失败，也不感知错误语义。
它适合做资源释放（如 Close()），但不适合做业务状态回退。
-
defer f.Close()合理；defer deleteFromCache(key)很可能错——因为 key 可能根本没写进 cache - 不要依赖
recover()做业务回滚：panic 是异常信号，不是控制流手段，且无法捕获由 goroutine 引发的 panic - 若真要用 defer 辅助回滚，必须配合标志位，例如：
rolledBack := false; defer func() { if !rolledBack { undo() } }()，并在成功时置rolledBack = true
分布式场景下优先用 Saga 模式而非本地回滚
跨服务操作（如扣库存 + 创建订单 + 发推送）无法靠单机事务保证一致性。此时“回滚”实际是发起一系列反向请求（Cancel / Compensate）。
Saga 的核心难点不在编码，而在状态持久化与重试边界。
- 每步操作完成后，必须把当前状态（如 “inventory_deducted”）写入可靠存储（DB 或消息队列），否则崩溃后无法续跑
- 反向操作要支持重试，因此必须幂等；建议用唯一业务 ID（如 order_id）做去重键
- 避免在 Saga 中嵌套长耗时操作（如生成 PDF），应拆成异步子任务并单独管理其生命周期
真正难的不是写 rollback 函数，而是界定“什么算一步操作”、决定“哪一层该承担补偿责任”、以及在失败发生时，能否准确知道系统当前处于哪个中间态。
