在go语言中，错误处理应优先使用标准库的errors包和自定义错误类型。1. 使用errors.new定义静态错误值，避免字符串拼接以确保可比较性；2. 调用errors.is判断特定错误，而非通过字符串比较；3. 需要添加上下文信息时，使用fmt.errorf的%w格式包装错误，以便保留错误链并能被unwrap解析；4. 自定义错误类型实现error接口，可携带结构化信息便于分类和展示；5. 实际开发中建议统一错误结构、避免过度包装、谨慎使用哨兵错误，并在日志中记录上下文信息，同时在单元测试中验证错误行为。
在Go语言中，错误处理是日常开发中最常见的操作之一。相比其他语言使用异常机制（try/catch），Go选择用返回值来显式处理错误，这种方式虽然更直观、可控性强，但也对开发者提出了更高的要求：如何写出清晰、可维护的错误处理代码？
答案其实就藏在标准库的
errors包和自定义错误类型之中。
如何正确创建和比较错误？
Go 的
errors包提供了两个核心函数：
errors.New()和
errors.Unwrap()，还有
fmt.Errorf()用于构造错误信息。
立即学习“go语言免费学习笔记（深入）”；
最常见的做法是预先定义一些错误变量：
var ErrInvalidInput = errors.New("invalid input")然后在函数中直接返回这个错误：
func validate(n int) error {
if n < 0 {
return ErrInvalidInput
}
return nil
}调用者可以用
errors.Is()来判断是否等于某个特定错误：
if err := validate(-1); err != nil {
if errors.Is(err, ErrInvalidInput) {
fmt.Println("捕获到无效输入错误")
}
}关键点：
- 使用
errors.New
创建静态错误值时要避免拼接字符串，否则无法准确比较。 - 尽量不要用字符串比较错误，推荐使用
errors.Is
而不是err.Error() == "xxx"
。 - 不要滥用
fmt.Errorf
，除非你需要附加上下文信息。
怎样添加上下文信息又不影响错误判断？
有时候我们希望在传递错误的同时加上更多信息，比如“读取配置失败”，而不是只返回底层的
os.ErrNotExist。
这时候可以使用
fmt.Errorf的
%w格式化动词包装错误：
func readConfig() error {
_, err := os.ReadFile("config.json")
if err != nil {
return fmt.Errorf("read config failed: %w", err)
}
return nil
}外层调用者仍然可以通过
errors.Is()检查原始错误：
if errors.Is(err, os.ErrNotExist) {
// 即使被包装过也能识别出来
}注意：
- 只有使用
%w
才能保留错误链，才能被Unwrap()
解析。 - 如果只是想加日志或调试信息，不建议用
%w
，改用普通格式化即可。
自定义错误类型有什么好处？
除了使用标准库提供的基础错误，你还可以通过实现
error接口来自定义错误类型，这样可以携带更多信息，便于后续处理。
举个例子：
type MyError struct {
Code int
Message string
}
func (e MyError) Error() string {
return e.Message
}然后你可以根据不同的业务场景返回不同结构的错误：
func process(data string) error {
if data == "" {
return MyError{Code: 400, Message: "empty input"}
}
return nil
}调用方可以使用类型断言获取详细信息：
if err := process(""); err != nil {
if myErr, ok := err.(MyError); ok {
fmt.Printf("错误码：%d，提示：%s\n", myErr.Code, myErr.Message)
}
}适用场景：
- 需要将错误分类，比如 HTTP 错误码、数据库错误等。
- 希望错误包含结构化数据，方便日志记录或前端展示。
- 想区分系统错误和业务逻辑错误。
实际开发中的一些建议
-
统一错误结构：项目大了之后建议统一错误类型，避免到处返回
error
而没有结构。 -
避免过度包装：每层都加一次
%w
容易让错误链变得冗长，影响可读性。 -
使用哨兵错误要谨慎：像
io.EOF
这种通用错误，在多层调用中容易误判。 - 错误日志应包含上下文：即使不包装错误，也应在日志中记录出错位置、参数等信息。
- 测试时验证错误行为：单元测试中别忘了验证函数是否返回预期错误。
基本上就这些。错误处理看起来简单，但要做到既清晰又实用，还是需要一点设计意识的。
