Go 错误处理：3 种写法一次讲清，从最小示例到边界

Go 错误处理是指在 Go 程序里用返回的 error 值显式表达“这一步可能失败”，并由调用方决定怎么应对的做法。你刚写 Go 时最容易困惑的就是它没有 try/catch，函数经常多返回一个 error，不处理就会编译报警。本文基于 Go 1.22 官方错误处理约定与 errors 包实践，讲清三种常见写法——多返回值判断、error wrapping 包装、panic/recover 兜底，并附上可运行示例与失败分支。看完你能分清哪些错误该当场处理、哪些该向上抛。今天这篇文章，编程狮就把这块讲透。

一、Go 错误处理到底是什么

用一句判断句给定义：Go 错误处理就是把错误当作普通返回值，由调用链逐层显式检查和传递，而不是靠异常机制自动冒泡。

打个比方，把 error 想成函数递给你的一张“可能出问题的便签”，你要么照着处理，要么原样转交给上一层。它不强迫你立刻反应，但只要你拿了返回值，就负有面对它的责任。

1.1 触发条件

只要函数依赖外部资源（网络、文件、数据库）或可能越界、除零，就应该返回 error。Go 的约定是错误是值，不是异常，这点在 Go error 接口设计里体现得很清楚。

⚠️ 注意：忽略 error（写成 _ = f()）等于埋雷，线上出问题无从排查，也绕过了编译器的显式提醒。

1.2 常见误解

有人觉得“Go 没有异常所以不健壮”。其实它把错误处理变成了明文责任，调用方必须面对，反而减少隐式崩溃。想打牢语法基础，可先过一遍 Go 语言教程。

1.3 error 接口到底长什么样

Go 的 error 只是一个接口：type error interface { Error() string }。任何实现了 Error() 方法的类型都能当错误用。这意味着你可以定义自己的错误类型，携带错误码、出错字段等上下文，而不只是返回字符串。标准库很多函数返回的就是具体的错误类型（如 *os.PathError），上层可以用类型断言或 errors.As 拿到细节。

二、写法一：多返回值显式判断

最基础也最常用。函数返回（结果，error），调用方立即 if err != nil。

package main

import (
    "fmt"
    "os"
)

func main() {
    f, err := os.Open("config.json")
    if err != nil {
        fmt.Println("打开失败:", err) // 实际项目里应 return 或 log
        return
    }
    defer f.Close()
    fmt.Println("打开成功")
}

上面这段做的是尝试打开文件，失败时打印错误并 return，成功才继续。预期结果是文件不存在时进入 err 分支、不执行后续读取。这是 Go 错误处理里覆盖最广的一种写法。

💡 小提示：defer 放在 err 判断之后、Close 之前，能避免对 nil 文件调用 Close 而 panic。

2.1 别忘了 defer 的关闭动作

打开文件、连接、锁这类资源，要在判断 err 之后、使用之前就 defer 关闭，而不是放到函数末尾。否则一旦提前 return，资源就泄漏。顺序上先 if err != nil 处理，再 defer f.Close()，再继续用 f，这是 Go 里最稳的套路。

三、写法二：error wrapping 包装上下文

当错误要向上抛时，用 fmt.Errorf("...: %w", err) 保留原始错误链，方便用 errors.Is 与 errors.As 判断根因。

package main

import (
    "errors"
    "fmt"
    "os"
)

func readConfig() error {
    _, err := os.Open("config.json")
    if err != nil {
        return fmt.Errorf("读取配置失败: %w", err) // 错误包装，保留底层 error
    }
    return nil
}

func main() {
    if err := readConfig(); err != nil {
        if errors.Is(err, os.ErrNotExist) {
            fmt.Println("配置文件缺失，使用默认配置")
            return
        }
        fmt.Println("未知错误:", err)
    }
}

这一步的预期结果是配置缺失时命中 ErrNotExist 分支，给出可预期的降级处理。错误链保持完整，便于上层按根因分流。

3.1 errors.As 比 errors.Is 更进一步

errors.Is 判断“是不是某类错误”，errors.As 则把底层错误取出来赋值给目标变量，方便读它的字段。比如网络错误里可能包了 *net.OpError，用 As 取出后能看到具体的网络操作类型，从而决定重试还是放弃。两者都依赖 %w 保留的链，用了 %v 就全失效。

四、写法三：panic/recover 兜底层崩溃

panic 只用于真正不可恢复的程序错误；recover 在 defer 里截获，把崩溃转成普通错误。

package main

import "fmt"

func safeDiv(a, b int) (res int, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("运行时 panic: %v", r) // 把 panic 转成 error
        }
    }()
    return a / b, nil // b 为 0 会 panic
}

func main() {
    r, err := safeDiv(10, 0)
    if err != nil {
        fmt.Println("捕获:", err)
        return
    }
    fmt.Println(r)
}

上面这段做的是除以零触发 panic，被 recover 接住后转成 error 返回，避免整个进程退出。panic recover 是兜底最后一环，不是常规流程控制，想看实战可参考 Panic 与 Recover。

4.1 recover 为什么常被误用

很多新手把 recover 当 try/catch 用，在正常流程里到处接异常，结果代码又慢又难读。正确姿势是：只在极少数“程序不该继续”的初始化或边界处用 defer+recover 兜底，把崩溃转成一个普通 error 返回给上层，然后让上层决定怎么降级。业务失败一律走 error，不要 panic。

五、踩坑清单

• 现象：编译报“declared but not used”。原因：拿到 err 却没判断。修复：显式 if err != nil 处理，或编译运行确认告警，或明确忽略（不推荐）。
• 现象：错误链断掉、errors.Is 判不出。原因：用了 %v 而非 %w。修复：错误包装用 %w 才能被识别，并验证 errors.Is 能命中根因。
• 现象：recover 没生效。原因：recover 不在 defer 的直接函数里。修复：把 recover 写在 defer 的匿名函数内，且 defer 要在 panic 前注册。

• 现象：自定义错误丢失类型。原因：用 %v 或字符串拼接吞掉原类型。修复：保留原错误用 %w 包装，或用 errors.As 取具体类型再处理。

总结

Go 错误处理用返回的 error 值显式表达失败，三种写法各有边界：日常用多返回值判断、跨层用 error wrapping 保留根因、只在防崩溃时用 panic/recover。落地记住：error 是值不是异常，忽略它等于埋雷；包装用 %w 才能被 errors.Is 识别。想看底层机制，可补 Go Internals 教程。

要点带走：

• 多返回值判断是默认首选，覆盖绝大多数场景；
• %w 包装保留错误链，%v 会切断根因追溯；
• panic/recover 是最后一环，别把它当普通流程控制。

延伸学习

想把这块知识系统补齐，可以按这个顺序来：

1. 对比不同语言，参考 对比错误处理方法；
2. 看日志与排查，读 Go 日志记录；
3. 延展 Go 语法，看 Go 泛型。

常见问题

Q：Go 为什么不像 Java 那样用 try/catch？

A：Go 把错误设计成普通返回值，强制调用方显式面对，避免异常在函数调用栈里隐式冒泡、难以定位。代价是代码里 if err != nil 较多，但责任更清晰，排查路径更短。

Q：什么时候该用 panic？

A：只在不可恢复的程序错误上用，比如初始化阶段读不到关键配置、数组越界这类逻辑 bug。普通的业务失败（文件不存在、参数错误）应返回 error，让调用方决定怎么降级。

Q：error wrapping 会不会影响性能？

A：几乎可忽略。包装只是多包一层结构，字符串格式化在出错分支才发生。相比它带来的可追踪性收益，性能开销不值得作为不用的理由，关键还是统一用 %w 的团队约定。