Go io.MultiReader 前一个输入返回真实错误后还会读取下一个吗

我在把多个分段输入串成一个 io.Reader 时，最容易误判的一点是：前一个 Reader 返回真实错误后，io.MultiReader 会不会“跳过坏输入”继续读取下一个？答案是不会。只有当前 Reader 返回精确的 io.EOF，MultiReader 才把它视为正常结束并尝试下一个输入；任何非 nil、非 EOF 的错误都会先返回给调用方。

官方资料：https://pkg.go.dev/io#MultiReader

非 EOF 错误不会触发 Reader 切换。当前调用返回错误后，下一次 Read 仍会继续读当前 Reader；等当前 Reader 最终返回 EOF，MultiReader 才会继续向后读取。

先把三种返回情况分开

io.MultiReader(r1, r2, r3) 只是把输入按顺序拼成一个逻辑 Reader，并不提供容错跳过策略。判断是否切换，关键看当前 Reader 的 err：

实现上，MultiReader 只会在看到 err == io.EOF 时移除当前输入。非 EOF 错误不会把当前 Reader 从队列里删掉，因此下一次调用仍然可能再次读到同一个 Reader。

返回数据同时返回错误时，也不能认为已经切换

io.Reader 允许一次 Read 同时返回已经读取的字节和一个错误。调用方必须先处理 n > 0 的数据，再根据错误决定下一步。对 MultiReader 来说，n > 0 并不会改变“当前 Reader 是否结束”的判断；非 EOF 错误仍然会被返回。

type readStep struct {
    data string
    err  error
}

type scriptedReader struct {
    steps []readStep
    index int
}

func (r *scriptedReader) Read(p []byte) (int, error) {
    // 每次按预先排好的返回序列模拟一个上游 Reader。
    if r.index >= len(r.steps) {
        return 0, io.EOF
    }
    step := r.steps[r.index]
    r.index++

    // 先复制数据，再把同一次 Read 的错误交给调用方处理。
    n := copy(p, step.data)
    return n, step.err
}

这个 Reader 的用途不是伪造一个特殊 API，而是把最容易被忽略的返回组合固定下来：第一次可能返回“已经读到一部分数据 + 真实错误”，第二次再返回 EOF。

连续调用两次 Read，就能看见切换时机

下面让第一个 Reader 先返回数据和真实错误，再在下一次调用返回 EOF；第二个 Reader 则提供后续文本。这样可以观察到：第一次调用出错时，第二个 Reader 根本还没有被读取。

func main() {
    upstreamErr := errors.New("上游分段校验失败")
    first := &scriptedReader{steps: []readStep{
        {data: "片段A", err: upstreamErr},
        {data: "", err: io.EOF},
    }}
    second := strings.NewReader("片段B")
    combined := io.MultiReader(first, second)
    buf := make([]byte, 16)

    // n 大于 0 且带真实错误：先消费片段A，不会跳到 second。
    n, err := combined.Read(buf)
    fmt.Printf("第一次: n=%d data=%q err=%v\n", n, buf[:n], err)

    // 当前 Reader 下一次返回 EOF，MultiReader 才会在本次调用中尝试 second。
    n, err = combined.Read(buf)
    fmt.Printf("第二次: n=%d data=%q err=%v\n", n, buf[:n], err)
}

结果语义是：第一次调用拿到 片段A 和真实错误；第二次调用先从第一个 Reader 读到 EOF，然后继续读第二个 Reader，拿到 片段B。如果第二个 Reader 也已经结束，MultiReader 才会在后续读操作中最终返回 EOF。

不要把包装后的 EOF 当成正常结束

这里有一个很实用的边界：MultiReader 判断的是精确的 io.EOF。Go 的 io 文档也要求 Reader 直接返回 EOF，因为调用方会使用相等判断。若把 EOF 包装成另一个错误，它在 MultiReader 看来就是非 EOF 错误。

func readExactlyEOF() error {
    // 直接返回 EOF，MultiReader 可以把它识别为当前输入正常结束。
    return io.EOF
}

func readWrappedEOF() error {
    // 这个错误虽然能用 errors.Is 判断包含 EOF，但不等于 EOF。
    return fmt.Errorf("分段结束: %w", io.EOF)
}

因此，自定义 Reader 在表示“没有更多输入”时应直接返回 io.EOF。如果这是结构化数据的意外截断，则应返回更具体的错误，而不是用包装 EOF 让组合 Reader 误以为遇到了普通故障。

业务代码应该怎样接住这个错误

如果业务要求“任何一段失败就停止”，MultiReader 的默认行为正好符合预期：调用方收到非 EOF 错误后退出循环或进入重试流程。处理循环时仍要遵守 Reader 约定，即使有错误也先处理本次拿到的字节。

for {
    n, err := combined.Read(buf)
    if n > 0 {
        // 错误和数据可能同次到达，不能丢弃已经读到的字节。
        if _, writeErr := dst.Write(buf[:n]); writeErr != nil {
            return writeErr
        }
    }
    if err != nil {
        if errors.Is(err, io.EOF) {
            // EOF 表示组合输入正常结束。
            break
        }
        // 非 EOF 错误需要交给重试、告警或上层失败策略。
        return fmt.Errorf("读取组合输入失败: %w", err)
    }
}

如果需求是“某一段坏了也要继续后面的段”，不要期待 MultiReader 自动完成这件事。可以在外层把每个 Reader 包装成明确的跳过策略，或者自己维护输入索引、错误记录和重试次数。这样“跳过”才是业务明确选择，而不是把真实错误悄悄吞掉。

几个容易混淆的问题

非 EOF 错误返回后，下一次 Read 会不会直接读第二个 Reader？

不会。下一次调用仍会调用当前 Reader；只有当前 Reader 后来返回精确的 io.EOF，MultiReader 才会进入下一个。

第一个 Reader 返回 n 大于 0 和非 EOF 错误，数据会丢吗？

不会因为 MultiReader 而丢失，但调用方必须先处理这 n 个字节。若看到错误就立刻返回而不消费缓冲区，丢数据的是调用方的错误处理逻辑。

想忽略某一段错误时，能不能直接把错误改成 EOF？

只有在业务确认该段可以安全跳过时才这样做，而且应在明确的包装层中记录原因。无条件把真实错误改成 EOF，会把数据不完整伪装成正常结束。

什么时候不适合使用 MultiReader？

当输入之间需要失败重试、跳过、回滚、并行读取或按业务条件选择时，MultiReader 的线性拼接语义太简单。此时应由上层显式管理每个 Reader 的生命周期和错误状态。

总结一下：io.MultiReader 把 EOF 当作“当前输入完成”，把非 EOF 错误当作“当前读取失败”。真实错误出现后，它不会替你跳到下一个 Reader；先处理本次数据，再按业务策略处理错误，才不会把组合流的边界读错。