Go io.Reader 为什么 EOF 前还要先处理 n：读取循环别丢最后一段

Go 里写 io.Reader 循环时，最容易被忽略的一点是：Read 可以同时返回 n > 0 和一个非空错误。碰到 io.EOF 也不能马上 break，要先把 buf[:n] 这段数据处理掉，再根据错误决定是否退出。很多人碰到的“文件最后几字节没拷过去”“HTTP body 尾部少一截”这类怪事，根子基本都出在这里。

目标边界：不是所有 EOF 都等于没有数据

io.Reader 的 Read(p []byte) 返回两个值：读到的字节数 n 和错误 err。很多人第一次写循环，会把注意力放在 err 上，觉得只要看到 io.EOF 就可以立刻退出。这个思路在 Go 里不够稳妥。

更可靠的判断逻辑是先看 n。只要 n > 0，p[:n] 里就是本轮读到的有效数据，哪怕同一轮还返回了 io.EOF，也不能把这段内容丢掉。io.EOF 可以放在处理完数据之后再校验。

错误写法为什么会丢最后一段

下面这种写法看起来非常符合直觉：先读，再看错误，最后处理数据。但如果最后一次 Read 返回了 n > 0 和 io.EOF，代码会直接先走退出逻辑，后面的数据处理代码根本没有机会运行。

buf := make([]byte, 4096)
for {
    n, err := r.Read(buf)
    if err != nil {
        if err == io.EOF {
            break
        }
        return err
    }

    handleChunk(buf[:n])
}

这个问题在本地测试小文件时不一定每次都能复现，因为不同 Reader 的内部返回策略不完全一样。真正容易踩坑的是线上的各类输入源：网络连接、压缩流、限速 Reader、分段响应、测试里自定义的 Reader，都可能让你在最后一轮同时拿到数据和流结束信号。

推荐流程：读取后先处理 n，再判断 err

更稳妥的循环把 n 放在前面处理。只要读到了字节，就先把本轮数据交给业务逻辑处理。然后再判断 err：如果是 io.EOF，说明这轮数据处理完以后可以正常结束流读取；如果是其他错误，再把错误返回给上层调用方。

func readAllChunks(r io.Reader) error {
    buf := make([]byte, 4096)

    for {
        n, err := r.Read(buf)
        if n > 0 {
            if e := handleChunk(buf[:n]); e != nil {
                return e
            }
        }

        if err == io.EOF {
            break
        }
        if err != nil {
            return err
        }
    }

    return nil
}

这段代码还有一个小细节：传给业务函数的是 buf[:n]，不是整个 buf。整个缓冲区可能包含上一轮读取留下的残留数据，只有前 n 个字节属于本轮的有效读取结果。

阶段拆解：一轮 Read 要看三个信号

可以把一次 Read 拆成三个独立信号来理解：第一，n 告诉你本轮是否拿到了有效数据；第二，err 告诉你 Reader 本身的运行状态；第三，业务处理函数告诉你这段数据是否写入、解析或转发成功。三个信号的判断顺序不能乱。

什么时候不用自己写循环

如果你的目标只是把一个 Reader 的内容完整写到另一个 Writer，优先用 io.Copy。标准库已经替你处理好了读取循环、缓冲逻辑和 EOF 边界，业务代码也能写得更简洁。

if _, err := io.Copy(dst, src); err != nil {
    return err
}

只有在你需要逐块解析、统计读取进度、做限速控制、校验分片内容、边读边更新业务状态时，才值得自己手写读取循环。自己写的时候，检查点就很明确：是否只处理 buf[:n] 长度的有效数据，是否把 n > 0 的判断放在数据处理之前，是否把 io.EOF 当作正常结束信号。

常见误区

1. 看到 err 就立刻 return

这会把 n > 0 的最后一段数据直接跳过去。更稳妥的做法是先把拿到的数据处理完，再做 err 的判断。

2. 把整个 buf 交给后续逻辑

缓冲区的容量通常大于本轮实际读到的长度，应该传入 buf[:n] 长度的切片。直接传整个 buf 可能把上一次读取残留的内容也带过去，引发异常。

3. 把 io.EOF 当成异常日志刷屏

io.EOF 是输入流正常结束的信号，正常读取结束时不用当成错误报警。真正需要记录告警的是非 EOF 的异常错误。

4. 自定义 Reader 的测试太理想

写单元测试的时候可以刻意模拟 n > 0 且 err == io.EOF 的返回组合，避免等到生产环境才发现最后一段数据被丢弃。

速查表

写 Go 读取循环时，可以按这张清单做最后检查：

• 读完一轮后，第一件事是不是检查 n > 0？
• 传给业务逻辑的是不是 buf[:n]？
• io.EOF 是不是在处理数据之后才判断？
• 非 EOF 错误有没有正确返回给调用方？
• 如果只是拷贝数据，是否能直接用 io.Copy？

相关问题

io.Reader 的 Read 会不会返回 n 为 0 且 err 为 nil？

调用方不应该依赖这种返回持续出现。实际循环里如果遇到异常的空读，可以按具体 Reader 的文档或超时策略处理，普通文件和网络读取更常见的返回情况是拿到有效数据、返回 EOF 或是返回具体业务错误。

io.ReadAll 会不会丢最后一段？

不会。标准库函数内部已经处理好了读取循环和 EOF 边界逻辑。只有自己手写循环时，才需要特别注意先处理 n 长度的数据。

读网络连接时也要这样写吗？

要。网络读取场景更应该遵守这个顺序，因为对端关闭、半包、超时和分段返回都可能让边界情况更复杂。

handleChunk 里能不能直接保存 buf[:n]？

如果要长期保存这段数据，应该主动复制一份。下一轮 Read 会复用同一个缓冲区，直接保存切片引用可能被后续读取的内容覆盖。

参考来源：Go 官方文档 io.Reader。