使用错误包装可提升Go程序的可观测性。自Go 1.13起，fmt.Errorf配合%w动词能添加上下文并保留原始错误，支持errors.Is和errors.As进行类型判断。标准库不提供堆栈追踪，可借助github.com/pkg/errors等第三方库实现Wrap或WithStack以记录调用链。对于需结构化上下文的场景，推荐定义包含操作、资源、时间等字段的自定义错误类型，并实现Error和Unwrap方法。上层应优先使用errors.Is和errors.As遍历错误链进行语义清晰的判断与提取。选择策略应基于需求：标准库适合轻量级包装，第三方库适用于需要堆栈的调试，自定义错误则利于日志解析与监控。关键在于信息清晰有用，而非过度包装。
在Go语言开发中，错误处理是程序健壮性的关键部分。单纯返回一个错误往往不足以定位问题，尤其是在多层调用或复杂逻辑中。通过错误包装和添加上下文信息，可以显著提升调试效率和系统可观测性。
使用 fmt.Errorf 包装错误并保留原始错误
从 Go 1.13 开始，fmt.Errorf 支持使用 %w 动词来包装错误，这样既能添加上下文，又能保留原始错误供后续检查。
例如，在调用数据库时发生错误，你可以这样包装：
if err != nil {
return fmt.Errorf("failed to query user with id %d: %w", userID, err)
}
这里使用 %w 而不是 %v，确保返回的错误实现了 Unwrap() error 方法，允许上层代码通过 errors.Unwrap() 或 errors.Is()、errors.As() 进行判断。
立即学习“go语言免费学习笔记（深入）”；
利用 errors.Wrap 及第三方库增强堆栈信息
标准库不提供调用栈追踪功能。若需完整堆栈信息，可使用如 github.com/pkg/errors 这类流行库。
该库的 errors.Wrap(err, msg) 方法可在不丢失原始错误的前提下附加描述，并记录调用位置。
_, err := db.Query("SELECT ...")
if err != nil {
return errors.Wrap(err, "db query failed")
}
配合 errors.WithStack() 还能直接包裹并附带当前堆栈。在最终日志输出时，可用 errors.Print() 打印带堆栈的完整错误链。
自定义错误类型以携带结构化上下文
对于需要传递丰富上下文的场景，定义自己的错误类型更灵活。
比如创建一个包含操作、目标、时间戳的结构体错误：
type MyError struct {
Op string
Resource string
Err error
Time time.Time
}
func (e *MyError) Error() string {
return fmt.Sprintf("[%s] %s: %s on %s", e.Time.Format(time.Stamp), e.Op, e.Err.Error(), e.Resource)
}
func (e *MyError) Unwrap() error { return e.Err }
这样构造错误：&MyError{Op: "read", Resource: "config.yaml", Err: io.EOF, Time: time.Now()}，便于统一日志解析与监控告警。
合理使用 errors.Is 和 errors.As 判断错误类型
当错误被多层包装后，应避免用 == 或类型断言直接比较。推荐使用标准库提供的工具函数。
判断是否为特定错误：
if errors.Is(err, sql.ErrNoRows) {
// 处理记录未找到
}
提取特定类型的错误进行进一步处理：
var myErr *MyError
if errors.As(err, &myErr) {
log.Printf("Operation %s failed on %s", myErr.Op, myErr.Resource)
}
这些方法会自动遍历错误链，找到匹配项，是安全且语义清晰的做法。
基本上就这些。关键是根据项目需求选择合适的方式：标准库适合轻量级上下文添加，第三方库适合需要堆栈的场景，而自定义错误则适用于需结构化数据传递的系统。错误包装不是越多越好，清晰、有用才是目的。
