Golang error类型使用详解

Go 语言中的 error 是一个需显式检查的接口类型，而非自动抛出的异常，正确使用它关乎程序健壮性与可维护性：必须用 if err != nil 判断、严禁忽略或布尔化错误；推荐 errors.New 和 fmt.Errorf（配合 %w 包装）创建错误，慎用自定义结构体；判定错误应依赖语义化的 errors.Is/errors.As，彻底摒弃脆弱的字符串匹配；包装错误仅在入口层添加必要上下文，避免冗余嵌套——每层 %w 都应服务于实际决策或调试需求，而非堆砌深度。掌握这些原则，才能让错误处理真正成为 Go 程序的守护者，而非隐患源头。

error 是接口，不是关键字，必须显式检查

Go 里 error 是一个内建的接口类型（type error interface { Error() string }），不是异常、不自动抛出、也不隐式中断流程。你写 json.Unmarshal(data, &v)，哪怕解码失败，程序照常往下跑——但 v 可能是零值或部分填充的脏数据，后续 panic 或逻辑错乱往往就从这里开始。

• 永远用 if err != nil 判断，不能写 if err（error 是接口，不支持布尔转换）
• 绝不要用 _ 忽略 err，除非你 100% 确认那个函数在当前上下文**不可能返回非 nil 错误**（比如 fmt.Sprintf）
• 错误检查要“fail fast”：出错立刻处理或返回，别堆一堆逻辑再回头查

创建 error 的三种常用方式：errors.New、fmt.Errorf、自定义结构体

简单场景用 errors.New；带变量或上下文就用 fmt.Errorf；只有当你需要调用方法（如 IsTimeout()）或被 errors.As 提取时，才定义结构体。

• errors.New("file not found") → 纯字符串错误，轻量、够用
• fmt.Errorf("failed to parse %s: %w", filename, io.ErrUnexpectedEOF) → 唯一推荐的包装方式，%w 保留底层错误链
• 自定义结构体要谨慎：90% 的业务错误不需要新类型；过度封装反而让 errors.Is 失效、增加测试负担

判断和提取错误：用 errors.Is 和 errors.As，别比字符串

靠 strings.Contains(err.Error(), "no such file") 判断错误类型是反模式：脆弱、不可移植、无法跨包复用。标准库和主流生态都依赖 errors.Is 和 errors.As 做语义化判定。

• errors.Is(err, os.ErrNotExist) → 检查错误链中是否存在目标错误（支持多层包装）
• errors.As(err, &pathErr) → 尝试把错误链里某个节点赋给 *os.PathError 这类具体类型，方便读取 pathErr.Path 等字段
• 别自己实现 IsXXX() 方法再手动遍历 Unwrap——errors.Is 已帮你做了

包装错误时只加一层上下文，别层层套娃

常见错误是每层都 fmt.Errorf("layer X: %w", err)，结果错误链拉得又长又没用："HTTP handler: service call: db query: read file: permission denied"。真正有用的只有最外层上下文 + 最内层根因。

• 入口层（如 HTTP handler）加一次上下文就够了：fmt.Errorf("create user: %w", err)
• 中间层（如 service）通常直接返回，或仅补充关键信息（如请求 ID）：fmt.Errorf("create user %s (req=%s): %w", userID, reqID, err)
• 底层（如 db、io）不包装，直接返回原始错误，留给上层决定怎么处理

最易被忽略的一点：错误链不是用来“展示深度”的，而是为了精准判定和调试。你写的每一层 %w，都要问一句——这层信息是否真的影响下游的决策逻辑？如果不是，那就别包。

今天关于《Golang error类型使用详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！