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”的肌肉记忆。
