Go 的 io.Reader 与 io.Writer 接口组合：流式数据处理的设计模式

两个接口背后，是一套“最低承诺”设计

很多Go程序员第一次接触io.Reader和io.Writer，都是从一个简单需求开始的：读文件、写HTTP响应。但真正把这两个接口的价值发挥出来，通常是在系统开始处理“大”数据或者传输链路变复杂之后。比如日志文件几十GB，网络请求需要转发和镜像，压缩、加密、校验不能一个环节一个环节地全部加载到内存再吐出去。如果这时候还是每个环节都自己管理[]byte，代码很快就会变成一团线。

这里想聊的，不只是两个接口的定义，而是它们在标准库和工程实践中积累的一套组合模式：让数据像水流过管道一样，从一个Reader流出，经过观察、变换、缓冲和分流，最后到达一个或多个Writer。这套模式足够简洁，却能解决大量真实问题。

io.Reader和io.Writer的定义并不复杂：

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

关键在它们只是“最低承诺”。Reader不保证一次读满你给它的缓冲区，Writer也不保证一次写完。Read可能返回n大于0但err非nil，Write如果只写了n个字节，还会同时返回一个非nil错误。这种看起来有点“脏”的约定，恰恰是为了让磁盘文件、网络连接、压缩流、内存缓冲，甚至自定义的转换逻辑，都能被同一套接口表达。

正因为有这个最低承诺，才需要组合层来补齐“一次读满”和“一次写完”的便利。io包里的Copy、MultiWriter、TeeReader这些工具，本质上就是在帮我们处理这些边角规则，同时让数据真正流动起来。

组合器：让数据流起来

真正让Reader/Writer变得强大的，是它们能被自由组合。标准库提供了几个非常典型的组合器：io.Copy把Reader数据写入Writer，io.MultiWriter把一次写操作分发给多个Writer，io.TeeReader让你在读取数据的同时把经过的数据写到另一个Writer，io.Pipe则能在两个goroutine之间建立同步内存管道。每一个组合器都只解决一个问题，连接它们的方式就是接口本身。

举个具体的例子。假设要从文件读取数据，一边把数据原样写入备份文件，一边计算SHA256校验值。如果不做组合，你可能要手动维护一个缓冲区，把同一份数据分别喂给文件、校验器和目标Writer。用组合器这样写：

func process(src io.Reader, dest io.Writer, mirror io.Writer) ([]byte, error) {
    hasher := sha256.New()
    teeReader := io.TeeReader(src, mirror)
    multiWriter := io.MultiWriter(dest, hasher)

    _, err := io.Copy(multiWriter, teeReader)
    if err != nil {
        return nil, err
    }
    return hasher.Sum(nil), nil
}

这里的链路很有意思。src先被TeeReader拆成两路：一路流向mirror做备份，一路继续往下游。随后下游是MultiWriter，把数据同时交给dest和hasher。整个路径只有一个io.Copy在驱动，没有手动循环，没有临时切片反复塞来塞去。每个组件只负责一件事，组合方式完全由接口决定。

常见误区：读不满、写不全，还有错误处理

实际项目里，下面这几个误区反复出现过。如果能避开，你对这两个接口的理解基本就到位了。

• 用len(p)当成有效数据长度。Read不保证填满缓冲区，尤其是网络连接、压缩流和管道。正确做法是永远使用返回的n，而不是len(p)。io.Copy能正确处理，手写循环时很容易错。
• 担心Write返回n小于len(p)且err为nil。io.Writer的约定里，n小于len(p)时必然伴随非nil错误。你可以依赖这个约定，不必自己写重试逻辑；但自己实现Writer时必须遵守。
• 以为加一层bufio就一定能提升性能。性能瓶颈往往不在拷贝次数，而在系统调用和内存分配。io.Copy默认32KB的缓冲区已经覆盖大多数场景，重复包装bufio反而可能引入不必要的Flush逻辑和内存开销。
• 忽略组合器中的nil。比如MultiWriter中的某个Writer为nil，或者TeeReader的w为nil，出错时才会在调用Write的地方panic。这种错误最好在初始化阶段就防御掉。

实际工程里怎么用：三个场景

到这里，你已经知道组合器是什么了。接下来看看它们在实际工程里怎么被用起来。

第一个场景是日志采集。团队需要解析一份几十GB的Nginx日志，如果用os.ReadFile或者io.ReadAll，内存会直接爆掉。改成流式读取之后，用bufio.Scanner包装源文件Reader，一行一行解析，再写入下游的数据管道。这里虽然没有直接用TeeReader，但核心思路是一样的：让数据沿着 Reader、Scanner、Writer 的路径流动，内存占用只取决于单条日志的大小，而不是整个文件。

第二个场景是HTTP流量镜像。后端服务需要把请求体转发到另一个分析系统，可以很自然地在Handler里用io.TeeReader包住Request.Body，读取的同时把原始数据写到另一个Writer。这样不用先读完再重建请求体，分析系统也能看到完整的数据流。镜像不影响主链路，但要注意TeeReader的写入失败会阻断后续读取，所以镜像路径最好也做好错误处理，或者异步落盘。

第三个场景是加密传输。把本地文件加密后上传，同时计算原始文件的SHA256。可以让crypto/cipher的StreamReader包住源文件Reader，然后直接交给io.Copy。整个过程中，明文和密文都不会完整出现在内存里，这对大文件场景几乎是必须的。

常用组合工具怎么选

下面这张表可以作为一个快速选型参考。它并不涵盖所有工具，但足够覆盖大多数流式数据处理任务。

落地建议：从替换手动循环开始

想在项目中熟练使用这些模式，建议从几个角度入手，而不是一开始就设计一个大而全的抽象层。

1. 先替换手动循环。把代码里自己写的 for { Read; Write } 改成io.Copy。你会发现逻辑立刻变短，错误处理也变简单了。这是最安全的入门方式。
2. 控制自定义Reader/Writer的粒度。不需要每个业务都实现一个独立类型。很多时候一个函数式包装就够了，比如 type ReadFunc func(p []byte) (int, error) 再加一层适配器。结构体里持有基础io.Reader和一个计数器，也可以实现流式统计。
3. 明确错误传播。组合器的错误传播顺序很重要。比如MultiWriter会依次调用所有Writer，遇到错误就返回，之前的写入不会回滚。TeeReader的Write失败会变成Read错误。设计管道时必须清楚错误会从哪里冒出来，以及如何统一处理。
4. 支持取消和超时。io.Reader本身没有context，但你可以通过包装器在每次Read前后检查context，或者为网络Reader设置SetReadDeadline。在长生命周期流中，这是一个容易忽略的健壮性问题。
5. 别滥用io.ReadAll。只要数据是流式的，尽量用流式处理。ReadAll会把所有内容都放进内存，它适合那些压测过的、有上限的小消息，不适合作为流水线主入口。

收尾：接口组合的工程哲学

io.Reader和io.Writer看似是Go里最不起眼的两个接口，但它们的组合能力比很多复杂架构都更深。组合而不是继承，只暴露最小能力，通过包装实现横切关注点——这套思想直接影响了Go生态里大量优秀库的设计。

下次需要从一个源读数据并写入多个地方，或者想在传输过程中观察数据时，先别急着写循环和临时切片。想一想能否用io.Copy、io.MultiWriter、io.TeeReader和io.Pipe把它们组合起来。数据流的问题，本来就该用流的方式解决。