io.multiwriter 是顺序分发而非原子写入，任一子 writer 失败即返回错误且不回滚已成功写入；它仅实现 io.writer 接口，无 writestring 方法，隐式转换易掩盖问题；多目标写入需自行封装事务逻辑，确保子 writer 生命周期覆盖全程。
io.MultiWriter 本质是顺序分发，不是原子写入
它只是把一次 Write 调用，按参数顺序依次转发给每个子 Writer。任一子写入失败（比如磁盘满、网络超时），就立刻返回错误，后续目标完全不执行——前面成功的不会回滚，也不会通知你“其它几个其实也失败了”。
- 常见现象：
write /var/log/app.log: no space left on device报错后，os.Stdout没输出，但日志文件里已有半截内容 - 根本原因：本地文件落盘快，放参数前面容易“先写后崩”；网络类
Writer易出错，应尽量放末尾 - 调试建议：临时拆开调用，单独对每个
Writer执行Write(p)，验证是否都能返回n == len(p)
WriteString 不是原生方法，隐式转换可能掩盖问题
io.MultiWriter 只实现了 io.Writer 接口，没有 WriteString 方法。你写的 mw.WriteString("hello") 实际触发的是 io.WriteString(mw, "hello")，它内部会把字符串转成 []byte 再调 Write。
- 问题常出在子
Writer对字节切片的处理逻辑上，比如自定义Writer忘记校验n == len(p) - 统一改用
mw.Write([]byte("hello"))，避免隐式转换带来的歧义和误判 -
bytes.Buffer虽然安全，但和网络Writer混用时可能掩盖阻塞问题——缓冲区满后Write会卡住，而io.MultiWriter不提供超时机制
多目标写入要“全成功或全失败”，别硬套 io.MultiWriter
它只是简化同步分发的工具，不是一致性管道。真要满足事务语义，得自己封装逻辑。
- 把易失败目标（如远程 HTTP 日志服务）抽出来，用独立
goroutine+context.WithTimeout控制，主流程只写本地文件+控制台 - 审计/双写类场景，优先考虑先落盘再异步投递（例如写完文件后发消息到 Kafka），而不是强求同步
- 真要封装原子写，得自己实现：收集所有
Writer的Write结果，任一失败就手动清理已写目标（比如truncate文件、重置buffer） - GORM 日志双写这种需求，直接实现一个带锁的
io.Writer，内部用sync.WaitGroup并行写并汇总error，比硬套io.MultiWriter更可控
子 Writer 生命周期必须覆盖整个写入过程
这是最常被忽略的一点：所有传给 io.MultiWriter 的子 Writer，其底层资源必须在整个写操作期间有效。
-
os.Stdout没问题，但如果你传了一个刚Close()的*os.File，运行时可能 panic 或静默丢数据 - 临时
bytes.Buffer如果作用域提前结束，也可能导致写入不可预期 - 尤其注意封装了
http.Post的自定义Writer：HTTP 连接生命周期是否与写入时机对齐？连接复用是否被正确管理？
io.MultiWriter 是个轻量分发器，不是保险柜。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
