在go语言中，自定义错误类型通过实现error接口的error方法携带更多信息，结合errors包和fmt.errorf可实现结构化错误处理。1.定义结构体并实现error方法，如type myerror struct{code int, message string}用于返回结构化错误；2.使用errors.is和errors.as判断错误类型，前者用于值比较，后者通过指针检查类型；3.用fmt.errorf搭配%w包装错误，保留原始上下文信息，便于后续提取或展开；4.实际开发中应避免滥用自定义类型，保持错误链简洁，优先使用errors.as而非类型断言，并防止重复包装错误。
在Go语言中，错误处理是一个非常核心的部分。虽然
error接口本身已经足够应对很多情况，但当你需要更丰富的上下文信息、错误类型判断或结构化数据时，自定义错误类型就变得很有必要了。这篇文章会从实际使用出发，讲清楚如何用好
errors包和
fmt.Errorf来实现清晰、可维护的错误处理逻辑。
自定义错误类型的基本写法
在Go中，要创建一个自定义错误类型，通常的做法是定义一个结构体，并让它实现
error接口的
Error() string方法。这样做的好处是可以携带更多信息，比如错误码、原始错误、操作上下文等。
举个简单的例子：
立即学习“go语言免费学习笔记（深入）”；
type MyError struct {
Code int
Message string
}
func (e MyError) Error() string {
return fmt.Sprintf("错误码：%d，信息：%s", e.Code, e.Message)
}之后你就可以像普通错误一样返回它：
return MyError{Code: 400, Message: "请求参数不合法"}这种结构化的错误类型，在大型项目中尤其有用，因为它可以被统一识别和处理，而不是仅仅靠字符串内容做判断。
errors.Is 与 errors.As：精准判断错误类型
定义了自定义错误后，如何在调用链中识别它？这时候就要用到标准库
errors里的两个函数：
Is和
As。
-
errors.Is(err, target error)
：用于判断某个错误是否等于目标错误（适用于简单值比较） -
errors.As(err, &target)
：用于判断某个错误是否是某种类型（适用于结构体或接口）
比如你有一个封装了底层错误的结构体：
type DatabaseError struct {
Op string
Err error
}
func (e DatabaseError) Error() string {
return fmt.Sprintf("数据库操作 %s 失败: %v", e.Op, e.Err)
}在调用处你可以这样检查：
if err != nil {
var dbErr DatabaseError
if errors.As(err, &dbErr) {
log.Printf("数据库操作失败：%s", dbErr.Op)
}
}注意这里用了取地址符
&dbErr，因为
errors.As需要通过指针设置匹配的结果。这一步很容易写错，记得加上。
fmt.Errorf + %w：包装错误并保留原始上下文
有时候我们不需要完全自定义错误类型，只需要把现有错误“包装”一下，加上一些上下文信息，同时又不影响后续的错误判断。这个时候可以用
fmt.Errorf配合
%w动词。
例如：
err := doSomething()
if err != nil {
return fmt.Errorf("处理数据时出错: %w", err)
}这段代码会在原有错误的基础上添加描述信息，同时将原始错误包装进去。后续可以通过
errors.Unwrap()或者
errors.As/
Is来提取原始错误。
需要注意的是：
%w
只能接受一个error
类型的参数- 如果你传入了非
error
类型，会导致运行时panic - 每次用
%w
包装都会形成一个错误链，可以通过递归展开获取完整的错误路径
实际开发中的几个建议
-
不要滥用自定义错误类型：除非你需要区分错误种类或附加元信息，否则直接返回
fmt.Errorf
生成的错误就够了。 -
保持错误链清晰：使用
%w
进行包装时，确保每一层都有明确的上下文信息，方便排查问题。 -
优先使用
errors.As
而非类型断言：这样可以兼容更多错误包装的情况，也更安全。 - 避免重复包装同一个错误：容易导致错误链冗长，影响调试效率。
总的来说，Go的错误处理机制虽然简单，但结合自定义错误类型和
errors包的工具，可以做到既灵活又可控。理解这些机制后，写出健壮、易维护的错误处理逻辑其实并不难。
