Go bufio.Reader Peek 之后为什么下一次 Read 还能读到同样内容

这个现象不是 bufio.Reader 把输入倒回去了，而是 Peek 根本没有消费数据。它返回当前读取游标之后的字节窗口，必要时先把底层数据填进缓冲区，但不会推进游标；因此紧接着调用 Read，自然还能读到刚才预览过的内容。

Peek 不推进游标，Read 才会消费缓冲区

可以把 bufio.Reader 想成三层：底层 io.Reader、内部字节缓冲区，以及指向“下一个未消费字节”的读取位置。Peek(n) 查看这个位置开始的 n 个字节，Read(p) 则从同一个位置取数据并推进它。

为什么 Peek 可能已经读了底层，却仍然不算消费

当缓冲区剩余字节不足 n 个时，Peek 会尝试填充缓冲区。这个动作改变的是“底层数据已经进入 bufio 缓冲区”的状态，不是“业务已经处理了这些数据”的状态。源码中的 Peek 会反复填充，最后返回从当前游标开始的切片；游标仍停在原处。

package main

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

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

	// Peek 只观察请求方法，不把它从 Reader 中消费掉。
	header, err := r.Peek(3)
	if err != nil {
		// 输入不足或缓冲区无法满足长度时，先处理错误再继续。
		panic(err)
	}
	fmt.Printf("peek=%q\\n", header)

	buf := make([]byte, 3)
	// Read 仍从同一读取位置取出 GET，并推进 Reader 的游标。
	n, err := r.Read(buf)
	fmt.Printf("read=%q n=%d err=%v\\n", buf[:n], n, err)
}

这段代码里，Peek(3) 可能让底层 bytes.Reader 的内容进入 bufio.Reader，但它不会让 GET 变成已消费数据。后面的 Read 从缓冲区复制同样的三个字节，所以看到重复内容是预期行为。

预览后该用 Read、Discard，还是复制一份

如果预览结果符合当前协议，就用 Read 把它交给解析器；如果只想跳过它，用 Discard 更直接。不要把 Peek 返回的切片当成永久缓存：官方文档明确说明，下一次读操作后这段字节就不再可靠。

// 需要跨越下一次读取保存预览内容时，复制到独立切片。
saved := append([]byte(nil), header...)

// 确认无需处理时再消费，避免业务游标停在原处。
if _, err := r.Discard(len(saved)); err != nil {
	// Discard 可能只跳过一部分数据，调用方仍应保留错误。
	panic(err)
}

三个容易误判的边界

• Peek 长度过大：当 n 大于 Reader 的缓冲区容量时，返回 ErrBufferFull；需要更大的预览窗口，应在创建 Reader 时选择合适的缓冲区，或改用分段解析。
• 输入提前结束：Peek 可能返回少于 n 个字节并同时给出错误，不能只判断切片内容是否非空。
• Read 不保证读满：一次 Read 至多对应底层的一次读取，返回长度可能小于目标切片；固定长度协议应考虑 io.ReadFull。

排查时可以先问一句：当前代码是在“判断下一段是什么”，还是在“正式消费下一段”？前者用 Peek，后者用 Read；两者之间不要用“底层已经读过”替代“业务已经消费”的判断。

常见问题

Peek 后直接调用 Read，为什么不是从下一个字节开始？

因为 Peek 不推进读取游标。它只是返回游标后的窗口，Read 仍从这个窗口的起点消费。

Peek 返回的切片能不能保存到结构体里？

不建议直接保存。下一次读操作后底层缓冲区可能被覆盖；需要跨读取使用时，用 append 复制出独立切片。

只想跳过 Peek 看到的内容怎么办？

确认不需要解析后调用 Discard。它表达“推进消费位置”的意图，比再次 Peek 更清楚。

总结

Peek 的关键语义是“看但不取”：它可以填充缓冲区，却不移动读取游标。因此后续 Read 读到同样内容并非重复读取，而是同一份未消费数据。把预览、消费、跳过和复制分别放在正确的调用上，文件流和网络协议解析就不容易出现错位。