应使用 errors.as() 或类型断言判断自定义错误类型，而非字符串比较；errors.as() 可穿透多层 %w 包装，支持错误链提取，且要求结构体字段首字母大写并实现 error() 和可选 unwrap() 方法。
如何判断错误是否为自定义类型
Go 中的错误本质是接口，error 接口只含一个 Error() 方法，因此不能靠值比较或字符串匹配来识别自定义错误。必须用类型断言或 errors.As() 来提取底层具体类型。
常见错误写法是：if err.Error() == "my custom error" —— 这既脆弱（消息可能变）、又无法区分同名不同类型的错误。
- 推荐用
errors.As(err, &target)：能正确处理嵌套错误链（比如被fmt.Errorf("wrap: %w", err)包裹过的错误） - 若确定错误未被包装且是直接返回，可用类型断言：
if e, ok := err.(*MyError); ok { ... } -
errors.Is(err, myErr)适合判断是否等于某个预定义的错误变量（如var ErrNotFound = errors.New("not found")），但不适用于带字段的结构体错误
定义可识别的自定义错误结构体
要让错误支持 errors.As() 提取，结构体需满足两个条件：实现 error 接口、且字段公开（否则无法被反射赋值）。同时建议实现 Unwrap() 方法以支持错误链遍历。
例如：
立即学习“go语言免费学习笔记（深入）”；
type ValidationError struct {
Field string
Value interface{}
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed on field %q with value %v", e.Field, e.Value)
}
func (e *ValidationError) Unwrap() error { return nil } // 若不嵌套其他错误，返回 nil
- 注意：字段名首字母大写（
Field而非field），否则errors.As()无法赋值 - 如果错误需要包装另一个错误，把被包装的错误存为字段（如
Err error），并在Unwrap()中返回它 - 避免在
Error()方法中拼接敏感信息（如密码、token），日志时容易泄露
在 HTTP handler 中统一处理自定义错误
Web 服务常需根据错误类型返回不同状态码和响应体，比如 *ValidationError 返回 400，*NotFoundError 返回 404。手动在每个 handler 里写 if errors.As(...) 易遗漏，应抽离到中间件或统一响应封装中。
- 定义错误到 HTTP 状态码的映射表，用
switch或 map + 类型断言判断 - 不要在中间件里直接调用
w.WriteHeader()后再写 body —— 若后续 handler panic，可能已写部分响应，改用 response writer 包装器拦截 - 若使用
net/http，推荐在 handler 函数签名中返回error，由顶层调用者统一处理，而非在 handler 内部直接http.Error()
为什么 errors.As() 比类型断言更安全
errors.As() 能穿透多层 %w 包装，而类型断言只能检查最外层错误类型。例如：fmt.Errorf("db failed: %w", &ValidationError{...})，此时 err.(*ValidationError) 会失败，但 errors.As(err, &e) 仍能成功提取。
- 只要错误链中任意一层是目标类型，
errors.As()就返回 true - 它内部使用 unsafe 和反射，但标准库已充分测试，生产环境可放心使用
- 若目标变量是指针，
errors.As()会尝试将匹配的错误赋值给该指针指向的内存；所以务必传入指针变量（&e），而非值（e）
真正难的是设计错误层次——比如该把数据库连接失败、查询超时、主键冲突分别定义为不同结构体，还是用一个 DBError 加 Code 字段区分。这取决于你是否需要在不同层级做差异化处理，而不是单纯为了“看起来像面向对象”。
