Go的error接口因仅要求Error()方法而无法满足业务错误分类需求，必须通过自定义结构体、指针实现Error()、正确实现Unwrap()等手段支持类型断言和错误链。
为什么 error 接口不能直接满足业务错误分类需求
Go 的 error 是个接口，只强制要求 Error() 方法返回字符串。这导致所有错误在类型层面“扁平化”——fmt.Errorf("not found") 和 os.ErrNotExist 都是 error，但前者无法被程序逻辑识别为“资源不存在”，只能靠字符串匹配，极不可靠。
真实场景中，你得区分“用户输入错误”“数据库超时”“权限不足”，并做不同处理（重试、提示、跳转）。靠字符串判断会崩：改个错别字、加个日志前缀就失效。
- 不要用
strings.Contains(err.Error(), "timeout")判断超时 - 不要把业务码塞进错误消息里再解析，比如
fmt.Errorf("ERR_403: permission denied") - 标准库的
os.IsNotExist()这类函数之所以可靠，是因为它内部做了类型断言，不是字符串匹配
如何定义可判断、可携带上下文的自定义错误类型
核心是让错误本身成为具体类型，支持类型断言和方法扩展。最常用且推荐的方式是结构体 + 实现 Error() 接口 + 附加字段。
例如定义一个带 HTTP 状态码和追踪 ID 的错误：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type AppError struct {
Code int
Message string
TraceID string
}
func (e *AppError) Error() string {
return e.Message
}
func (e *AppError) StatusCode() int {
return e.Code
}
- 必须用指针实现
Error()，否则值类型每次调用都可能生成新实例，影响errors.Is()判断 - 字段命名避免和标准库冲突，比如别叫
Err或Unwrap（除非你真要支持错误链） - 如果需要嵌套原始错误（如包装
io.EOF），加一个err字段并实现Unwrap()方法，否则errors.Unwrap()会失败
errors.Is() 和 errors.As() 为什么经常失效
这两个函数依赖错误链（通过 Unwrap() 向下查找）和类型匹配。失效主因不是函数有问题，而是自定义错误没按约定实现。
常见失效场景：
- 用值类型实现
Error()：断言*AppError永远失败，因为errors.As(err, &target)找不到对应指针类型 - 忘了实现
Unwrap()：当用fmt.Errorf("wrap: %w", appErr)包装后，errors.Is(wrappedErr, appErr)返回 false - 在
Unwrap()里返回了 nil 而非底层 error：中断错误链，上层无法穿透判断
正确写法示例：
func (e *AppError) Unwrap() error {
return e.err // e.err 是另一个 error 类型字段
}
什么时候该用 fmt.Errorf("%w")，什么时候该直接返回自定义错误
包装（wrapping）不是为了“显得高级”，而是为了保留原始错误语义的同时补充上下文。滥用会导致错误链过深、调试困难。
- 底层调用失败需透传原因时用
%w：比如数据库查询失败，你封装成AppError，但应保留sql.ErrNoRows以便上层用errors.Is(err, sql.ErrNoRows)判断 - 纯业务校验失败不用
%w：用户邮箱格式错误，直接返回&AppError{Code: 400, Message: "invalid email"}即可，没有底层 error 可包装 - 日志里打印错误时，优先用
%+v而非%v，能展开整个错误链和字段，比只看Error()字符串有用得多
错误链不是越长越好，关键路径上保持 2–3 层足够；超过这个深度，大概率说明抽象层次混乱，该重构而不是继续包装。
