在 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 接口的结构体。它的优点是简单、清晰，适合大多数不需要追踪调用栈的场景。
立即学习“go语言免费学习笔记（深入）”；
err := errors.New("something went wrong")但问题也在这里：它不包含任何堆栈信息。如果你在多层调用中返回了这样的错误，最终捕获的时候只能知道“出错了”，却不知道错在哪一层发生的。
使用建议：
- 用于内部函数或私有方法中，调用层级不深的情况。
- 如果你在上层已经能明确知道错误来源，也可以直接用这个。
- 不适合需要调试、排查问题的生产环境错误处理。
2. runtime.Caller：手动构造带堆栈的错误
如果你想让错误带上发生时的调用堆栈，可以使用 runtime.Caller 来获取当前调用栈信息，然后构建自定义错误类型。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
示例代码如下：
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）：功能强大，使用方便，适合大型项目或对错误追踪要求高的系统。
基本上就这些区别。选择哪种方式，取决于你的具体使用场景和对错误信息的依赖程度。
