Golang错误处理最佳实践与设计模式

Go语言的错误处理核心在于将error视为需显式传递和决策的值，而非用于控制流的异常机制；文章系统阐述了如何避免滥用panic、正确使用errors.Is/As进行语义化错误判断、通过%w包装增强上下文、设计可测试的错误传播链，并强调错误处理的本质是面向调用方的责任划分与业务意图表达——每一处if err != nil背后，都应有清晰的失败应对策略，而非机械返回或静默忽略。

Go 中 error 类型不是异常，别用 panic 处理业务错误

Go 的 error 是值，不是控制流机制。把业务逻辑错误（如用户输入非法、数据库记录不存在）交给 panic，会导致调用栈中断、难以 recover，且掩盖了本该显式处理的失败路径。

常见错误现象：panic: record not found 被顶层 recover 拦截后吞掉，日志里只留一行空 panic，根本看不出是哪个 SQL 查询失败。

• 仅在程序无法继续运行时用 panic（如配置文件缺失、监听端口被占用）
• 所有 I/O、网络、解析、校验类操作，必须返回 error 并由调用方决定如何响应
• 避免在库函数中 log.Fatal 或 os.Exit，这会剥夺使用者的错误处置权

用 errors.Is 和 errors.As 判断错误类型，而不是字符串匹配

早期 Go 项目常写 if strings.Contains(err.Error(), "timeout")，这种写法脆弱：错误消息一变就失效，且无法跨包复用语义。

Go 1.13 引入的 errors.Is 和 errors.As 支持对包装错误（wrapped error）做语义化判断：

if errors.Is(err, context.DeadlineExceeded) {
    // 处理超时
}
var netErr net.Error
if errors.As(err, &netErr) && netErr.Timeout() {
    // 更细粒度的网络超时判断
}

• 自定义错误应实现 Unwrap() error 方法，或直接用 fmt.Errorf("wrap: %w", err)
• 第三方库返回的错误若未包装（如某些旧版 PostgreSQL 驱动），可先用 errors.Unwrap 尝试降级
• 不要依赖 err == someErrVar 做判断——除非你明确控制了错误变量的唯一性（如 var ErrNotFound = errors.New("not found")）

不要忽略 error，但也不要无脑 if err != nil 后全盘返回

忽略错误（_ = doSomething()）是 Go 最常见 bug 来源；但另一种倾向是每层都原样返回，导致上层拿到的错误堆栈浅、上下文丢失。

关键在于区分「错误传播」和「错误增强」：

• 底层调用失败，但当前函数语义上可以兜底（如缓存未命中则查 DB），就不该把底层错误透传上去
• 需要传递错误时，优先用 %w 包装：return fmt.Errorf("fetch user %d from db: %w", id, err)
• 导出函数的错误应尽量包含动作 + 对象 + 原因（如 "decode JSON body: invalid character 'x'"），而非仅 "invalid input"
• HTTP handler 等入口处可统一用中间件捕获并转为 HTTP 状态码，但中间业务层不应自己写 http.Error

测试中主动构造和断言错误，尤其是包装链

很多 Go 项目只测“成功路径”，等线上遇到 io.EOF 或自定义 ErrValidation 才发现处理逻辑没覆盖。

单元测试要验证错误是否被正确包装、是否能被 errors.Is 识别、是否含预期字段：

func TestFetchUser(t *testing.T) {
    svc := &Service{repo: &mockRepo{err: errors.New("db timeout")}}
    _, err := svc.GetUser(123)
    if !errors.Is(err, context.DeadlineExceeded) {
        t.Fatal("expected wrapped timeout error")
    }
}

• mock 对象应支持返回各种预设错误（io.EOF、sql.ErrNoRows、自定义错误等）
• 对返回错误的函数，至少写一个 “error path” 测试用例
• 使用 testify/assert.ErrorIs 或原生 errors.Is 断言，别用 assert.EqualError 比对字符串

错误处理真正难的不是语法，而是每次调用前想清楚：这个错误发生时，调用方需要知道什么？它能否重试？要不要告警？有没有更友好的降级方式？这些决策藏在每一行 if err != nil 后面。

今天关于《Golang错误处理最佳实践与设计模式》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！