errors.Join 不适合链路追踪，因其仅聚合错误而不保留调用顺序、嵌套层级和上下文字段（如 traceID、spanID），无法构建可追溯的错误传播路径。
Go 1.20+ 的 errors.Join 为什么不能直接用于链路追踪
它只是把多个错误聚合成一个 error 值，不保留调用顺序、不支持嵌套层级、也不提供上下文字段（如 traceID、spanID）。你用 errors.Join(err1, err2, err3) 后，errors.Unwrap 只能拿到第一个（或全部，取决于实现），但无法区分“谁在上层封装了谁”。链路追踪需要的是错误传播路径，不是错误集合。
实操建议：
-
errors.Join适合日志聚合或批量校验失败汇总（比如配置项校验返回所有错误），不适合替代包装器 - 若强行用它做链路追踪，后续调用
errors.Unwrap会丢失结构——它返回[]error，而标准库的fmt.Errorf("%w", ...)只接受单个error - 真正要构建错误链，必须靠手动嵌套：用
fmt.Errorf("at db layer: %w", innerErr)一层套一层
如何让自定义错误类型支持 Unwrap 和链式 Is/As
标准库的 errors.Is 和 errors.As 依赖 Unwrap() 方法返回下一个错误。如果你写了个带 traceID 的错误包装器，但没实现 Unwrap，那整个链就断了——上游查不到原始错误类型，也匹配不到 os.IsNotExist 这类判定。
正确做法是让包装器同时满足两个条件：
立即学习“go语言免费学习笔记（深入）”；
- 实现
Unwrap() error方法，返回被包裹的err（不能返回nil，除非是终端错误） - 如果要透传原始错误的底层行为（比如
Timeout()或Temporary()），还得把对应方法也转发过去 - 不要在
Unwrap()里加逻辑（比如过滤、转换），否则errors.Is行为会不可预测
示例：
type TracedError struct {
err error
traceID string
}
func (e *TracedError) Error() string {
return fmt.Sprintf("trace[%s]: %v", e.traceID, e.err)
}
func (e *TracedError) Unwrap() error {
return e.err // 关键：只返回原始 error，不加工
}
fmt.Errorf("%w", err) 包装时，为什么有时 errors.Is 失败
常见原因是被包装的 err 本身不支持 Unwrap，或者你用了非标准方式构造错误（比如直接返回 &MyError{...} 却没实现 Unwrap）。更隐蔽的问题是：你在中间某层用了 fmt.Errorf("%v", err)（注意是 %v 不是 %w），这会彻底切断错误链。
排查要点：
- 逐层检查是否所有包装都用了
%w，哪怕只有一处写成%s或%v，链就断了 - 确认底层错误（比如第三方库返回的）是否实现了
Unwrap；有些老版本 SDK 返回的是裸errors.New，不支持展开 -
errors.Is是深度优先遍历整个Unwrap链，但一旦某环节返回nil，就停止向下——所以别在Unwrap()里加条件返回nil
在 HTTP handler 中注入 traceID 并保持错误链完整
最易出错的地方是：handler 拿到 context.Context 里的 traceID，想塞进错误，但又不想破坏 %w 链。这时候不能新建一个独立错误再 Join，也不能丢掉原始 err。
推荐模式是写一个轻量包装函数：
func WithTrace(err error, traceID string) error {
if err == nil {
return nil
}
return &TracedError{err: err, traceID: traceID}
}
然后在 handler 里这样用：
- 不要：
return errors.Join(err, fmt.Errorf("trace=%s", traceID)) - 要：
return WithTrace(err, getTraceID(r.Context())) - 后续任何地方调用
errors.Is(err, os.ErrNotExist)仍能命中，因为TracedError.Unwrap()正确返回了err
注意：如果你用 OpenTelemetry 或类似框架，它的 Span 已经在 context 里，错误包装只需读取，不要重复存储 traceID 字段——除非你要导出到日志系统做独立检索。
