自定义错误需用结构体实现Error()方法，导出字段便于读取，指针类型支持errors.As提取，嵌入cause并实现Unwrap()可构建错误链，避免字符串匹配。
为什么不能直接用 errors.New 或 fmt.Errorf？
当你需要区分错误类型（比如做 if errors.Is(err, ErrTimeout)）、携带额外字段（如错误码、请求ID、重试次数），或实现特定的 Error() 格式化逻辑时，errors.New 和 fmt.Errorf 就不够用了。它们返回的是无结构的 *errors.errorString，无法扩展行为，也不支持类型断言识别。
如何定义可识别、可携带数据的自定义错误类型？
标准做法是定义一个结构体，并实现 Error() string 方法。关键点在于：是否导出字段、是否嵌入 error、是否实现 Unwrap() —— 这些直接影响错误链和判断逻辑。
- 导出字段（如
Code）便于外部读取，但需谨慎暴露内部状态 - 不嵌入
error可保持干净；若要包装底层错误，应显式声明字段（如cause error）并实现Unwrap() - 必须实现
Error() string，否则不是合法的error接口值
type ValidationError struct {
Code int
Field string
Message string
ReqID string // 非标准但实用的上下文字段
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed (code=%d, field=%s): %s [req=%s]", e.Code, e.Field, e.Message, e.ReqID)
}
func (e *ValidationError) Unwrap() error {
return nil // 当前不包装其他错误；若需链式，返回 e.cause
}
如何正确判断和使用自定义错误？
避免用字符串匹配（strings.Contains(err.Error(), "validation")），应优先用类型断言或 errors.As。注意：只有指针类型才能被 errors.As 成功提取，所以定义时用 *ValidationError，创建时用 &ValidationError{...}。
-
errors.Is(err, ErrInvalid)仅适用于预定义的变量错误（如var ErrInvalid = &ValidationError{Code: 400}） -
errors.As(err, &target)才能提取结构体字段，target 必须是指针 - 如果错误被多层
fmt.Errorf("wrap: %w", err)包装，errors.As仍能穿透找到最内层的自定义类型
var ve *ValidationError
if errors.As(err, &ve) {
log.Printf("Validation error: code=%d, field=%s, req=%s", ve.Code, ve.Field, ve.ReqID)
if ve.Code == 400 {
http.Error(w, ve.Message, http.StatusBadRequest)
return
}
}
常见陷阱：为什么 errors.As 总是失败？
最常踩的坑是创建错误时用了值而非指针，或者接收目标用了值类型。Go 的接口值存储的是具体类型的动态值 —— 若你传入 ValidationError{...}（值），它实现 error，但 errors.As 无法将接口值“转换”成值类型地址，只能转成指针类型。
- ❌ 错误写法：
err := ValidationError{Code: 400}→ 类型是ValidationError，非指针，errors.As失败 - ✅ 正确写法：
err := &ValidationError{Code: 400} - ❌ 错误接收：
var ve ValidationError; errors.As(err, ve)→ 第二个参数不是指针 - ✅ 正确接收：
var ve *ValidationError; errors.As(err, &ve) - 另外注意：如果自定义类型没导出字段，外部包无法访问字段，但类型断言本身仍可成功
Unwrap、创建时用不用指针——每个选择都会在错误传播链的下游产生实际影响。 
