在 Go 中应通过预定义的导出错误变量（如 pkg.ErrExample）进行指针级相等比较，而非调用 err.Error() 后比对字符串，以确保类型安全、语义清晰且不受错误消息变更影响。
在 go 中应通过预定义的导出错误变量（如 `pkg.errexample`）进行指针级相等比较，而非调用 `err.error()` 后比对字符串，以确保类型安全、语义清晰且不受错误消息变更影响。
Go 的错误处理机制与 Java 等语言有本质区别：error 是一个接口类型，其核心方法是 Error() string，但不提供 GetMessage() 或类似反射式访问能力。更重要的是，Go 鼓励将错误视为可识别的值（value），而非仅依赖字符串内容——这直接决定了错误比较的正确方式。
✅ 正确做法：定义并比较错误变量
在包内声明具名的、导出的错误变量（推荐首字母大写以供外部使用）：
// somepackage/errors.go
package somepackage
import "errors"
// ErrExample 是一个预定义的、可导出的错误值
var ErrExample = errors.New("this is an example")
// DoSomething 可能返回该错误
func DoSomething() error {
return ErrExample // 或其他逻辑分支中返回
}
调用方通过直接比较错误变量进行判断：
if err := somepackage.DoSomething(); err != nil {
if err == somepackage.ErrExample {
// ✅ 安全、高效、语义明确：这是同一错误实例
log.Println("Handled known example error")
return
}
// 其他错误走通用处理流程
return fmt.Errorf("unexpected error: %w", err)
}
这种比较基于 error 接口底层指向的相同 *errors.errorString 实例（errors.New 返回的是不可变单例），因此 == 比较是可靠且零分配的。
❌ 错误做法：字符串匹配 err.Error()
// ⚠️ 危险！脆弱且低效
if err.Error() == "this is an example" { ... }
该方式存在严重问题：
- 易碎性：一旦错误消息微调（如添加标点、翻译、上下文信息），比较即失效；
-
性能开销：每次调用
Error()触发字符串构造与内存分配； -
语义丢失：无法区分不同错误类型但偶然消息相同的场景（例如两个独立包都定义了
"invalid input"）； -
不兼容包装错误：若错误被
fmt.Errorf("wrap: %w", err)包装，err.Error()返回完整链式消息，原始子串无法直接提取。
? 进阶：支持错误包装与类型断言
当需要处理嵌套错误（如 fmt.Errorf("failed to read: %w", io.EOF)）时，应使用 errors.Is() 判断是否为某类错误：
import "errors"
if errors.Is(err, io.EOF) {
// ✅ 正确识别被包装的 EOF 错误
}
对于自定义错误类型（实现 Unwrap() error），同样适用。而 errors.As() 可用于类型断言获取底层错误实例。
✅ 最佳实践总结
-
始终优先定义包级错误变量（如
var ErrTimeout = errors.New("operation timeout")）； -
对外暴露时使用大驼峰命名（
ErrXXX）并导出，便于下游精准判断； -
禁止用
err.Error() == "xxx"做逻辑分支，这是 Go 社区公认的反模式； -
涉及错误链时，用
errors.Is()/errors.As()替代直接==； - 标准库大量采用此范式（如
net/http.ErrBodyNotAllowed、io.EOF），可放心效仿。
遵循这一约定，你的错误处理将更健壮、可维护，并与 Go 生态保持一致。
