Go通过显式返回error接口值处理错误，需主动检查；标准errors.New和fmt.Errorf（支持%w嵌套）适用于简单与上下文错误；自定义错误类型可扩展字段和方法；应使用errors.Is/As判断而非字符串匹配；错误链和统一日志增强可维护性。
在 Go 中，错误处理不是靠异常机制，而是通过显式返回 error 类型值来实现的。Go 要求你“看见”错误、主动检查它，而不是隐式抛出和捕获。掌握标准 error 接口、合理使用 errors.New 和 fmt.Errorf，再配合自定义错误类型，就能写出清晰、可调试、可扩展的错误处理逻辑。
理解 error 是一个接口，不是特殊类型
Go 的 error 是一个内建接口：
Error() string
}
任何实现了 Error() string 方法的类型，都可作为 error 使用。标准库中的 errors.New("msg") 返回的是一个内置的私有结构体，它只携带字符串；而 fmt.Errorf("format %v", v) 支持格式化，还支持嵌套（用 %w 动词）。
- 用
errors.New创建简单、无上下文的错误，比如errors.New("file not found") - 用
fmt.Errorf添加动态信息或包裹底层错误，比如fmt.Errorf("reading config: %w", err) - 不要忽略返回的 error，至少写
if err != nil { return err }或明确记录/处理
用 %w 实现错误链（Wrapping），保留原始错误上下文
从 Go 1.13 开始，%w 动词让错误可以嵌套，形成“错误链”。这让你既能向上层提供有意义的错误消息，又能用 errors.Unwrap、errors.Is、errors.As 向下检查原始错误类型或值。
立即学习“go语言免费学习笔记（深入）”；
- 包装：
return fmt.Errorf("failed to connect to DB: %w", sql.Open(...)) - 判断是否是某类错误：
if errors.Is(err, os.ErrNotExist) { ... } - 提取底层错误实例：
var pathErr *os.PathError; if errors.As(err, &pathErr) { log.Println("path:", pathErr.Path) } - 避免用
==或strings.Contains(err.Error(), "...")做错误判断，它们脆弱且不可靠
定义自定义错误类型，支持更多行为和字段
当需要携带状态码、追踪 ID、重试建议等额外信息时，定义结构体并实现 Error() 方法即可：
Field string
Value interface{}
Code int
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed on %s: %v (code: %d)", e.Field, e.Value, e.Code)
}
// 可选：实现 Is 或 As 的支持，便于统一判断
func (e *ValidationError) Is(target error) bool {
_, ok := target.(*ValidationError)
return ok
}
- 导出字段方便外部读取（如日志、API 响应）
- 若需类型断言或行为扩展（比如
Retryable()方法），直接加方法即可 - 注意：如果要参与错误链，推荐用
fmt.Errorf("...: %w", e)包装，而非自己实现Unwrap()—— 除非你有特殊需求
统一错误处理模式：中间件、defer 恢复、日志增强
在实际项目中，错误不只出现在函数内部，还需考虑 HTTP handler、CLI 命令、数据库事务等场景：
- HTTP handler 中，用 defer + recover 处理 panic（仅限真正意外），但常规错误应由 handler 显式返回并转为 HTTP 状态码
- CLI 工具可用
main()返回error，被os.Exit(1)自动处理；配合log.SetPrefix("[ERROR] ")统一日志前缀 - 关键操作前后用
defer记录成功/失败，比如defer func() { if err != nil { log.Printf("operation failed: %v", err) } }() - 避免重复打印同一错误：不要在每一层都
log.Println(err)，而是在最外层（如 main 或 handler）集中记录，并保留完整错误链
