不能直接用 io.MultiWriter 拼接多个后端，因其会导致日志格式不统一、并发竞争、单点失败导致全链路写入失败且缺乏错误隔离；正确做法是自定义 MultiHandler，每个后端独立格式化、容错和异步写入，并通过 atomic.Value 实现安全热更新。
为什么不能直接用 io.MultiWriter 拼接多个后端？
表面上看，把 os.file、net.conn、bytes.buffer 全塞进 io.multiwriter 似乎就能“同时写多个后端”，但实际会出问题：日志格式不统一、写入并发竞争、单个后端失败导致整条日志丢失、缺乏错误隔离。比如某个 http 日志服务超时，multiwriter.write() 就直接返回错误，连本地文件都写不进去。
真正可行的路径是——自己控制写入生命周期，每个后端独立处理、独立容错、独立格式化。
- 每个后端应接收原始日志结构体（如
LogEntry{Time, Level, Msg, Fields}），而非已格式化的字符串 - 格式化（JSON / 文本 / Protobuf）应在后端内部完成，避免前置串行化拖慢快后端（如内存缓冲）
- 写入必须包裹
recover()或显式err != nil判断，失败不传播 - 推荐用 goroutine 异步写入（带限速/队列），但注意：不是所有后端都适合异步——比如审计日志要求强顺序和落盘确认
log/slog 的 Handler 接口怎么组合多个后端？
Go 1.21+ 的 slog 天然支持多后端：只要实现 slog.Handler，在 Handle() 方法里分发到不同目标即可。关键不是“怎么写”，而是“怎么避免阻塞主线程 + 怎么做错误分流”。
示例骨架：
type MultiHandler struct {
handlers []slog.Handler
mu sync.RWMutex
}
func (h *MultiHandler) Handle(_ context.Context, r slog.Record) error {
h.mu.RLock()
defer h.mu.RUnlock()
var wg sync.WaitGroup
var mu sync.Mutex
var firstErr error
for _, handler := range h.handlers {
wg.Add(1)
go func(h slog.Handler) {
defer wg.Done()
if err := h.Handle(context.Background(), r); err != nil {
mu.Lock()
if firstErr == nil {
firstErr = err
}
mu.Unlock()
// 这里可加告警、打 metric、或写 fallback 文件
log.Printf("handler write failed: %v", err)
}
}(handler)
}
wg.Wait()
return firstErr // 只返回第一个错误，不中断其他
}
⚠️ 注意：Handle() 是同步调用，上面用 goroutine 是为了不让一个慢 handler 拖垮整体。但你要确保每个 handler 自身线程安全（比如 slog.JSONHandler 是安全的，但自定义文件 handler 若没加锁就可能 panic）。
文件 + 网络 + 内存缓冲，三类后端的典型坑点
混合使用时，每类后端的可靠性、延迟、容量特征差异极大，硬拼在一起容易翻车。
-
文件后端：用
os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_APPEND)，别用O_TRUNC；每日轮转需监听SIGHUP或用fsnotify，否则日志可能写到旧文件；Write()后建议file.Sync()（审计场景必需），但会显著降吞吐 -
网络后端（如 Loki、Fluentd）：必须带重试（指数退避）、连接池、批量压缩（
snappy）、超时控制（context.WithTimeout）；不要让单次Handle()卡住几秒——应立即返回并后台重发 -
内存缓冲后端（如环形 buffer 供调试 dump）：用
sync.Pool管理[]byte，避免 GC 压力；设置固定大小（如 1000 条），满时丢最老日志，别 panic
如何动态增删后端而不重启？
核心是把 handlers 切片换成线程安全容器，并暴露方法，但要注意：增删瞬间可能有日志“漏写”或“重复写”。稳妥做法是——只允许追加，删除走软标记 + 延迟清理。
- 用
atomic.Value存当前活跃 handler 列表（类型为[]slog.Handler），每次更新整个切片，避免读写竞争 - 删除后端时不直接从切片移除，而是设一个
disabled map[uintptr]bool，Handle()中先查是否 disabled - 如果真要热插拔（比如配置中心下发变更），建议搭配版本号 + CAS 更新，避免新旧 handler 交替时状态不一致
最常被忽略的是：handler 初始化本身可能失败（比如网络不通、目录无权限），这些错误必须在添加时显式检查并反馈，不能等到第一次 Handle() 才暴露。
