multierror 不直接保留原始错误堆栈是因为默认仅拼接错误消息，需显式启用 WithIncludeStack(true) 或 ErrorFormat 并用 %w 包装子错误才能保留栈帧；errors.Join 完全不支持栈保留。
为什么 multierror 不直接保留原始错误堆栈？
Go 标准库的 errors.Join 和早期 multierror（v1.0 之前）默认只拼接错误消息，不保留每个子错误的调用栈。你在日志里看到的往往是 "failed to fetch user: failed to connect to DB"，但查不到具体是哪一行代码 dial 失败、哪一行 decode 出错。
关键点在于：只有显式启用 multierror.Append 的 multierror.ErrorFormat 配置，并配合 fmt.Errorf(..., %w) 包装，才能让每个子错误携带自己的栈帧。
- 必须用
%w而非%s或字符串拼接来包装底层错误，否则栈信息被截断 - v1.1+ 版本需设置
multierror.FormatFunc或启用multierror.WithIncludeStack(true) - 若用
errors.Join替代multierror，它完全不支持栈保留——这是硬限制
如何在 Gin HTTP handler 中收集并透传多错误堆栈？
Gin 默认 panic 恢复机制会丢弃 multierror 的结构化信息，只返回最外层错误文本。要让前端或下游服务拿到完整错误链和各子错误位置，得手动接管错误处理流程。
典型做法是定义一个中间件，在 c.Errors 为空时检查返回值是否为 *multierror.Error，然后序列化其 Errors 字段为 JSON 数组，每个元素包含 Error() 和 StackTrace()（需提前调用 multierror.ErrorFormat 注册）。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不要依赖
c.Error(err)自动推入c.Errors—— 它会 flatten 成单个字符串 - 用
multierror.Flatten(err)判断是否真有多个错误，避免空数组误报 - 在 JSON 响应中加字段如
"errors": [{"msg": "...", "stack": ["file.go:42", "svc.go:117"]}]
multierror 和 errors.Join 在微服务链路中的兼容性陷阱
跨服务调用时，如果上游用 multierror 封装，下游用 errors.Join 合并新错误，结果会丢失所有原始堆栈——因为 errors.Join 返回的是标准 joinedError 类型，不实现 multierror.Error 接口，也无法调用其 StackTrace() 方法。
更隐蔽的问题是：gRPC 的 status.FromError 无法解析 multierror.Error，会退化为 Unknown 状态码；必须先 multierror.Flatten 成单个 error 再转 status，否则链路追踪里看不到真实失败节点。
- 统一团队内错误聚合方案：全用
multierror，禁用errors.Join在关键路径 - 对外暴露 gRPC/HTTP 接口前，始终调用
multierror.Flatten，确保可被标准工具识别 - Prometheus 错误指标打点时，别用
err.Error()做 label —— 相同字符串掩盖不同根因，改用fmt.Sprintf("%T", err)+ 子错误类型计数
并发场景下 multierror.Append 的竞态风险
在 goroutine 中直接对全局或共享的 *multierror.Error 变量调用 Append 是不安全的——multierror.Error 内部用切片存储错误，没有锁保护。常见症状是 panic 报 fatal error: concurrent map writes（虽然它没用 map，但底层切片 append 触发的内存重分配可能被多协程同时触发）。
正确姿势是每个 goroutine 构造自己的 *multierror.Error，最后用 multierror.Append 合并（该函数本身是线程安全的）。
- 错误写法：
var errs *multierror.Error; go func() { errs = multierror.Append(errs, e) }() - 正确写法：
go func() { localErrs := multierror.Append(nil, e); mu.Lock(); totalErrs = multierror.Append(totalErrs, localErrs); mu.Unlock() } - 更推荐：用
sync.WaitGroup+ channel 收集每个 goroutine 的error，主线程统一构建multierror
multierror，而是怎么让每个子错误的 StackTrace() 在跨 goroutine、跨 HTTP/gRPC、跨日志采集器时不被 silently 吞掉。很多团队卡在第三层——以为用了 multierror 就万事大吉，结果排查问题时发现所有错误都指向同一行 handler.go:89。 
