Golang错误带堆栈信息传递方法

在 Golang 中，错误处理可通过 errors.New、runtime.Caller 或第三方库实现。1. errors.New 创建简单错误，无堆栈信息，适合内部调用层级不深的场景；2. runtime.Caller 可手动添加堆栈信息，便于定位错误位置，适合中间件或关键业务逻辑；3. 第三方库如 pkg/errors 提供更强大功能，支持错误链和包装机制，适合大型项目。选择方式取决于具体需求：简洁性、调试能力或功能丰富性。

在 Golang 中，错误处理是一个非常重要的部分。有时候你不仅仅需要知道一个错误发生了，还想知道这个错误是从哪里产生的——比如函数调用栈的信息。这就引出了两个常见的做法：使用 errors.New 创建普通错误，或者通过 runtime.Caller 手动添加堆栈信息。

下面我们就来看看这两种方式的区别和适用场景。

1. errors.New：简洁但没有堆栈信息

errors.New 是 Go 标准库中最基础的错误创建方法，它返回一个实现了 error 接口的结构体。它的优点是简单、清晰，适合大多数不需要追踪调用栈的场景。

err := errors.New("something went wrong")

但问题也在这里：它不包含任何堆栈信息。如果你在多层调用中返回了这样的错误，最终捕获的时候只能知道“出错了”，却不知道错在哪一层发生的。

使用建议：

• 用于内部函数或私有方法中，调用层级不深的情况。
• 如果你在上层已经能明确知道错误来源，也可以直接用这个。
• 不适合需要调试、排查问题的生产环境错误处理。

2. runtime.Caller：手动构造带堆栈的错误

如果你想让错误带上发生时的调用堆栈，可以使用 runtime.Caller 来获取当前调用栈信息，然后构建自定义错误类型。

示例代码如下：

type stackError struct {
    msg string
    file string
    line int
}

func (e *stackError) Error() string {
    return fmt.Sprintf("%s:%d: %s", e.file, e.line, e.msg)
}

func newStackError(msg string) error {
    _, file, line, _ := runtime.Caller(1)
    return &stackError{
        msg:  msg,
        file: file,
        line: line,
    }
}

这样生成的错误就会包含文件名和行号，方便定位问题。

使用建议：

• 适用于需要精确追踪错误位置的场景，比如中间件、公共库、关键业务逻辑。
• 可以结合 fmt.Errorf 或者封装成通用工具函数来简化使用。
• 性能开销略高，但在大多数情况下是可以接受的。

3. 更进一步：结合 pkg/errors 库（推荐）

虽然标准库的 errors 和 runtime 已经能满足基本需求，但在实际项目中，很多人会选择使用第三方库，比如 pkg/errors，它可以很方便地包装错误并记录堆栈信息。

err := errors.Wrap(err, "failed to do something")

它的好处包括：

• 自动记录调用堆栈。
• 支持错误链（error wrapping）。
• 提供 WithMessage、Wrap 等多种实用方法。

不过要注意的是，Go 1.13+ 开始支持标准库中的错误包装机制（fmt.Errorf 的 %w 动词），配合 errors.Is 和 As 函数也能实现类似功能。

小结一下

• errors.New：轻量、简单，但不带堆栈，适合本地或已知上下文的错误。
• runtime.Caller：可以自定义错误结构，带上堆栈信息，适合需要调试的场景。
• 第三方库（如 pkg/errors）：功能强大，使用方便，适合大型项目或对错误追踪要求高的系统。

基本上就这些区别。选择哪种方式，取决于你的具体使用场景和对错误信息的依赖程度。