Go io.MultiReader 拼接多个文件时怎么判断中间文件已经读完

如果只是把多个文件连续读成一条输出流，io.MultiReader 很方便；但它不会告诉调用方“刚刚读完的是第几个文件”。中间文件返回的 io.EOF 会被 MultiReader 内部消费，只有所有输入都结束后，外层读取才会得到最终 EOF。

官方地址：https://pkg.go.dev/io#MultiReader

我的处理方式是：仍然用 MultiReader 负责顺序拼接，但给每个文件 Reader 包一层，自己记录底层 EOF、文件名和已读字节数。这样合并接口保持简单，文件边界也不会丢。

io.MultiReader 到底隐藏了什么

官方定义是“多个输入 Reader 的逻辑拼接”，它们按顺序读取；某个 Reader 返回 EOF 后，MultiReader 继续读下一个，所有输入都返回 EOF 时才向外返回 EOF。非 EOF 错误则会直接返回。

所以这段代码只能判断整条流结束，不能判断中间文件结束：

package main

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

func main() {
	// MultiReader 把两个输入暴露成一个连续的 Reader。
	merged := io.MultiReader(
		strings.NewReader("文件A"),
		strings.NewReader("文件B"),
	)

	data, err := io.ReadAll(merged)
	if err != nil {
		// ReadAll 成功读到末尾时返回 nil，而不是把 EOF 当成错误。
		panic(err)
	}
	fmt.Println(string(data)) // 文件A文件B
}

外层看到的是一个连续的 文件A文件B。如果业务需要在 A、B 之间写索引、计费或审计记录，不能依赖 MultiReader 暴露内部下标。

用包装 Reader 记录每个文件的结束

Reader 规范允许一次读取先返回数据、下一次再返回 EOF；也允许最后一次同时返回 n > 0 和 EOF。包装器应先累计 n，再观察错误，并且只把第一次 EOF 转成一次边界事件。

type boundaryReader struct {
	name     string
	r        io.Reader
	bytes    int64
	finished bool
	onEOF    func(name string, bytes int64)
}

func (b *boundaryReader) Read(p []byte) (int, error) {
	// 先保留本次读到的数据，再处理同一次返回中的 EOF。
	n, err := b.r.Read(p)
	b.bytes += int64(n)

	if err == io.EOF && !b.finished {
		// MultiReader 会消费这个 EOF，但包装器可以留下边界记录。
		b.finished = true
		if b.onEOF != nil {
			b.onEOF(b.name, b.bytes)
		}
	}
	return n, err
}

这里的关键不是把 EOF 继续传给上层，而是在 EOF 被 MultiReader 消费之前，记录一次“这个输入结束了”。如果底层返回的是其他非空错误，包装器应原样返回，不要把它伪装成正常边界。

把多个文件接入合并流

下面的示例使用真实文件句柄，但不把路径写死在 Reader 逻辑里。打开文件后立即登记关闭动作；边界回调只负责记录状态，真正的内容仍由合并流消费者统一读取。

func concatFiles(paths []string) error {
	readers := make([]io.Reader, 0, len(paths))
	files := make([]*os.File, 0, len(paths))

	for _, path := range paths {
		// 每个文件单独打开，失败时释放已经打开的句柄。
		f, err := os.Open(path)
		if err != nil {
			for _, opened := range files {
				_ = opened.Close()
			}
			return err
		}
		files = append(files, f)

		name := path
		readers = append(readers, &boundaryReader{
			name: name,
			r:    f,
			onEOF: func(name string, bytes int64) {
				fmt.Printf("%s 已读完，共 %d 字节\n", name, bytes)
			},
		})
	}

	// MultiReader 只负责顺序拼接；中间 EOF 由包装器记录。
	_, readErr := io.Copy(io.Discard, io.MultiReader(readers...))
	var closeErr error
	for _, f := range files {
		if err := f.Close(); closeErr == nil && err != nil {
			closeErr = err
		}
	}
	if readErr != nil {
		return readErr
	}
	return closeErr
}

这段实现需要补上 fmt、io 和 os 导入。生产代码还可以把边界事件写入结构化日志或计数器；不要在回调里做阻塞很久的业务操作，否则会拖慢读取。

什么时候不该用 MultiReader

如果文件边界本身就是协议的一部分，例如每个文件都要单独解析、失败后要回滚到当前文件，或者后续需要按文件随机访问，那么直接循环处理 *os.File 更清晰。MultiReader 适合“顺序拼接后只关心一条连续流”的场景；包装 Reader 适合在这个前提下补回轻量的边界观测。

常见问题

中间文件的 EOF 会不会丢失？

对 MultiReader 的调用方来说，中间 EOF 不会作为最终结果暴露；它被用来切换到下一个 Reader。对包装器来说，仍可在底层返回 EOF 的瞬间记录边界。

可以通过读取次数推断当前文件吗？

不可靠。读取缓冲区大小、底层 Reader 的分块方式和最后一次返回形态都会变化。要记录边界，应观察每个输入 Reader 自己的 EOF，而不是猜测外层 Read 的次数。

一句话总结：MultiReader 负责把多个 Reader 变成连续流，不负责告诉你文件边界；需要边界时，在每个输入外包一层有状态的 Reader，记录 EOF 和字节数，再把这些包装器交给 MultiReader。