defer 本身无法实现细粒度事务回滚，因其仅延迟执行、不感知错误或panic、不理解事务边界；应使用显式回滚链，即记录可逆操作并倒序调用undo，配合context控制超时与取消。
事务回滚不能只靠 defer
直接说结论：defer 本身无法实现细粒度事务回滚。它只是延迟执行，不感知函数是否 panic、返回错误，更不理解“事务边界”或“回滚逻辑”。常见误区是写一堆 defer rollback()，结果发现部分操作已提交、回滚没生效、甚至 panic 被吞掉。
为什么 defer 在事务中容易失效
典型失败场景：数据库操作嵌套调用，中间某步出错，但上层没检查错误就继续往下走；或者 defer 绑定的是无参函数，无法拿到当前上下文里的连接、状态或已执行步骤列表。
-
defer执行时机固定在函数 return 前，但事务回滚必须发生在“确认失败后立即”，而非“函数退出时” - 多个
defer按 LIFO 顺序执行，若回滚逻辑依赖执行顺序（比如先删缓存再撤 DB），手动管理易错 - panic 会被
recover拦截，但普通 error 返回不会触发任何defer的条件分支
用显式回滚链替代 defer
真正可行的做法是把“可逆操作”封装成带 undo 方法的结构体，按调用顺序追加到一个切片里，在出错时倒序调用 undo。核心不是延迟，而是记录 + 可控执行。
示例片段：
立即学习“go语言免费学习笔记（深入）”；
type RollbackStep struct {
undo func() error
}
func (r *RollbackStep) Do() error {
// 实际操作
if err := db.Insert(...); err != nil {
return err
}
// 记录回滚动作（注意：这里要捕获当前需要撤销的参数）
r.undo = func() error {
return db.DeleteByID(...)
}
return nil
}
// 调用方维护 steps 切片
var steps []RollbackStep
if err := step1.Do(); err != nil {
rollback(steps)
return err
}
steps = append(steps, step1)
- 每个操作自己负责生成对应的
undo函数，闭包捕获必要状态（如 ID、版本号） - 回滚必须显式调用
rollback(steps)，且要在所有 error 分支里覆盖到 - 不要把
undo放进defer—— 它可能根本不会被执行（比如提前 return）
Context 和 cancel 的配合使用
当事务涉及 HTTP 请求、RPC 调用或超时控制时，仅靠 error 传递不够。需要用 context.Context 驱动主动中断，并让各步骤响应 ctx.Done() 提前释放资源。
- 数据库连接、HTTP client 等应接收
ctx参数，支持 cancel - 每个
RollbackStep的undo函数也应接受ctx，避免阻塞 - 不要依赖
defer关闭连接 —— 应在 rollback 或 success 后明确 Close，否则连接可能泄漏
细粒度事务的关键不在语法糖，而在每一步都清楚“我做了什么”和“怎么撤回去”。defer 是工具，不是机制；回滚链的本质是状态快照 + 显式控制流。
