当前位置：首页 > 文章列表 > Golang > Go教程 > Go bufio.Peek 怎样预读协议头而不消费数据

Go bufio.Peek 怎样预读协议头而不消费数据

来源：17golang原创 2026-10-14 01:07:01 0浏览收藏

在处理 TCP、文件或消息队列里的自定义协议时，常见需求是先看开头几个字节，确认它是不是目标协议，再交给后续解析器继续读取。Go 的 bufio.Reader.Peek 正好用于这个场景：它返回接下来的 n 个字节，但不会推进读取位置。

官方地址：https://pkg.go.dev/bufio

这里有两个容易忽略的边界：Peek 返回的切片只在下一次读取前有效；如果 n 大于 Reader 的缓冲区容量，会返回 bufio.ErrBufferFull。所以正确做法不是“先 Peek，出错再随便重试”，而是先按协议头长度配置缓冲区，再区分短输入和容量不足。

本文要点：① Peek 只观察、不消费；② n 不应超过 Reader 的容量；③ 确认协议后用 Read 或 Discard 消费，别长期保存 Peek 返回的切片。

Peek 为什么不会让读取位置前进

假设协议的前四个字节是 GOLG，后面才是长度字段和正文。我们先把输入包装成缓冲 Reader，再读取四字节协议头。Peek 的返回值用于判断，后面的 Read 仍然会从 G 开始拿数据。

package main

import (
    "bufio"
    "bytes"
    "fmt"
    "io"
)

func readFrame(src io.Reader) error {
    // 缓冲区至少容纳协议头；后续读取仍通过同一个 Reader 完成。
    br := bufio.NewReaderSize(src, 1024)

    // Peek 只查看前四个字节，不推进 br 的读取位置。
    header, err := br.Peek(4)
    if err != nil {
        return fmt.Errorf("预读协议头失败: %w", err)
    }
    if !bytes.Equal(header, []byte("GOLG")) {
        return fmt.Errorf("未知协议头: %q", header)
    }

    // 确认协议后再消费协议头，读取位置此时才真正前进。
    if _, err := io.CopyN(io.Discard, br, 4); err != nil {
        return fmt.Errorf("消费协议头失败: %w", err)
    }
    fmt.Println("协议已确认，后续读取从正文开始")
    return nil
}

func main() {
    // 示例输入包含协议头和正文，说明 Peek 后仍可继续读取。
    if err := readFrame(bytes.NewBufferString("GOLGpayload")); err != nil {
        fmt.Println(err)
    }
}

代码里的关键不是把头部复制到另一个 Reader，而是始终复用同一个 br。如果在 Peek 后重新从原始 src 读取，就可能绕过缓冲区里已经预取的字节，导致协议头或正文顺序错乱。

Go bufio.Reader 中协议输入、Peek 协议头、判断和后续 Read 的静态关系说明图 — 图1：结构说明图，查看协议输入、bufio.Reader、Peek 和后续读取之间的静态关系；这不是运行截图。

缓冲区容量决定 Peek 能检查多长的头

bufio.NewReaderSize(src, size) 的第二个参数不是装饰项，它决定了 Reader 能为一次 Peek 保留多大的连续缓冲。比如协议头固定为 32 字节，就应该把缓冲区设置为不小于 32 的值；如果把 Peek(32) 用在只有 16 字节容量的 Reader 上，结果会是 ErrBufferFull。

func inspectHeader(src io.Reader, headerSize int) error {
    // 先校验协议配置，避免负数或零长度让判断失去意义。
    if headerSize

上面的片段需要额外导入 errors。实际项目里可以把协议头长度作为固定常量，也可以在构造 Reader 时留出少量余量。关键是不要把“输入暂时还没到齐”和“缓冲区绝对装不下”混为一谈：前者要等待或结束读取，后者要调整 Reader 设计。

Go Peek 的缓冲区容量、ErrBufferFull、io.EOF 和后续读取之间的静态关系说明图 — 图2：结构说明图，展示 Peek 的容量边界与 ErrBufferFull、短输入错误的关系；这不是运行截图。

短读、ErrBufferFull 和切片有效期怎么处理

官方文档对 Peek 的返回规则可以归纳为三类。第一，返回完整 n 个字节且错误为 nil，说明当前 Reader 已经能提供完整协议头。第二，返回少于 n 个字节并带错误，通常表示底层输入结束或读取失败，返回的部分数据只能用于记录和诊断。第三，n 大于 Reader 容量时返回 ErrBufferFull，这不是“再读一次就会好”，而是当前缓冲设计不允许这次预读。

Peek 返回的字节会在下一次 Reader 读取后失效。若协议判断结果要异步保存，应先复制：saved := append([]byte(nil), header...)。如果只是立即比较魔数，就不要额外复制。确认后，使用同一个 Reader 的 Read、Discard 或协议解析函数消费数据；不要调用 UnreadByte 试图撤销 Peek，因为 Peek 会让这类“撤回上次读取”的操作暂时不满足前置条件。