在 golang 中处理错误类型时，哨兵错误适用于固定、通用的错误状态，通过预定义错误值进行比较；类型断言适合携带更多信息的错误，通过结构体实现 error 接口并进行类型判断。1. 哨兵错误如 io.eof，适合标准库或公开 api，优点是清晰且性能好，但灵活性差、无法携带信息。2. 类型断言如自定义 struct，适合业务逻辑中需提取详细信息的场景，扩展性强但稍复杂，推荐使用 errors.as 安全匹配。3. 选择依据在于是否需要携带信息、跨包共享及代码简洁性，两者也可混合使用。
在 Golang 中处理错误时，常常需要根据不同的错误类型做出不同的响应。最常见的两种方式是使用哨兵错误（Sentinel Errors）和类型断言（Type Assertion）。它们各有适用场景，也各有利弊。
下面我们就来聊聊这两种方法的区别、使用时机以及实际中怎么用更合适。
哨兵错误：直接比较预定义的错误值
哨兵错误指的是预先定义好一些错误变量，比如 io.EOF，然后通过直接比较的方式来判断错误类型：
立即学习“go语言免费学习笔记（深入）”；
if err == io.EOF {
// 处理文件读取结束的情况
}这种方式简单明了，适合那些只需要知道“发生了哪种已知错误”的情况。
使用建议：
-
适合标准库或公开 API：像
io.EOF这样的错误被广泛使用，使用者不需要导入额外包就能识别。 - 注意导出性：自定义哨兵错误变量要以大写字母开头才能被其他包访问。
- 避免滥用：不要为每个小错误都定义一个哨兵，容易造成混乱。
优点是写法清晰、性能好；缺点是灵活性差，无法携带额外信息。
类型断言：判断错误的具体类型
当错误需要携带更多信息时，通常会定义一个具体的错误类型结构体，并实现 error 接口：
type MyError struct {
Code int
Msg string
}
func (e *MyError) Error() string {
return e.Msg
}然后在错误处理中使用类型断言来判断具体类型：
if e, ok := err.(*MyError); ok {
fmt.Println("错误码：", e.Code)
}这种方式适用于需要区分多种错误类别并提取详细信息的场景。
使用建议：
用于业务逻辑中的丰富错误信息：例如数据库连接失败、超时、认证失败等不同类型错误。
-
结合
errors.As更安全：Go 1.13+ 推荐使用errors.As来做类型匹配，能穿透包装过的错误链：var myErr *MyError if errors.As(err, &myErr) { // 处理 } 结构体指针实现接口更好：如果用值接收者实现
Error()方法，在断言时可能会不匹配。
这种方式扩展性强，但写起来稍微复杂一点，而且需要暴露错误结构体给调用方。
怎么选？这两个方案有什么区别？
- 哨兵错误是“值比较”，适合固定、通用的错误状态。
- 类型断言是“类型判断”，适合需要携带上下文或结构化信息的错误。
举个例子：
- 文件读完了？用
io.EOF就够了。 - 数据库连接失败的原因有几种？用类型断言可以分别处理超时、权限、网络等问题。
你也可以混合使用，比如定义多个哨兵错误变量，或者多个错误类型，根据项目需求灵活组合。
总的来说，在 Golang 中区分错误类型，哨兵错误和类型断言各有优势。选择哪个取决于你的错误是否需要携带更多信息、是否需要跨包共享，以及是否希望保持代码简洁。
基本上就这些。
