Go中errors.New和fmt.Errorf区别_Go错误创建方式对比_技术教程

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("不会执行到这里")
	}
}