该用 errors.New 构造无动态值的静态错误，如 errors.New("file not found")；需插值变量时用 fmt.Errorf，如 fmt.Errorf("failed to read %s: %w", filename, err)，并显式用 %w 保留错误链。
Go里什么时候该用 errors.New，什么时候该用 fmt.Errorf
errors.New 只能构造不含动态值的静态错误，比如 errors.New("file not found")；fmt.Errorf 支持格式化插值，适合带变量的错误描述，比如 fmt.Errorf("failed to read %s: %w", filename, err)。如果错误消息里要拼接路径、状态码、用户ID这类运行时值，必须用 fmt.Errorf。
注意：fmt.Errorf 默认不包装错误（即不带 %w 动词），直接拼字符串会丢失原始错误链。需要保留底层错误上下文时，务必显式使用 %w 并传入一个实现了 error 接口的值。
自定义错误类型为什么不能只靠 fmt.Errorf 实现
当你需要区分错误种类（比如重试型错误 vs 终止型错误）、附带额外字段（如HTTP状态码、重试次数）、或实现特定行为（如 Timeout() 方法），仅靠字符串错误远远不够。这时必须定义结构体并实现 Error() 方法。
- 结构体字段可导出，便于外部检查和调试
- 可以嵌入
error字段实现错误链（推荐用fmt.Errorf("... %w", underlying)包装） - 避免用指针接收者实现
Error()—— Go 标准库约定是值接收者，否则errors.Is/As可能失效
type MyError struct {
Code int
Message string
Err error // 底层错误，用于 %w 包装
}
func (e MyError) Error() string {
return fmt.Sprintf("code=%d: %s", e.Code, e.Message)
}
func (e MyError) Unwrap() error {
return e.Err
}
errors.Is 和 errors.As 要求自定义错误满足什么条件
这两个函数依赖错误链的正确构建和标准接口实现。常见失败原因：
- 没实现
Unwrap()方法 →errors.Is无法向下遍历错误链 - 自定义类型用了指针接收者定义
Error()→errors.As匹配失败（因为类型不一致） - 用
fmt.Sprintf拼错字符串代替fmt.Errorf(... %w)→ 错误链断裂，Unwrap()返回 nil - 多个包装层中某一层漏了
%w→ 链在那一层断开
验证方式：打印 errors.Unwrap(err) 看是否返回预期的底层错误；或用 fmt.Printf("%+v", err) 观察是否显示 wrapped 错误。
生产环境建议的错误处理组合策略
不要全用一种方式。合理分层更利于诊断和恢复：
- 底层I/O或网络调用：原样返回或用
%w包装，保留原始错误信息 - 业务逻辑层：用自定义错误类型封装领域语义（如
ValidationError、NotFoundErr），附带必要字段 - API响应层：统一转换为标准响应结构，隐藏敏感细节，但日志中保留完整错误链
- 日志记录前调用
fmt.Sprintf("%+v", err)—— 它会递归展开所有%w包装的错误，比err.Error()有用得多
最常被忽略的一点：自定义错误类型一旦导出，就构成API契约。后续修改字段或方法签名可能破坏下游代码，所以初期设计要留余量，比如预留 Meta map[string]string 字段。
