Go bufio.Reader.Discard 的部分跳过与 EOF 处理方案

bufio.Reader.Discard(n) 用来跳过输入流的前 n 个字节，但它不保证每次都能跳够。判断是否成功时，必须同时看 discarded 和 err：只有 discarded == n 且 err == nil 才表示完整跳过；如果返回数量小于 n，即使已经跳过一部分，也不能继续把后面的内容当成完整数据。

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

先把完整跳过和部分跳过分开

我在处理带固定前缀的流时，最容易误判的是“已经返回了一个整数，所以应该成功”。实际上，Discard 的第一个返回值是本次实际跳过的数量；当底层 Reader 在目标位置之前返回 EOF 或其他错误时，它会返回部分数量和错误。这个语义适合流式输入，但要求调用方不能只写一条 if err != nil。

按参数和缓存边界调用 Discard

官方文档规定，负数参数会返回 ErrNegativeCount；传入零时不读取底层 Reader，直接返回成功。若要跳过的字节已经在缓冲区内，操作可以只移动内部读取位置；如果超出当前缓存，Reader 会继续向底层读取，直到满足数量或遇到错误。

package main

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

func main() {
    reader := bufio.NewReader(bytes.NewBufferString("HEAD|payload"))

    // 只跳过已知长度的协议前缀，返回值用于确认是否真的跳够。
    discarded, err := reader.Discard(len("HEAD|"))
    if err != nil || discarded != len("HEAD|") {
        // 数量不足时不能把后续内容误认为完整 payload。
        fmt.Printf("prefix incomplete: discarded=%d err=%v\n", discarded, err)
        return
    }

    // 这里才安全读取前缀之后的业务数据。
    fmt.Println("prefix skipped")
}

不要把“当前 Buffered() 不足”直接等同于失败，因为 Discard 可能继续从底层读取。只有返回结果已经给出，才能根据数量和错误作最终判断。反过来，如果底层 Reader 很快返回 EOF，调用方也应接受“已经跳过部分字节但消息不完整”的结果。

用返回值区分 EOF 和其他读取错误

对固定长度字段而言，EOF 通常意味着输入被截断；网络连接、文件读取或自定义 Reader 返回的其他错误，则应该向上层保留。可以把这段判断封装起来，让协议解析代码只处理“完整”或“失败”两条路径：

func discardExactly(r *bufio.Reader, n int) error {
    // 先拒绝负数，避免让参数错误混入流读取逻辑。
    if n 

上面的函数使用了 fmt，完整文件中应同时导入它。若业务希望把“EOF 前刚好跳完”的特殊情况视为成功，还应根据协议定义单独处理，不能用一个泛化的忽略错误规则覆盖所有输入。

适用场景和不要使用它的边界

• 协议中已经知道字段长度，只需要丢弃前缀、填充字节或无关段落时，Discard 比先读入临时切片更直接。
• 需要检查被跳过内容时，不要丢弃；应使用 Peek 或读取到受控缓冲区后再校验。
• 长度来自不可信输入时，先限制最大值，避免一次请求驱动过大的底层读取。
• 跳过失败后不要继续复用同一个消息解析状态，先关闭、重置或丢弃当前帧，避免边界错位。

常见问题

Discard 返回的数量小于 n 时还能继续读吗？

通常不应把后续字节当作当前固定字段继续解析。先根据错误判断输入是否截断或底层失败，再由协议层决定是否丢弃整帧或重新同步。

Discard(0) 会触发底层读取吗？

不会。零值表示不需要跳过数据，直接返回；它适合在通用封装中作为无操作输入，但不能用来探测底层是否已经到 EOF。

为什么不能只判断 err == nil？

完整性还取决于实际跳过数量。固定长度操作必须确认 discarded == n，否则部分跳过后继续解析会让字段边界整体偏移。