Go errors.Join怎样同时保留多个底层错误怎样在批处理代码中减少额外分配

我在整理一段批处理代码时，最先遇到的不是语法问题，而是错误信息在数据流转中被截断：一批任务明明有多个失败项，函数出口却只返回最后一个 error。只保留最后一个错误会覆盖前面的原因；把错误拼成字符串又会丢掉 errors.Is 和 errors.As 能识别的类型关系。

更合适的做法是：循环中只把非 nil 错误追加到切片，最后调用一次 errors.Join。它会过滤 nil 输入，在所有输入都是 nil 时返回 nil，并通过 Unwrap() []error 保留多错误树。官方文档：https://pkg.go.dev/errors

把错误看成一条数据链路：任务结果先过滤 nil，再进入错误切片，出口统一 Join 一次；成功路径不创建额外错误，调用方用 Is/As 读取结构。

为什么不能只保留最后一个错误

假设一批任务依次校验文件、同步配置和写入索引。如果每次失败都执行 lastErr = err，调用方最终只看到最后一个任务的错误，无法知道是否还有其他对象需要补偿。批处理错误通常应该同时满足两点：保留每个失败项的上下文，以及让调用方仍能按哨兵错误或自定义类型判断。

直接用字符串连接虽然看起来简单，但它把结构变成了文本。文本适合展示，不适合判断。errors.Join 的返回值可以被 errors.Is 和 errors.As 沿错误树检查，因此应该把聚合和展示分开。

用 errors.Join 保留多个失败项

最小写法是准备几个可能失败的操作，把非 nil 结果交给 errors.Join：

package main

import (
    "errors"
    "fmt"
)

var (
    errConfig = errors.New("配置文件无效")
    errIndex  = errors.New("索引写入失败")
)

func collectErrors() error {
    var errs []error

    // 只收集已经产生的错误，成功项不会进入切片。
    errs = append(errs, fmt.Errorf("同步 config.yaml: %w", errConfig))
    errs = append(errs, nil) // nil 会被 errors.Join 丢弃。
    errs = append(errs, fmt.Errorf("写入 users 索引: %w", errIndex))

    // 所有输入为 nil 时 Join 返回 nil，调用方可以直接按 error 判断。
    return errors.Join(errs...)
}

这里的关键不是把错误“拼起来”，而是保留每个错误作为树中的节点。错误文本会按换行连接，便于日志展示；程序判断仍应使用 errors.Is 或 errors.As。

用 errors.Is 和 errors.As 读取错误树

errors.Join 返回的错误实现了 Unwrap() []error。因此，调用方不需要知道内部切片，也不应该依赖换行后的错误文本：

func inspect(err error) {
    // Is 适合判断某个稳定的哨兵错误是否在聚合结果中。
    if errors.Is(err, errConfig) {
        fmt.Println("需要重新加载配置")
    }

    // As 适合提取某种自定义错误类型携带的字段。
    var pathErr *os.PathError
    if errors.As(err, &pathErr) {
        fmt.Println("失败路径:", pathErr.Path)
    }
}

多错误树会被 Is 和 As 继续遍历。需要注意的是，通用的 errors.Unwrap(err) 只处理 Unwrap() error，不会直接展开 errors.Join 返回的 Unwrap() []error；通常让 Is/As 完成语义检查更稳妥。

在循环中只为失败项收集错误

减少额外分配的重点是控制失败集合，而不是为了“看起来统一”给成功项创建占位错误。下面的函数把任务标识加入上下文，成功时直接跳过：

type Job struct {
    Name string
}

func runBatch(jobs []Job, run func(Job) error) error {
    // 预留少量容量，降低错误数量较多时的切片扩容次数。
    errs := make([]error, 0, len(jobs))
    for _, job := range jobs {
        if err := run(job); err != nil {
            // 只在失败分支包装一次，保留任务名和底层错误。
            errs = append(errs, fmt.Errorf("任务 %s: %w", job.Name, err))
        }
    }

    // Join 只在出口调用一次，空切片会得到 nil。
    return errors.Join(errs...)
}

容量预留不是越大越好：如果批次很大且失败很少，按 len(jobs) 预留可能浪费内存。可以根据已知失败率设置较小容量，或让切片按需增长。对我来说，真正稳定的原则是成功路径不生成包装错误，失败路径只围绕已有错误增加一次上下文，最后才把集合交给 errors.Join。

空值、单错误和重复包装怎么处理

如果接口明确要求返回原错误身份，单错误时直接返回可能更直观；如果调用方只依赖 errors.Is 和 errors.As，统一调用 Join 能减少分支。无论哪种选择，都不要把错误文本拆分后再反向判断。

相关问题

errors.Join 会忽略 nil 吗？会。nil 输入会被丢弃，全部输入为 nil 时返回 nil。

能否用 errors.Unwrap 取出 Join 的全部错误？不能直接取出。Join 使用的是 Unwrap() []error，应优先使用 errors.Is 和 errors.As。

批处理是不是一定要预留 len(jobs) 的容量？不一定。容量应该根据批次大小、失败率和内存预算决定；预留只是降低扩容的一个选择。

这套写法适合谁？适合需要同时处理多个独立任务、又希望调用方保留错误类型判断的服务和批处理程序；单个操作的简单函数通常直接返回原错误更清楚。