Go MultiWriter第一个Writer失败后其他Writer未完成的处理边界

线上日志要同时写入文件、控制台和审计流时，io.MultiWriter 很容易被误解成“并发广播”。它实际按传入顺序逐个调用 Write：第一个 Writer 返回错误或短写后，本次写入立即结束，后面的 Writer 不会继续执行。因此一次调用可能已经部分成功，返回的 n 只能说明失败前最后一个 Writer 写了多少字节，不能把所有目标都视为同一状态。

先把MultiWriter的停止条件还原出来

Go 官方 io 文档给出的语义很明确：每次写入会按列表顺序交给每个 Writer；某个 Writer 返回错误，整体写入就停止，不会继续列表后面的目标。如果 Writer 返回的字节数小于输入长度但错误为空，MultiWriter 会把它转换成 io.ErrShortWrite。

这意味着它适合“前一个目标失败就认为本次复制失败”的场景，例如主文件和备份文件必须保持同一批次。但它不提供事务回滚，也不保证失败前已经写入的目标能够撤销。

用失败Writer区分已完成与未完成目标

下面的 Writer 只用于构造一个可读的故障场景：第 2 个目标返回错误，调用者同时记录每个目标是否被触达。示例输出是由模拟 Writer 返回值决定的说明，不代表某次线上运行结果。

package main

import (
    "errors"
    "fmt"
    "io"
)

type auditWriter struct {
    name string
    fail bool
}

func (w *auditWriter) Write(p []byte) (int, error) {
    // 记录每个目标是否被调用；fail 用来模拟下游拒绝本次写入。
    fmt.Printf("触达 %s\n", w.name)
    if w.fail {
        return 0, errors.New("下游暂时不可写")
    }
    return len(p), nil
}

func main() {
    // 顺序是 A、B、C；B 失败后，C 不会被调用。
    w := io.MultiWriter(
        &auditWriter{name: "A"},
        &auditWriter{name: "B", fail: true},
        &auditWriter{name: "C"},
    )
    n, err := w.Write([]byte("event-1"))
    fmt.Printf("n=%d err=%v\n", n, err)
}

这个场景中 A 已经完成，B 被触达但没有写入，C 尚未触达。若把 err != nil 简化成“所有目标都失败”，重试时就可能再次写入 A，产生重复日志或重复消息。正确做法是把“已确认成功”“当前失败”“未执行”分开保存。

按业务语义选择容错写法

如果要求全量一致，保留 MultiWriter 的失败即停语义，但要把目标顺序固定，并在上层保存批次编号和失败位置。若只是尽力写入，例如主日志必须落盘、调试镜像可丢弃，则可以为每个目标单独调用 Write，收集所有结果后再决定是否告警。

type result struct {
    index int
    n     int
    err   error
}

func writeBestEffort(data []byte, writers []io.Writer) []result {
    results := make([]result, 0, len(writers))
    for i, writer := range writers {
        // 每个目标独立记录结果，避免一个错误掩盖后续目标状态。
        n, err := writer.Write(data)
        results = append(results, result{index: i, n: n, err: err})
    }
    return results
}

“尽力写入”不是简单忽略错误：至少要记录目标编号、n、错误类型和批次标识。若后续要重试，还要确认目标是否支持幂等键，或者把事件改成带唯一 ID 的追加写入。

生产排查清单：先确认阻塞，再决定重试

遇到“后面的 Writer 没有数据”时，先确认前一个 Writer 是返回错误、短写，还是一直阻塞。管道、网络连接和自定义缓冲 Writer 都可能让调用停在某一个目标上。随后检查四件事：

• 是否记录了 Writer 的稳定编号，而不是只打印一条总错误。
• 是否把短写当成失败，并保留本次输入的长度。
• 重试时是否会重复写入已经成功的目标。
• 关闭文件、连接和缓冲层的顺序是否由同一生命周期管理。

如果目标之间允许独立成败，使用逐目标收集结果的封装；如果必须按顺序并在首错处停止，MultiWriter 更直接。关键不是强行让所有 Writer 都完成，而是让“部分成功”成为明确、可观测、可恢复的业务状态。

常见问题

MultiWriter 会并发调用多个Writer吗？

不会。它在一次 Write 中按传入顺序串行调用；需要并发时要自行设计同步、背压和错误聚合。

第一个Writer成功后第二个失败，能自动回滚第一个吗？

不能。io.Writer 没有通用回滚协议，调用者必须依靠幂等写入、补偿动作或可接受的部分成功策略处理。