Go 的 error 接口仅定义 Error() string 是刻意设计，强调值语义、组合与显式判断；错误识别应使用 errors.Is/errors.As 而非字符串匹配，自定义错误需实现 Unwrap() 以支持链式比较。
Go 的 error 接口本身极其简单，但它的设计直接决定了整个生态的错误处理风格——不是靠类型继承或异常机制，而是靠值语义、组合与显式判断。
为什么 error 只有 Error() string 方法
这个极简定义（
type error interface { Error() string }）是刻意为之：它不约束实现方式，不预设错误分类，也不要求堆栈、码值或上下文。任何能返回字符串描述的类型都能成为 error，比如 fmt.Errorf 返回的底层结构、自定义 struct、甚至 nil 本身（表示无错误）。
这种设计让错误可以轻量构造，也避免了 Java 式的 Exception 层级膨胀。但代价是——你不能靠 switch err.(type) 安全识别所有错误类型，除非对方明确实现了你期望的接口（如 Timeout() 或 IsNotFound()）。
-
标准库中多数 I/O 错误实现了
Timeout() bool和Temporary() bool，但它们不是error接口的一部分，而是额外约定 -
os.PathError、net.OpError等都嵌入了error字段，用组合而非继承表达“错误+上下文” - 如果只依赖
Error() string做判断（比如strings.Contains(err.Error(), "timeout")），极易因描述变更而断裂
如何正确识别和区分错误类型
Go 鼓励用类型断言或 errors.Is/errors.As（Go 1.13+）做语义判断，而不是字符串匹配。
立即学习“go语言免费学习笔记（深入）”；
errors.Is(err, os.ErrNotExist) 利用底层的 Unwrap() 链递归比对目标错误值；errors.As(err, &pathErr) 尝试将错误链中的任意一层赋值给指定类型变量。
- 自定义错误必须实现
Unwrap() error才能被errors.Is正确穿透（例如用fmt.Errorf("wrap: %w", underlying)） - 若需暴露结构化信息（如 HTTP 状态码、SQL 错误码），应在错误类型中定义方法（如
StatusCode() int），并配合errors.As使用 - 不要在
Error() string中塞机器可读字段（如"code=404 msg=not found"），这会让调用方被迫解析字符串
为什么 Go 不支持 try/catch 或 throws 声明
这是设计选择，不是遗漏。Go 要求错误必须被显式检查（哪怕只是写 if err != nil { return err }），防止“静默失败”。编译器不会强制你处理 error，但工程实践和 linter（如 errcheck）会盯住未检查的返回值。
- 没有异常栈展开，意味着
defer+recover仅用于真正意外的 panic 场景（如空指针解引用），不能替代错误处理 - 多返回值天然支持
val, err := fn()模式，把错误当作普通值传递、转换、包装、丢弃，控制流完全透明 - 函数签名不声明可能返回的错误类型，所以无法静态知道
http.Get可能返回哪些具体错误——只能查文档或看源码
最易被忽略的一点：错误值的可比较性。error 是接口类型，两个 error 是否相等，取决于底层具体类型的 == 行为。标准库中 errors.New("x") == errors.New("x") 是 false，因为每次调用都生成新对象；而 os.ErrNotExist == os.ErrNotExist 是 true，因为它是包级导出的变量。别想当然认为相同描述的错误就相等。
