Go bufio.Reader.UnreadByte 为什么只能回退一次

Go 的 bufio.Reader.UnreadByte 只能回退一次，不是因为缓冲区只能保存一个字节，而是 Reader 只维护“最近一次成功读操作”的回退资格。成功调用一次 UnreadByte 后，这个资格立即失效；下一次再调用就会得到 bufio: invalid use of UnreadByte。

把 UnreadByte 当成“单步撤回”即可，不要把它当作解析器的回滚栈。只需要查看短前缀时优先用 Peek，需要多次试探时显式保存已经读出的字节或 token。

这个边界正是 bufio.Reader 的接口契约：最近一次方法必须是读操作，且只能撤回最近一次读出的字节。

为什么 UnreadByte 只支持最近一次读

Reader 内部至少要维护缓冲区、读游标 r、写游标 w 和一个表示最近字节的状态。ReadByte 取出一个字节后推进 r，并记录 lastByte；UnreadByte 把游标退回一个位置，再把这个状态清空。它没有保存“上上次字节”的栈，所以第二次回退没有可依据的历史。

可以用一个很小的例子看出状态转换：

package main

import (
    "bufio"
    "fmt"
    "strings"
)

func main() {
    r := bufio.NewReader(strings.NewReader("ab"))

    first, _ := r.ReadByte() // 读取 a，并建立一次回退资格
    err1 := r.UnreadByte()   // 撤回 a，资格随即清空
    err2 := r.UnreadByte()   // 没有新的读操作，因此返回 ErrInvalidUnreadByte

    next, _ := r.ReadByte() // 重新读取刚才撤回的 a
    fmt.Printf("%c %v %v %c\n", first, err1, err2, next)
}

这里的“只能一次”是状态语义，不是数据长度限制。即使底层缓冲里还有很多字节，UnreadByte 也不会自动沿着 r 连续后退，因为那会把接口变成不可控的回滚操作。

哪些调用会让回退资格失效

判断是否能回退，关键不是看调用名称里有没有“读”，而是看它是否是 Reader 认可的最近一次读操作。常见边界如下：

还有一个容易忽略的点：ReadRune 会记录最后一个字节，因此它之后的 UnreadByte 与 UnreadRune 不是同一套语义。若目标是撤回完整 UTF-8 字符，应使用 UnreadRune，不要只退回字符的最后一个字节。

把一次回退约束换成可控的解析状态

如果只是判断输入是否以某个短前缀开头，Peek 更直接：它查看缓冲内容但不推进读游标。需要按字节读取并在多个候选之间试探时，应把候选内容放到自己的切片或 token 结构中，解析成功后再提交，而不是连续调用 UnreadByte。

func hasPrefix(r *bufio.Reader, prefix []byte) (bool, error) {
    got, err := r.Peek(len(prefix)) // 观察前缀，不推进 Reader 游标
    if err != nil {
        return false, err // 数据不足或底层读取失败时交给调用方处理
    }
    for i := range prefix {
        if got[i] != prefix[i] { // 比较候选前缀，未匹配时不需要回退
            return false, nil
        }
    }
    return true, nil
}

若解析规则必须消费字节，可以使用“读取到临时 token，再决定是否提交”的方式。临时 token 是应用层的历史记录，长度和生命周期由业务控制，能够表达多字节回滚、错误恢复和日志定位；UnreadByte 只适合紧邻一次读取的微小调整。

相关问题

连续两次调用 UnreadByte 为什么不是回退两个字节？ 因为第一次成功后，Reader 将最近回退状态标记为无效；第二次调用没有新的成功读操作作为依据。

Peek 之后怎样重新获得 UnreadByte 资格？ 先执行一次成功的读操作，例如 ReadByte；但如果本来就只需观察数据，继续使用 Peek 更清晰。