go 中 defer 不能直接写条件语句，但可通过匿名函数实现带判断的延迟执行；最佳实践是在资源创建后立即 defer，避免 nil 调用 panic 并确保资源始终释放。

go 中 defer 不能直接写条件语句，但可通过匿名函数实现带判断的延迟执行；最佳实践是在资源创建后立即 defer，避免 nil 调用 panic 并确保资源始终释放。

在 Go 开发中，defer 是管理资源（如数据库连接、文件句柄、HTTP 响应体）生命周期的关键机制。但一个常见误区是：defer 后只能跟函数调用，不能跟控制语句（如 if、for 或代码块）。因此，以下写法是语法错误：

defer if res != nil {  // ❌ 编译失败：unexpected if
    res.Close()
}

✅ 正确做法是将逻辑封装进一个匿名函数并立即调用（注意末尾的 ()）：

defer func() {
    if res != nil {
        res.Close()
    }
}()

该匿名函数会在外层函数返回前执行，且能安全访问当前作用域中的变量（如 res），同时规避了对 nil 值调用 Close() 导致的 panic。

不过，更符合 Go 惯用法（idiomatic Go） 的方式，是在资源成功初始化后立刻 defer，从根本上避免 res 为 nil 的风险。例如：

res, err := db.Query("SELECT ...")
if err != nil {
    return err
}
defer res.Close() // ✅ 安全：res 非 nil 才会走到这里
// 后续处理 res.Scan() 等逻辑...

这种模式具备三大优势：

• 简洁性：无需每次检查 nil；
• 确定性：只要 Query 成功，res 必然有效，defer 可无条件调用；
• 可读性：资源获取与释放逻辑紧邻，符合“谁创建、谁负责清理”的清晰责任边界。

⚠️ 注意事项：

• 匿名函数中的变量捕获是闭包引用，若 res 在 defer 后被重新赋值，可能影响实际行为（建议保持变量不可变）；
• 若需传递参数以避免闭包延迟求值问题，可显式传参：

  defer func(r io.Closer) {
      if r != nil {
          r.Close()
      }
  }(res)

• 多个 defer 按后进先出（LIFO） 顺序执行，需注意依赖关系。

总结：优先采用「创建即 defer」模式；仅当资源可能跨多分支路径（如多个 if/else 分配不同资源）或初始化逻辑复杂时，再使用带 nil 检查的匿名函数 defer。这既保障安全性，又遵循 Go 简洁、明确的设计哲学。