Golang错误处理模式解析与error接口使用

在 Golang 中，错误处理通过返回 error 类型实现，调用者判断其是否为 nil 来识别错误。1. error 是一个接口，需实现 Error() string 方法；2. 错误应使用预定义变量（如 io.EOF）比较，而非字符串；3. 返回具体类型指针即使为 nil 也可能导致接口不为 nil；4. Go 1.13 起支持错误包装，可用 fmt.Errorf(%w) 构造错误链，并通过 errors.Unwrap、Is、As 处理复合错误，提升程序健壮性。

在 Golang 中，错误处理是通过返回 error 类型来实现的。函数通常会在最后返回一个 error 值，调用者通过判断这个值是否为 nil 来决定是否有错误发生。这种模式虽然简单，但非常直接有效。

error 接口的基本结构

Go 的标准库中定义了 error 是一个接口：

type error interface {
    Error() string
}

也就是说，只要某个类型实现了 Error() 方法并返回字符串，它就可以作为 error 使用。例如，标准库中的 errors.New() 函数会创建一个带有错误信息的结构体，它实现了 error 接口。

常见用法如下：

if err := doSomething(); err != nil {
    log.Println("出错了：", err)
}

这里的关键在于：函数返回了一个 error，调用方检查是否为 nil 来决定是否出错。

为什么不能直接比较 error 字符串？

很多人刚接触 Go 时可能会写出这样的代码：

if err == "EOF" { ... }

这显然是不对的，因为 err 是一个接口，不是字符串。正确的做法是使用标准库中的变量，比如：

if err == io.EOF {
    // 到达文件末尾
}

io.EOF 是一个预定义的 error 实例，可以直接比较。如果你自己定义错误，也可以这样做：

var ErrMyError = errors.New("my error")

// 使用时
if err == ErrMyError {
    // 处理特定错误
}

nil 检查机制背后的“陷阱”

Go 的 error 是接口类型，而接口变量的比较和赋值有一些细节需要注意。

容易踩坑的例子：

func myFunc() error {
    var err *myError // 假设 *myError 实现了 error 接口
    return err // 即使 err 是 nil，返回的 error 接口也不是 nil！
}

func main() {
    if err := myFunc(); err != nil {
        fmt.Println("这里会输出：有错误")
    }
}

上面这个例子中，虽然 err 是 nil，但返回的是一个具体类型的指针（即使为 nil），所以接口不等于 nil。这是很多新手容易忽略的地方。

解决方法是避免返回具体类型的指针，或者确保在没有错误时返回真正的 nil。

如何构造和包装错误？

从 Go 1.13 开始，标准库支持了错误包装（wrapping）功能，可以通过 fmt.Errorf 加上 %w 动词来包装错误：

err := fmt.Errorf("读取失败: %w", io.EOF)

这样你可以在后续通过 errors.Unwrap() 或 errors.Is()、errors.As() 来提取原始错误：

• errors.Is(err, io.EOF)：判断是否包含某个错误。
• errors.As(err, &target)：尝试将错误转换为某种类型。

这种方式让错误链更清晰，也便于统一处理。

基本上就这些。Golang 的错误处理机制虽然看起来简单，但在实际开发中如果不注意细节，很容易踩坑。掌握好 error 接口的使用方式、理解 nil 检查的原理，以及合理使用错误包装，能让你写出更健壮的 Go 程序。