errors.is 和 errors.as 无法穿透自定义错误包装，是因为包装层未正确实现 unwrap() 方法，导致错误链在第一层中断；必须每层都实现 unwrap() 才能支持多级解包。
为什么 errors.Is 和 errors.As 无法穿透自定义错误包装？
因为 Go 的错误包装（如 fmt.Errorf("wrap: %w", err)）默认只保留底层错误的值，不暴露其具体类型。当你用 errors.As 尝试提取某个自定义错误类型时，如果中间层没实现 Unwrap() 或实现得不完整，查找就会在第一层断掉。
常见错误现象：errors.As(err, &target) == false，但你知道 err 里肯定包着 target；或者 errors.Is(err, myErr) 返回 false，尽管 err 是用 %w 包装过它的。
- 确保每一层包装错误都正确实现了
Unwrap() error方法（返回被包装的error） - 若需多级解包（比如嵌套两层包装），必须每层都支持
Unwrap()，否则errors.Is/As只查到第一层就停 - 避免在包装中做“条件性 Unwrap”——比如某些情况下返回 nil，这会让错误链断裂
如何让自定义错误既隐藏实现、又支持标准判断？
关键不是“不暴露类型”，而是“控制暴露方式”。Go 官方推荐的做法是：定义私有结构体 + 公开判定函数 + 实现 Unwrap 和 Is（可选）。
使用场景：你提供一个 SDK，内部用 *os.PathError 做底层操作，但不想用户依赖 os.PathError 字段；同时又希望调用方能用 errors.Is(err, ErrNotFound) 判断。
立即学习“go语言免费学习笔记（深入）”；
- 定义错误变量时用
var ErrNotFound = errors.New("not found")，而非公开结构体 - 自定义错误类型字段设为小写（如
path string），外部不可访问 - 实现
Unwrap() error返回底层错误，让errors.Is能继续向下查 - 如果需要精确匹配某类底层错误（比如只对
*os.PathError做特殊处理），再加Is(error) bool方法
type wrappedError struct {
msg string
err error // 底层真实错误
code int
}
func (e *wrappedError) Error() string { return e.msg }
func (e *wrappedError) Unwrap() error { return e.err }
func (e *wrappedError) Is(target error) bool {
if _, ok := target.(interface{ IsMyCode(int) bool }); ok {
return e.code == 404
}
return false
}
%w 包装 vs fmt.Errorf("%s", err)：差在哪？
前者保留错误链，后者彻底切断。用字符串拼接会丢失所有类型信息和底层错误，errors.Is 和 As 在它面前完全失效。
性能影响几乎可忽略，但兼容性影响巨大：任何基于错误链的诊断、重试、日志分类逻辑都会失效。
- 永远不要用
fmt.Sprintf("%v", err)或err.Error()再造新错误 -
%w只能出现在fmt.Errorf的最后一个参数，且只能有一个；多个包装要用嵌套调用 - 注意：如果传给
%w的是 nil，整个 error 变成 nil，这是易踩坑点
什么时候该隐藏错误类型，什么时候不该？
隐藏的目的是解耦，不是保密。如果你的错误类型本身承载了业务语义（比如 ValidationError），那它就应该被识别；如果你只是把 os.Open 失败转成 “failed to load config”，那底层 *os.PathError 就该藏住。
容易被忽略的复杂点：日志和监控系统往往依赖错误类型做聚合或告警。如果全盘隐藏，会导致 “unknown error” 泛滥；但如果暴露太多，又会让调用方无意中依赖内部实现。
- 对外暴露的错误变量（如
ErrTimeout）应保持稳定，哪怕底层实现换掉也要保证errors.Is(err, ErrTimeout)有效 - 调试阶段可在错误中保留
stack或cause字段（非导出），用专用函数提取，不走标准错误接口 - 测试时别只检查
Error()输出字符串——它最不稳定；优先测errors.Is和行为响应
