multierr.combine 会静默丢弃 nil 错误，只合并非 nil 的真实错误；multierr.append 是增量追加，每次返回新错误对象，适合循环累积；两者均不处理 nil，需手动过滤。
multierr.Combine 为什么不能直接合并 nil 错误
它会静默丢弃 nil，这是设计使然——multierr.Combine 只收集“真实错误”，不是做空值兜底的。如果你传入 nil，它就当没这回事，不报错也不提醒。
常见错误现象：调用链里某个分支没出错（返回 nil），但你仍把它塞进 multierr.Combine，结果发现最终错误“变少”了，甚至变成 nil，还以为逻辑漏了。
- 务必在传入前过滤或显式判断：
if err != nil { errors = append(errors, err) } - 别依赖
multierr.Append的“追加语义”来省略判空——它同样跳过nil - 如果想保留“某步未执行”的语义，得自己包装成非-nil 错误，比如
fmt.Errorf("step X skipped: %w", err)
multierr.Append 和 Combine 的行为差异在哪
multierr.Append 是增量式追加，适合循环中边跑边攒；multierr.Combine 是一次性合并切片，适合把已知多个错误打包。
使用场景不同导致行为差异明显：前者每次调用都返回新错误对象，后者接收 []error 并扁平化嵌套结构（比如把 multierror.Error 再拆开）。
立即学习“go语言免费学习笔记（深入）”；
-
multierr.Append(err1, err2)等价于multierr.Combine(err1, err2)，但只接受两个参数 - 多次用
Append累积，底层仍是新建multierror.Error，没有复用或优化内存 - 若已有
[]error切片，直接用multierr.Combine(errors...)更清晰，也避免中间对象
错误链里嵌套 multierror.Error 怎么避免重复展开
multierr 默认会展开嵌套的 multierror.Error，但有时你手动 wrap 了多次（比如用 fmt.Errorf("%w", err) 包了一层又一层），会导致同一错误在 Error() 输出里重复出现。
这不是 bug，是错误链遍历逻辑决定的：只要满足 errors.Is 或 errors.As，就会被识别并展开。
- 避免对已合并的
multierror.Error再用fmt.Errorf("%w", ...)包裹 - 如需添加上下文，改用
multierr.Append(fmt.Errorf("context: %w", err), otherErr)，而非二次 wrap - 调试时可用
multierr.Flatten(err)手动压平一次，再检查内容是否重复
和标准库 errors.Join 对比，什么情况必须用 multierr
errors.Join（Go 1.20+）也能合并多个错误，但它不提供 multierr.Append 那种流式构建能力，也不支持运行时动态追加（因为返回的是不可变的 joinError）。
更关键的是：当你需要把错误列表透传给下游、且下游要调用 errors.Unwrap 或 errors.As 做类型断言时，multierr 的行为更可控——它保证每个子错误都可被单独识别，而 errors.Join 在某些嵌套深度下可能丢失原始类型。
- 需要循环中逐步收集错误 → 必须用
multierr.Append - 要兼容老版本 Go（multierr
- 下游代码依赖
multierror.Error的具体方法（如Errors()）→errors.Join不满足
multierr 不是银弹，它解决的是“聚合”问题，不是“错误分类”或“恢复策略”问题——那得靠你自己设计上下文和判断逻辑。 
