Go io.MultiWriter 写入失败会不会继续：部分写入、短写入与错误传播

把同一份日志同时写到文件和标准输出时，io.MultiWriter 看起来像一个“自动同步”的 Writer。真正要注意的是它没有事务语义：目标按传入顺序逐个写入，只要某个目标返回错误或短写入，本次写入就停止，前面已经成功写入的内容不会被撤回。

调用`io.MultiWriter`返回的复合Writer执行写入时，会按初始化时传入的顺序逐个往每个目标Writer写入完整内容：遇到任意一个Writer返回非nil错误就直接终止流程，把这个错误直接抛出来，排在出错位置之后的所有Writer都不会得到调用机会。已经成功完成写入的前序Writer不会做任何数据擦除操作，最终写入结果处于部分成功的状态。

先用两个输出目标看清写入顺序

下面的代码把一条日志写给两个 strings.Builder。两个目标都成功时，返回值是完整字节数，两个缓冲区都会得到同样内容。

var fileBuf, consoleBuf strings.Builder
writer := io.MultiWriter(&fileBuf, &consoleBuf)

n, err := io.WriteString(writer, "request_id=req-17 status=ok\n")
fmt.Printf("n=%d err=%v\n", n, err)
fmt.Printf("file=%q console=%q\n", fileBuf.String(), consoleBuf.String())

这里的顺序就是参数顺序：先写 fileBuf，再写 consoleBuf。如果第一个目标已经成功，第二个目标才会收到这次调用。它更像 Unix tee 的顺序写入，而不是一个可以一起提交或一起回滚的事务。

目标返回错误时，后面的 Writer 不会继续

用一个可控的 Writer 模拟磁盘写入失败，最容易观察 MultiWriter 的停止位置。测试 Writer 记录自己是否收到调用，并主动返回一个错误：

type failWriter struct {
    called int
    err    error
}

func (w *failWriter) Write(p []byte) (int, error) {
    w.called++
    return 0, w.err
}

var first, second strings.Builder
broken := &failWriter{err: errors.New("disk full")}
writer := io.MultiWriter(&first, broken, &second)

n, err := writer.Write([]byte("line-1\n"))
fmt.Println(n, err, first.String(), broken.called, second.String())

输出中，first 已经有内容，broken.called 为 1，而 second 仍为空。错误返回只说明失败目标的写入没有完成，并不代表整个调用对前面目标做了回滚。

短写入不是“差一点也算成功”

io.Writer 的契约要求：如果返回的 n 小于输入长度，就应该同时返回一个非 nil 错误。MultiWriter 对不遵守这个契约的 Writer 做了保护：它把这种情况标记为 io.ErrShortWrite。

type shortWriter struct{}

func (shortWriter) Write(p []byte) (int, error) {
    if len(p) == 0 {
        return 0, nil
    }
    return len(p) - 1, nil
}

var after strings.Builder
writer := io.MultiWriter(shortWriter{}, &after)
n, err := writer.Write([]byte("abcdef"))
fmt.Printf("n=%d err=%v after=%q\n", n, err, after.String())

这次调用返回的 n 是 5，错误是 short write，而 after 为空。后续 Writer 没有机会“把缺的一个字节补上”，因为 MultiWriter 不会把同一目标的部分结果拆开重试，也不会继续处理后面的目标。

日志分流场景如何处理半成功

把文件、标准输出和远程采集器放进同一个 MultiWriter 很方便，但失败后的业务语义要先说清楚。如果文件是审计主记录，远程采集器失败时可以让主流程继续，并单独计数；如果两个目标必须一致，就不能只靠 MultiWriter 保证一致。

func writeAudit(w io.Writer, line string) error {
    n, err := io.WriteString(w, line)
    if err != nil {
        return fmt.Errorf("write audit: %w", err)
    }
    if n != len(line) {
        return io.ErrShortWrite
    }
    return nil
}

func appendWithFallback(primary, backup io.Writer, line string) error {
    if err := writeAudit(primary, line); err == nil {
        return nil
    }
    // 只有在确认 primary 未写入，或业务允许重复时才使用 fallback。
    return writeAudit(backup, line)
}

示例中的 fallback 不能机械套用。主目标可能已经写入一半，错误也可能发生在 flush 或网络连接收尾阶段；此时直接写备用目标会产生重复审计记录。更稳妥的做法是给每条记录带唯一 ID，在下游按 ID 去重，或者先写本地持久队列，再由独立发送器负责投递。

重试前先判断错误发生在哪一层

遇到 MultiWriter 返回错误，不要马上把同一个字节切片再次写进去。至少先记录目标顺序、返回字节数、错误类型和业务记录 ID。你需要回答的是：失败目标有没有写入，前面目标已经写了多少，重试是否会被下游识别为同一条记录。

• 可丢弃输出：例如调试终端，失败后记录指标即可，不必阻塞主业务。
• 可重放输出：例如缓存刷新通知，给消息加幂等键，再交给队列重试。
• 不可重复输出：例如审计或计费记录，优先使用带事务边界的持久化日志，不把多个目标的写入当成原子操作。

这里别把 io.ErrShortWrite 简化成“网络抖动”。它只是一个写入契约错误，具体根因可能是自定义 Writer、磁盘封装、压缩层或连接层没有正确传播错误。

用测试固定停止和部分成功语义

回归测试至少覆盖三种情况：全部成功、第二个目标返回错误、目标短写入。除了断言 err，还要断言后续目标没有被调用，以及第一个目标的内容没有被测试代码“自动清理”。

func TestMultiWriterStopsAfterError(t *testing.T) {
    var first, after strings.Builder
    broken := &failWriter{err: errors.New("collector unavailable")}
    writer := io.MultiWriter(&first, broken, &after)

    _, err := writer.Write([]byte("audit-17"))
    if err == nil || err.Error() != "collector unavailable" {
        t.Fatalf("unexpected error: %v", err)
    }
    if first.String() != "audit-17" {
        t.Fatalf("first writer lost data: %q", first.String())
    }
    if after.Len() != 0 {
        t.Fatalf("writer after failure was called: %q", after.String())
    }
}

如果业务要求“所有副本都最终送达”，测试目标就不应该是“MultiWriter 返回 nil”，而应该是记录入队、重试、去重和最终确认这条完整链路。MultiWriter 适合简单的同步分流，不适合替代可靠消息系统。

常见问题

io.MultiWriter 会并发写多个目标吗？

不会。它按传入顺序逐个调用 Writer；需要并行写入时要自己设计并发、错误收集和退出规则。

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

不能。Writer 通常没有通用回滚接口，前面已经写入的内容会保留，重试前必须考虑重复和半条记录。

短写入但错误为 nil 为什么会得到 ErrShortWrite？

因为 Writer 契约要求短写入伴随错误。MultiWriter 用 io.ErrShortWrite 把这个不完整结果显式传给调用方，并停止后续写入。

什么时候不该用 MultiWriter？

当多个副本必须原子一致、失败必须可靠补偿，或目标写入延迟差异很大时，使用持久队列、单一主日志加异步分发等方案更容易保证语义。

把 MultiWriter 当作顺序分流器

io.MultiWriter 的价值是把一份字节按顺序交给多个 Writer，代码短、行为也明确。它不提供事务、不提供自动重试，也不替调用方判断半成功记录该怎么处理。只要在代码旁边写清目标顺序、错误停点和重试去重规则，它就能稳定承担日志镜像、调试输出等轻量分流任务。