Go语言通过%w包装错误实现错误链，保留原始错误上下文并逐层添加信息，结合errors.Is和errors.As可精准判断和提取错误，自定义错误类型则增强上下文携带能力，构建清晰可靠的错误处理体系。
在Go语言中，错误处理是程序健壮性的重要组成部分。随着程序复杂度上升，仅返回一个简单的错误信息往往不足以定位问题根源。因此，实现错误链传递（Error Chaining）变得尤为关键——它能保留原始错误上下文的同时附加更丰富的调用路径信息，帮助开发者快速排查问题。
理解错误链的基本原理
错误链的核心思想是在不丢失底层错误的前提下，逐层包装并添加上下文信息。Go 1.13引入了对错误包装的支持，通过errors.Unwrap、errors.Is和errors.As等函数，使我们能够判断错误类型、提取原始错误或进行语义比较。
要实现错误链，通常使用fmt.Errorf配合%w动词来包装错误：
if err != nil {
return fmt.Errorf("failed to process user data: %w", err)
}
这样生成的错误既包含当前层级的描述，也保留了底层错误，形成一条可追溯的“链”。
立即学习“go语言免费学习笔记（深入）”；
使用%w进行错误包装
%w是实现错误链的关键。与%v不同，%w会将传入的error作为被包装错误嵌入新错误中。
- 每次调用fmt.Errorf(..., %w, err)都会创建一个新的错误实例，其内部持有原错误引用
- 可通过errors.Unwrap()逐层解包获取原始错误
- 推荐每一层只包装一次，避免重复包装导致信息冗余
示例：
func readConfig() error {
_, err := os.Open("config.json")
if err != nil {
return fmt.Errorf("reading config failed: %w", err)
}
return nil
}
func setupApp() error {
err := readConfig()
if err != nil {
return fmt.Errorf("initializing app failed: %w", err)
}
return nil
}
当setupApp()返回错误时，你可以沿着链路回溯到os.Open的具体失败原因。
利用errors.Is和errors.As进行错误判断
传统的错误比较使用==或errors.Cause()（第三方库），但在标准库支持下，errors.Is和errors.As更为安全可靠。
- errors.Is(err, target)：判断错误链中是否存在某个特定错误（如os.ErrNotExist）
- errors.As(err, &target)：判断错误链中是否含有指定类型的错误，并赋值给目标变量
例如：
err := setupApp()
if errors.Is(err, os.ErrNotExist) {
log.Println("config file not found")
} else if e, ok := err.(*os.PathError); errors.As(err, &e) {
log.Printf("path error occurred: %v", e.Path)
}
这种写法不受中间包装层数影响，只要原始错误存在即可正确匹配。
自定义错误类型增强上下文
对于需要携带额外信息的场景，可以定义结构体实现error接口，并支持包装行为。
type AppError struct {
Msg string
Op string
Err error
}
func (e *AppError) Error() string {
return fmt.Sprintf("%s: %v", e.Op, e.Err)
}
func (e *AppError) Unwrap() error {
return e.Err
}
func NewAppError(op, msg string, err error) *AppError {
return &AppError{Msg: msg, Op: op, Err: err}
}
使用方式：
err := readConfig()
if err != nil {
return NewAppError("setupApp", "failed to initialize", err)
}
这种方式便于统一日志格式、注入操作名、时间戳等元数据，适合大型项目。
基本上就这些。合理使用%w包装、结合Is/As判断、必要时定义结构化错误类型，就能构建清晰可靠的错误链体系。关键是保持每层职责明确，不丢失原始错误，也不过度包装。不复杂但容易忽略细节。
