wrap 方法是 pkg/errors 包中用于包装错误并附加上下文信息的函数，其定义为 wrap(err error, message string) error。它能在保留原始错误的同时添加描述，便于追踪错误来源。使用时应在每层调用中用 wrap 封装下层错误并附上当前层的上下文，从而构建完整的错误链。查看完整错误信息可用 %+v 格式化输出或通过 errors.cause() 获取根源错误。使用 wrap 时应避免重复包装、确保传入非 nil 错误、正确记录日志，并注意兼容标准 error 接口。
在 Golang 中处理错误时，经常遇到一个问题：当错误从底层层层返回到上层调用者时，信息丢失或者难以定位问题根源。这时候就需要一种既能保留原始错误信息，又能附加上下文描述的错误处理方式。pkg/errors 提供的 Wrap 方法就是解决这个问题的关键。
什么是 Wrap 方法？
Wrap(err error, message string) error 是 pkg/errors 包中的一个核心函数。它的作用是将一个已有的错误包装起来，并附加一段描述性的信息。这样做的好处是可以构建出带有上下文信息的错误链，方便排查问题。
举个简单的例子：
立即学习“go语言免费学习笔记（深入）”；
err := doSomething()
if err != nil {
return errors.Wrap(err, "doSomething failed")
}如果 doSomething() 返回了一个错误，比如 “connection refused”，通过 Wrap 就能知道这个错误是在执行 doSomething 的时候发生的，而不是仅仅看到“connection refused”却不知道发生在哪一层。
如何正确使用 Wrap 构建错误链？
在多层嵌套调用中，每一层都应该使用 Wrap 来封装下层传来的错误，并加上当前层的上下文。这样做可以保证最终错误信息足够详细。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
举个结构清晰的例子：
func ReadFile(path string) error {
data, err := ioutil.ReadFile(path)
if err != nil {
return errors.Wrap(err, "ReadFile: failed to read file")
}
// ...
return processFile(data)
}
func processFile(data []byte) error {
if len(data) == 0 {
return errors.New("processFile: empty file")
}
// ...
return storeData(data)
}
func storeData(data []byte) error {
if err := db.Save(data); err != nil {
return errors.Wrap(err, "storeData: failed to save to database")
}
return nil
}在这个流程中，每一步都通过 Wrap 把错误带上当前上下文。一旦出错，你就能清楚地看到错误路径，比如：
storeData: failed to save to database: connection refused
而不是只看到最原始的 “connection refused”。
如何查看完整的错误链信息？
当你拿到一个被多次 Wrap 过的错误后，可以通过 errors.Cause() 或者 %+v 格式来查看完整堆栈信息。
- 使用
%+v打印错误会显示完整的错误链和每个层级的调用位置：
fmt.Printf("%+v\n", err)- 如果你想提取最原始的错误（比如判断是不是某个特定错误类型），可以用
errors.Cause()：
if errors.Cause(err) == io.EOF {
// handle EOF
}注意：Go 1.13+ 原生也支持了类似功能（如 errors.Unwrap 和 errors.Is），但在实际项目中 pkg/errors 仍因其丰富的调试信息而广受欢迎。
使用 Wrap 时需要注意什么？
虽然 Wrap 很实用，但也要注意以下几点：
- 不要过度包装：每层都加一样的描述，反而会让错误信息变得冗余。要确保每次包装都带来新的上下文。
-
避免空指针错误：传给
Wrap的第一个参数不能为nil，否则会导致 panic。建议先做非空判断。 -
日志记录方式：打印错误时尽量用
%+v，否则看不到完整的错误链。 - 兼容性考虑：如果你写的库可能会被其他人调用，最好保持返回的是标准 error 接口，而不是自定义错误类型。
基本上就这些。用好 Wrap 能让你的错误信息更清晰、更有价值，尤其是在复杂系统中定位问题时非常有用。
