Go bufio.Reader.Peek 怎样处理空值和异常分支

Go bufio.Reader.Peek 的空值与异常处理，应同时检查返回错误和数据长度，再访问切片。固定前缀解析中，“没有下一条记录”与“下一条记录只剩一部分”应有不同结果；Reader 指针为 nil 则属于调用入口问题。Peek 不消费字节，识别成功后还必须从同一个 Reader 正式读取或丢弃，否则重复调用会一直看到同一段前缀。

Go 官方地址：https://go.dev/。我会把这类小解析器的结束规则写得尽量明确：无剩余字节才允许正常结束，已有记录片段就报告截断。这个选择来自下文的示例协议，不代表所有协议都必须如此定义。

先把空值拆成三种情况

第一种是调用方传入 nil 的 Reader 指针，应该在 helper 入口返回明确错误。第二种是一个已经正确构造、但数据源为空的 Reader；它是正常对象，需要依照输入结束规则处理。第三种是请求 Peek(0)，这是请求零个字节，不能用来检测数据源是否结束。

本文使用一条三字节记录：两个固定前缀字节 A、B，加一个任意字节载荷。这个简单格式允许把“前缀完整”与“记录完整”分开讨论：即便前缀已经取得，载荷仍可能缺失。

把错误处理规则放在索引之前

下面是容易造成越界访问的写法。它把“预读可能失败”的事实抹掉了：

// 反例：忽略错误后，p 可能不足两个字节；不要这样写。
p, _ := br.Peek(2)
matched := p[0] == 'A' && p[1] == 'B'

我更倾向于让每个错误分支先退出，再比较前缀。这样看到索引表达式时，前置条件已经明确，而不是在每个索引旁散落补丁。这里调整的是应用组织方式，Peek 的标准库语义并没有因本文发生变更，也没有某个新提案才允许这样写。

Peek 在无法取得请求长度时，可以同时返回部分字节和一个说明原因的错误。不能把“错误非空”理解成“一定完全没有数据”，也不能把“拿到部分数据”理解成“已满足完整前缀”。

用完整解析器处理前缀和截断

下面的 main.go 包含完整入口。它在固定前缀不足时，把协议层错误表达为 io.ErrUnexpectedEOF；其他预读错误保留原因。未知前缀返回自定义错误，调用方选择停止，不尝试自动寻找下一个前缀。

package main

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

var errNilReader = errors.New("Reader 不能为空")
var errBadPrefix = errors.New("记录前缀不匹配")

func nextRecord(br *bufio.Reader) (byte, error) {
    // 这是应用入口检查，避免在 nil 指针上调用读取方法。
    if br == nil {
        return 0, errNilReader
    }
    p, err := br.Peek(2)
    if err != nil {
        if errors.Is(err, io.EOF) {
            if len(p) == 0 {
                // 新记录尚未开始，允许调用方正常结束。
                return 0, io.EOF
            }
            // 已有一部分前缀，不能当作正常流结束。
            return 0, fmt.Errorf("记录前缀不足: %w", io.ErrUnexpectedEOF)
        }
        return 0, fmt.Errorf("预读记录前缀: %w", err)
    }
    // 只在完整前缀可用时索引，比较期间不进行其他读取。
    if p[0] != 'A' || p[1] != 'B' {
        return 0, errBadPrefix
    }
    var record [3]byte
    // Peek 没有消费前缀，必须从同一个 br 读取整条三字节记录。
    if _, err := io.ReadFull(br, record[:]); err != nil {
        return 0, fmt.Errorf("读取完整记录: %w", err)
    }
    return record[2], nil
}

func run() error {
    // 第一条为完整记录，末尾 A 用于演示不完整前缀分支。
    br := bufio.NewReader(strings.NewReader("ABxA"))
    for index := 1; ; index++ {
        value, err := nextRecord(br)
        if errors.Is(err, io.EOF) {
            return nil
        }
        if err != nil {
            return fmt.Errorf("第 %d 条记录: %w", index, err)
        }
        // 零字节也可以是合法载荷，是否成功只由 err 决定。
        fmt.Printf("记录 %d 的载荷=%q\n", index, value)
    }
}

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

字符串 ABxA 是本例主动设置的输入，目的是让一条完整记录之后还留有截断前缀。按程序规则，第一条应被解析，下一条应报告前缀不足；这是代码设计预期，本文没有执行示例或展示虚构日志。若改为空字符串，应允许正常结束；若改为 AB，则应进入完整记录读取不足的分支。

Peek 成功只保证本次请求的两个字节可用。后面使用 io.ReadFull 从同一个 br 消费三个字节，不会跳过前缀，也不会直接绕到底层 reader。返回的 p 在比较完成后不再使用，避免后续读取覆盖它时还持有旧视图。

如果底层读取产生非 EOF 错误，helper 会返回该错误的包装，不擅自视为正常结束。完整记录读取失败后，Reader 可能已经消费部分字节；在这个协议实现里，调用方立即停止，不能简单重试整个 nextRecord 并假设仍处于同一条记录的开头。

说明缓冲区与返回切片的期限

Peek 返回的是对内部缓冲内容的视图，不是长期拥有的一份副本。官方文档规定其字节只在下一次读取前有效。需要在后续读取之后继续保留前缀时，应在读取前复制到自己的存储；小型固定前缀也可以像本例一样立即比较，随后不再引用。

请求长度超过 Reader 的缓冲区大小时，会得到 bufio.ErrBufferFull。它表达缓冲区与请求不匹配，不能据此判定输入源为空。本例只请求两个字节，且通过 bufio.NewReader 正常初始化，不需要靠反复重试扩充请求；泛化到可变长度协议时，应先设定业务上限，再选择缓冲大小或改用分段读取。

负数请求返回 bufio.ErrNegativeCount。对于已正确构造的 Reader，当前实现的零长度预读返回零长度切片和 nil 错误，不触发补充数据读取，因此不能拿 Peek(0) 当作 EOF 探针。不要按切片是否等于 nil 分类这些情况，应使用请求长度、len 和 error 的语义。

还要区分“有效空数据源”和“Reader 零值”。本例始终使用构造函数；不要仅声明一个 Reader 零值就假设它已经连接数据源。若采用复用对象的方式，应按标准库 Reset 的约定提供有效数据源。

按调用场景决定继续还是结束

如果数据来自网络，Peek 可能为凑齐字节调用底层读取，并非天然的非阻塞查看。超时应由连接及其读取策略管理，不应看到暂时无结果就循环忙等。多个解析任务也不应无协调地交替读取同一个 br，否则前缀与消费对象会失去对应。

我的采用建议是：固定短前缀先比较后消费；较长或可变记录独立设计长度上限和分段读取；可恢复协议则另外定义丢弃与重新同步规则。不要把一个“忽略所有错误再重试”的循环当成通用容错方案。

常见问题

Peek 会把前缀读走吗？它可能从底层补充缓冲，但不会推进这个 Reader 的逻辑读取位置；正式消费仍需后续读取或 Discard。

为什么 errors.Is(err, io.EOF) 不能直接覆盖所有结束分支？协议还要看是否已经有部分记录。本文只把新记录边界的无数据 EOF 当作正常结束。

不消费数据直接再次 Peek 能跳到下一条吗？不能，同一位置仍会返回同一段前缀。必须明确消费当前记录。

可以在读取之后再复制 p 吗？这可能已经复制到被覆盖的缓冲内容。需要保留时应在后续读取前复制。

官方资料：https://pkg.go.dev/bufio#Reader.Peek（预读与切片期限）；https://pkg.go.dev/io#ReadFull（完整读取与截断错误）；https://go.dev/src/bufio/bufio.go（负数与零长度请求的当前实现）。