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) 做语义判断——这些不是可选优化，而是参与标准错误协议的前提。