Go语言中defer语句置于错误检查之后的原因探究

你猜的完全正确！这正是这种惯用写法的核心原因，除此之外还有一些关键细节需要明确：

1. 避免对nil值调用方法引发Panic #

在Go中，如果os.Open或者os.Create调用失败，返回的文件句柄（src或dst）会是nil。而Close()是*os.File类型的指针方法，当你对一个nil的*os.File调用Close()时，会直接触发nil指针解引用panic。

举个反例就能看清楚问题：

// 错误写法：defer放在错误检查之前
func CopyFile(dstName, srcName string) (written int64, err error) {
    src, err := os.Open(srcName)
    defer src.Close() // 如果Open失败，src是nil，这里会panic！
    if err != nil {
        return
    }
    // ...后续逻辑
}

如果os.Open失败，src为nil，defer注册的src.Close()在函数退出时执行，就会导致程序崩溃。而把defer放在err != nil检查之后，就能确保只有当文件句柄有效（非nil）时，才会注册关闭操作，从根源避免这个panic。

2. 避免对未成功创建的资源执行无效操作 #

当资源创建失败时，其实根本没有需要释放的资源——比如os.Create失败，意味着目标文件并没有被成功创建，也就不存在“关闭”的必要。把defer放在错误检查之后，也能避免这种无意义的操作，让逻辑更严谨。

回到你给出的示例代码：

func CopyFile(dstName, srcName string) (written int64, err error) {
    src, err := os.Open(srcName)
    if err != nil {
        return // Open失败，直接返回，不会执行后面的defer
    }
    defer src.Close() // 确认src有效后，注册关闭操作
    dst, err := os.Create(dstName)
    if err != nil {
        return // Create失败，返回时只会执行src的Close()，dst是nil不会被处理
    }
    defer dst.Close() // 确认dst有效后，注册关闭操作
    return io.Copy(dst, src)
}

这段代码的逻辑非常清晰：只有当资源成功获取后，才会通过defer确保它被正确关闭，既避免了panic，也保证了资源的安全释放。

内容的提问来源于stack exchange，提问作者yangmillstheory