错误处理是 Go 语言中最具辨识度的设计之一。Go 通过一个简洁的接口和若干约定，将错误视为普通的值，而非异常控制流。随着 Go 1.13 对错误包装与判定功能的引入，错误处理体系变得更为成熟和统一。本文梳理 Go 错误机制的核心概念、标准用法及设计思路。
1. error 接口
Go 内置的 error 接口是所有错误值的抽象类型，其定义极为简单：
go
type error interface {
Error() string
}任何实现了 Error() string 方法的类型都可以作为 error 使用。这一设计使得错误值本身可以携带丰富的信息，而调用方只需将其作为值返回和检查。
2. 创建错误
2.1 errors.New
最基础的错误创建方式，适用于仅需传递静态错误信息的情景。
go
import "errors"
var ErrNotFound = errors.New("item not found")生成的错误仅包含一个字符串，无法携带额外上下文，但足以满足简单的判断场景。
2.2 fmt.Errorf
当需要格式化错误消息时，可以使用 fmt.Errorf。它支持类似 fmt.Sprintf 的格式动词。
go
name := "config.yaml"
err := fmt.Errorf("failed to read %s", name)在此之前，该函数只能生成包含格式化字符串的错误。自 Go 1.13 起，fmt.Errorf 新增了 %w 动词，用于包装另一个错误，这是后续错误链机制的基础。
3. 错误包装与解包
3.1 错误包装（wrapping）
在函数中捕获底层错误后，附加上下文信息再向上传递，这是 Go 中推荐的错误处理模式。fmt.Errorf 的 %w 动词能将一个已有的错误嵌入到新错误中，从而形成一条错误链。
go
func ReadConfig(path string) (Config, error) {
data, err := os.ReadFile(path)
if err != nil {
return Config{}, fmt.Errorf("reading config: %w", err)
}
// ...
}外层调用通过 ReadConfig 获得的错误，其文本信息包含了"reading config: ..."前缀，但同时又保留了对原始 err 的引用。这种做法既丰富了错误的语义，又不丢失底层的细节。
3.2 错误解包（unwrapping）
errors.Unwrap 函数用于从已包装的错误中提取内层错误。它要求传入的错误实现了 Unwrap() error 方法。通过递归解包，可以遍历整条错误链。
go
inner := errors.Unwrap(wrappedErr)多数情况下开发者无需手动解包，而是使用 errors.Is 和 errors.As 沿着错误链进行判定。
4. 错误的识别：errors.Is 与 errors.As
直接比较两个错误值通常不可靠，因为包装操作会改变最外层错误的地址。Go 1.13 提供了两个函数来沿着错误链进行比较和匹配。
4.1 errors.Is
errors.Is 判断错误链中是否存在与目标错误值相等的错误。它遵循如下逻辑：
- 首先使用
==比较当前错误与目标 - 若不等，则调用
Unwrap()继续向下比较，直到链结束或找到匹配
go
if errors.Is(err, fs.ErrNotExist) {
// 文件不存在的处理
}即使 err 被多层包装，只要底层是 fs.ErrNotExist，errors.Is 就能判定成功。这使得错误判断对包装透明。
4.2 errors.As
errors.As 用于从错误链中提取特定类型的错误。它会遍历错误链，尝试将每个错误赋值给目标类型，一旦成功即返回 true。
go
var pathErr *os.PathError
if errors.As(err, &pathErr) {
// 可以使用 pathErr.Path、pathErr.Op 等详细信息
}需要注意的是，errors.As 的第二个参数必须是一个指向某类型的指针的指针（即 **T），它会将匹配的错误设置到该指针指向的位置。
4.3 判定函数的设计
errors.Is 的判断基于等价比较，对于自定义错误类型，可以通过实现 Is(target error) bool 方法来提供自定义的相等逻辑。同样，errors.As 会检查错误是否实现了 As(target interface{}) bool 方法。这两个方法由标准库内部调用，允许自定义类型干预判定过程，通常用于实现更灵活的匹配规则。
5. 自定义错误类型
当需要传递比简单字符串更丰富的上下文时，可以定义自定义错误类型。
go
type ValidationError struct {
Field string
Value interface{}
Msg string
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed for %s: %s", e.Field, e.Msg)
}使用该类型时，调用方可以通过 errors.As 提取出 *ValidationError 来获取各个字段信息。
值得注意的是，自定义错误类型通常应以值类型实现 Error() 方法，而为了实现 Unwrap() 以便包装，则应返回内部包含的错误。例如：
go
type QueryError struct {
Query string
Err error
}
func (e *QueryError) Error() string {
return fmt.Sprintf("query %s: %v", e.Query, e.Err)
}
func (e *QueryError) Unwrap() error {
return e.Err
}如此设计的 QueryError 即可被 fmt.Errorf 的 %w 包装，也能被 errors.Is 和 errors.As 穿透到底层错误。
6. 错误处理的惯用模式
6.1 立即处理，不要忽略
Go 编译器允许忽略错误返回值（通过 _ 接收），但这通常被视为不良实践。每个错误都应该被显式处理，或者至少记录日志并决定是否继续。
go
data, err := os.ReadFile(path)
if err != nil {
log.Printf("read %s failed: %v", path, err)
return
}6.2 添加上下文向上传递
在底层函数返回错误时，调用者不应只做简单透传，而应添加有助于定位问题的上下文信息。这可以通过 fmt.Errorf 和 %w 完成。
go
func process(path string) error {
f, err := openFile(path)
if err != nil {
return fmt.Errorf("process %s: %w", path, err)
}
defer f.Close()
// ...
return nil
}这样在顶层打印错误时，能看到从入口到具体出错环节的完整链路。
6.3 避免重复包装
不必要的层层包装会使错误信息冗长且干扰判断。通常只在跨越函数边界、添加上下文信息时才进行包装。如果只是转发错误，可以原样返回。
6.4 预先定义哨兵错误
对于可以被上层程序判别的特定错误，使用包级别 var 定义哨兵错误值。
go
var ErrTxDone = errors.New("transaction has already been committed or rolled back")调用方用 errors.Is 检查此类错误，而不是依赖错误字符串的匹配。
6.5 错误只处理一次
每个错误应当只在最合适的层级处理一次：要么记录日志然后吞掉，要么传递下去。避免既记录日志又返回错误，这会导致重复日志输出。
7. 错误处理与 panic / recover
Go 中另有 panic 和 recover 机制，用于处理不可恢复的严重错误（如程序内部一致性被破坏），而非用于常规的业务错误。本文聚焦于 error 接口及其生态系统，故对 panic 不作展开。
8. 总结
Go 的错误处理哲学将错误视为值，通过接口和常规控制流进行处理。error 接口的极简设计为各类错误类型提供了统一容器；%w、errors.Is 和 errors.As 则构成错误包装、传递和判定的标准工具箱。
掌握这组核心机制，能够在不引入额外复杂度的前提下，构建出可读性好、可维护性强且信息充分的错误处理体系。这也是 Go 语言在工程实践中所追求的直接与清晰。