Go中函数返回error需显式检查，典型模式是if err != nil立即返回；应避免else嵌套以保持代码扁平；错误包装用%w保留原始信息以便errors.Is()判断；仅少数场景如defer file.Close()可忽略error并注释说明。
Go 中函数返回 error 的典型检查模式
Go 语言要求显式处理 error，没有异常机制，所以几乎所有 I/O、解析、网络操作等函数都以 error 为最后一个返回值。最常见写法是立即用 if err != nil 判断并提前返回：
func readFile(filename string) ([]byte, error) {
data, err := os.ReadFile(filename)
if err != nil {
return nil, fmt.Errorf("failed to read %s: %w", filename, err)
}
return data, nil
}
这种写法不是“风格选择”，而是 Go 编译器不强制但工具链（如 go vet）会警告未检查的 err。漏掉检查往往导致静默失败或 panic。
避免嵌套：用 if err != nil { return } 而非 else
初学者容易把成功逻辑包在 else 块里，造成深层缩进。Go 社区惯例是“快速失败”——出错立刻返回，让主逻辑保持左对齐：
// ✅ 推荐：扁平结构，易读易维护
func processConfig(path string) error {
cfg, err := loadConfig(path)
if err != nil {
return fmt.Errorf("load config: %w", err)
}
if !cfg.IsValid() {
return errors.New("config is invalid")
}
return saveProcessed(cfg)
}
// ❌ 不推荐：嵌套加深，错误路径和主逻辑耦合
func processConfigBad(path string) error {
cfg, err := loadConfig(path)
if err == nil {
if cfg.IsValid() {
return saveProcessed(cfg)
} else {
return errors.New("config is invalid")
}
} else {
return fmt.Errorf("load config: %w", err)
}
}
多层 if-else 还会让新增校验逻辑变得笨重，也增加漏处理 err 的风险。
立即学习“go语言免费学习笔记（深入）”；
error 包装与 unwrapping：用 %w 而非 %v
当需要在错误消息中保留原始原因以便调试或条件判断时，必须用 %w 动词包装，否则会丢失底层 error 链：
-
fmt.Errorf("failed: %w", err)→ 可用errors.Is()或errors.As()检查原始错误 -
fmt.Errorf("failed: %v", err)→ 仅字符串拼接，原始error类型信息丢失
常见误用场景：
// ❌ 错误：丢失原始 os.PathError
if os.IsNotExist(err) { ... } // 总是 false
// ✅ 正确：用 %w 包装后仍可识别
err = fmt.Errorf("reading file: %w", err)
if errors.Is(err, os.ErrNotExist) { ... } // ✅ 成立
注意：errors.Unwrap() 只解一层，errors.Is() 会递归遍历整个包装链，更安全。
何时忽略 error？只有极少数明确可忽略的场景
不是所有 error 都必须处理，但忽略前得有充分理由。以下情况可考虑忽略（但仍建议加注释说明）：
-
defer file.Close()中的err：文件已写完，关闭失败通常不影响业务逻辑，但需记录日志（如用log.Printf("close failed: %v", err)） -
os.Remove()删除一个可能不存在的临时文件：可用os.IsNotExist(err)判断后静默跳过 - 指标上报、审计日志等“尽力而为”操作失败
绝对不能忽略的典型例子：json.Unmarshal()、database/sql.QueryRow().Scan()、http.NewRequest() —— 这些失败意味着数据损坏、SQL 注入风险或请求构造错误，必须处理。
复杂点在于：error 处理不是孤立的语法问题，它和函数职责、调用方预期强相关。比如一个导出函数是否该把内部 io.EOF 向上暴露，取决于调用方是否需要区分“读完了”和“出错了”。这类设计决策比怎么写 if err != nil 更关键，也更容易被忽略。
