在 golang 中，错误处理应优先使用结构体实现 error 接口以携带额外信息，1. 自定义错误类型通过实现 error() 方法支持类型判断与信息扩展；2. 简单错误可用 errors.new 或 fmt.errorf，但不便于类型提取；3. 使用 fmt.errorf 的 %w 动词包装错误可保留原始信息；4. 解包错误可通过 errors.unwrap、errors.is 和 errors.as 遍历错误链进行匹配或类型提取；5. 实践中应优先使用 errors.as 判断类型，避免随意包装无上下文的错误，关键路径添加上下文再包装，并避免字符串比较以提升可靠性与可维护性。
在 Golang 中，错误处理是程序设计的重要组成部分。
errors库提供了创建、包装和解包错误的能力，让我们可以写出更清晰、可维护的错误逻辑。下面我们就来看看如何使用
errors包来创建自定义错误，并演示错误包装与解包的最佳实践。
自定义错误类型：实现 error 接口
最基础的方式是通过定义一个结构体并实现
error接口的
Error() string方法：
type MyError struct {
Msg string
}
func (e MyError) Error() string {
return "MyError: " + e.Msg
}这样你就可以像使用标准错误一样使用它：
立即学习“go语言免费学习笔记（深入）”；
err := MyError{"something went wrong"}
fmt.Println(err)这种方式适合需要携带额外信息的场景，比如错误码、状态、发生位置等。你可以扩展这个结构体，加入更多字段以供后续处理。
使用 errors.New 和 fmt.Errorf 创建简单错误
对于不需要附加额外信息的错误，直接使用
errors.New就够用了：
err := errors.New("this is a simple error")如果需要格式化错误信息，可以用
fmt.Errorf：
err := fmt.Errorf("invalid value: %d", val)但要注意的是，这两种方式创建的错误都是“裸”的字符串错误，不便于做类型判断或提取上下文信息。所以，在需要做错误类型区分时，还是建议用上面的结构体方式。
错误包装（Wrap）：保留原始错误信息
Go 1.13 引入了
fmt.Errorf的
%w动词来进行错误包装：
err := fmt.Errorf("failed to read config: %w", originalErr)这会把
originalErr包装进新的错误中，方便后续调用者使用
errors.Unwrap()或
errors.As()提取原始错误。
注意：只有使用 %w 格式符包装的错误才能被正确解包。其他方式（如拼接字符串）无法保留原始错误结构。
错误解包（Unwrap）：提取原始错误进行判断
如果你得到了一个被包装过的错误，想判断它是否是由某个特定错误引起的，可以用以下方法：
errors.Unwrap(err)
：获取包装错误的下一层错误。errors.Is(err, target)
：判断某层错误是否等于目标错误。errors.As(err, &target)
：判断某层错误是否是指定类型的错误。
例如：
if errors.Is(err, os.ErrNotExist) {
// 处理文件不存在的情况
}或者检查自定义错误类型：
var myErr *MyError
if errors.As(err, &myErr) {
fmt.Println("Got a MyError with message:", myErr.Msg)
}这些方法会自动遍历整个错误链，直到找到匹配项为止，非常实用。
实践建议：怎么用才合理？
优先使用 errors.As 而不是 type switch
因为errors.As
可以处理嵌套包装的错误，而 type switch 只能判断当前层级的错误类型。不要随意包装所有错误
如果你只是传递错误而不加任何上下文信息，就不需要用%w
。否则会让错误链变得复杂且难以理解。在关键路径上添加上下文信息再包装
比如在函数调用栈的高层加上操作失败的原因，这样调试时更容易定位问题。避免只比较错误字符串
字符串比较不稳定，容易因为拼写错误或语句变化而出错。应该尽量使用类型或变量对比。
基本上就这些。Golang 的错误机制虽然看起来简单，但在实际项目中要处理得当，还是要靠合理的包装和解包策略。用好
errors包提供的工具，可以让你的错误处理更清晰、更可靠。
