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