go 的 error 接口仅强制实现 error() string 方法，体现“少即是多”哲学；它不预设结构或运行时行为，仅定义打印共识，支持自定义错误类型、%w 包装链、errors.is/as 识别及 unwrap 协议。
Go 的 error 接口不是“异常机制”，而是一个极简但可扩展的值类型契约——它只强制你提供一个字符串描述，其余全靠你自己决定要不要加错误码、堆栈、上下文或嵌套链。
为什么 error 只有一个 Error() string 方法？
这是 Go “少即是多”哲学的直接体现：不预设错误的结构（比如 Java 的 Throwable 层级），也不绑定运行时行为（比如 Python 的 raise）。它只定义“如何被打印”这一最低共识，让开发者自由选择实现方式：
- 简单场景用
errors.New("xxx")或fmt.Errorf("xxx")，背后是私有*errorString，轻量无开销 - 需要区分错误类型时，自定义结构体并实现
Error()，再配合errors.As()做类型断言 - 要保留调用链时，用
%w包装原始错误，后续可用errors.Unwrap()或errors.Is()追溯 - 不要试图给
error加方法（如Retry()或Log()）——它只是接口，不是基类；行为应由外部函数或中间件承载
errors.Is() 和 errors.As() 为什么必须搭配 %w 使用？
这两个函数不是万能的“错误识别器”，它们只对显式包装过的错误链生效。如果你用 fmt.Errorf("failed: %v", err)（用 %v），原始错误就被转成字符串丢弃了，errors.Is() 就永远查不到底层 os.ErrNotExist。
正确做法是：
立即学习“go语言免费学习笔记（深入）”；
if os.IsNotExist(err) {
return fmt.Errorf("config file missing: %w", err) // ✅ 用 %w 保留引用
}
// 后续调用方可以：
if errors.Is(err, os.ErrNotExist) { ... } // 成功匹配
-
%w是 Go 1.13+ 引入的“包装动词”，它让错误具备单向链式结构，类似指针引用 -
errors.Is()沿链逐层Unwrap()直到匹配目标错误值（支持==比较） -
errors.As()则尝试将链中任一节点转型为指定类型，用于提取自定义字段（如错误码） - 没用
%w包装的错误，哪怕内容一样，也无法被Is()或As()正确识别
自定义错误类型时，Cause 字段该不该暴露？
该，但必须通过接口或方法暴露，而不是直接导出字段。Go 不鼓励“错误对象属性直取”，而是推荐封装访问逻辑：
type AppError struct {
Code int
Msg string
cause error // 小写，不导出
}
func (e *AppError) Cause() error { return e.cause } // 显式提供访问入口
func (e *AppError) Error() string { return e.Msg }
- 直接导出
cause字段会破坏封装，调用方可能绕过错误链逻辑直接操作底层错误 - 用方法暴露（如
Cause()）既满足Unwrap()协议（Go 1.20+ 要求），又保留控制权 - 如果希望被
errors.Unwrap()自动识别，类型需实现Unwrap() error方法，返回e.cause - 别在
Error()里拼接e.cause.Error()——这会让日志重复、掩盖原始堆栈，交给上层统一格式化更安全
真正难的不是写对 error 接口，而是克制住“把所有信息塞进一个错误值”的冲动。Go 的错误模型默认信任调用链的分层职责：底层只报“发生了什么”，中间层加“在哪发生的”，上层决定“怎么响应”。一旦越界混用（比如在数据库层就写 HTTP 状态码），后面所有错误分类、重试、日志都会变味。
