Go 的 error 接口不可扩展，但可通过自定义结构体实现 error 并添加额外方法（如 Code、Unwrap），再用类型断言或 errors.As 提取；必须实现 Unwrap() 才支持 errors.Is/As 的错误链解析。
Go 的 error 接口本身不能扩展
Go 标准库定义的 error 接口只有 Error() string 这一个方法，它是一个**极简、不可变的契约**。你无法给它添加新方法，也不能“继承”它去构造子接口——Go 没有传统 OOP 的继承机制，接口只能被实现，不能被扩展。
但你可以定义自己的接口（比如 WrappedError、TimeoutError），只要它包含 Error() string，就自动满足 error 接口，同时还能提供额外方法。这才是 Go 中处理错误多态性的惯用方式。
如何让自定义错误既兼容 error 又带额外能力
典型做法是：定义一个结构体实现 error，再额外声明方法；同时可选地让它实现一个更丰富的自定义接口。关键在于类型断言时的判断路径。
- 必须实现
Error() string方法，否则不满足error接口 - 额外方法（如
Unwrap() error、Code() int、Retryable() bool）按需添加，不破坏兼容性 - 调用方通过
if e, ok := err.(MyCustomError); ok { ... }或errors.As(err, &e)提取具体类型 - 避免在基础
error接口上“强行加方法”，那会导致编译失败
type MyAPIError struct {
msg string
code int
raw error
}
func (e *MyAPIError) Error() string { return e.msg }
func (e *MyAPIError) Code() int { return e.code }
func (e *MyAPIError) Unwrap() error { return e.raw }
// 使用示例：
err := &MyAPIError{msg: "not found", code: 404}
fmt.Println(err.Error()) // ✅ 输出 "not found"
if apiErr, ok := err.(*MyAPIError); ok {
fmt.Println(apiErr.Code()) // ✅ 输出 404
}
errors.Is 和 errors.As 要求你实现 Unwrap()
如果你希望自定义错误能被 errors.Is（匹配底层错误）或 errors.As（提取具体类型）正确识别，就必须实现 Unwrap() error 方法。这是标准库约定，不是强制接口的一部分，但工具链依赖它。
- 返回
nil表示无嵌套错误（终端错误） - 返回非
nil表示错误链中还有上游错误，会被递归检查 - 多个嵌套层级时，每个中间错误都应实现
Unwrap() - 若忘记实现，
errors.As将无法向下穿透到内层类型
func (e *MyAPIError) Unwrap() error { return e.raw } // 必须写这一行，否则 As/Is 失效
别用空接口或反射绕过类型安全
有人试图用 interface{} 存错误、再靠反射取字段，或者定义泛型 wrapper 强行统一行为——这会丢失编译期检查，增加运行时 panic 风险，也违背 Go 的显式错误处理哲学。
- Go 鼓励“错误即值”，优先用结构体字段携带上下文（如
Time time.Time、ReqID string） - 日志或调试时用
%+v打印结构体，比拼接字符串更可靠 - HTTP 错误码映射、重试策略等逻辑，应封装在错误创建处或独立函数中，而非塞进接口
真正容易被忽略的点是：**错误类型的判定时机往往在 handler 或顶层 recover 处，而不是错误产生的瞬间**。这意味着你要确保整条调用链上的所有包装器都一致实现了 Unwrap 和类型方法，否则某一层漏掉，下游就再也拿不到原始信息了。
