Go 1.13通过%w支持错误包装，结合errors.Unwrap、Is和As实现多级错误溯源与类型判断，自定义错误需实现Unwrap方法以支持链式解析，避免重复包装和格式误用可提升可维护性。
在Go语言中，错误处理是程序健壮性的核心部分。当系统复杂度上升时，单一的错误返回无法满足调试和日志追踪的需求，因此需要实现多级错误传递与合理封装。Go 1.13引入了对错误包装（error wrapping）的支持，使得开发者可以在不丢失原始错误的前提下附加上下文信息，从而实现清晰的错误溯源。
使用%w格式化动词进行错误包装
从Go 1.13开始，fmt.Errorf 支持使用 %w 动词来包装已有错误。这种方式会创建一个新的错误，同时保留原始错误，供后续通过 errors.Unwrap 提取。
例如，在调用底层函数出错时，可以添加调用层的信息：
if err := readFile(name); err != nil {
return fmt.Errorf("failed to read config file %s: %w", name, err)
}
这里返回的错误既说明了“读取配置文件失败”，又保留了底层的具体错误（如文件不存在、权限不足等），便于上层判断和处理。
立即学习“go语言免费学习笔记（深入）”；
通过errors.Is和errors.As进行错误判断
在多层调用中，经常需要判断某个错误是否由特定类型或值引起。直接比较错误可能因中间层包装而失败。Go提供了两个实用函数：
- errors.Is(err, target)：判断错误链中是否存在与目标相等的错误。
- errors.As(err, &target)：判断错误链中是否有某个错误属于指定类型，并将其赋值给目标变量。
示例：
if err := operation(); err != nil {
if errors.Is(err, os.ErrNotExist) {
log.Println("file does not exist")
}
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("path error occurred on %s", pathErr.Path)
}
}
即使 operation() 返回的是被多次包装的错误，只要原始错误是 os.ErrNotExist 或包含 *os.PathError，上述判断依然有效。
自定义错误类型并支持包装
在业务逻辑中，常需定义带有额外信息的错误类型。实现多级传递时，应确保自定义错误也能被正确包装和解包。
例如：
type AppError struct {
Msg string
Err error // 包装原始错误
}
func (e *AppError) Error() string {
return e.Msg
}
func (e *AppError) Unwrap() error {
return e.Err
}
构造时可包装底层错误：
return &AppError{Msg: "service unavailable", Err: err}
这样上层仍可通过 errors.Is 或 errors.As 追溯原始错误，同时也可对 *AppError 类型做专门处理。
避免过度包装和信息丢失
虽然包装增强了上下文，但也要注意以下几点：
- 不要重复包装同一错误，否则会导致错误链冗长且难以解析。
- 使用 %v 而非 %w 会丢失原始错误，务必检查格式字符串。
- 日志中打印错误时建议使用 %+v（如果错误类型支持），以输出完整的堆栈或包装链。
第三方库如 github.com/pkg/errors 提供了更丰富的功能（如堆栈跟踪），但在标准库已支持基本包装的场景下，优先考虑减少依赖。
基本上就这些。掌握错误包装机制后，Go中的多级错误传递变得清晰可控，既能定位根源，又能提供丰富上下文，是构建可维护服务的关键实践。
