Go函数返回多个值时如何处理error_Go error返回模式解析

Go函数返回多个值时error必须放在最后，以便if err != nil快速判断、配合:=声明且避免解构混乱；需显式检查不可忽略，推荐早返回而非defer或panic处理业务错误。

Go语言中函数返回多个值（尤其是带error）是标准做法，核心原则是：**把error作为最后一个返回值，调用时必须显式检查，不能忽略**。

为什么error总放在最后？

这是Go的约定俗成，便于配合if err != nil快速判断。编译器不强制，但所有标准库、主流项目都遵循这一模式，保持一致性。

• 方便和:=短变量声明配合使用，比如：result, err := doSomething()
• 支持defer+recover之外的显式错误处理路径，更清晰可控
• 避免把error夹在中间导致解构混乱，例如a, err, b := f()语义模糊

常见error处理写法（推荐 vs 不推荐）

推荐写法：立即检查，早返回

data, err := readFile("config.json")
if err != nil {
    return fmt.Errorf("failed to read config: %w", err)
}
// 继续处理 data

不推荐写法：

• 忽略error：data, _ := readFile("config.json") —— 可能掩盖关键失败
• 延迟检查：defer func(){ if err != nil { log.Fatal(err) } }() —— defer不适用于控制流分支
• 用panic代替error返回 —— panic用于真正异常（如空指针），不是业务错误

自定义error与错误链（Go 1.13+）

用%w动词包装底层错误，保留原始上下文；用errors.Is()或errors.As()做语义判断：

if errors.Is(err, os.ErrNotExist) {
    // 文件不存在，可尝试创建
}
var pathErr *os.PathError
if errors.As(err, &pathErr) {
    log.Printf("I/O error on %s: %v", pathErr.Path, pathErr.Err)
}

多返回值函数的设计建议

• 只在必要时返回多个值，避免过度设计（例如不需要同时返回count, total, err，可封装为结构体）
• 若逻辑上必然成对出现（如key/value查找），可返回value, ok, err，其中ok表示存在性，err表示操作失败
• 导出函数的error类型尽量用接口（如error），内部实现可用自定义类型，利于解耦

基本上就这些。Go的error处理不复杂但容易忽略，关键是养成“每次调用都看err”的肌肉记忆。