Go中error接口可以扩展吗_Go自定义错误接口解析

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 和类型方法，否则某一层漏掉，下游就再也拿不到原始信息了。