Go的io流转依赖接口契约与组合，核心是io.Reader/Writer的循环处理、io.Copy的缓冲搬运、io.Pipe的零拷贝同步及资源关闭与Context传递。
Go 的 io 流转不是靠“把数据搬来搬去”，而是靠接口契约和组合——只要类型实现了 io.Reader 或 io.Writer，它就能无缝接入任何流式处理链。关键不在“怎么读完再写”，而在“谁在读、谁在写、谁控制节奏”。
io.Reader 和 io.Writer 的真实行为边界
这两个接口只各有一个方法：Read(p []byte) (n int, err error) 和 Write(p []byte) (n int, err error)。它们不承诺一次读/写完全部数据，也不保证 p 被填满或清空——只按当前可用资源（比如网络包大小、文件系统块、缓冲区余量）返回实际字节数。
常见错误现象：
- 调用
Read后直接假设p已满，忽略返回的n，导致读到脏数据或 panic - 对
io.Writer传入一个大切片，却没检查n < len(p)就继续后续逻辑，结果部分数据丢失 - 把
io.EOF当成普通错误处理并中止流程，而其实它只是“读完了”，很多场景下应视为正常退出条件
使用时必须循环处理，直到 err == io.EOF 或其他非临时错误出现。例如从标准输入逐块读取：
立即学习“go语言免费学习笔记（深入）”；
buf := make([]byte, 4096)
for {
n, err := os.Stdin.Read(buf)
if n > 0 {
// 处理 buf[:n]
}
if err == io.EOF {
break
}
if err != nil {
log.Fatal(err)
}
}
io.Copy 是怎么避免手动循环的
io.Copy 不是语法糖，它是带缓冲的阻塞式搬运工：内部固定使用 32KB 缓冲区，反复调用 src.Read → dst.Write，自动处理 n < len(buf)、临时错误重试、io.EOF 终止等细节。
性能影响：
- 小数据（<1KB）：和手动循环差别不大，但代码更干净
- 大数据（>1MB）：比 naive 循环快，因缓冲区复用+减少函数调用开销
- 网络流（如 HTTP body）：能适配底层 TCP 窗口，比自己设小缓冲更稳
注意它返回的是总字节数，不是最后一次 Read 的 n；出错时已写入的部分不会回滚。
为什么 bytes.Buffer 不适合大流，而 io.Pipe 可以
bytes.Buffer 是内存容器：所有写入都 accumulate 在内部 slice 里，Read 只是从头开始消费。1GB 数据 = 1GB 内存占用。
io.Pipe 是同步通道：它返回一对 *io.PipeReader 和 *io.PipeWriter，写入会阻塞，直到另一端有 goroutine 调用 Read —— 数据从 writer 缓冲区直拷贝到 reader 缓冲区，中间不落地。
致命陷阱：
- 同一 goroutine 中先
pw.Write再pr.Read→ 死锁（因为 write 卡住等 reader 来 pull） - 忘记启动 goroutine 写入，或写入后没调用
pw.Close()→ reader 永远等不到 EOF - 写入时发生错误，但没调用
pw.CloseWithError(err)→ reader 会一直阻塞，无法感知失败
正确姿势必须分 goroutine：
pr, pw := io.Pipe()
go func() {
defer pw.Close()
if err := json.NewEncoder(pw).Encode(data); err != nil {
pw.CloseWithError(err)
return
}
}()
// 此时 pr 可被任意 consumer 使用，内存恒定
流转链中容易被忽略的 Close 和 Context 传递
很多实现了 io.Reader 的类型（如 http.Response.Body、*os.File、*gzip.Reader）还实现了 io.Closer。不显式 Close() 可能导致文件句柄泄漏、HTTP 连接不复用、gzip 解压器内部 buffer 不释放。
更隐蔽的问题是 context 无法穿透：
-
io.Copy不接受context.Context，无法响应超时或取消 - 想中断一个正在
Copy的流，只能靠关闭底层连接（如net.Conn.Close()），但不一定立即生效 - 若需可取消，得自己封装循环 +
select检查ctx.Done()，并在每次Read/Write后判断
真正复杂的流式处理，往往卡在“谁负责关、什么时候关、关了之后另一端怎么知道”，而不是“怎么读出来”。
