Go中调用errors.Join仅传入单个错误是否存在问题？

问题背景 #

Go 1.20引入了errors.Join函数用于合并多个错误，现在有个实际场景的疑问：仅传入单个错误调用该函数是否存在问题？

比如处理可写文件的关闭错误时，传统写法会用命名返回值，仅在主逻辑无错误时才把Close的错误赋值给返回的err，避免静默丢失关闭错误：

defer func() {
    cerr := f.Close()
    if err == nil {
        err = cerr
    }
}()

而改用errors.Join的写法更简洁，看起来能同时保留主逻辑和关闭的错误：

defer func() {
    cerr := f.Close()
    err = errors.Join(err, cerr)
}()

但这里有个细节：当err和cerr其中一个为nil、另一个非nil时，errors.Join不会直接返回那个非nil错误，而是返回一个包装它的errors.joinError结构。这种包装会不会引发问题？尤其是调用栈中多个函数都采用这种写法，导致单个错误被多层包装的情况？

核心分析与结论 #

调用errors.Join传入单个非nil错误本身不会触发功能性问题，但需要注意几个细节：

1. 标准错误判断不受影响 #

Go标准库的errors.Is、errors.As函数支持穿透joinError包装，所以即便错误被单层或多层joinError包裹，依然能正常判断错误类型、匹配特定错误值。比如：

var ErrCustom = errors.New("custom error")

func foo() error {
    return errors.Join(ErrCustom, nil)
}

func bar() error {
    return errors.Join(foo(), nil)
}

func main() {
    err := bar()
    fmt.Println(errors.Is(err, ErrCustom)) // 输出 true
}

2. 多层包装的冗余问题 #

如果多个层级的函数都用errors.Join包装单个错误，会形成joinError(joinError(原错误))的嵌套结构，带来两个小问题：

• 错误的字符串输出会出现冗余，比如打印时会看到[[custom error]]这类重复包裹的格式；
• 若有自定义错误处理逻辑依赖于错误的具体类型（而非标准的Is/As方法），可能会出现不兼容的情况。

3. 场景适配建议 #

• 如果需要完整保留所有可能的错误（比如主逻辑错误和文件关闭错误都不能丢），errors.Join的写法更合理，因为它不会丢失任何错误信息；
• 如果担心多层包装的冗余，可以在调用前做简单判断，仅在存在多个非nil错误时使用errors.Join，否则直接返回原错误：

  defer func() {
      cerr := f.Close()
      if err == nil {
          err = cerr
      } else if cerr != nil {
          err = errors.Join(err, cerr)
      }
  }()
  

  这种写法兼顾了错误不丢失和避免不必要的包装。

内容的提问来源于stack exchange，提问作者user200783