Go 中的 error 是接口类型，需实现 Error() 方法；须显式返回和检查，不可忽略；错误链用 errors.Is/As 判断；自定义错误应避免在 Error() 中打日志或冗余包装。
Go 中的 error 类型本质就是接口
Go 的 error 不是特殊语法糖，而是标准库定义的一个接口：
type error interface {
Error() string
}任何实现了 Error() 方法的类型，都可赋值给 error。这意味着你可以直接用 errors.New("xxx") 或 fmt.Errorf("xxx") 构造基础错误，也能自定义结构体实现更丰富的上下文（比如带码、时间、堆栈）。
常见误区是把 error 当作异常来“抛出”——Go 没有 throw 或 try/catch。它靠显式返回和判断：函数签名末尾常带 error，调用后必须检查，否则 go vet 会警告未使用的返回值。
不要忽略 error 返回值
这是 Go 项目中最高频的 bug 来源。例如：
os.Open("config.json") // ❌ 忽略 error，文件不存在时程序 panic 或静默失败正确做法是立即检查：
- 用
if err != nil分支处理，而非嵌套在if err == nil里——前者更易读且防漏判 - 短变量声明要小心作用域：
if f, err := os.Open(...); err != nil { ... }中f在 if 外不可用 - 多个连续 I/O 操作时，别重复写
if err != nil，可用辅助函数或defer func()统一收口（但仅限清理，不替代判断）
区分 errors.Is 和 errors.As 的使用场景
Go 1.13 引入了错误链（fmt.Errorf("wrap: %w", err)），使得错误可嵌套。此时不能只用 == 或 strings.Contains(err.Error(), "...") 判断——它们无法穿透包装层。
errors.Is(err, target) 用于判断错误链中是否存在某个**预定义的哨兵错误**（如 io.EOF、os.ErrNotExist）；errors.As(err, &target) 用于提取错误链中第一个匹配的**具体错误类型**（比如你自定义的 *MyAppError）。
典型误用：
if err == os.ErrNotExist { ... } // ❌ 可能被 fmt.Errorf("%w", ...) 包裹，失效 if errors.Is(err, os.ErrNotExist) { ... } // ✅ 正确
t { ... } // ❌ 可能被 fmt.Errorf("%w", ...) 包裹，失效
if errors.Is(err, os.ErrNotExist) { ... } // ✅ 正确自定义错误类型要谨慎加堆栈，别滥用 fmt.Errorf("%w")
加堆栈对调试有用，但有代价：分配内存、影响性能、暴露内部路径。生产环境建议只在关键入口（如 HTTP handler、CLI 主命令）做一次包装，而不是每层都 fmt.Errorf("failed to parse: %w", err)。
若需结构化错误，推荐组合方式：
- 定义带字段的 struct：
type ValidationError struct { Field string; Msg string; Code int } - 实现
Error()方法（返回用户友好的消息） - 实现
Unwrap()方法（返回嵌套的底层 error，支持errors.Is/As） - 避免在
Error()中拼接堆栈字符串——交给日志系统统一处理更可控
最常被忽略的一点：错误不是日志。不要在 Error() 方法里调用 log.Printf 或写文件，那会污染错误语义，也破坏纯函数原则。
