Golangerrors.New与fmt.Errorf区别解析

你在学习Golang相关的知识吗？本文《Golang errors.New与fmt.Errorf区别详解》，主要介绍的内容就涉及到，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

该用 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。

• 典型误用：err = errors.Join(err, fmt.Errorf("context: %s", ctx)) —— 这会让调用方必须显式遍历，破坏原有错误处理流程
• 真正适用：errors.Join(ioErr1, ioErr2, ioErr3)，且上层明确要检查所有子错误（例如健康检查聚合）
• errors.Join 返回的 error 不支持 errors.Is 直接匹配子错误，要用 errors.Is 配合循环或 errors.Unwrap 展开

事情说清了就结束。最常被忽略的其实是错误类型的可判定性——无论用哪种方式构造 error，都要想清楚：下游会不会、能不能、需不需要用 errors.Is 或类型断言来区分它。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golangerrors.New与fmt.Errorf区别解析》文章吧，也可关注golang学习网公众号了解相关技术文章。