multierror 不能直接捕获堆栈是因为其默认仅拼接错误文本，不保留子错误原始调用栈；需显式用 fmt.errorf("xxx: %w", err) 包装底层错误，并通过 %+v 或遍历 errors 字段输出完整堆栈。
为什么 multierror 不能直接捕获堆栈？
Go 标准库的 errors.Join 和早期 github.com/hashicorp/go-multierror 默认只拼接错误文本，不保留每个子错误的原始调用栈。你在日志里看到的往往是顶层错误的堆栈，底层失败点的 runtime.Caller 信息全丢了——这在微服务链路追踪中非常致命。
关键在于：必须显式启用堆栈捕获。新版 multierror（v1.1.0+）支持 multierror.Append 配合 fmt.Errorf 的 %w 动作，但前提是每个子错误本身已携带堆栈。
- 推荐做法：所有底层错误都用
fmt.Errorf("xxx: %w", err)包装，而不是errors.New或字符串拼接 - 避免在中间层用
err.Error()再造错误，会切断堆栈链 - 若使用
github.com/pkg/errors，需迁移到fmt.Errorf+%w，因pkg/errors已归档且与multierror堆栈融合不兼容
如何让 multierror.Error 输出完整堆栈？
默认 multierror.Error.Error() 只返回扁平化错误消息。要输出可读堆栈，必须调用 .ErrorOrNil() 并配合自定义格式化逻辑，或直接遍历 .Errors 字段。
实操建议：
- 不要依赖
log.Printf("%+v", multiErr)—— 它不会自动展开子错误堆栈 - 用
for _, e := range multiErr.Errors手动打印每个错误，并对每个e调用fmt.Printf("%+v\n", e)（%+v是关键） - 若用 zap/logrus，需封装一个
MultiErrorField函数，把multiErr.Errors转成字段数组，否则 JSON 日志里只存字符串 - 注意：只有用
fmt.Errorf包装且含%w的错误，%+v才会展开堆栈；裸errors.New即使放进multierror也无堆栈
在 gRPC / HTTP handler 中聚合多个并发错误时怎么避免 panic？
multierror.Append 不是线程安全的。微服务里常见模式是并发调用下游，然后汇总错误——如果多个 goroutine 同时往同一个 *multierror.Error 实例写，会 panic 或丢错误。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
正确姿势：
- 每个 goroutine 创建自己的
multierror.Error（或用new(multierror.Error)），最后用multierror.Append合并它们（该函数接收任意error，包括其他multierror.Error） - 更稳妥：用 slice 收集
error，最后一次性传给multierror.Combine（它内部做线程安全合并） - 切记别在闭包里共享
multiErr变量，例如for range中启动 goroutine 时直接引用外部multiErr - gRPC server 拦截器里若想统一收集验证错误，应在请求作用域内新建
multierror.Error，而非复用全局实例
和 OpenTelemetry trace 关联时要注意什么？
multierror 本身不感知 trace context，但微服务出错后，你往往需要把错误关联到当前 span。问题在于：多个子错误可能来自不同 span（比如并发调用三个下游服务），而 multierror 只存 error，不存 span。
可行方案：
- 不在
multierror里塞原始 error，而是塞带上下文的 wrapper，例如struct{ Err error; Span trace.Span }，再自定义Error()方法 - 更轻量：记录错误时，用
span.RecordError(err)对每个子错误单独调用一次，再把multierror整体作为主错误附加到 span - 避免把整个
multierror.Error当作 span 的唯一 error 上报——这样会丢失各子错误的独立 traceID 和状态码 - HTTP handler 返回 500 时，响应体里的错误详情应包含每个子错误的 code、message、traceID（如果有），而不是只吐出
multierror.Error().Error()
真正麻烦的是错误传播路径上的中间件——比如 auth middleware 报错、validator 报错、db query 报错，它们各自生成的错误堆栈层级不同，multierror 只负责聚合，不负责对齐调用上下文。这点得靠设计约定，不是靠库能解决的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
