io.MultiWriter只有一份有内容是因为它不校验各写入器的Write返回值，错误时部分写入导致不一致；必须检查n和err，且需自行管理文件生命周期、避免同步阻塞。
用 io.MultiWriter 写多个文件时，为什么只有一份有内容？
因为 io.MultiWriter 是“写入即分发”，但它不处理底层 Write 调用的返回值校验——只要任意一个写入器返回错误（比如磁盘满、权限不足、文件被删），整个写操作就失败，但其他写入器可能已部分写入，造成数据不一致或静默截断。
- 务必检查
io.MultiWriter.Write()的返回n和err，不能只看是否为nil - 如果某个文件写入失败（如
write /var/log/app2.log: no space left on device），其余文件仍会继续写，但你不会自动知道哪边断了 - 推荐封装一层：用
sync.Once或独立 goroutine 分别管理每个文件写入，并统一收集错误
日志多端分发时，os.File 和 io.Writer 的生命周期怎么管？
文件句柄是稀缺资源，io.MultiWriter 本身不持有或关闭任何 io.Writer，它只是转发 Write。一旦你把 *os.File 塞进去，就得自己负责 Close()，否则泄漏。
- 不要在
io.MultiWriter初始化后立刻Close()对应的*os.File - 如果日志需要轮转（如按天切文件），不能直接替换
*os.File变量——MultiWriter里存的是旧指针，新文件不会被写入 - 可行做法：用接口包装，例如
type LogWriter struct { mu sync.RWMutex; w io.Writer }，写前RLock()，轮转时Lock()替换内部w
性能瓶颈常出在 io.MultiWriter.Write 同步阻塞上
io.MultiWriter 是同步串行写入所有目标，耗时 = 所有写入器中「最慢的那个」的耗时。比如一个写本地 SSD，一个写远程 syslog socket，后者延迟高，会拖垮整体吞吐。
- 避免把网络 I/O（如 HTTP 日志上报）和本地文件混进同一个
io.MultiWriter - 高频日志场景下，优先考虑异步分发：用 channel + goroutine 把日志分发到不同 writer，而不是靠
MultiWriter硬扛 - 小数据（bufio.NewWriter 包裹各
*os.File，但注意：缓冲区满或Flush()才真正落盘，崩溃可能丢日志
替代方案：不用 io.MultiWriter 怎么安全分发？
当需要错误隔离、独立缓冲、或不同写入策略（如失败重试、降级），硬套 io.MultiWriter 反而增加维护成本。
立即学习“go语言免费学习笔记（深入）”；
- 最简替代：
for _, w := range writers { w.Write(p) }，显式控制每路行为 - 需并发写入：启动固定数量 goroutine，用
sync.WaitGroup等待全部完成，再聚合错误 - 想保留
io.Writer接口又需灵活控制？实现自定义类型：type MultiLogWriter struct { writers []io.Writer; mu sync.RWMutex }，重写Write方法做定制逻辑
多端日志最麻烦的从来不是“怎么写出去”，而是“某一路挂了要不要停其他路”“失败了要不要告警”“时间戳/上下文要不要每路都重算”——这些 io.MultiWriter 一概不管，得你补全。
