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

在处理 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 读取，就可能绕过缓冲区里已经预取的字节，导致协议头或正文顺序错乱。

缓冲区容量决定 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 设计。

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

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

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

一个可落地的检查清单

• 协议头长度是否不大于 br.Size()，是否把容量不足与输入结束分开处理。
• Peek 后是否继续使用同一个 bufio.Reader，而不是回到原始 Reader。
• 返回切片是否只在下一次读取前使用，需要跨生命周期保存时是否显式复制。
• 协议确认后是否明确消费头部，避免业务解析器再次把头当作正文。

简而言之，Peek 适合做“先看再决定”的协议分流，不适合代替完整读取。只要把 Reader 的容量、错误分支和切片生命周期一起设计，预读就能保持简单且可控。

相关问题

Peek 和 ReadSlice 有什么区别？

Peek 按长度查看数据且不推进位置；ReadSlice 按分隔符查找，并且返回的切片也只在下一次 I/O 前有效。协议头是固定长度时优先考虑 Peek，按换行等边界读取时再考虑 ReadSlice 或 ReadString。

协议头可能超过缓冲区时怎么办？

如果长度是协议设计的一部分，应在创建 Reader 时把容量设到足够大；如果长度不受控，就不要盲目 Peek 全部内容，而应先读取一个有界长度字段，再用限制读取方式保护后续正文。