Go 语言在 1.20 版本中引入的一个实用功能：errors.Join()。掌握它，能让你的错误处理更加优雅和高效。
什么是 errors.Join()？
简单来说，errors.Join() 允许我们将多个 error 合并成一个单一的 error。
这个合并后的错误仍然可以通过 errors.Is 和 errors.As 进行检查，保持了与 Go 语言错误处理机制的一致性。
func Join(errs ...error) error它会将所有非 nil 的错误合并在一起。如果所有参数都是 nil，则返回 nil。
哪些场景适合使用 errors.Join()？
虽然在开发中通常推崇“快速失败”（Fail Fast）的原则，即遇到第一个错误就立即返回，但在一些特定场景下，收集并返回多个错误会更加合理。
1. 输入验证：一次性报告所有问题
在验证用户输入（如 API 请求参数、表单提交）时，如果每次只返回第一个校验错误，用户就需要反复提交和修改，体验很差。使用 errors.Join() 可以收集所有验证错误，一次性反馈给用户。
func validateUserInput(input UserInput) error {
var errs []error
if len(input.Username) < 3 {
errs = append(errs, errors.New("用户名长度不能小于3个字符"))
}
if !strings.Contains(input.Email, "@") {
errs = append(errs, errors.New("邮箱格式不正确"))
}
if len(input.Password) < 6 {
errs = append(errs, errors.New("密码长度不能小于6个字符"))
}
return errors.Join(errs...)
}2. 并行任务：收集所有协程的错误
当使用 goroutine 执行多个并行任务（如并发请求多个下游服务）时，如果只返回第一个发生的错误，可能会丢失其他重要信息。errors.Join() 可以帮助我们收集所有任务的错误。
func processTasks(tasks []Task) error {
var wg sync.WaitGroup
var mu sync.Mutex
var errs []error
for _, task := range tasks {
wg.Add(1)
go func(t Task) {
defer wg.Done()
if err := t.Execute(); err != nil {
mu.Lock()
errs = append(errs, err)
mu.Unlock()
}
}(task)
}
wg.Wait()
return errors.Join(errs...)
}3. 批量操作：汇总处理过程中的错误
处理多个文件或数据库记录时，即使部分操作失败，我们也可能希望继续执行其他操作，最后统一返回所有错误。
func processFiles(files []string) error {
var errs []error
for _, file := range files {
if err := processSingleFile(file); err != nil {
errs = append(errs, fmt.Errorf("处理文件 %s 失败: %w", file, err))
}
}
return errors.Join(errs...)
}4. Defer 中的错误：合并主体错误与清理错误
在函数中，我们常用 defer 执行清理操作（如关闭文件），这些操作也可能返回错误。如果函数主体和 defer 中都可能返回错误，可以使用 errors.Join() 合并它们。
func writeToFile(filename string, data []byte) (err error) {
f, err := os.Create(filename)
if err != nil {
return fmt.Errorf("创建文件失败: %w", err)
}
defer func() {
closeErr := f.Close()
err = errors.Join(err, closeErr)
}()
_, err = f.Write(data)
if err != nil {
return fmt.Errorf("写入文件失败: %w", err)
}
return nil
}使用 errors.Join() 的最佳实践
1. 🎯 明确适用场景，避免滥用
errors.Join() 虽好，但不要滥用。在绝大多数情况下，遇到第一个错误就“快速失败”仍然是更简单、更可预测的策略。
以下是一些使用原则：
- 适合：需要聚合多个独立错误以提供完整上下文或支持部分成功/部分失败的场景（如输入验证、批量操作）。
- 避免：错误之间存在依赖关系，后续操作依赖于前序操作的成功结果时。
2. 🔍 保持与 errors.Is() 和 errors.As() 的兼容
errors.Join() 返回的错误对象保持了与标准错误检查工具的兼容性。你可以这样使用：
err := processTasks(tasks)
if err != nil {
// 使用 errors.Is 检查特定错误
if errors.Is(err, ErrNetworkTimeout) {
// 处理网络超时
}
// 使用 errors.As 提取特定类型的错误
var validationErr *ValidationError
if errors.As(err, &validationErr) {
// 处理验证错误
}
}3. ⚙️ 考虑性能与资源消耗
在性能敏感的代码路径中，需要注意频繁创建错误对象可能带来的内存分配压力。在某些情况下，预定义错误变量可能更合适。
// 预定义错误变量，减少内存分配
var (
ErrValidationFailed = errors.New("验证失败")
ErrNetworkIssue = errors.New("网络问题")
)4. 🧩 设计清晰的 API 和错误契约
设计 API 时，应该明确：它可能返回哪些类型的错误？在什么情况下会返回错误？调用方应该如何响应这些错误？
如果一个 API 的职责是单一且明确的，那么通常情况下，它在遇到第一个无法自行处理的错误时就应该返回，而不是试图收集所有可能的内部错误再“打包”抛给调用者。
写在最后
errors.Join() 是 Go 错误处理工具箱中的一个有力补充，它特别适用于需要收集和报告多个错误而不是遇到第一个错误就立即终止的场景。
在以下情况下考虑使用 errors.Join()：
- 需要向用户或调用方报告多个错误（如表单验证、批量操作）。
- 执行并行操作且需要了解所有失败原因。
- 需要合并函数主体和 defer 中的错误。
在以下情况下避免使用 errors.Join()：
- 错误之间有关联，早期错误可能导致后续操作无意义。
- 性能极度敏感的代码路径。
- 简单操作，其中快速失败更合适。
良好的错误处理，在提供丰富信息和保持代码简单性之间找到平衡。选择合适的工具，并根据你的特定需求做出设计决策，才是编写健壮、可维护Go代码的关键。
