怎么用 err.(type) 判断错误是不是自定义类型
Go 里没有“异常继承”概念，errors.Is 和 errors.As 是推荐方式，但类型断言仍是底层常用手段。直接写 err.(*MyError) 看似简单，但容易 panic——只要 err 不是该指针类型，运行时就崩。
正确做法是用双返回值形式做安全断言：
if myErr, ok := err.(*MyError); ok {
// 使用 myErr.Code 或 myErr.Msg
}
常见错误现象：把 err.(MyError)（值类型）和 err.(*MyError)（指针类型）搞混，尤其当你的错误是用 errors.New 包装过、或通过 fmt.Errorf 构造时，原始值可能已丢失指针语义。
- 自定义错误建议统一实现为指针类型（即
func (*MyError) Error() string），避免值接收器导致断言失败 - 如果错误链中嵌套了其他错误（比如用
fmt.Errorf("wrap: %w", err)），类型断言只对最外层有效；要查内层得用errors.Unwrap或errors.As - 断言前先确认
err != nil，否则nil做类型断言会得到零值 +ok=false，不 panic 但逻辑易错漏
为什么 errors.As 比类型断言更可靠
errors.As 能穿透错误包装（%w），自动遍历整个错误链找匹配类型，而类型断言只能看当前层级。这是它存在的根本原因。
立即学习“go语言免费学习笔记（深入）”；
使用场景很明确：你要处理的是被 fmt.Errorf("failed to x: %w", err) 包裹过的错误，且目标类型在链中间或底层。
var myErr *MyError
if errors.As(err, &myErr) {
// myErr 现在指向匹配到的实例
}
注意参数必须传指针（&myErr），不是值；否则 errors.As 无法写入。这也是最容易踩的坑——传错类型会导致始终返回 false，还看不出哪错了。
-
errors.As兼容接口类型断言（比如interface{ Timeout() bool }），比硬写结构体指针更灵活 - 性能上略低于直接类型断言（有链遍历开销），但日常 HTTP/DB 错误处理中可忽略
- Go 1.13+ 才有，老项目若还在用 1.12 及以前，得自己递归
Unwrap+ 断言
errors.Is 和 errors.As 别混用的典型场景
errors.Is 查的是错误是否等于某个值（比如 os.ErrNotExist），或实现了 Is 方法并返回 true；errors.As 查的是能否转换成某类型。两者目的完全不同。
常见错误现象：想判断错误是不是网络超时，却写了 errors.Is(err, &net.OpError{}) ——这永远 false，因为 Is 不做类型匹配，只做值比较或调 Is() 方法。
- 判断是否是特定错误值（如
io.EOF、sql.ErrNoRows）→ 用errors.Is - 想取错误里的字段（如
Timeout()、Code()、RetryAfter）→ 用errors.As - 既想判又想取，优先用
errors.As，成功后调对应方法（比如myErr.Timeout()），别再补一层errors.Is
多维错误处理时，fmt.Errorf 的 %w 不能乱加
加 %w 是为了保留原始错误以便后续用 errors.As 或 errors.Is 分析，但不是所有地方都该加。加错位置会让错误链变长、语义模糊，甚至暴露不该透出的内部错误。
典型反例：HTTP handler 里把数据库错误原样 %w 包进响应错误，结果用户看到 "pq: duplicate key violates unique constraint" ——这既是安全风险，也破坏封装。
- 对外返回错误时，只
%w那些需要被上层决策的错误（比如重试、降级、日志分类），其余应转为通用错误（如errors.New("service unavailable")） - 日志记录时建议用
fmt.Sprintf("%+v", err)，它会打印完整错误链和栈，比err.Error()有用得多 - 测试中验证错误链要用
errors.Is/errors.As，别依赖strings.Contains(err.Error(), "xxx")，后者脆弱且不可靠
错误链不是越深越好，关键在每一层是否承担明确职责：谁负责分类，谁负责修饰，谁负责兜底。断言只是工具，真正难的是设计错误传播的边界。
