Go 1.20+ 链式错误需始终用 %w 封装以保留类型与堆栈，避免 %v 断链；errors.Join 返回可穿透的复合错误；errors.Is 递归检查全链，优于手动 Unwrap；自定义错误一般无需实现 Is，除非需特殊匹配逻辑。
Go 1.20+ 的 fmt.Errorf 链式错误封装怎么写才不丢上下文
直接用 fmt.Errorf("failed to read config: %w", err) 是最安全的链式起点，但很多人漏掉关键点：只有 %w 能保留原始错误类型和堆栈（如果底层实现了 Unwrap()），%v 或 %s 会把错误转成字符串，断开链。
常见错误现象：errors.Is(err, io.EOF) 返回 false，尽管原始错误确实是 io.EOF——因为中间某层用了 %v。
- 始终优先用
%w封装可恢复错误（如 I/O、网络、解析失败） - 只在日志或用户提示时用
%v，且确保不用于判断逻辑 - 若需附加结构化信息（如请求 ID、重试次数），建议用自定义错误类型实现
Unwrap()和Error()，而非拼接字符串
如何用 errors.Join 合并多个错误又保持可查性
errors.Join 不是简单拼字符串，它返回一个实现了 Unwrap() 的复合错误，支持 errors.Is 和 errors.As 向下穿透查找任意子错误。
使用场景：批量操作中部分失败（如并发上传多个文件）、校验多个字段都出错、HTTP 多个 header 解析失败。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 合并后仍可用
errors.Is(err, fs.ErrNotExist)判断是否存在某个底层错误 - 但
errors.As(err, &target)只会匹配第一个能转换成功的子错误，顺序有影响 - 不要对
nil调用errors.Join，它会忽略nil值，但容易误判“没错误”——建议先过滤nil
errors.Unwrap 和手动递归遍历错误链的区别在哪
errors.Unwrap 只取直接包装的错误（单层），而真实错误链可能是多层嵌套（A 包 B，B 包 C）。想检查整个链是否含某个错误类型，必须递归调用或用 errors.Is ——后者内部就是这么做的。
容易踩的坑：写个循环反复 errors.Unwrap 却没处理循环引用（比如自定义错误里不小心把自身赋给了 cause 字段），导致无限循环。
- 优先用
errors.Is(err, target)替代手写展开逻辑 - 若真要遍历全链做定制处理（如收集所有 HTTP 状态码），用
errors.Unwrap+ 显式去重检测 - 注意
fmt.Errorf("oops: %w", nil)返回nil，errors.Unwrap(nil)也返回nil，别假设非空
自定义错误类型要不要实现 Is 方法
绝大多数情况不用。Go 标准库的 errors.Is 已通过反射比较底层错误值，只要链中任一环节用了 %w，就能穿透到目标错误。自己实现 Is 容易出错，还可能破坏标准行为。
例外：你的错误类型需要响应非标准匹配逻辑，比如“只要错误消息含 'timeout' 就算超时”，或者封装了带状态码的 gRPC 错误，想让 errors.Is(err, status.Error(codes.DeadlineExceeded, "")) 成立。
- 实现
Is(error) bool时，必须同时调用errors.Is检查被包装错误，否则断链 - 不要在
Is里做耗时操作（如正则匹配），它可能被高频调用 - 如果只是加字段（如
Retryable bool），用errors.As提取更清晰
%w、哪一层该终止传播、哪一层该打日志但不再包装」——这取决于错误语义，不是技术能力问题。 
