该用 errors.New 时是需固定无变量错误描述且要轻量安全比较的场景；它不支持格式化和错误链，而 fmt.Errorf 通过 %w 动词实现标准错误包装与上下文嵌入，语义更清晰。
什么时候该用 errors.New？
当你只需要一个固定、无变量的错误描述时，errors.New 是最轻量的选择。它内部只是构造一个 *errors.errorString 结构体，开销极小，且返回的错误值可安全比较（相同字符串多次调用会得到相等的指针）。
- 适合预定义错误常量，比如
var ErrInvalidInput = errors.New("invalid input") - 不支持格式化，传入含变量的拼接字符串（如
"file " + name + " not found"）会让代码难读、易出错 - 无法包装底层错误，也不支持 Go 1.13+ 的错误链（
%w）
为什么必须用 fmt.Errorf 而不是拼接字符串再传给 errors.New？
手动拼接字符串再喂给 errors.New 看似可行，但实际绕开了标准错误处理的关键能力：上下文嵌入与错误包装。
-
fmt.Errorf("failed to parse %s: %w", filename, err)中的%w可以保留原始错误，供errors.Is或errors.Unwrap追踪 - 直接拼接丢失类型信息和原始错误引用，调试时看不到“谁抛出的原始错误”
-
fmt.Errorf底层其实也是调用errors.New，但它先完成格式化，再构造错误——你省去的是手动fmt.Sprintf+errors.New两步，还获得标准语义
fmt.Errorf 的 %w 动词到底怎么用？
%w 是 Go 1.13 引入的专用动词，专用于包装（wrap）另一个 error 值。它不是字符串插值，而是建立错误链关系。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func readFile(filename string) error {
f, err := os.Open(filename)
if err != nil {
return fmt.Errorf("failed to open %s: %w", filename, err)
}
defer f.Close()
return nil
}
// 调用方可以这样检查原始错误：
if errors.Is(err, os.ErrNotExist) {
// 处理文件不存在的情况
}
- 只有
%w参数必须是error类型，其他占位符（如%s、%d）照常用 - 一个
fmt.Errorf中最多只能有一个%w；多个包装请用fmt.Errorf("...: %w", errors.Join(err1, err2))（Go 1.20+） - 忘记加
%w而写成%s，会导致原始错误被转成字符串丢弃，再也无法用errors.Is判断
性能差异大吗？要不要为简单错误刻意避免 fmt.Errorf？
在绝大多数业务场景下，差异可忽略。但要注意：这不是“性能问题”，而是“语义清晰度问题”。
-
errors.New零分配（仅一次结构体指针），fmt.Errorf至少有一次字符串格式化分配 —— 但在 HTTP handler 或数据库操作里，这点开销远小于 I/O 本身 - 真正该警惕的是滥用
fmt.Errorf包装非错误值，比如fmt.Errorf("status code: %d", code)（code不是error）—— 这破坏了错误链，也误导调用方 - 如果你发现某处高频创建错误（如循环内），且内容完全静态，才值得考虑缓存
errors.New(...)的结果，而不是每次新建
错误链和上下文不是锦上添花的功能，而是 Go 错误处理的基础设施。用错 %w 或回避它，会在排查生产问题时多花几倍时间翻日志找根因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
