io.MultiWriter仅支持同步镜像写入，无法按条件分流；它将同一数据复制到所有目标，不支持日志级别路由、WriteString或并发优化，任一子Writer出错即中止，且需注意空切片panic及参数顺序影响容错。
io.MultiWriter 不能分流，只能同步镜像写入
它不是“按条件分发”，而是把同一份数据原样复制到所有目标。比如你写 "hello"，每个 io.Writer 都会收到完整的 "hello"，无法做到 error 写文件、info 打屏这种分级行为。
常见错误现象：误以为 io.MultiWriter 能替代日志级别路由，结果所有级别日志都涌进同一个文件或控制台，调试时信息过载又无法过滤。
- 它只实现
Write([]byte)方法，不提供WriteString或级别判断能力 - 所有写入共用一个锁，高并发下容易成为瓶颈
- 任一子
Writer返回 error（如磁盘满、权限拒绝），写入立即中止，前面已成功的部分不会回滚
如何安全构造 io.MultiWriter 实例
别用嵌套调用：mw = io.MultiWriter(mw, newWriter) —— 容易漏赋值、创建冗余包装器、难以维护。
正确做法是先收集活跃的 io.Writer 到切片，再一次性展开：
var writers []io.Writer
if logToFile {
file, _ := os.OpenFile("app.log", os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)
defer file.Close()
writers = append(writers, file)
}
if logToStdout {
writers = append(writers, os.Stdout)
}
if len(writers) == 0 {
log.SetOutput(io.Discard)
} else {
multi := io.MultiWriter(writers...)
log.SetOutput(multi)
}
注意：writers... 是 Go 可变参数展开语法，不是省略号；空切片传给 io.MultiWriter 会 panic，必须兜底处理。
写入顺序影响容错和性能
io.MultiWriter 按参数顺序逐个调用 Write，所以顺序不是随意的。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 把稳定、快速、关键的目标（如本地日志文件）放前面，确保它优先落盘
- 把慢或易失败的目标（如 HTTP 日志服务、网络 socket）放后面，避免它卡住或中断关键日志
- 不要把
http.ResponseWriter放进io.MultiWriter—— 它写完可能关闭连接，后续写入会 panic
性能上，整体耗时由最慢的那个 Writer 决定；兼容性上，某些自定义 Writer 可能未正确实现 Write 的返回长度语义，导致截断，建议单独测试每个子写入器。
需要真正分流？换 zapcore.NewTee
当你要按日志级别、字段、环境变量等条件把不同内容发往不同目标（比如 error 写磁盘、warn 发 Slack、debug 输出到 stderr），io.MultiWriter 就彻底不合适了。
这时候该用 zapcore.NewTee，它支持多 Core 组合，每个 Core 可绑定独立的 WriteSyncer 和 LevelEnabler：
file, _ := os.OpenFile("error.log", os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)
console := zapcore.Lock(os.Stdout)
core1 := zapcore.NewCore(
zapcore.NewJSONEncoder(zap.NewProductionEncoderConfig()),
zapcore.AddSync(file),
zapcore.ErrorLevel,
)
core2 := zapcore.NewCore(
zapcore.NewConsoleEncoder(zap.NewDevelopmentEncoderConfig()),
console,
zapcore.InfoLevel,
)
logger := zap.New(zapcore.NewTee(core1, core2))
关键点：每个 Core 控制自己能接收哪些级别，互不干扰；WriteSyncer 可以是文件、网络、内存缓冲，甚至自定义封装；别直接用 zap.NewProduction()，它返回的是单输出实例，没法扩展。
真正复杂的日志拓扑里，io.MultiWriter 只适合做最底层的“物理镜像”，逻辑分流必须交给结构化日志库的 Core 层来处理 —— 这一点很容易被忽略，直到线上出问题才意识到写法从一开始就不对。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
