该用 errors.new 而非 fmt.errorf 时：错误内容为固定字符串、不依赖变量、无需上下文，如 "connection timeout"；此时更轻量、语义清晰，便于 errors.is 精确比对。
什么时候该用 errors.New，而不是 fmt.Errorf
当错误内容是固定字符串、不依赖变量、也不需要上下文信息时，errors.New 更轻量、语义更清晰。它只做一件事：构造一个带消息的 error 值，不引入格式化开销，也不隐式调用 fmt.Sprint。
- 适合场景：
return errors.New("connection timeout")、校验失败的静态提示（如"invalid config key"） - 避免滥用：
errors.New("user " + name + " not found")—— 字符串拼接易出错，且无法做类型判断或错误链扩展 - 性能差异很小，但语义上
errors.New表明“这是个简单哨兵错误”，方便后续用errors.Is精确比对
fmt.Errorf 的 %w 动词不是可选技巧，而是错误包装的事实标准
只要错误需要携带原始原因（比如调用底层函数失败后向上层透传），就必须用 %w。不用它，errors.Unwrap 和 errors.Is 就失效，调试时会卡在第一层错误里找不到根因。
- 正确写法：
fmt.Errorf("failed to read config: %w", io.ErrUnexpectedEOF) - 常见错误：
fmt.Errorf("failed to read config: %v", io.ErrUnexpectedEOF)—— 这只是把错误转成字符串，丢失了原始 error 类型和堆栈线索 -
%w只接受单个error类型参数，不能写成%w, %w或混用其他动词 - Go 1.20+ 支持多层包装，但每层都必须用
%w，否则链就断了
自定义错误类型比 errors.New 和 fmt.Errorf 更适合业务逻辑分发
当你需要根据错误类型做不同处理（比如重试、降级、记录不同日志级别），靠字符串匹配或 errors.Is 查哨兵值很快会失控。这时候应该定义结构体错误。
- 示例：
type ValidationError struct { Field string; Message string }，实现Error()方法 - 优势：能携带结构化字段，支持类型断言（
if e, ok := err.(*ValidationError); ok { ... }），也兼容%w包装 - 注意点：不要让自定义错误嵌套过深；如果只是加个字段，优先考虑
fmt.Errorf("...: %w", underlying)而非重造轮子 - 别用
errors.New或fmt.Errorf返回自定义错误实例——它们返回的是*errors.errorString，类型断言会失败
Go 1.20+ 的 errors.Join 不是给普通错误用的，别误当“多个错误合并”工具
errors.Join 解决的是“一个操作触发多个独立失败”的场景（比如批量写入时部分失败），它返回的 error 是可遍历的复合体。但日常的“错误传递”或“错误补充上下文”，仍然用 %w。
立即学习“go语言免费学习笔记（深入）”；
- 典型误用：
err = errors.Join(err, fmt.Errorf("context: %s", ctx))—— 这会让调用方必须显式遍历，破坏原有错误处理流程 - 真正适用：
errors.Join(ioErr1, ioErr2, ioErr3)，且上层明确要检查所有子错误（例如健康检查聚合） -
errors.Join返回的 error 不支持errors.Is直接匹配子错误，要用errors.Is配合循环或errors.Unwrap展开
errors.Is 或类型断言来区分它。 
