go错误处理核心是类型断言与错误包装：用errors.as提取底层错误（需实现unwrap），errors.is判断哨兵值（需实现is），避免字符串匹配和裸断言。
Go 语言中没有传统意义上的“异常”，错误就是值，error 是一个接口。要检查错误类型，核心是**类型断言（type assertion）**和**错误包装（wrapping）**的正确处理——不这么做，errors.Is 和 errors.As 很容易失效。
用 errors.As 提取底层错误值
当你不确定错误是否由某个具体类型（比如 *os.PathError、*net.OpError）返回，又需要访问其字段时，errors.As 是首选。它会沿着错误链向上查找第一个匹配的底层错误类型。
常见错误：直接用类型断言 err.(*os.PathError)，但若错误被 fmt.Errorf("failed: %w", err) 包装过，就会失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终优先用
errors.As(err, &target)，而不是裸断言 -
target必须是指针变量，且类型需为具体错误类型（如*os.PathError） - 对自定义错误，确保实现了
Unwrap() error方法才能被正确遍历
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("path: %s, op: %s", pathErr.Path, pathErr.Op)
}
用 errors.Is 判断错误是否等于某个哨兵值
适用于判断是否是预定义的错误常量，比如 io.EOF、os.ErrNotExist，或你自己定义的 var ErrTimeout = errors.New("timeout")。
关键点：
-
errors.Is(err, io.EOF)能穿透多层%w包装，比err == io.EOF安全得多 - 仅适用于可比较的错误值（
errors.New或fmt.Errorf不带格式动词的简单包装），不适用于含字段的结构体错误 - 不要对自定义结构体错误直接用
errors.Is判断——它不会调用你的Is()方法，除非你显式实现该方法
自定义错误类型要支持标准判断逻辑
如果你写了类似 type MyError struct { Code int; Msg string }，默认 errors.Is 和 errors.As 都无法识别它。要让它融入 Go 错误生态，必须显式支持：
- 实现
Unwrap() error：返回被包装的下层错误（如有），否则errors.As和errors.Is无法向下遍历 - 实现
Is(target error) bool：用于errors.Is的自定义匹配逻辑（例如按Code字段比对） - 实现
Error() string：这是error接口的强制要求
漏掉 Unwrap 是最常见疏忽——哪怕你只包装一次，没它，上层调用 errors.As 就会停在你这层，再也找不到真正的底层错误。
避免用字符串匹配判断错误
像 strings.Contains(err.Error(), "permission denied") 看似简单，但极其脆弱：
- 错误消息可能随 Go 版本、系统语言、甚至日志封装而变化
- 无法区分语义相同但表述不同的错误（如 "access denied" vs "permission denied"）
- 完全绕过了错误类型的结构信息，丧失类型安全
真正需要区分权限类错误？用 errors.As(err, &os.SyscallError{}) 再检查 Err 字段，或用 os.IsPermission(err) 这类专用判定函数。
最易被忽略的其实是错误包装的深度和一致性：一次 %w 没加，整条错误链就断了；一个自定义错误忘了写 Unwrap，下游所有 errors.As 都会静默失败——这种问题在线上很难复现，只能靠代码审查和单元测试覆盖关键路径。
