Go bufio.Reader 怎样预读并回退字节

Go bufio.Reader 的 Peek 用于“先看但不消费”，不需要再回退；已经读取一个字节后想交还给下一层解析器，才使用 UnreadByte。两者不能理解成“Peek 配合 UnreadByte”：Peek 会使紧接着的 UnreadByte 无法成功，直到出现新的读取操作。

官方文档地址：https://pkg.go.dev/bufio。下面用一个小型ASCII解析任务说明接口分工：识别固定前缀，以及读完数字后保留分隔符。示例是教学设计，未宣称本机运行或生产性能收益。

把缓冲层交给一个明确的所有者

设想一个导入程序需要判断记录有没有标记前缀，又需要把数字后的分号留给下一个字段处理函数。如果每层都临时包装一个Reader，或者预读后又直接读取底层输入，解析位置就难以推理。一个更清晰的结构是：入口创建bufio.Reader，前缀识别器和字段解析器共享它，并由同一个调用链顺序使用。

这里区分两个位置：Reader对调用方暴露的逻辑位置，与底层io.Reader已经交付数据的位置。Peek为了凑足数据可能触发底层读取，所以“不消费”只描述缓冲Reader这一层，不表示底层文件或连接完全没动。后续解析必须继续经过这个缓冲层。

这也是批量输入场景下值得先做的架构取舍：先统一数据入口和所有权，再讨论缓冲大小，而不是把多个互不知情的预读器叠在同一个流上。本文没有给出并发吞吐或内存节省的测量结论。

固定前缀用 Peek 判断，匹配后再消费

下面的consumeMarker接收调用方已有的Reader。只有完整匹配三个字节的标记才Discard；不匹配、或输入结尾不足三个字节时，不消费当前位置的内容。片段需要导入bufio、errors和io。

// consumeMarker 只在完整匹配时消费前缀；不匹配时保留当前位置。
func consumeMarker(r *bufio.Reader) (bool, error) {
    const marker = "@@:"
    head, err := r.Peek(len(marker))
    if err != nil {
        if errors.Is(err, io.EOF) {
            return false, nil // 末尾不足以组成前缀；已有字节仍留在Reader中。
        }
        return false, err // 缓冲不足或底层I/O异常不能伪装成“不匹配”。
    }
    if string(head) != marker {
        return false, nil
    }
    // Peek返回的是借用切片；匹配必须在下一次读取前完成。
    n, err := r.Discard(len(marker))
    if err != nil {
        return false, err
    }
    if n != len(marker) {
        return false, io.ErrUnexpectedEOF
    }
    return true, nil
}

原创输入“@@:73;rest”的设计预期是返回true，下一次读取从数字开始；输入“!73;rest”应返回false，感叹号仍属于未消费内容；输入“@@”应返回false，两个字节仍留给上层决定如何处理。这些是示例契约，不是运行日志。

head借用Reader内部缓冲。在下一次读取前完成比较，不把它存入长生命周期对象；如果业务需要保留内容，应在读取前复制到自有切片。对照图中的“借用前缀”与“逻辑位置”，能避免把一段视图误当成独立保存的数据。

读到一个分隔字节后，用 UnreadByte 留给下层

数字字段采用另一种策略：逐字节读取，遇到首个非数字就退还这一字节。它适合只需要一字节前瞻的ASCII语法，不等于任意长度回溯。完整示例如下：

package main

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

// readDigits 读取ASCII数字，并把首个非数字字节留给调用方。
// 本示例只限制最多8位；超长错误已经消费部分输入，不承诺回滚。
func readDigits(r *bufio.Reader) (string, error) {
    var out strings.Builder
    for {
        b, err := r.ReadByte()
        if err != nil {
            if errors.Is(err, io.EOF) && out.Len() > 0 {
                return out.String(), nil // 数字恰好位于输入末尾。
            }
            return "", err
        }
        if b  '9' {
            // 必须紧邻成功的ReadByte；不要在中间插入Peek或Discard。
            if err := r.UnreadByte(); err != nil {
                return "", err
            }
            if out.Len() == 0 {
                return "", fmt.Errorf("当前位置不是ASCII数字")
            }
            return out.String(), nil
        }
        if out.Len() == 8 {
            return "", fmt.Errorf("数字超过8位")
        }
        out.WriteByte(b)
    }
}

func main() {
    // 此后的解析都交给同一个Reader，不再绕过它读取底层输入。
    r := bufio.NewReader(strings.NewReader("73;rest"))
    digits, err := readDigits(r)
    if err != nil {
        fmt.Println(err)
        return
    }
    sep, err := r.ReadByte()
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Printf("digits=%s separator=%q\n", digits, sep)
}

对固定输入“73;rest”，设计预期是数字字符串为“73”，调用方读到的separator是分号。字段函数没有吞掉它，因此后续分隔符处理逻辑仍由调用方负责。示例用字符串输入，不涉及需要关闭的外部资源。

这个函数还有一个需要主动说明的失败语义：超过8位时报错，已经读取的数字不恢复，连触发超长判断的那个数字也已经被读走。真实导入程序可把这种记录视为格式错误并交给上层处理，不能捕获错误后假定Reader仍处在字段开头。

为什么 Peek 后不能直接 UnreadByte

Peek本身没有消费要看的字节，因而没有必要用UnreadByte去“撤销预读”。UnreadByte针对的是最近一次读取中的最后一个字节，不是保存游标的接口；连续调用它也不能把多字节输入倒着退回。Discard和WriteTo同样不能作为紧接UnreadByte之前的有效读取操作。

如果最近一次成功的ReadByte之后又调用Peek，再尝试UnreadByte，就破坏了原本的一字节回退契约。解决方式不是忽略错误，而是重新设计小函数：只看时Peek；需要消费时读取；要归还分隔符时，把ReadByte和UnreadByte放在同一小段逻辑内，不插入其他操作。

ASCII例子也不能直接套到Unicode字符解析。UnreadByte只退一个字节，多字节字符应按字符边界设计；需要回退完整rune时使用ReadRune与UnreadRune这一对，而不是退一个UTF-8尾字节后继续当作完整字符读取。

缓冲、阻塞和错误处理有哪些代价

固定前缀应该有明确长度上限。Peek要求的长度超过缓冲容量会遇到ErrBufferFull；它不是自动扩容的任意前瞻窗口。若目标是解析不受信任的长字段，应另做长度限制和错误处理，不要按输入声明的巨大长度直接申请预读。

对于网络或管道输入，Peek可能等待更多底层数据；预读不等于立即返回。Reader并不替你规定网络超时，应由持有底层连接的业务层设置相应策略。这里不通过本地启动服务来演示，也不假定一次底层Read能取得完整前缀。

准备接入业务时，可以把前缀匹配、前缀不匹配、截断前缀、空输入、首字节非数字、数字以EOF结束、超长数字列入你自己的回归清单。观察的是每种情况下返回值、错误和下一未消费字节是否符合设计，不是只判断函数有没有panic。

常见疑问

UnreadByte会让底层连接或文件倒退吗？

不要作这种理解。它是缓冲Reader的回退能力，不是底层Seek；共享Reader才能维持本文所说的解析位置关系。

Peek返回了部分数据和错误，应不应该一律丢弃？

取决于协议。本例要求完整固定前缀，所以将EOF短前缀当作不匹配；其他读取错误继续向上返回。需要区分“截断标记”与“普通文本”的协议，应修改错误契约，而不是沿用本例的false处理。

把Reader藏在字段函数内部会更方便吗？

只有该函数完全拥有后续数据读取时才好推理。若还要把剩余流交给调用方，应接收或返回同一Reader；不要内部预读一批数据后只把底层输入交出去。

相关一手资料：Reader接口文档、Go官方bufio源码。