判断自定义错误应优先用Errors.Is（值匹配哨兵错误）或errors.As（类型匹配并提取结构体字段），类型断言仅适用于未包装的单层错误场景。
在 go 中判断一个 error 是否为自定义错误，核心在于理解 Go 的错误机制：Go 的 error 是接口，自定义错误通常实现该接口，而类型匹配需结合 errors.Is、errors.As 和类型断言三种方式，具体用哪种取决于你的设计目标——是检查错误链中是否存在某个**特定值**（如哨兵错误），还是想提取某个**具体错误类型**的实例进行进一步操作。
用 errors.Is 判断是否为哨兵错误（值匹配）
当你定义了一个包级变量作为“哨兵错误”（如 var ErrNotFound = errors.New("not found")），应使用 errors.Is 判断它是否出现在错误链中。它会自动遍历 Unwrap() 链，适合做“是否发生了某类已知错误”的布尔判断。
- ✅ 推荐用于：http 处理中判断是否返回 404（
if errors.Is(err, ErrNotFound) { return http.StatusNotFound }） - ⚠️ 注意：不能用于提取自定义结构体字段，只返回
bool - ❌ 不要对结构体字面量用
errors.Is，它只比对指针或可比较的值（如errors.New或fmt.Errorf带%w包装的哨兵）
用 errors.As 提取自定义错误结构体（类型匹配 + 赋值）
当你定义了带字段的自定义错误类型（如 type ValidationError Struct { Field String; Msg string }），且实现了 Error() 和可选的 Unwrap() 方法，就该用 errors.As。它会在错误链中查找第一个匹配该类型的实例，并将其实例赋值给目标变量。
- ✅ 推荐用于：需要访问错误内部字段时，例如记录日志：
var ve ValidationError; if errors.As(err, &ve) { log.printf("validation failed on %s: %s", ve.Field, ve.Msg) } - ⚠️ 注意：第二个参数必须是指向目标类型的指针（
&ve），否则匹配失败 - ✅ 支持嵌套包装：即使
err是fmt.Errorf("failed: %w", &ValidationError{...})，errors.As仍能成功提取
用类型断言直接判断底层 error 类型（仅限单层）
如果确定错误没有被包装（即不是通过 %w 包装的），且你只需要快速判断其原始类型，可用类型断言 err.(*MyError)。但这种方式不推荐用于通用错误处理，因为它无法穿透错误链，也不符合 Go 错误最佳实践。
- ✅ 可用于：单元测试中验证函数返回的错误是否为预期类型（
assert.IsType(t, &MyError{}, err)） - ❌ 不适用于生产环境中的错误处理逻辑，尤其当错误可能被中间件或库包装过
- ⚠️ 断言失败会 panic（若用
err.(*MyError)）或返回 nil（若用err, ok := err.(*MyError)），需额外判空
自定义错误类型的设计建议
为了让 errors.Is 和 errors.As 正常工作，自定义错误类型最好遵循以下习惯：
- 哨兵错误用包级
var定义（var ErrInvalid = errors.New("invalid input")），不要每次调用都errors.New - 结构体错误实现
Unwrap() error方法（如果支持包装），返回内部嵌套的 error - 避免同时暴露哨兵和结构体两种形式来表达同一语义；优先选一种：简单场景用哨兵，需携带上下文时用结构体
- 导出错误类型名（首字母大写），方便其他包调用
errors.As
基本上就这些。记住：用 errors.Is 回答“是不是这个错”，用 errors.As 回答“这个错里有没有我想要的类型”，类型断言只是临时辅助手段。不复杂但容易忽略细节。