应使用 errors.As(err, &e) 判断自定义错误类型，它可安全穿透多层包装并提取底层值；若错误未被包装且类型明确，可用类型断言 if e, ok := err.(MyCustomError); ok {…}，但需避免对 nil 断言。
如何判断 error 是否为特定自定义错误类型
Go 中的 error 是接口，底层可能指向任意实现了 Error() 方法的类型。直接用 == 比较会失败，必须用类型断言或 errors.As() 提取原始值。
常见错误现象：写 if err == MyCustomError{...} 总是 false；或者用 err.(MyCustomError) panic，因为断言失败没处理。
- 优先使用
errors.As(err, &target)—— 它能穿透多层包装（比如fmt.Errorf("wrap: %w", e)），安全提取底层错误 - 若确定错误未被包装，且类型明确，可用类型断言：
if e, ok := err.(MyCustomError); ok { ... } - 避免对
nil做断言：err为nil时，err.(MyCustomError)会 panic；而errors.As(nil, &t)返回false，安全
为什么 errors.Is 和 errors.As 行为不同
errors.Is 判断「是否等于某个错误值或其包装链中的某一层」，适合检查是否为预设的哨兵错误（如 io.EOF）；errors.As 则尝试将错误「转换成具体类型」，用于获取结构体字段或调用方法。
使用场景举例：你封装了一个带重试次数的错误 type RetryError struct{ Attempts int }，需要读取 Attempts 字段 —— 这时只能用 errors.As，errors.Is 无法帮你拿到结构体实例。
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is(err, io.EOF)→ 正确，io.EOF是变量，可比较 -
errors.Is(err, MyCustomError{})→ 错误，传的是值而非地址，且Is不支持结构体字面量匹配 -
errors.As(err, &e)要求e是对应类型的非 nil 指针，否则返回false
自定义错误类型必须实现 Error() 方法才能被识别为 error
如果定义了结构体但没实现 Error() string，它就不是 error 接口，无法赋值给 error 变量，更谈不上断言。
示例中常见疏漏：忘记导出方法名（写成 error()）、返回值类型写错（如 func Error() int）、或方法接收者用值而非指针导致方法集不完整（尤其当结构体较大时，指针接收者更合理）。
- 正确写法：
func (e *MyError) Error() string { return e.Msg } - 若用值接收者：
func (e MyError) Error() string，则*MyError和MyError都满足error接口，但前者更常用（避免拷贝） - 字段需导出（首字母大写），否则外部包无法访问，
errors.As虽能成功断言，但取字段会报错
嵌套错误时断言失败的典型原因
用 fmt.Errorf("failed: %w", originalErr) 包装后，原始错误被藏在内部。此时直接对包装后的 err 做 err.(MyError) 断言必然失败，因为外层是 *fmt.wrapError 类型。
这也是为什么官方推荐统一用 errors.As 和 errors.Is —— 它们会自动递归遍历 %w 链。
- 手动解包（不推荐）：
if w, ok := err.(interface{ Unwrap() error }); ok { inner := w.Unwrap() }，但只解一层，不通用 - 正确做法：
var e *MyError; if errors.As(err, &e) { fmt.Println(e.Attempts) } - 注意：若包装时用了
%v或字符串拼接（如"failed: " + err.Error()），错误链就断了，errors.As无法穿透
最易被忽略的一点：断言目标变量必须是指针类型且非 nil，且自定义错误的字段和方法都得导出；否则看似语法通过，运行时取不到值或 panic。
