Go bufio.Reader Peek 后调用 Discard 为什么会让缓存内容失效

先说结论：bufio.Reader.Peek 返回的是 Reader 内部缓冲区的一段预览，不会推进读取位置，但它不是独立副本。只要后面发生读取操作（包括用 Discard 消费这段数据），就不能继续把原来的切片当成稳定快照；需要跨越后续读取保存时，应立即复制。

官方文档：https://pkg.go.dev/bufio#Reader.Peek

这条边界很容易在协议头判断、魔数识别和分隔符预检中被忽略。下面只围绕“预览后是否消费、是否需要保留”把生命周期拆开。

先看清 Peek 返回的是什么

Peek(n) 的第一个作用是查看接下来的最多 n 个字节，读取位置暂时不前移。第二个容易漏掉的事实是：返回值是指向 Reader 内部缓冲区的切片。它适合立即比较，不等于已经复制了一份数据。

package main

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

func main() {
    r := bufio.NewReader(bytes.NewBufferString("GET /health HTTP/1.1\r\n"))

    preview, err := r.Peek(4)
    if err != nil {
        // Peek 可能因输入不足或 n 超过缓冲区容量而返回错误。
        panic(err)
    }

    // preview 只用于当前判断；此时读取位置仍在输入开头。
    fmt.Printf("prefix=%q buffered=%d\n", preview, r.Buffered())
}

官方文档还明确指出，Peek 返回的字节会在下一次读取时失效；如果请求的 n 大于 Reader 的缓冲区大小，可能得到 bufio.ErrBufferFull。因此，判断成功不能只看切片内容，还要处理 err。

用 Discard 消费预览内容

如果预览只是为了确认“这是不是某种头部”，确认后希望把这段字节消费掉，可以使用 Discard(len(preview))。它推进的是 Reader 的读取位置，而不是把 preview 变成副本。

package main

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

func consumePrefix(r *bufio.Reader, prefix []byte) error {
    preview, err := r.Peek(len(prefix))
    if err != nil {
        return fmt.Errorf("预览前缀：%w", err)
    }
    if !bytes.Equal(preview, prefix) {
        return fmt.Errorf("前缀不匹配：%q", preview)
    }

    discarded, err := r.Discard(len(prefix))
    if err != nil {
        // Discard 少于请求数量时必须把错误交给调用方。
        return fmt.Errorf("消费前缀：已丢弃 %d 字节：%w", discarded, err)
    }
    if discarded != len(prefix) {
        // 这个判断让“成功消费完整前缀”成为显式条件。
        return fmt.Errorf("消费前缀不完整：%d/%d", discarded, len(prefix))
    }
    return nil
}

func main() {
    r := bufio.NewReader(bytes.NewBufferString("MAGICpayload"))
    if err := consumePrefix(r, []byte("MAGIC")); err != nil {
        panic(err)
    }
    // Discard 后，下一次读取从 payload 开始。
    rest, err := r.ReadString('\\n')
    fmt.Printf("rest=%q err=%v\n", rest, err)
}

当要丢弃的字节已经在当前缓冲区内时，Discard 可以不访问底层 Reader；但这并不改变返回切片的生命周期。也就是说，“消费成功”和“旧切片仍可长期使用”是两个完全不同的判断。

需要保留时先复制

如果业务需要把预览结果交给后续函数、缓存到结构体，或者在 Discard 后继续使用，就先复制。最小写法是 append([]byte(nil), preview...)，它会产生一份独立的底层数组。

package main

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

func peekAndKeep(r *bufio.Reader, n int) ([]byte, error) {
    preview, err := r.Peek(n)
    if err != nil {
        return nil, fmt.Errorf("预览数据：%w", err)
    }

    // 先复制，再允许后续读取或 Discard 改变 Reader 的内部缓冲区。
    saved := append([]byte(nil), preview...)
    if _, err := r.Discard(n); err != nil {
        return nil, fmt.Errorf("消费预览数据：%w", err)
    }
    return saved, nil
}

func main() {
    r := bufio.NewReader(bytes.NewBufferString("HEADbody"))
    saved, err := peekAndKeep(r, 4)
    if err != nil {
        panic(err)
    }
    // saved 不再依赖 r 的内部缓冲区，可在后续逻辑中安全使用。
    fmt.Printf("saved=%q\n", saved)
}

复制的代价是一次内存分配和 n 字节拷贝，所以不要把所有 Peek 都无条件复制。判断标准很直接：只在当前函数内比较，直接使用；要跨过下一次读取或异步传递，复制。

对比直接读取与预览后消费

很多代码其实不需要 Peek。若业务确定无论如何都要消费这段数据，直接 Read 到调用方提供的切片通常更清楚；只有需要“先判断、再决定是否消费”时，Peek 才能表达出回退语义。

还有一个经常一起出现的坑：调用 Peek 后，UnreadByte 或 UnreadRune 在下一次读取前不能按普通读取操作理解。若代码依赖回退，应该把整个状态转换写清楚，不要把 Peek 当成一次已经完成的 Read。

常见误区与速查

• 误区一：Peek 返回的切片就是副本。不是。它指向 Reader 的内部缓冲区，后续读取会让它失去稳定性。
• 误区二：Discard 只改变位置，不影响旧切片。Discard 会消费缓冲内容；旧切片不能再承担快照职责。
• 误区三：只要 len(preview) 等于 n 就算成功。还要检查 Peek 的 error，尤其要区分输入不足和 ErrBufferFull。
• 误区四：所有协议头都应该 Peek。如果不需要回退或条件判断，直接 Read/ReadFull 往往更容易维护。

可以把规则压缩成一句话：Peek 用来判断，Discard 用来消费，复制用来延长数据寿命。

相关问题

Peek 会移动 bufio.Reader 的读取位置吗？

不会。Peek 只让数据可见，读取位置仍保持不变；要消费这段数据，需要调用 Read 或 Discard。

Peek 返回 ErrBufferFull 怎么办？

说明请求的连续预览长度超过 Reader 的缓冲区容量。可以缩小预览范围、调整 Reader 大小，或改用分段读取的协议解析方式。

Discard 之后还能读取剩余内容吗？

可以。Discard 只跳过指定数量的字节，下一次 Read 会从新的当前位置继续；需要保留的旧内容则必须在 Discard 前复制。