在go语言中处理错误时，保留调用栈信息有助于定位问题，常见的两种方式是fmt.errorf和errors.wrap。1. fmt.errorf是标准库提供的基础错误构造方式，适合快速构造新错误信息，但会丢弃原始错误的类型和堆栈信息，适用于不需类型判断的场景；2. errors.wrap来自第三方包pkg/errors，可在添加上下文的同时保留原始错误类型与调用栈，支持错误链追溯，更适合调试和维护复杂系统；3. 实际使用建议：若仅需报错内容可用fmt.errorf，若需保留错误源头信息则选errors.wrap或go 1.13+的%w格式，后者无需第三方依赖。选择方式应基于是否需要回溯错误根源。
在Go语言中，处理错误时我们经常需要保留调用栈信息以便定位问题。当错误在多层函数调用中传递时，如何清晰地记录错误路径就成了一个关键点。这时候就会遇到两个常用的错误包装方式：
fmt.Errorf和
errors.Wrap（来自
github.com/pkg/errors包）。它们都能对错误进行封装，但适用场景略有不同。
1. fmt.Errorf
：基础的错误构造方式
fmt.Errorf是标准库提供的方法，用于生成一个新的错误对象。它的使用非常简单，适合直接构造错误信息。
if err != nil {
return fmt.Errorf("failed to do something: %v", err)
}这种方式的问题在于：它会丢弃原始错误的类型信息和堆栈信息。如果你只是想把错误往上抛，并且不打算在上层根据具体错误类型做判断，那这可能没问题。但如果你需要保留原始错误以便后续断言或判断类型，就不推荐这样做。
立即学习“go语言免费学习笔记（深入）”；
优点：
- 标准库自带，无需引入第三方包
- 使用简单，适合快速构造错误信息
缺点：
- 不保留原始错误的堆栈信息
- 错误链断裂，不利于调试追踪
2. errors.Wrap
：带上下文信息的错误包装
errors.Wrap来自
pkg/errors这个流行的第三方包，它允许你在保留原始错误的同时添加上下文信息。比如：
if err != nil {
return errors.Wrap(err, "failed to do something")
}这样做的好处是：你可以通过 errors.Cause()
获取最原始的错误类型，也可以用
errors.WithStack()等方法来记录完整的调用栈，方便排查问题。
优点：
- 保留原始错误类型和堆栈信息
- 支持错误链追溯
- 更适合构建可维护、可调试的系统
缺点：
- 需要引入第三方依赖
- 如果过度使用，可能会导致日志信息冗余
3. 实际使用建议：分场景选择合适方式
在实际开发中，怎么选其实取决于你是否关心错误的“上下文”与“源头”。
如果你只关心最终报错内容：
可以使用
fmt.Errorf，尤其是你在做一些简单的封装或者不想引入额外依赖的时候。
如果你需要做错误类型判断或希望保留调用栈：
那就应该使用
errors.Wrap或者类似的方法，比如 Go 1.13+ 的
fmt.Errorf带
%w的写法：
return fmt.Errorf("additional context: %w", err)这样也能支持错误链的展开（通过
errors.Unwrap），而且不需要第三方库。
小结一下
fmt.Errorf
是标准做法，适合轻量级错误包装errors.Wrap
提供了更丰富的上下文信息，适合需要调试和错误链追踪的场景- Go 1.13+ 可以考虑使用
%w
来实现类似功能，避免引入第三方依赖
基本上就这些。选择哪种方式不复杂，但容易忽略的是你将来是否需要回溯错误根源。
