Go bufio.Reader.Peek 怎样查看前缀又不消耗输入

bufio.Reader.Peek(n) 返回接下来至多 n 个字节，不推进这个 Reader 的逻辑读取位置；拿到完整前缀后可以先判断，再从同一个 Reader 正式读取。它可能为了凑齐数据读取底层输入，所以“不消耗”不等于“不触发 I/O”，也不代表底层流的位置没变化。

例如导入一份内存文本，先看开头是否为四字节标识 NOTE，再决定后续处理。这里最需要避免的错误，是 Peek 之后绕开缓冲层读取原始流。下面用固定输入拆解这个场景，所有代码均为原创教学示例，输出是推导的预期现象，未在本文制作过程中执行。

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

前置条件：不消耗的是缓冲读取位置

可以把对象关系分成三组：输入来源含底层输入；缓冲读取器含 Reader、内部缓冲、逻辑读取位置；查看接口含 Peek、前缀视图。Reader 包装底层输入、管理内部缓冲和逻辑读取位置，Peek 关联 Reader，前缀视图关联内部缓冲。查看返回的视图时，不把逻辑读取位置向后移动。

这里 n 按字节计数；四字节前缀不一定等于四个汉字。本文只处理固定长度前缀，不展开分词或完整协议框架。网络输入还可能需要等待更多数据，Peek 本身没有“只看看、立即返回”的通用保证。

初始化并编写代码：只查看四字节前缀

判断函数接收现有 *bufio.Reader，主函数也继续使用这个对象。先检查 Peek 的错误，再比较完整的四字节标识，避免输入只有两字节时误判或越界。

package main

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

// inspectMagic 只做前缀判断，不消费 r 的逻辑输入。
func inspectMagic(r *bufio.Reader) (bool, error) {
    prefix, err := r.Peek(4)
    if err != nil {
        // 四字节不齐时不把已有片段当成完整标识。
        return false, fmt.Errorf("查看四字节前缀：%w", err)
    }
    return bytes.Equal(prefix, []byte("NOTE")), nil
}

func run() error {
    r := bufio.NewReader(strings.NewReader("NOTE:orange"))
    matched, err := inspectMagic(r)
    if err != nil {
        return err
    }
    fmt.Println("匹配：", matched)

    header := make([]byte, 4)
    // 仍从同一个缓冲读取器消费；不能绕回底层输入。
    if _, err := io.ReadFull(r, header); err != nil {
        return fmt.Errorf("读取标识：%w", err)
    }
    rest, err := io.ReadAll(r)
    if err != nil {
        return fmt.Errorf("读取剩余内容：%w", err)
    }
    fmt.Printf("实际读取：%s 剩余：%s\n", header, rest)
    return nil
}

func main() {
    // 教学输入来自内存；真实文件由创建它的调用方负责关闭。
    if err := run(); err != nil {
        fmt.Println("失败：", err)
    }
}

inspectMagic 的 false、nil 表示完整前缀不匹配；false、非 nil 错误表示没有完成这次查看。业务层可以对这两种情况作不同处理。示例使用包装错误保留底层原因，调用方可用 errors.Is 识别 EOF 或缓冲容量错误。

运行检查：相同 Reader 仍能读到原始前缀

将上一节完整代码保存为独立目录的 main.go，可以自行运行：

# 运行这个固定内存输入示例，观察查看与正式读取是否关联同一前缀。
go run main.go

按代码可推导以下输出，属于预期文本，不是实测日志：

匹配： true
实际读取：NOTE 剩余：:orange

io.ReadFull 消费四字节到调用方提供的 header；它与 Peek 的职责不同。正式读取若在读满之前结束，需要检查错误和已读数量；ReadFull 对完全无数据的 EOF 与已取得部分数据后的 UnexpectedEOF 有不同返回。示例的固定输入足够长，因此读取完成后 header 仍为 NOTE。

这里的检查不应只看匹配结果：如果主函数误用底层流，前缀判定可能成功，后续处理却丢掉已预读的数据。把 Reader 作为后续函数的共同输入，可以让这个所有权约定在代码上保持明确。

扩展实验：短输入与 ErrBufferFull 分开处理

把正常例子换成短输入和超容量请求，错误含义就能分开。请求约束包含请求长度、缓冲容量；返回信息包含前缀片段、返回错误；错误分类包含 EOF、ErrBufferFull。请求长度与缓冲容量形成容量约束，请求长度与前缀片段形成长度比较，返回错误关联这两种错误类别。它们是解释接口返回值的静态关系。

package main

import (
    "bufio"
    "errors"
    "fmt"
    "io"
    "strings"
)

func main() {
    short := bufio.NewReader(strings.NewReader("NO"))
    prefix, err := short.Peek(4)
    // Peek 返回的部分数据仍有价值，但不足四字节，不能直接索引第四字节。
    fmt.Printf("短数据：%q 长度=%d EOF=%t\n", prefix, len(prefix), errors.Is(err, io.EOF))

    limited := bufio.NewReaderSize(strings.NewReader(strings.Repeat("x", 80)), 16)
    // 使用 Size()+1 明确请求超过实际缓冲容量，避免猜测内部最小值。
    fragment, err := limited.Peek(limited.Size() + 1)
    fmt.Printf("缓冲不足：%t 部分长度=%d\n", errors.Is(err, bufio.ErrBufferFull), len(fragment))
}

第一组固定输入的预期片段为 "NO"、长度 2、EOF 为 true。第二组构造的请求长度明确大于实际缓冲容量，预期 ErrBufferFull 为 true；它不能被解释为“源数据一定太短”。不要忽略非 nil 错误直接用返回片段做完整前缀匹配。

需要较长但有上限的前缀，应在最初包装输入时选择合适的 NewReaderSize；不要在已经预读后，对原始输入重新建 Reader 期待找回旧数据，也不要无上限放大 n。若真正的需求是消费一大段到独立存储，应另用有长度约束的读取方案。

清理与常见问题：保留副本并沿用读取器

Peek 返回的是借用视图，下一次读取后不再保证有效。若要把前缀交给异步逻辑或长期保存，应在继续读取之前复制：

// 片段放在已有 r 的处理函数中；先查看完整前缀，再获得独立副本。
prefix, err := r.Peek(4)
if err != nil {
    return err
}
saved := make([]byte, len(prefix))
copy(saved, prefix)
// saved 可在之后读取 r 时继续使用；不要改写借用的 prefix。
_ = saved

连续 Peek 两次会跳过前缀吗？

没有夹杂消费操作时，查看仍从当前逻辑位置开始。即使需要更多预读，也不能由此认为底层流没有变化。跨会改变内部缓冲的调用保存视图时，使用独立副本更清楚。

查看后想跳过标识怎么办？

明确调用 Discard(4) 并检查返回数量与错误，或者像完整示例一样正式读取四字节。Peek 自己不承担消费职责，不需要用 UnreadByte 去“退回”查看过的数据。

Reader 会自动关闭底层文件吗？

关闭资源应由持有文件或连接的调用方安排。本文的内存输入无需关闭；迁移到文件或连接时，不要把缓冲包装器当成资源生命周期的所有者。保持后续读取都经过同一 Reader，再按业务约定关闭原资源。

官方资料：接口契约见 https://pkg.go.dev/bufio；缓冲与位置关系见 https://go.dev/src/bufio/bufio.go；正式读取的长度和错误语义见 https://pkg.go.dev/io#ReadFull。