为何在该场景下使用io.Copy搭配bytes.Buffer无法正常工作？

这个问题的核心在于io.Copy的工作机制和QUIC流的生命周期特性不匹配，我们一步步拆解来看：

1. io.Copy的行为逻辑 #

io.Copy(dst, src)会持续从src读取数据并写入dst，直到src返回io.EOF或者发生错误才会停止。也就是说，它需要明确的“数据结束”信号才会完成复制操作。

2. QUIC流的状态问题 #

在你的客户端代码里，用io.Copy(s, bytes.NewBuffer([]byte("hello, world")))把数据写入QUIC流后，并没有关闭流的写方向。QUIC流是双向的，只有当主动调用s.Close()（或者关闭会话）时，才会向对方发送“写端关闭”的信号，对方的流读取操作才会收到io.EOF。

而你的客户端写完数据后只是保持流打开，server端的io.Copy(buf, s)就会一直等待EOF信号，但永远等不到——直到QUIC的NetworkIdleTimeout触发，因为长时间没有网络活动，抛出超时错误。

3. 直接使用Read为什么能正常工作？ #

Read(b []byte)的逻辑是：读取最多len(b)字节的数据到b中，只要读取到足够的字节（这里刚好是len("hello, world")）就会立即返回，不需要等待EOF。它只关心是否读取到了指定长度的数据，而不是流是否关闭，所以能正常拿到结果并继续执行后续代码。

两种可行的解决思路 #

• 思路一：保持使用io.Copy，但客户端写完后关闭流
  在客户端的io.Copy之后添加流关闭操作：

  if _, err = io.Copy(s, bytes.NewBuffer([]byte("hello, world"))); err != nil {
      log.Fatal("failed to write:", err)
  }
  s.Close() // 关闭流的写方向，发送EOF信号给server
  

  这样server端的io.Copy就会收到EOF，完成复制后正常退出。

• 思路二：继续使用Read读取指定长度的数据
  就像你修改后的代码那样，明确读取固定长度的字节，适合已知数据长度的场景。

内容的提问来源于stack exchange，提问作者Louis Thibault