go 语言没有全局统一的“标准错误类型”（如 java 的 illegalargumentexception），但通过包级导出变量（如 io.eof）、自定义错误类型和 go 1.13+ 的错误包装机制，可实现语义清晰、可判断、可扩展的错误处理。
go 语言没有全局统一的“标准错误类型”（如 java 的 illegalargumentexception），但通过包级导出变量（如 io.eof）、自定义错误类型和 go 1.13+ 的错误包装机制，可实现语义清晰、可判断、可扩展的错误处理。
在 Go 中，错误（error）是一个接口类型，其设计哲学强调明确性、可判定性与可组合性，而非继承式异常分类。因此，Go 并不存在类似 Java 的 java.lang.*Exception 这类跨包通用的标准错误类型体系。取而代之的是约定优于强制的实践模式——由各标准库包按需导出语义明确的错误变量或类型，供用户直接比较或断言使用。
✅ 常见且推荐的错误声明方式
1. 包级导出错误变量（var ErrXXX = errors.New(...)）
这是最轻量、最常用的模式，适用于需要被调用方精确识别的失败场景。例如：
package mypkg
import "errors"
var (
ErrNotFound = errors.New("item not found")
ErrPermission = errors.New("insufficient permissions")
ErrTimeout = errors.New("operation timed out")
)✅ 优势：内存地址唯一，支持高效指针比较（err == mypkg.ErrNotFound）；Go 1.13+ 后更推荐配合 errors.Is() 使用，自动处理嵌套包装：
if errors.Is(err, mypkg.ErrNotFound) {
// 安全匹配，即使 err 是 fmt.Errorf("failed: %w", originalErr)
}⚠️ 注意：切勿在函数内重复调用 errors.New() 返回新实例（如 return errors.New("not found")），否则无法可靠比较。
2. 自定义错误类型（type XXXError struct { ... }）
当错误需携带上下文信息（如状态码、时间戳、原始值）或支持行为扩展时，应定义结构体错误类型：
type ValidationError struct {
Field string
Value interface{}
Reason string
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed on %s: %s (value=%v)", e.Field, e.Reason, e.Value)
}
func (e *ValidationError) Unwrap() error { return nil } // 若无底层错误，返回 nil配合 errors.As() 可安全提取并使用字段：
var ve *mypkg.ValidationError
if errors.As(err, &ve) && ve.Field == "email" {
log.Printf("Email validation failed: %s", ve.Reason)
}3. 复用标准库中的“事实标准”错误
少数几个标准包错误已被广泛接受为跨包语义契约，可直接复用（无需重新定义）：
| 错误变量 | 所属包 | 典型用途 |
|---|---|---|
| io.EOF | io | 读取流到达末尾 |
| io.ErrUnexpectedEOF | io | 预期更多数据但提前结束 |
| os.ErrNotExist | os | 文件/目录不存在（常用于路径操作） |
| context.Canceled / context.DeadlineExceeded | context | 上下文取消或超时 |
? 关键原则：若实现标准接口（如 io.Reader.Read），必须返回 io.EOF 而非自定义错误，以满足接口契约。
4. 错误包装（Go 1.13+ 推荐）
使用 fmt.Errorf("context: %w", err) 添加上下文，同时保留原始错误链：
func FetchData(ctx context.Context, url string) error {
resp, err := http.Get(url)
if err != nil {
return fmt.Errorf("http GET %s failed: %w", url, err) // 包装
}
defer resp.Body.Close()
// ...
}调用方可逐层解包：
if errors.Is(err, context.DeadlineExceeded) {
retry()
} else if errors.Is(err, io.EOF) {
handleSuccess()
}❌ 不推荐的做法
- 字符串匹配 err.Error()：脆弱、易受格式变更影响，违反封装原则；
- 随意返回 errors.New("xxx") 而不导出变量：导致调用方无法可靠判定错误类型；
- 过度抽象错误层次（如定义 BaseError, ClientError, ServerError）：Go 鼓励扁平化、语义化错误，而非模拟 OOP 异常继承树。
总结：如何选择？
| 场景 | 推荐方式 |
|---|---|
| 简单、需被广泛识别的失败（如未找到、权限拒绝） | 导出 var ErrXXX = errors.New(...) |
| 需携带结构化信息或支持多态行为 | 自定义错误类型 + Unwrap()/As() |
| 实现标准接口（如 io.Reader, net.Listener） | 严格复用对应包的约定错误（如 io.EOF, net.ErrClosed） |
| 添加调用链上下文（日志、调试） | fmt.Errorf("msg: %w", err) 包装 |
| 临时性、内部错误，无需外部判定 | errors.New(...) 或 fmt.Errorf(...)（不包装） |
遵循这些实践，你不仅能写出符合 Go 习惯的健壮错误处理逻辑，还能让 API 更易用、更易测试、更具演化韧性。
