应优先使用 errors.as 判断错误类型，而非 reflect.typeof；因 error 是接口，反射无法直接获取底层结构体字段或准确类型名，且 reflect.deepequal 比较不可靠。
怎么用 reflect.TypeOf 判定错误是否为特定类型
直接用 reflect.TypeOf 看不到底层错误类型，它返回的是接口的类型（*errors.errorString 或 *fmt.wrapError），不是你包装前的原始类型。真正要判断“这个 error 是不是 *os.PathError”，得先解包。
实操建议：
- 优先用
errors.As—— 它内部处理了嵌套、指针匹配、接口实现等边界情况，比反射安全得多 - 如果非要用反射，必须先用
errors.Unwrap一层层剥开，再对每个中间值调用reflect.TypeOf - 注意：
reflect.TypeOf(err).Name()对接口类型永远返回空字符串，得用reflect.TypeOf(err).Elem().Name()（前提是它是指针）
errors.As 和 reflect.ValueOf 混用会出什么问题
常见错误现象：把 errors.As(err, &target) 的 &target 换成 reflect.ValueOf(&target).Interface()，结果判定失败或 panic。
原因很简单：errors.As 要求第二个参数是「非 nil 的指针」，而 reflect.ValueOf(&target).Interface() 返回的是 interface{}，类型擦除后不再保留指针语义。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 别把反射值塞进
errors.As，它不接受reflect.Value - 若需动态类型匹配（比如从字符串名查类型），用
reflect.Zero(reflect.TypeOf((*MyError)(nil)).Elem()).Interface()构造目标指针，再传给errors.As - 记住：反射构造的指针必须和目标错误底层类型完全一致，包括导出性 ——
unexportedField无法被errors.As匹配
自定义错误类型在反射中丢失字段值的原因
使用 reflect.ValueOf(err).Interface() 后发现字段全为零值，或者 reflect.ValueOf(err).NumField() == 0，不是 bug，是 Go 的 error 接口约束导致的。
Go 的 error 是接口，任何实现了 Error() string 方法的类型都能赋值给它。但接口变量只保存方法集，不暴露结构体字段 —— 即使你传的是 *MyError，反射看到的也是接口头，不是原始结构体。
实操建议：
- 想读字段？必须先用
errors.As或类型断言还原为具体类型，再对结果做反射 - 避免在日志或序列化里直接对
error接口做reflect.ValueOf，它几乎没信息 - 如果真要泛化处理错误字段，定义统一接口（如
HasCode() int、Details() map[string]any），而不是依赖反射挖结构体
为什么 reflect.DeepEqual 不适合比较两个 error
现象：用 reflect.DeepEqual(err1, err2) 判断两个错误是否“相等”，结果不稳定 —— 有时 true，有时 false，哪怕它们 Error() 输出一样。
根本原因是：很多错误类型（比如 fmt.Errorf、errors.New）底层是私有结构体，字段含不可见的 frame 或 pc，每次创建都不同；而且 reflect.DeepEqual 会递归比较所有字段，包括未导出字段。
实操建议：
- 比较错误是否相等，用
errors.Is（判断是否同一类）或errors.As（判断是否可转为某类型） - 需要内容一致？只比
err1.Error() == err2.Error()，但注意这忽略类型差异，慎用于关键逻辑 - 单元测试里验证错误，优先 assert 类型 + 关键字段，而不是整个 error 值
最常被忽略的一点：反射能“看到”错误，但看不到它的语义。Go 的错误设计本意就是通过行为（Error()、Is()、As()）而非结构来交互。硬挖反射，往往说明抽象层出了问题。
