Go bufio.Reader.Peek 返回的切片为什么不能长期保存：缓冲区复用边界

线上协议解析里经常先看几个字节再决定走哪条分支。问题是，bufio.Reader.Peek 返回的并不是一份独立副本：它指向 Reader 的内部缓冲区，下一次读操作后就不再适合继续保存或异步使用。

把 Peek 的结果当作“当前输入窗口”使用；如果要跨过下一次读取、交给 goroutine 或写入缓存，立刻用 bytes.Clone 或 append([]byte(nil), header...) 复制。

先把协议头判断限制在一次读取窗口内

假设一个连接的消息以 GO1 开头，解析器要先判断版本，再把完整消息交给后续读取逻辑。最小判断可以这样写：

func isGo1Message(r *bufio.Reader) (bool, error) {
    header, err := r.Peek(4)
    if err != nil {
        return false, err
    }
    return string(header) == "GO1 ", nil
}

这里的 header 只参与当前函数里的比较，没有跨越下一次读操作，所以不需要复制。Peek 没有推进位置，后续调用 Read 仍然可以从 G 开始读取。

为什么下一次 Read 会改变 Peek 得到的内容

bufio.Reader 维护着一块可复用的字节缓冲区。Peek 返回其中一段切片；当后续 Read 消费数据、移动剩余字节或从底层 Reader 补充数据时，这块内部空间可能被重写。

因此，下面的代码保存的不是稳定快照：

header, _ := r.Peek(4)
_, _ = r.ReadByte()
// header 仍然可访问，但不能再把它当作“读之前的四个字节”
fmt.Println(string(header))

这不是每次都能稳定复现的“字符串变乱码”问题，而是生命周期契约：官方文档只保证返回字节到下一次读调用前有效。要跨过读取边界，复制明确的长度：

header, err := r.Peek(4)
if err != nil {
    return err
}
snapshot := bytes.Clone(header)
_, err = r.ReadByte()
if err != nil {
    return err
}
useLater(snapshot)

复制、直接使用和重新 Peek 怎么选

只做当前分支判断：直接使用

魔数、协议版本、分隔符这类短前缀通常只需要在当前函数比较。比较完成后马上继续读取，代码简单，避免一次多余分配。

要交给异步任务：复制后再交出

如果把 header 放进 channel、缓存到结构体、交给 goroutine 或保存到日志队列，使用 bytes.Clone(header)。复制的成本与头部长度成正比，通常比追查偶发数据串改便宜。

只需再次判断：重新 Peek

不需要保存历史内容时，消费数据后重新调用 Peek，让每个判断都绑定当前窗口。不要把旧切片和新 Reader 状态混在一起。

两个容易忽略的边界：短读与 ErrBufferFull

当底层输入不足以提供 n 个字节时，Peek 会返回较短切片和解释原因的错误。此时先判断 len(header)，再决定是等待更多输入还是把连接视为不完整。

如果 n 大于 Reader 的缓冲区容量，返回错误是 bufio.ErrBufferFull。这通常说明“预览长度”超过了缓冲策略，不应该靠循环 Peek 把它当成普通网络短读处理。需要读取完整大消息时，改用明确的流式协议或增大 Reader 缓冲区，而不是长期持有内部切片。

header, err := r.Peek(1024)
if errors.Is(err, bufio.ErrBufferFull) {
    return fmt.Errorf("header exceeds reader buffer: %w", err)
}
if err != nil {
    return err
}

回归检查：让切片生命周期在测试里显形

测试重点不是断言某一次内部数组一定被覆盖，而是把接口边界写进代码审查规则：Peek 结果只在下一次读前使用，跨边界的数据必须复制。可以覆盖三组行为：

• Peek 后未读取时，后续 Read 仍从相同前缀开始。
• Peek 后读取一个字节时，业务代码不再读取旧切片。
• 请求长度超过缓冲容量时，明确识别 bufio.ErrBufferFull。

如果解析器需要保留原始头部，测试应直接验证保存的是副本，而不是依赖当前 Go 版本或当前缓冲区大小下的偶然内容。

常见问题

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

不会。它只是查看接下来的字节；真正消费数据仍由后续读取操作完成。

把 Peek 返回值转成 string 还需要复制吗？

需要看生命周期。转换成 string 后得到的是独立的字符串值，适合保存；如果只是当前比较，用 bytes.Equal 可以避免不必要的转换。

Peek 返回 ErrBufferFull 时应该重试吗？

通常不应把它当网络短读重试。先检查预览长度是否设计过大，再决定增大 Reader 缓冲区或改成流式读取。

把规则收进代码评审清单

看到 Peek 时，沿着返回值往后追一遍：下一次读在哪里发生，切片是否跨函数或跨协程，长度是否可能超过缓冲容量。当前窗口内判断就直接用，跨越读取边界就复制；这两个决定比记住某次运行中“看起来没变”更可靠。