io.MultiReader 是最轻量的流式拼接方式，按顺序读取多个 io.Reader，不自动管理关闭、不加载内存，需预检文件并手动关闭句柄，错误在首次 Read 时暴露。
用 io.MultiReader 拼接多个 io.Reader 实例
直接拼接文件流，不用先读入内存或临时合并文件，io.MultiReader 是最轻量、最符合 Go 设计哲学的方式。它返回一个新 io.Reader，按顺序读取传入的各个 reader，读完前一个才读下一个。
常见错误是把文件句柄（*os.File）直接传给 MultiReader 而没考虑关闭时机——它不自动管理底层 reader 的生命周期，你得自己确保所有源 reader 在使用结束后被关闭。
- 必须按预期顺序传入 reader：顺序即拼接顺序，错位无法纠正
- 任意一个 reader 返回
io.EOF后自动跳到下一个；若中间某个 reader 返回非EOF错误（如磁盘 I/O 失败），整个读取立即中止并返回该错误 - 如果某 reader 是空的（比如刚打开的空文件），它会被安静跳过，不影响后续读取
- 示例：
readers := []io.Reader{file1, file2, file3} combined := io.MultiReader(readers...)
处理大文件时避免一次性加载到内存
有人用 os.ReadFile 读取每个文件再拼接字节切片，这在文件总大小超百 MB 时极易触发 OOM。真正流式处理的关键是全程保持 reader 链路不断，让下游（比如 HTTP 响应体、gzip 写入器）边读边消费。
典型场景是构建 ZIP 下载流或日志归档 API：前端请求一个“打包包”，后端把多个日志文件按时间顺序串成单一流输出，用户浏览器接收时无需等待全部文件读完。
立即学习“go语言免费学习笔记（深入）”；
- 别用
bytes.Buffer或[]byte中转，哪怕只是临时拼接两份小文件 - 如果需要加头部/尾部（如 JSON 封装、自定义协议头），用
io.MultiReader把 header reader、主体 reader、footer reader 串起来 - 注意：所有参与拼接的 reader 必须支持多次调用
Read（比如strings.NewReader可以，但某些封装过的 reader 可能不可重用）
文件路径不存在或权限不足时的错误捕获位置
错误不会在构造 io.MultiReader 时暴露，而是在第一次 Read 调用时才从第一个 reader 冒出来。这意味着你不能靠 “创建成功” 判断文件可读——必须把 os.Open 的错误检查放在拼接之前。
更麻烦的是，如果第 3 个文件打不开，前两个已经部分读出的数据可能已发送给下游（比如写入了 HTTP 连接），此时没法回滚。所以健壮做法是：预检所有文件。
- 逐个调用
os.Stat确认存在且可读，比等 runtime panic 更可控 - 不要依赖
defer file.Close()在拼接构造后统一关闭——每个os.Open应该立刻配对defer，否则可能泄漏句柄 - 示例错误信息：
open /path/to/missing.log: no such file or directory，它来自具体某个*os.File.Read调用，不是MultiReader自身报的
与 io.Copy 配合时的缓冲和性能提示
单纯构造 io.MultiReader 不会触发任何 I/O，真正的读取发生在你把它交给 io.Copy 或手动循环 Read 时。默认 io.Copy 使用 32KB 缓冲区，对大多数磁盘文件足够，但若源是网络 reader（比如 HTTP 响应体），可能需要显式指定更大缓冲区。
- 不要自己实现
Read循环来“优化”——io.Copy已经做了最佳实践，包括零拷贝判断和缓冲复用 - 如果目标 writer 是慢设备（如磁盘日志文件），瓶颈不在拼接逻辑而在写入速度，这时
MultiReader的开销几乎为零 - 调试时可用
io.TeeReader包裹某个子 reader 来观察其原始数据流，但上线时务必移除，避免额外拷贝
拼接本身没有隐藏状态或上下文，但每个参与 reader 的打开方式、编码、是否支持 seek 都会影响最终行为——这些细节不会被 MultiReader 抹平，得你自己兜底。
