errors.New仅支持固定字符串，适合全局常量错误；fmt.Errorf支持格式化和%w包装，可构建错误链并保持语义，适用于需动态上下文的场景。
errors.New 只能传固定字符串，不能格式化
errors.New 是最轻量的错误创建方式，它只接受一个 string 参数，内部直接构造一个不可变的 errorString 实例。这意味着你没法往里面塞变量、时间戳、文件名这类动态内容。
- ✅ 适合定义全局常量错误，比如
var ErrNotFound = errors.New("not found") - ❌ 一旦写死就无法注入上下文，像
errors.New("failed to open " + filename)这种拼接是反模式——既难读又易出错（空格、引号、类型转换都可能翻车） - ⚠️ 它不支持
%w包装语法，无法形成错误链，后续用errors.Is或errors.As判断原始错误时会失效
fmt.Errorf 支持格式化和错误包装（%w）
fmt.Errorf 本质是 fmt.Sprintf + errors.New 的组合，所以它天然支持占位符和任意类型的参数。更重要的是，从 Go 1.13 起，它支持 %w 动词，让错误可以“包裹”另一个错误，保留原始调用栈和语义。
- ✅ 动态构建错误信息：例如
fmt.Errorf("read config: %w", io.ErrUnexpectedEOF) - ✅ 错误链友好：被
%w包裹的错误可用errors.Is(err, io.ErrUnexpectedEOF)精准识别，哪怕中间套了三四层 - ⚠️ 不要滥用
%v或%s打印 error 值本身（比如fmt.Errorf("wrap: %s", err)），这会丢失原始 error 类型和包装关系，errors.Is就失效了
什么时候该用哪个？看错误是否需要携带上下文
选型不是看“哪个更高级”，而是看错误值是否需要表达「发生了什么 + 在哪发生的 + 因为什么」。简单说：
- 用
errors.New：定义包级公共错误常量（如ErrInvalidInput）、单元测试中造桩、或者错误信息完全静态且永不变化 - 用
fmt.Errorf：日志里带文件名/行号、HTTP handler 中返回带状态码的错误、封装底层库错误（如os.Open返回的*os.PathError）、需要支持重试或分类处理的业务错误 - ⚠️ 混用陷阱：不要在同一个错误链里交替用两者做包装。比如
fmt.Errorf("outer: %w", errors.New("inner"))没问题，但反过来errors.New(fmt.Sprintf("outer: %v", innerErr))会切断错误链，errors.Unwrap和errors.Is全部失效
性能差异几乎可忽略，别为这个纠结
有人担心 fmt.Errorf 比 errors.New 慢，因为涉及格式化。实际在绝大多数场景下，这种开销远小于一次系统调用（比如磁盘 I/O 或网络请求）。而且 Go 编译器对简单格式化（如 "%s"）做了优化，甚至能内联。
- ✅ 微基准测试显示：100 万次
fmt.Errorf("hello")和errors.New("hello")耗时差不到 50ns/次 - ❌ 真正影响性能的是错误频繁创建+panic+recover，而不是选哪个构造函数
- ? 记住：错误对象本身是 cheap 的；昂贵的是你为它写的日志、监控上报、或用户提示逻辑
package main
import (
"errors"
"fmt"
"io"
)
func main() {
// ✅ 正确：用 fmt.Errorf 包装底层错误，保留可判断性
original := io.ErrUnexpectedEOF
wrapped := fmt.Errorf("decode JSON failed: %w", original)
if errors.Is(wrapped, io.ErrUnexpectedEOF) {
fmt.Println("识别成功") // 会打印
}
// ❌ 错误：用 errors.New + 字符串拼接，断开错误链
broken := errors.New("decode JSON failed: " + original.Error())
if errors.Is(broken, io.ErrUnexpectedEOF) {
fmt.Println("不会执行到这里")
}
}
Go 错误处理的复杂点从来不在“怎么创建”，而在于“怎么保持错误语义不丢失”。%w 和 errors.Is 是配套工具，但前提是——你得从第一行 fmt.Errorf 就用对。 
