Go io.MultiReader 遇到中间 EOF 怎样判断后续读取是否还会继续

在把多个文件片段、网络响应或内存缓冲区拼成一个 io.Reader 时，最容易误判的是：前一个输入返回 io.EOF，是不是意味着整个 io.MultiReader 也结束了？答案是不会。io.MultiReader 会把当前 Reader 的 EOF 当成“这一段读完”，然后继续读取后面的 Reader；只有所有输入都结束，组合 Reader 才返回 EOF。

判断要点：EOF 是某个输入的正常结束信号，非 EOF 错误才是需要立即交给调用方处理的失败信号。

官方说明可参考：https://pkg.go.dev/io#MultiReader。下面用一个小实验把这个边界拆开。

先看 io.MultiReader 的读取语义

io.MultiReader(r1, r2, r3) 把多个 Reader 按传入顺序组合起来。调用方只看到一个 Reader，但内部仍然保留当前输入和剩余输入两个概念：

• 当前 Reader 返回数据时，数据直接交给调用方。
• 当前 Reader 返回 EOF 时，MultiReader 丢弃这一段，切换到下一个 Reader。
• 所有 Reader 都返回 EOF 后，外层 Read 才返回 EOF。
• 当前 Reader 返回其他错误时，MultiReader 会把错误交给调用方，不会把它当作切换信号。

用最小示例观察中间 EOF

下面把两个字符串 Reader 交给 io.MultiReader。第一个输入读完后会自然产生 EOF，但调用方最终仍能读到第二个输入。代码中的注释只标记关键边界，不把示例输出当成截图证据。

package main

import (
	"fmt"
	"io"
	"strings"
)

func main() {
	// 第一个 Reader 读完后会返回 EOF，第二个 Reader 仍然待读取。
	reader := io.MultiReader(strings.NewReader("part-A|"), strings.NewReader("part-B"))
	buf := make([]byte, 4)

	for {
		n, err := reader.Read(buf)
		if n > 0 {
			// 先消费有效字节，再判断 err，避免丢掉 n 和 err 同时返回的数据。
			fmt.Printf("%q", buf[:n])
		}
		if err == io.EOF {
			// 这里表示所有输入都结束，而不是某一个输入刚结束。
			break
		}
		if err != nil {
			// 真实错误不能按 EOF 处理，应保留给上层决定是否重试。
			panic(err)
		}
	}
	fmt.Println()
}

这个示例的关键不是打印格式，而是循环判断顺序：先处理 n，再判断 err。对于实现良好的 Reader，n > 0 与错误同时出现是允许的，不能因为看见错误就跳过已经读出的字节。

预期文字输出可以理解为 "part-A|part-B"。这里的“中间 EOF”由 MultiReader 内部处理，外层只在最后一段也读完时看见 EOF。

区分 EOF 与真实错误

排查“后续 Reader 没有读到”的问题时，先确认前一个 Reader 返回的是 io.EOF，还是一个业务或 I/O 错误。可以用一个自定义 Reader 模拟中途失败：

type failReader struct {
	data []byte
	done bool
}

func (r *failReader) Read(p []byte) (int, error) {
	if r.done {
		// 非 EOF 错误表示这一段读取失败，MultiReader 不会自动跳到下一段。
		return 0, fmt.Errorf("片段读取失败")
	}
	r.done = true
	copy(p, r.data)
	return len(r.data), nil
}

如果某个 Reader 返回的不是 EOF，MultiReader 会把这次错误返回给调用方，后续 Reader 不会被当作正常续读目标。实际工程里不要用“遇到任意错误就继续下一个 Reader”的包装逻辑掩盖问题，否则文件损坏、网络中断等异常可能悄悄变成不完整数据。

空输入与工程使用边界

下面几种情况可以作为排查清单：

如果输入来自文件或网络响应，资源关闭仍由创建这些资源的代码负责；MultiReader 只负责组合读取，不会替你关闭底层对象。把多个带生命周期的 Reader 交给它之前，最好明确谁拥有关闭责任。

总结一下：中间 EOF 是正常换段，真正需要排查的是非 EOF 错误、输入顺序、空输入和底层资源生命周期。只要调用方遵守“先处理 n，再区分 EOF 与其他错误”的 Reader 习惯，MultiReader 的行为就很稳定。

相关问题

io.MultiReader 会缓存所有输入吗？

不会。它按顺序持有并读取 Reader，不会把所有内容预先拼成一个大缓冲区。

为什么不能把所有错误都当成 EOF？

EOF 代表正常结束，其他错误可能意味着数据不完整或资源异常；混淆后会让调用方得到静默截断的结果。