io.MultiWriter 不保证原子性：任一 Write 失败即停止且不回滚，导致数据不一致；须检查 error 并自行实现事务逻辑，不可依赖其强一致性。
io.MultiWriter 写入多个目标时数据不一致？
根本原因是 io.MultiWriter 是“尽力而为”写入：只要任意一个 Write 返回错误，它就立刻停止后续写入，且**不回滚已成功的写入**。你看到部分文件有内容、部分为空，大概率是中间某个 Writer 出错了（比如磁盘满、权限不足、网络连接断开），但前面的 os.File 已经落盘了。
常见错误现象：write /tmp/log: no space left on device 后，日志文件写了一半，标准输出却没收到；或者 HTTP 响应体只写到 ResponseWriter，没写进审计日志文件。
- 务必检查返回的
error：它代表的是**第一个失败的写入错误**，不是全部结果 - 不要假设所有目标都写成功了——
io.MultiWriter不提供原子性保障 - 如果业务要求“全写成功或全不写”，得自己封装重试或事务逻辑，不能依赖
io.MultiWriter
用 io.MultiWriter 时 Writer 顺序影响性能和容错
io.MultiWriter 按参数顺序逐个调用 Write，所以把慢的、易出错的 Writer 放后面更稳妥。比如同时写本地文件 + 远程 HTTP 日志服务，把 http.Post 包装的 Writer 放最后，至少保证本地日志先落地。
性能上，最慢的那个 Writer 决定整体耗时；兼容性上，注意有些 Writer（如 http.ResponseWriter）可能不支持重复写或写完即关闭，放太前会导致后续写入 panic 或静默失败。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 优先把稳定、快速、关键的目标放前面（如
os.Stdout、本地*os.File） - 避免把
bytes.Buffer和网络Writer混在一起——前者几乎不失败，后者超时/断连会中断整个链 - 如果某
Writer可能阻塞（如未设置超时的net.Conn），必须单独做超时控制，io.MultiWriter本身不处理
为什么 WriteString 调用后部分目标没内容？
io.MultiWriter 只实现 io.Writer 接口，没有 WriteString 方法。如果你直接对 io.MultiWriter 调用 WriteString，实际走的是 io.WriteString 函数，它内部会把字符串转成 []byte 再调 Write —— 看似没问题，但某些 Writer（比如自定义的、未正确实现 Write 的）在处理字节切片时行为异常，导致写入截断或跳过。
- 统一用
Write方法传[]byte，别混用WriteString - 确认每个子
Writer都满足：写入长度等于输入长度，除非返回 error - 调试时可临时拆开，单独测试每个
Writer是否能正确接收并写出完整字节
替代方案：需要可靠分发时别硬扛 MultiWriter
当场景涉及日志归档、审计双写、响应镜像等强一致性需求，io.MultiWriter 就是错的工具。它设计初衷只是简化“同步写多处”的代码，不是构建可靠管道。
- 用 goroutine + channel 分发：每个目标独立写，失败可单独重试或告警
- 用
io.Pipe拆流，配合io.Copy并发写入，失败不影响其他分支 - 对关键路径（如支付响应日志），宁可多写几行代码做显式错误检查和补偿，也不要赌
io.MultiWriter的“看起来省事”
真正难的从来不是怎么把字节塞进多个 Writer，而是搞清楚哪几个目标必须成功、失败后要不要补、补不了能不能降级——这些决策点，io.MultiWriter 一个都不管。
