能，errors.Is 和 errors.As 可靠检查包装链，但要求错误必须用 fmt.Errorf("%w") 包装或自定义类型实现非 nil 的 Unwrap() 方法，否则链断裂导致检测失败。
Go 1.13+ 的 errors.Is 和 errors.As 能否可靠检查包装链？
能，但必须确保错误是用 fmt.Errorf 加 %w 包装的，不是 %v 或字符串拼接。用错方式会导致整个包装链断裂，errors.Is 查不到底层错误，errors.As 也无法解包到具体类型。
-
%w是唯一被 Go 错误系统识别为“包装”的机制；%v、+ ""、sprintf都只生成新错误值，不保留原始错误引用 - 第三方库（如
github.com/pkg/errors）的Wrap在 Go 1.13+ 中仍可工作，但其返回值需满足Unwrap() error方法签名，否则errors.Is会跳过它 - 自定义错误类型若想参与包装链，必须实现
Unwrap() error方法，且不能返回nil（除非已是链尾）
测试中怎么写断言来验证某错误是否包裹了 os.ErrNotExist？
直接用 errors.Is(err, os.ErrNotExist)，而不是 err == os.ErrNotExist 或字符串匹配。前者会递归遍历整个 Unwrap() 链，后者只比对最外层。
- 常见错误：在测试里写
assert.Equal(t, err, os.ErrNotExist)—— 这永远失败，因为包装后的错误不是同一个实例 - 更隐蔽的坑：用
strings.Contains(err.Error(), "no such file")—— 一旦底层错误消息变更或被多层翻译，断言就失效 - 如果需要获取被包装的具体错误值（比如检查它的字段），用
errors.As(err, &target)，其中target是对应类型的指针
if !errors.Is(err, os.ErrNotExist) {
t.Fatal("expected wrapped os.ErrNotExist, got:", err)
}
为什么 errors.Is 有时返回 false，明明日志里能看到 “caused by”？
日志输出的 “caused by” 是格式化时人工拼的字符串，和运行时的包装链无关。真正起作用的只有 Unwrap() 方法返回的错误值。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 典型场景：中间件或工具函数用了
fmt.Errorf("handler failed: %v", err)—— 这里用的是%v，没调Unwrap()，链就断了 - 另一个常见点：HTTP handler 中用
http.Error(w, err.Error(), http.StatusInternalServerError)后继续返回err，但上游可能已丢弃原错误，只留字符串 - 调试技巧：临时加一行
fmt.Printf("unwrapped: %+v\n", errors.Unwrap(err))看实际能解开几层
自定义错误类型如何正确支持包装链检测？
必须显式实现 Unwrap() error 方法，并返回内部保存的原始错误。不实现，或返回 nil 过早，都会让 errors.Is 停止遍历。
立即学习“go语言免费学习笔记（深入）”；
- 不要在
Unwrap()里做逻辑判断（比如“只有 debug 模式才返回”），这会让测试行为不一致 - 如果错误包含多个子错误（如批量操作失败），
Unwrap()应只返回一个（通常是第一个或主因），Go 官方目前不支持多分支包装 - 嵌套包装时注意循环引用：A.Wrap(B), B.Wrap(A) 会导致
errors.Ispanic，测试里要避免构造这种结构
type MyError struct {
msg string
cause error
}
func (e *MyError) Error() string { return e.msg }
func (e *MyError) Unwrap() error { return e.cause }
测试里最容易被忽略的，是包装链依赖运行时行为而非字符串内容——只要有一处用了 %v 或忘了实现 Unwrap，整条链就静默失效，而错误日志看起来依然“合理”。 
