Python BufferedReader.read1 和 read 有什么区别

我第一次把 BufferedReader.read1(8) 换进流式读取代码时，最直观的现象是：明明请求 8 个字节，返回值却只有 3 个。后来把同一段代码改回 read(8)，结果又更接近 8 个字节。真正的差别不是返回类型，而是缓冲层是否允许为了满足这次请求继续触达底层流。

结论：read(size) 可以进行多次底层读取，尽量拿到接近 size 的数据；read1(size) 保留一次底层读取边界，拿到多少就先返回多少。本文只讨论同步二进制流，不扩展到异步文件读取。

官方资料地址：https://docs.python.org/3/library/io.html#io.BufferedReader.read1

把 read 记成“尽量拿够”，把 read1 记成“只拿一轮”。两者都可能返回少于 size 的 bytes，短读不等于 EOF。

先复现：短读到底来自哪一层

排查时我先排除了字符串编码和文件打开模式，把输入压到一个每次最多返回 3 字节的原始流。这样可以只观察 BufferedReader 到 RawIOBase 的边界：如果底层一次只给 3 字节，read 是否会继续追读，read1 是否会停在这一轮。

import io

class LimitedRaw(io.RawIOBase):
    """每次最多提供 3 字节，用于观察缓冲层的读取次数。"""

    def __init__(self, data):
        self._data = memoryview(data)
        self._pos = 0
        self.calls = 0

    def readable(self):
        # 告诉 BufferedReader：这个对象支持读取。
        return True

    def readinto(self, buffer):
        # 故意制造底层短读，不代表真实文件一定如此。
        self.calls += 1
        if self._pos >= len(self._data):
            return 0  # 0 表示 EOF。
        count = min(3, len(buffer), len(self._data) - self._pos)
        buffer[:count] = self._data[self._pos:self._pos + count]
        self._pos += count
        return count

raw = LimitedRaw(b"abcdefgh")
reader = io.BufferedReader(raw, buffer_size=8)
print(reader.read(8), raw.calls)

raw = LimitedRaw(b"abcdefgh")
reader = io.BufferedReader(raw, buffer_size=8)
print(reader.read1(8), raw.calls)

这个例子关注的是调用关系，不是某个固定输出数字。read(8) 会在需要时继续从底层取数据；read1(8) 只使用一次底层读取机会，因此可能把 3 字节的短读直接交给上层。内部缓冲区已经有数据时，返回长度还会受缓冲状态影响。

分层检查：read 和 read1 的契约差在哪里

官方 BufferedIOBase 文档给出的重点是：read(size) 返回最多 size 字节，底层可能被调用多次；返回少于 size 不代表 EOF。相对地，read1(size) 返回最多 size 字节，并按一次底层读取机会来组织结果；size 省略或为负数时，具体实现会选择内部大小，不能把它当成“自动读到文件末尾”。

因此，看到“请求 8、返回 3”时，检查顺序应该是：

1. 确认调用对象确实是 BufferedReader 或兼容的 BufferedIOBase，没有被包装器改写语义。
2. 确认底层是普通阻塞流还是非阻塞流；非阻塞状态会引入 None 或 BlockingIOError。
3. 确认业务需要的是“当前可用的一段”，还是“必须收齐 N 字节”；后者不能依赖一次 read 或 read1。

我的经验是，问题往往不是 read1 “少读了”，而是调用方误把短读当成完整记录。流式解析应该把每一块当作增量输入；定长协议则要显式累计，并区分短读、EOF 和暂时没有数据。

修复：让调用方明确处理短读

def read_exact(reader, size):
    # 只有累计到 size 或明确 EOF，才把结果交给定长协议解析器。
    chunks = []
    remaining = size
    while remaining:
        chunk = reader.read1(remaining)
        if chunk == b"":
            # 阻塞流到达 EOF；此时不能再等待同一段数据。
            break
        if chunk is None:
            # 非阻塞流暂时没有数据，调用方可稍后重试或返回未完成状态。
            break
        chunks.append(chunk)
        remaining -= len(chunk)
    return b"".join(chunks)

若底层实现抛出 BlockingIOError，应在外围状态机中处理，而不是简单吞掉异常。b'' 表示普通流的 EOF，None 表示当前没有可取数据；它们都不应该被当作“又一个空记录”。

反向确认：哪些现象不能直接下结论

• 返回少于 size：只能说明本次没有拿满，不等于 EOF。
• read1 更早返回：说明它保留了短读边界，不自动证明它比 read 更快。
• size 为负数：不要把返回量当作稳定的缓冲区大小，具体实现可以自行选择。
• 非阻塞流没有数据：区分 None、BlockingIOError 和空 bytes，再决定等待、重试还是结束。

常见问题

read1(size) 会比 read(size) 更快吗？

不能直接这样判断。read1 可能减少一次调用内的追读，但会让上层收到更多短块；最终取决于底层流、缓冲区和消费者。

read1(size) 返回少于 size 就是文件结束吗？

不是。少于 size 是短读，只有阻塞流返回空的 b'' 才能按普通 EOF 语义处理。

总结：需要尽量填满请求量时使用 read()；需要把一次底层读取的边界交给上层时使用 read1()。如果业务要求定长，就自己写累计逻辑，把短读和 EOF 分开处理。