Go 嵌套 MultiReader 在 io.Copy 后再次 Read 触发 nil pointer panic

先对外层 io.MultiReader 读取一个字节，再用 io.Copy 读完，最后读取仍被保留的内层 reader，却得到 invalid memory address or nil pointer dereference。如果堆栈落在 io.(*multiReader).Read，要检查嵌套 reader 是否在混用 Read 与 WriterTo 路径。

这不是只有多 goroutine 才能触发的竞争。下面的单线程结构就具备条件；片段要求导入 io、strings 与 fmt：

inner := io.MultiReader(strings.NewReader("abc"), strings.NewReader("def"))
outer := io.MultiReader(inner)
b := make([]byte, 1)
outer.Read(b)
io.Copy(io.Discard, outer)
fmt.Println(inner.Read(b))

它用于说明对象关系，生产代码仍须检查前两次读取的返回值。问题在 Go 1.27.1 有明确表现，已核对的 1.27.2 源码也保留相关 nil 分支；更早版本中的相似错误曾修过 Read，但那项修正没有覆盖后来加入的 WriteTo。

io.Copy 不保证一直调用 Read

MultiReader 对外返回 io.Reader，动态类型仍实现了 io.WriterTo。io.Copy 会优先使用源端的 WriteTo，不是按变量声明类型决定只调用 Read。

外层第一次 Read 会展平只有一个内层 MultiReader 的结构，使两者可能共享同一份 reader 切片。受影响的 WriteTo 在用完某一项后，把共享切片里的该项设成 nil，以便尽早回收资源。内层还保留着同一份切片，随后调用 Read 就可能尝试读取 nil 项。

因此，外层读完之后内层本应报告 EOF，却触发了 panic。这里没有承诺内层还能重新读取原内容；修复目标是正常结束，不能把 EOF 当成“流被清空”的新故障。

让一个入口负责消费，或显式隐藏 WriterTo

最直接的调整是收紧 reader 的所有权：把嵌套结构交给外层后，后续只使用外层，不再把内层同时保存为可继续消费的入口。需要重新读取内容时，应按源的能力重新打开、重新创建或使用受控缓冲，而不是复用已经被消费的 reader。

若现有接口确实还会读取内层，短期可以让复制只经过 Reader 接口。下面定义的包装只暴露 Read，随后把它用于原来的复制位置：

type readerOnly struct {
    io.Reader
}

_, err := io.Copy(io.Discard, readerOnly{Reader: outer})
if err != nil {
    return err
}

第二段应放在返回 error 的函数里，并保留原来真正的目标 writer。包装后的源不再暴露 MultiReader 的 WriterTo，因而避开这里清空共享项的路径。它可能改变复制的性能特征，要按实际吞吐与错误处理要求评估，不必全项目替换 io.Copy。

io.CopyBuffer 同样会优先使用可用的 WriterTo；只换成它或改缓冲区大小，并不能保证走普通 Read 路径。用 recover 吞掉 panic 也无法补回复制状态和未处理的数据。

主线修正已把 WriteTo 用完的项替换成可返回 EOF 的对象。截止本次核证，这不等于正式 1.27.2 已带上修复；选择后续工具链时要核对对应版本，标准库更新还需重新构建程序。

验证时保留“外层先 Read、再 Copy、最后读内层”的原顺序，检查复制到目标的字节完全正确，结束后读取返回 0, io.EOF，并覆盖源端返回真实错误的情况。这项调整不会让共享 reader 变成可并发使用，也不会增加回放能力。