Go语言defer坑太多？那是因为你没看这篇

先问个问题：下面这段代码会输出什么？

func main() {
    for i := 0; i < 3; i++ {
        defer fmt.Println("i =", i)
    }
}

很多人会脱口而出：i = 0, i = 1, i = 2。
错！实际输出是：i = 2, i = 1, i = 0。

什么？defer不是在函数结束前执行吗？为什么顺序反了？

这就引出了我今天要讲的——Go语言defer的正确打开方式，以及那些年我踩过的坑。

defer的"先进后出"不是bug，是feature

defer采用后进先出（LIFO）的顺序执行，这是故意的设计。想象一下打开文件后defer关闭、获取锁后defer释放——如果顺序反过来，很多嵌套的资源管理就乱套了。

但真正让人栽跟头的，往往不是这个基础特性，而是闭包和defer的组合拳。

闭包捕获变量的艺术与陷阱

再看一个例子，这次用闭包：

func main() {
    for i := 0; i < 3; i++ {
        defer func() {
            fmt.Println("i =", i)
        }()
    }
}

输出是什么？

全部都是 i = 2！

因为defer注册的函数捕获的是变量i本身，而不是当时的值。等defer执行时，循环早已结束，i的值已经是2了。

这个问题太经典了，江湖人称"循环变量捕获陷阱"。解决方案是用参数传值：

func main() {
    for i := 0; i < 3; i++ {
        defer func(val int) {
            fmt.Println("i =", val)
        }(i)  // 把i的值传进去，而不是捕获i本身
    }
}

这次输出正确了：i = 0, i = 1, i = 2。

我要吐槽：错误处理里的defer滥用

我见过太多人把defer当成万能胶水，哪里需要粘哪里。尤其是错误处理场景，简直是重灾区。

func readData() error {
    f, err := os.Open("data.txt")
    if err != nil {
        return err
    }
    defer f.Close()  // 看起来很美

    // 读取数据...

    // 突然有一天，你加了这行代码：
    if condition {
        return errors.New("early return")
    }

    return nil
}

看起来没毛病？等等，如果f.Close()本身返回错误怎么办？

你可能会说，那就用更优雅的方式：

func readData() error {
    f, err := os.Open("data.txt")
    if err != nil {
        return err
    }

    if condition {
        f.Close()  // 重复代码
        return errors.New("early return")
    }

    // ... 各种return路径都要close

    return f.Close()
}

这就陷入了复制粘贴的深渊。更可怕的是，你永远不知道下一个开发者会不会漏掉某个路径的Close调用。

正确姿势：组合模式

真正优雅的方案是用组合。我推荐这个模式：

type File struct {
    *os.File
    closed bool
}

func OpenFile(name string) (*File, error) {
    f, err := os.Open(name)
    if err != nil {
        return nil, err
    }
    return &File{File: f}, nil
}

func (f *File) Close() error {
    if f.closed {
        return nil  // 幂等close，重复调用不报错
    }
    f.closed = true
    return f.File.Close()
}

// 使用
func readData() error {
    f, err := OpenFile("data.txt")
    if err != nil {
        return err
    }
    defer f.Close()

    if condition {
        return errors.New("early return")
    }

    // ... 各种return，defer帮你兜底

    return nil
}

这样做的好处：defer可以多次调用而不panic，逻辑清晰，不易出错。

recover必须和defer搭配才有意义

说到defer，不得不提panic和recover这三兄弟。

func risky() {
    panic("oops")

    // 这行永远不会执行
    fmt.Println("unreachable")
}

func main() {
    risky()  // 程序会崩溃
}

加上recover：

func safe() (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("caught panic: %v", r)
        }
    }()

    panic("oops")

    return nil  // unreachable
}

func main() {
    if err := safe(); err != nil {
        fmt.Println(err)
    }
    fmt.Println("程序继续运行")
}

注意这个细节：recover只有在defer函数里直接调用才有效。因为panic会跳帧，只有defer能"抓住"它。

另外，我见过有人这样写：

func bad() {
    defer recover()  // 没用！recover需要通过defer捕获panic的返回值
    panic("oops")
}

这个defer recover()是无效的！必须写成 defer func() { recover() }()。

defer和method的矛盾：值 receiver vs 指针 Receiver

这个坑比较隐蔽。

type Counter struct {
    count int
}

func (c Counter) Add(n int) {
    c.count += n
}

func main() {
    var c Counter
    c.Add(5)
    fmt.Println(c.count)  // 输出0！Add修改的是副本
}

换成指针Receiver：

func (c *Counter) Add(n int) {
    c.count += n
}

func main() {
    var c Counter
    c.Add(5)
    fmt.Println(c.count)  // 输出5
}

现在的问题是：如果defer注册一个指针方法，但指针可能在defer执行前变成nil呢？

func main() {
    var c *Counter  // nil
    defer c.Add(5)  // 编译错误：cannot use c.Add (func(int)) as argument to defer
}

Go编译期就会报错。但如果你这样：

type Handler struct {
    name string
}

func (h *Handler) Close() error {
    fmt.Println("closing", h.name)
    return nil
}

func main() {
    var h *Handler  // nil
    defer func() {
        if h != nil {
            h.Close()
        }
    }()
    // h还是nil，但程序不会panic，因为我们在defer里做了检查
}

这种防御性编程在处理可能为nil的对象时很有用。

性能：defer的代价你真的在乎吗？

江湖传言defer性能很差。这是真的吗？

实测：在Go 1.14之后，defer的性能已经大幅提升，甚至在某些场景下和手写cleanup代码差不多快。

但如果你在热点代码里（比如说，一秒执行几十万次的循环）用了defer，还是会有肉眼可见的开销。这时候你可以：

// 普通版本（清晰但有开销）
func process() {
    f, _ := os.Open("data")
    defer f.Close()
    // ... 处理逻辑
}

// 性能敏感版本（手写cleanup）
func processFast() error {
    f, err := os.Open("data")
    if err != nil {
        return err
    }

    // ... 处理逻辑

    return f.Close()
}

但说实话，95%的情况下你不需要优化defer。代码可读性比那点微乎其微的性能重要得多。

总结：defer的正确使用指南

说了这么多，来个总结：

• 用defer管理资源：文件、网络连接、锁、数据库事务等
• 避免在循环中使用defer：除非你能接受LIFO顺序
• 闭包捕获要注意：用参数传值，别直接引用循环变量
• recover必须在defer的函数里直接调用
• 性能敏感场景可以不用defer，但大多数情况下别过早优化

defer是Go语言给我的一把双刃剑。用对了，代码优雅又安全；用错了，debug到怀疑人生。

希望这篇能让你少踩几个坑。踩坑不可避免，但我们可以选择站在坑里还是爬出来。

有问题？来聊。