Go 的 error 接口仅含 Error() string 方法，旨在标准化错误表达而非抽象异常，强调开发者自主控制错误处理；fmt.Errorf 配 %w 支持错误链，errors.Is/As 依赖 Unwrap/Is/As 方法实现才能正确判断和提取底层错误。
Go 的 error 接口不是为了抽象异常，而是为了标准化错误值的表达和传递。它刻意保持极简（仅一个 Error() string 方法），不支持堆栈、类型断言自动展开或恢复机制——这不是缺陷，而是设计选择：把错误处理的控制权完全交还给开发者。
为什么 error 只有一个方法？
Go 拒绝“异常即控制流”的范式。一个字符串返回值足够用于日志、调试和简单判断；更复杂的上下文（如源文件、行号、嵌套原因）由具体实现决定，而非接口强求。这带来三个实际影响：
- 任何 struct、string、自定义类型只要实现了
Error() string就是error，无需继承或注册 - 无法在接口层统一获取堆栈——
runtime.Caller必须在构造错误时显式调用 - 无法通过接口方法重试、忽略或恢复错误——必须靠业务逻辑显式分支处理
fmt.Errorf 与 errors.New 的适用场景差异
两者都返回 *errors.errorString，但行为不同：
-
errors.New("failed")：纯静态字符串，无格式化，开销最小，适合固定错误消息 -
fmt.Errorf("read %s: %w", filename, err)：支持动参和错误链（%w），是 Go 1.13+ 推荐的包装方式 - 注意：
fmt.Errorf("err: %v", err)（用%v）会丢失原始错误类型，无法用errors.Is或errors.As判断
如何正确判断和提取底层错误？
Go 不提供 instanceof 式类型检查，而是用两个函数配合包装语义：
if errors.Is(err, os.ErrNotExist) {
// 匹配目标错误或其任意包装层级
}
var pathErr *os.PathError
if errors.As(err, &pathErr) {
// 提取最近一层匹配的 *os.PathError 实例
}
关键点：
-
errors.Is依赖Is(error)方法，标准库类型已实现；自定义错误需手动实现该方法才能参与链式匹配 -
errors.As只解包一层（即直接包装者），不会递归穿透多层%w - 若用
fmt.Errorf("wrap: %v", err)（非%w），整个链就断了——errors.Is和errors.As都失效
自定义 error 类型最容易被忽略的细节
写一个带字段的 error struct 很容易，但要让它真正融入 Go 错误生态，必须补全三件事：
- 实现
Error() string：
返回可读描述（通常包含字段值）
- 实现
Unwrap() error：返回内部嵌套的 error（如果有），否则返回nil - 实现
Is(error) bool和/或As(interface{}) bool：若需被errors.Is/errors.As识别
漏掉 Unwrap，%w 包装后就变成“黑盒”；漏掉 Is，下游就无法用 errors.Is(err, MySpecificError) 做语义判断——这些不是可选优化，而是参与标准错误协议的前提。
