Go errors.Join 怎样减少临时分配

如果一段批量校验代码在循环里不断调用 errors.Join，临时切片和错误文本就会跟着中间结果反复创建。更稳妥的做法是：先在调用方收集非 nil 错误，必要时预留容量；等一批工作结束后只调用一次 errors.Join；程序判断错误类型时使用 errors.Is 或 errors.As，不要为了判断而提前把错误转成字符串。

但要先划清边界：errors.Join 并不是零分配函数。当前标准库实现会先数出非 nil 参数，再为返回的 joinError 建立一份精确容量的错误切片。因此本文讨论的是如何减少调用方和循环中的额外临时分配，而不是承诺 Join 本身没有分配。

errors.Join 到底会分配什么

errors.Join(errs ...error) 会丢弃 nil 参数；如果所有参数都是 nil，直接返回 nil。只要存在一个非 nil 错误，它就会创建一个聚合错误，并把非 nil 错误保存到内部切片中。这样返回值才能继续被 errors.Is 和 errors.As 检查。

从工程角度看，可以把成本拆成三层：

所以，“减少临时分配”的目标应当写成“减少不必要的中间结果”，而不是“让 errors.Join 变成零成本”。

在调用方一次收集错误

批量校验通常不需要在每个项目完成时立刻生成聚合错误。可以先把具体错误保留在调用方的切片里，最后再统一决定是否返回聚合结果。下面的例子把错误收集和错误组合分开：

package main

import "errors"

type Item struct {
	Name  string
	Active bool
}

func validateItem(item Item) error {
	if item.Name == "" {
		return errors.New("名称为空") // 保留具体校验原因，交给边界统一组合
	}
	if !item.Active {
		return errors.New("项目未启用") // 单项错误不在这里调用 errors.Join
	}
	return nil
}

func validateBatch(items []Item) error {
	// 预留大致容量，减少收集阶段的后备数组扩容；容量不是正确性的前提。
	errs := make([]error, 0, len(items))
	for _, item := range items {
		if err := validateItem(item); err != nil {
			errs = append(errs, err) // 只保存非 nil 错误，避免无意义占位
		}
	}

	// 只在批次边界组合一次；没有错误时 Join 会返回 nil。
	return errors.Join(errs...)
}

这里的容量预留是一个工程选择：如果输入批次很大但失败比例很低，直接按 len(items) 预留可能浪费空间，可以改成经验上限，或者让切片自然增长。关键点是不要为了“每轮都返回一个当前累计错误”而在循环中反复调用 Join。

把 Join 推迟到边界

如果业务流程需要继续处理所有项目，就让内部函数返回结构化的单项错误，直到真正的 API、任务或命令边界再组合。这样中间层不需要反复拆解和重新格式化错误。

func importAll(records []Item) error {
	// 这个切片只在本次导入中使用，返回 Join 后不再修改它。
	collected := make([]error, 0, minInt(len(records), 64))
	for _, record := range records {
		if err := validateItem(record); err != nil {
			collected = append(collected, err) // 保留原始 error，便于后续 Is/As
		}
	}

	// 在对外返回前才建立聚合错误，避免每条记录都产生一个中间聚合值。
	return errors.Join(collected...)
}

func minInt(a, b int) int {
	// 限制初始容量只影响内存预留，不改变最终错误集合。
	if a 

有一个容易忽略的生命周期规则：errors.Join 返回的聚合错误会持有内部错误切片。调用方的 collected 本身在 Join 内部会被复制到另一份精确容量切片，但其中的错误对象仍然是同一组接口值。不要在聚合错误仍会被使用时，把这些错误对象背后的可变状态交给另一个 goroutine 修改。

不要在循环里反复格式化错误

多错误的 Error() 文本是按错误顺序拼接并用换行分隔的。它适合日志、命令行提示和最终响应，不适合用来驱动程序判断。下面这种写法会不断产生中间文本，且丢失了结构化匹配能力：

func badSummary(items []Item) string {
	var summary string
	for _, item := range items {
		if err := validateItem(item); err != nil {
			// 循环内反复拼接字符串，会制造中间文本；这里只作反例说明。
			summary += err.Error() + "; "
		}
	}
	return summary
}

更好的方式是先保留错误对象，最终确定需要展示时再读取一次文本：

func summarize(items []Item) (string, error) {
	err := validateBatch(items)
	if err == nil {
		return "通过", nil // 没有错误时不创建聚合文本
	}

	// 只在确实要返回展示文本时调用一次 Error；程序判断不要依赖字符串。
	return err.Error(), err
}

如果调用方要判断某个哨兵错误或提取自定义错误类型，应保留返回的 error 并使用匹配 API：

var ErrInvalidItem = errors.New("无效项目")

func isInvalid(err error) bool {
	// errors.Is 会遍历 Join 返回的多错误树，不需要先读取 Error 文本。
	return errors.Is(err, ErrInvalidItem)
}

按场景选择是否 Join

不是所有错误都需要聚合。可以用下面的决策表确定边界：

此外，调用方可以使用一个短生命周期的 []error 缓冲，但不能无条件把它放进全局池。聚合错误会保留错误对象；如果对象包含大切片、请求上下文或不应延长生命周期的引用，盲目复用反而可能造成内存滞留。

结论：减少的是中间结果，不是 Join 的必要成本

围绕 errors.Join 做性能整理时，优先检查三个问题：是否在循环内重复 Join，是否为了判断错误而重复调用 Error()，以及收集切片是否可以在明确生命周期内预留容量。把错误对象保留到最后一次边界组合，通常就能消掉大部分不必要的中间结果。

同时要接受一个事实：只要需要返回多个错误，errors.Join 就需要建立自己的聚合表示。正确的优化目标是让这次必要的分配只发生一次、发生在合适的边界，并让后续代码继续使用 errors.Is 与 errors.As 的结构化能力。

相关问题

errors.Join 传入的 nil 会怎样？

nil 参数会被丢弃；如果所有参数都是 nil，返回值就是 nil。

errors.Join 后还能用 errors.Is 吗？

可以。非 nil 的 Join 返回值实现了 Unwrap() []error，errors.Is 和 errors.As 会遍历这棵错误树。

为了减少分配，能不能直接复用 Join 内部的切片？

不能把 Join 的内部切片当成公开缓冲区使用。调用方可以复用自己的收集切片，但应让聚合错误独占其生命周期，不要在仍会读取聚合错误时改写相关错误对象。