Go bufio.Reader 如何查看下一行但不消费内容

在解析自定义协议时，经常要先看看输入的下一行是不是某个头部，然后再把完整字节交给后续解析器。这个动作不能用 ReadString('\n') 代替，因为它会推进读取位置。Go 里真正“不消费”的入口是 bufio.Reader.Peek(n)：它查看接下来的 n 个字节，但不会移动 Reader 的当前位置。

先用 Peek 看清不消费的字节边界

Peek(n) 返回从当前位置开始的字节视图，不推进 Reader。它可能为了凑够 n 个字节继续向底层输入读取，但对调用者来说，后续的 Read 仍会拿到这段数据。这里的“不消费”指读取位置不前移，不代表底层连接完全没有发生 I/O。

如果协议头长度固定，例如先判断 5 个字节是不是 HELLO，代码可以这样写：

package main

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

func main() {
    r := bufio.NewReader(strings.NewReader("HELLO\nbody"))

    header, err := r.Peek(5) // 只观察协议头，不推进读取位置
    if err != nil {
        panic(err) // 输入不足时先交给上层处理
    }
    fmt.Println(bytes.Equal(header, []byte("HELLO")))

    line, err := r.ReadString('\n') // 仍能读到原来的 HELLO\n
    if err != nil {
        panic(err) // 真实项目应区分 EOF 与底层读取错误
    }
    fmt.Printf("%q\n", line)
}

注意，header 只是 Reader 内部缓冲区的视图。若要把它保存到异步任务、缓存或下一次读取之后使用，应主动复制：safe := append([]byte(nil), header...)。

把下一行探测限制在缓冲区容量内

Peek 的参数是字节数，不是分隔符，因此不存在直接的 PeekLine。当协议规定“单行最多不超过 Reader 缓冲区”时，可以从 1 个字节逐步扩大预览范围；发现 \n 就复制这一行。复制很重要，否则后续 Read 可能覆盖返回切片。

package main

import (
    "bufio"
    "bytes"
    "errors"
    "io"
)

var ErrLineTooLong = errors.New("line exceeds bufio.Reader capacity")

func peekLine(r *bufio.Reader) ([]byte, error) {
    for n := 1; n = 0 {
            line := append([]byte(nil), chunk[:end+1]...) // 脱离内部缓冲区
            return line, nil
        }
        if err != nil && !errors.Is(err, io.EOF) {
            return nil, err // 非 EOF 错误不能当作“没有换行”
        }
    }
    return nil, ErrLineTooLong // Peek 超过缓冲容量无法保证整行
}

这个函数只负责预览，不会消费输入。调用方确认后，再执行 ReadString('\n') 或自己的解析逻辑即可。若输入在没有换行时提前结束，Peek 可能返回少于请求长度的数据和 io.EOF；这时要根据业务决定把尾部当作最后一行，还是把它视为格式错误。

别把 ReadSlice 和 UnreadByte 当成整行回退

ReadSlice('\n') 能找换行，但它会消费数据，而且返回的切片会在下一次读取后失效。UnreadByte 也只能回退最近一次读取的一个字节，不能把已经读走的一整行恢复。因此，“先 ReadSlice 再 UnreadByte”无法实现安全的整行预读。

把切片生命周期和错误分支写清楚

生产代码里至少要检查三件事：第一，Peek 返回的字节是否已经复制；第二，预览长度是否小于等于 r.Size()；第三，io.EOF、bufio.ErrBufferFull 和底层 I/O 错误是否分别处理。若协议行可能超过固定容量，宁可让上层调整缓冲区或改用可回放设计，也不要把不完整前缀交给业务解析器。

一句话记忆：Peek 适合“看一眼再决定”，ReadString 适合“读走一行”。两者可以连续使用，但不要把返回的内部切片跨过下一次读取保存。

相关问题

Peek 会不会阻塞底层连接？

可能会。为了凑够请求的字节数，Reader 可以继续从底层读取；但 Peek 本身不会推进 bufio.Reader 的消费位置。

Peek 返回的切片能长期保存吗？

不能默认长期保存。下一次读取可能覆盖它；需要长期使用时，用 append([]byte(nil), data...) 复制。

长行应该把 Reader 调得多大？

按协议允许的最大行长加上换行符设置，并在超限时返回错误。若长度没有上限，应使用可回放缓冲层，而不是无限增大 Peek 参数。