Python io.BufferedReader.peek 怎样预读字节

需要判断二进制流的文件头或协议前缀、但又不能提前消费数据时，可以把可读的二进制输入包装为 io.BufferedReader，再调用 peek(size)。它返回当前位置附近的 bytes，不会推进 BufferedReader 的逻辑读取位置；但返回数量可能比请求值少，也可能更多，所以判断协议时应检查必要的前缀，而不是要求长度恰好相等。

官方文档：https://docs.python.org/3/library/io.html#io.BufferedReader.peek

先判断：什么时候应该用 peek

典型触发信号是：输入可能是多种二进制格式，需要先看固定前缀再选择解析器；或者上游流不可回退，不能先 read() 再用 seek() 恢复。此时直接读取会把判断动作和消费动作混在一起，后续解析容易少掉文件头。

peek() 的定位是“观察缓冲区前面的字节”。它不是复制一个全新的流，也不承诺返回精确的字节数量。对文件、BytesIO 这类可读输入，返回值通常是非空的 bytes；对非阻塞底层流，如果继续操作会阻塞，文档允许返回空字节。

快速判断：建立二进制读取边界

BufferedReader 面向可读的二进制底层流。下面用内存字节流展示调用关系；示例只说明 API 语义，不把图中的内容当作线上运行结果。

import io

payload = b"PK\x03\x04demo-data"
reader = io.BufferedReader(io.BytesIO(payload), buffer_size=8)

# tell() 记录的是 BufferedReader 对调用方暴露的逻辑位置。
before = reader.tell()

# peek 只观察前缀，不让后续 read 跳过这些字节。
preview = reader.peek(4)
after_peek = reader.tell()

# 真正消费数据仍然要显式调用 read。
chunk = reader.read(4)
after_read = reader.tell()

print(preview[:4])
print(before, after_peek, after_read)
print(chunk)

排查时重点看三个关系：preview 是 bytes；before 与 after_peek 的逻辑位置相同；只有 read(4) 执行后，读取位置才随消费动作推进。底层实现可能为了填充缓冲而多取一些原始数据，但这些数据仍由 BufferedReader 管理，调用方不应把底层读取次数当成业务消费量。

处理步骤：用最小前缀判断协议

协议判断只需要稳定的最小前缀。例如 ZIP 文件常见的开头是 PK，PNG 文件则有更长的签名。判断条件应使用切片比较，让多出来的缓冲字节不影响结论。

def classify_stream(reader):
    # 只拿够判断格式的最小前缀，避免把 peek 的长度误当成协议长度。
    prefix = reader.peek(8)

    # 空字节表示当前没有可供判断的数据，可能是 EOF 或非阻塞流暂时无数据。
    if not prefix:
        return "empty-or-wait"

    # 先匹配足够长的签名，再处理短前缀，避免把不完整输入误判为未知格式。
    if prefix.startswith(b"\x89PNG\r\n\x1a\n"):
        return "png"
    if prefix.startswith(b"PK"):
        return "zip-like"
    if len(prefix) 

这里的关键不是把 peek(8) 当成“必定返回 8 个字节”，而是先判断空值，再用已返回的内容匹配。官方说明明确允许返回值少于或多于请求量，因此协议代码还要定义短前缀的处理策略。

回退路径：空结果、短读与 EOF 分开处理

值班时看到“预读为空”，不要立即把它归结为文件损坏。至少有三种情况需要分开：已经到 EOF；底层是非阻塞流且暂时不能继续；输入还没有提供足够的签名。对可重试的输入应返回等待信号，对确定结束的输入应返回 EOF，对完整前缀才进入解析器。

对于带长度字段的协议，可以先预读固定长度的头部，确认完整后再消费；如果头部不完整，就保留当前逻辑位置，等待更多数据或执行回滚。

def read_length_prefixed(reader):
    # 长度字段是 4 字节大端整数，未拿齐时不进入正文解析。
    header = reader.peek(4)
    if len(header) 

这段代码适合文件或已经有明确 EOF 语义的输入。对于 socket 等非阻塞流，不应仅凭一次空结果就关闭连接；应结合事件循环或上层读就绪信号再次调用。若输入不可回退，回滚的对象是业务状态而不是强行对底层流调用 seek()。

告警确认：几个容易误判的边界

复盘清单：把误读问题留在边界内

• 确认底层输入是二进制可读流，并明确是否可能非阻塞。
• 记录调用方请求的预读数量，但不要把它当作返回数量保证。
• 用协议规定的最小前缀判断类型，短前缀不能直接判为未知格式。
• 把 peek() 和 read() 分开记录：前者观察，后者消费。
• 对空结果定义等待、EOF 和重试策略，对不完整帧定义回退策略。
• 使用 with 管理文件流或在异常路径显式关闭资源，避免关闭后继续访问。

相关问题

peek 会不会改变底层文件指针？

对调用方使用的 BufferedReader 逻辑位置，peek 不推进位置；底层原始流可能已经为缓冲读取了更多数据，所以不要绕过缓冲对象直接操作同一个底层流。

为什么不能用 len(peek(8)) == 8 判断数据完整？

官方 API 允许返回数量少于或多于请求量。要判断完整性，应根据协议需要的前缀长度和消息长度字段决定，而不是依赖一次 peek 的精确返回长度。

非阻塞流 peek 返回空 bytes 怎么办？

先区分“暂时没有数据”和“已经 EOF”。如果底层会阻塞，空结果不应直接触发关闭；应回到读就绪通知或重试分支。