Go 函数不能返回多个 error 类型值，因语言强制仅允许一个 error 返回值；应通过 errors.Is/As、自定义错误类型或 errors.Join 等方式分类和组合错误。
Go 中函数返回多个 error 类型值不仅不推荐，而且在语言层面根本不可行——Go 的函数签名只允许一个类型为 error 的返回值（哪怕你写两个 error，编译器也会报错）。所谓“返回多个 error”，实际是开发者试图用不同方式表达错误分类、上下文或组合逻辑，但误用了返回值设计。
为什么不能写 func Foo() (int, error, error)
Go 编译器会直接拒绝这种签名：multiple errors in function signature（非字面错误，但语义等价）。Go 的 error 是接口类型，设计初衷就是“单一出口”：任何错误都应满足 error 接口，由调用方统一判断、包装或透传。
- 语言强制要求：函数最多声明一个
error类型的返回值（可与其他非 error 类型并存，如(int, error)） -
标准库和生态全部遵循该约定，比如
os.Open()、json.Unmarshal()、http.Do()都只返回一个error - 若真需区分多种错误来源，应通过
errors.Is()/errors.As()或自定义错误类型来实现，而非拆成多个error返回值
想表达“多种错误情况”，该怎么做
常见误区是把不同错误原因硬塞进多个 error 返回位，结果导致调用方必须写一堆 if err1 != nil { ... } else if err2 != nil { ... }，既难读又破坏错误处理一致性。
- 用一个
error包装多个底层错误：调用fmt.Errorf("failed to X: %w", err)或errors.Join(err1, err2)（Go 1.20+） - 定义具名错误变量，便于判断：
var ErrNotFound = errors.New("not found")，再用errors.Is(err, ErrNotFound) - 需要携带额外字段（如状态码、重试建议）时，实现自定义错误结构体，并嵌入
error接口
type ValidationError struct {
Field string
Code int
Err error
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed on %s: %v", e.Field, e.Err)
}
func (e *ValidationError) Unwrap() error {
return e.Err
}
哪些场景容易误以为要多个 error
典型伪需求包括：“网络失败”和“解析失败”要分开返回、“数据库连接失败”和“事务回滚失败”要独立暴露。这些其实都属于错误链路中的不同环节，正确做法是分层包装，而不是平级并列。
- HTTP handler 中，
json.Decode()失败和db.Create()失败应分别包装，最终统一返回一个顶层error，调用方用errors.As()提取具体类型 - 并发操作中多个 goroutine 出错，应使用
errgroup.Group或errors.Join()合并，而非让函数返回(res1, res2, err1, err2) - 生成代码工具或 DSL 解析器中，可能有语法错误、类型错误、运行时错误三类，应统一为一个
ParseError类型，内部用字段区分类别，而非三个error
真正麻烦的不是“能不能返回多个 error”，而是没想清楚错误的归属层级和传播意图。Go 的单 error 设计倒逼你做错误建模——是终端用户需要看到的错误？还是调试时需追溯的底层原因？这两者通常不该出现在同一个返回位上。
