Go bufio.Reader.Peek 读取头部后如何不丢数据

很多协议解析代码会先看几个字节，再决定交给哪一种解码器。这里用 bufio.Reader.Peek 是合适的，但有一个容易误判的地方：Peek 只把数据“借给你看”，不会推进读取位置；真正的读取仍然要由后续 Read、io.ReadFull 或 Discard 完成。因此，先判断头部、再按相同长度消费，才不会丢数据或重复处理。

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

想读取头部后继续从头部之后处理，就先用 Peek(n) 判断，再用一次成功的读取消费这 n 个字节；如果只是探测，直接保留 Reader 不再读取即可。需要长期保存预览内容时，先复制切片。

先分清 Peek 与 Read 的位置变化

Peek(n) 返回接下来最多 n 个字节，但不移动 Reader 的读位置。它适合做协议魔数、版本号或换行前缀的判断；它不是“读取并删除”。如果紧接着调用 Read，读到的仍然是刚才看到的头部。

还有两个生命周期细节要记住：返回的字节只保证在下一次读取前有效；调用 Peek 后，UnreadByte 和 UnreadRune 在下一次读取前也不能按普通读取规则使用。若要把预览交给异步任务或跨函数保存，使用 append([]byte(nil), preview...) 做副本。

用 Peek 判断头部后再精确消费

下面的例子假设协议头固定为 4 字节。判断成功后，io.ReadFull 会把这 4 个字节真正取走；后面的 decodePayload 从负载开始读取。代码中的两个读取动作目的不同：第一个只观察，第二个才推进位置。

package main

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

func readPacket(r io.Reader) error {
    // 固定头部必须能放进缓冲区，否则 Peek 可能返回 ErrBufferFull。
    br := bufio.NewReaderSize(r, 4*1024)

    preview, err := br.Peek(4)
    if err != nil {
        // 短输入、底层 I/O 错误和缓冲区不足都在这里处理。
        return fmt.Errorf("peek packet header: %w", err)
    }
    if !bytes.Equal(preview, []byte("PKT1")) {
        // Peek 没有推进位置，拒绝时 Reader 仍从原头部开始。
        return fmt.Errorf("unknown packet header %q", preview)
    }

    header := make([]byte, 4)
    if _, err := io.ReadFull(br, header); err != nil {
        // 真正消费头部时仍检查错误，避免把半个头部交给解码器。
        return fmt.Errorf("consume packet header: %w", err)
    }
    return decodePayload(br)
}

func decodePayload(r io.Reader) error {
    // 示例只表达读取边界；实际项目在这里解析负载并处理 EOF。
    _, err := io.Copy(io.Discard, r)
    return err
}

关键不是把 preview 转成字符串，而是建立“观察后是否消费”的明确约定。如果协议分支不需要消费头部，就不要调用第二次读取；如果需要交给统一解码器，则必须先复制并消费，或由解码器接收一个明确的头部参数。

处理缓冲区大小、短输入和切片生命周期

Peek 的参数不能随意大于缓冲区容量。比如使用默认缓冲区时，想预览一段远大于缓冲区的完整消息，应该改用流式解析，而不是不断增大 Peek。固定头部则可以通过 NewReaderSize 让容量至少覆盖头部。

不要在下一次读取后继续使用原始 preview，也不要把它当成永久拥有的内存。复制后的 headerCopy 可以保存，但它只是检查结果；若要重新拼回完整数据流，还必须同步消费原 Reader 中对应的字节，否则会出现头部重复。

把 Peek 放进可复用的头部检查函数

生产代码里可以把“预览、比较、消费”封装在一个函数中，让调用方只拿到已经确认的结果。函数返回错误时不应假装 Reader 已经前进；这能让上层决定丢弃连接、记录坏包，或交给其他协议分支。

func consumeMagic(br *bufio.Reader, magic []byte) error {
    // 复制 magic 只为比较长度，不让调用方依赖 Peek 的返回切片。
    preview, err := br.Peek(len(magic))
    if err != nil {
        return err
    }
    if !bytes.Equal(preview, magic) {
        return fmt.Errorf("unexpected magic %q", preview)
    }
    // 成功判断后只消费一次，保证后续读取从负载起点开始。
    _, err = io.CopyN(io.Discard, br, int64(len(magic)))
    return err
}

如果头部长度来自不可信输入，先限制最大值，再决定是否扩大缓冲区；不要为了让 Peek 成功而把整个消息一次性放入内存。这个边界通常比“有没有调用 Peek”更值得写进代码评审清单。

相关问题

Peek 后可以直接修改返回的字节吗？

不建议。它属于 Reader 的内部缓冲视图，下一次读取后就可能失效；需要修改或异步保存时先复制。

Peek 返回 ErrBufferFull 时数据丢了吗？

不会因为 Peek 本身丢失；它没有推进位置。应根据返回的部分数据和错误决定是否改用流式解析。

为什么 Peek 后 UnreadByte 失败？

因为 Peek 会让最近一次“可回退的读取”状态失效，先完成下一次正常读取后再按 UnreadByte 的规则使用。