Go通过io.Reader和io.Writer两个极简接口抽象读写操作，要求实现Read([]byte)(int,error)或Write([]byte)(int,error)，支持任意类型组合；强调不可变性、单向流语义，禁止Seek/Peek等方法，鼓励包装而非继承，典型应用如io.Copy。
io.Reader 和 io.Writer 是接口，不是具体类型
Go 把「读」和「写」抽象成两个极简接口，而不是提供一堆带缓冲、超时、加密的封装类。这意味你不需要记住 BufferedReader 或 EncryptedWriter 这类名字——只要类型实现了 Read([]byte) (int, error)，它就是 io.Reader；只要实现了 Write([]byte) (int, error)，它就是 io.Writer。
这种设计让组合变得自然：你可以把 os.File、bytes.Buffer、net.Conn、甚至自定义的 rot13Reader 全部当成 io.Reader 传给同一函数，不用改签名、不用类型断言。
- 常见错误：试图对
io.Reader做len()或下标访问 —— 它不保证可回溯、不保证长度已知 - 典型场景：HTTP handler 中接收请求体用
req.Body（io.ReadCloser），返回响应用w http.ResponseWriter（隐式实现io.Writer） - 注意：接口方法参数是切片而非字符串，因为底层 I/O 操作面向字节流，且避免每次读取都分配新字符串
组合优于继承，靠嵌入和包装实现能力增强
Go 不支持继承，但通过结构体字段嵌入（embedding）和包装（wrapping）轻松叠加行为。比如 bufio.Reader 并非继承自某个基类，而是持有一个 io.Reader 字段，并在其上加缓冲逻辑；gzip.NewReader 接收一个 io.Reader，返回一个新的、解压语义的 io.Reader。
type CountingReader struct {
r io.Reader
n int64
}
func (c *CountingReader) Read(p []byte) (int, error) {
n, err := c.r.Read(p)
c.n += int64(n)
return n, err
}
- 关键点：包装器必须显式调用被包装对象的方法，不能“自动转发”——这是可控性的代价，也是清晰性的来源
- 性能影响：每层包装增加一次函数调用和可能的内存拷贝；高频场景（如日志写入）应避免无谓嵌套
- 容易踩的坑：忘记在包装
io.ReadCloser时实现Close()方法，导致资源泄漏
io.Copy 是最典型的接口协同范式
io.Copy 函数只依赖 io.Reader 和 io.Writer，却能处理文件复制、网络代理、内存流转等各种场景。它内部使用固定大小缓冲区（默认 32KB）循环读写，屏蔽了底层细节。
_, err := io.Copy(dst, src) // dst: io.Writer, src: io.Reader
- 错误现象：
io.Copy返回io.EOF表示读到流尾，这不是异常，通常无需报错；真正需关注的是其他error类型 - 参数差异：有
io.CopyN（精确复制 N 字节）、io.CopyBuffer（允许指定缓冲区）供特殊需求 - 兼容性注意：某些
io.Writer实现（如http.ResponseWriter）不支持多次调用Write后再Flush，此时直接传给io.Copy可能出错，需确认目标是否支持流式写入
设计思想落地的关键约束：不可变性与单向契约
Go 的 I/O 接口不提供 Seek、Peek、Reset 等方法，明确表达“流是一次性的、向前推进的”。这迫使开发者直面数据流动的本质，也避免了因接口膨胀带来的实现负担。
- 这意味着：不能指望从
http.Request.Body读两次；想重读就得用io.TeeReader+bytes.Buffer显式缓存 - 这也意味着：
io.Reader的实现者只需专注「按需吐出字节」，不必操心位置管理或并发安全（除非文档特别说明） - 最容易被忽略的地方：很多标准库函数（如
json.NewDecoder、xml.NewDecoder）接受io.Reader，但它们内部会读取并消耗流——传同一个实例给多个解码器会导致后一个读不到数据
