17370845950

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）循环读写，屏蔽了底层细节。

立即学习“go语言免费学习笔记（深入）”；

_, 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，但它们内部会读取并消耗流——传同一个实例给多个解码器会导致后一个读不到数据