Go bufio.Reader.Discard 怎样跳过已读字节并处理短读取

在解析固定格式的输入时，我经常会先判断一段前缀，再把已经确认无用的字节消费掉。这个动作适合交给 bufio.Reader.Discard：它会跳过接下来的 n 个字节，并返回实际跳过的数量和错误。需要注意，Discard 是消费，不是预读；如果跳过数量不足，不能只看返回的 err，还要同时检查 discarded。

固定长度跳过成功的判断是 discarded == n && err == nil。当 0 时，官方保证它不会从底层 io.Reader 再读取；如果数据不足，则返回已经跳过的数量和错误。

先把问题缩小成一个固定前缀任务

假设协议输入以四个字节的 HEAD 开头，业务层已经完成前缀判断，现在只需要跳过它，让后续读取从正文开始。这里不应该用 Peek 代替，因为 Peek 只查看数据，不会推进读取位置。

用 Reader.Discard 消费固定字节

下面的小例子把输入放在内存 Reader 中，实际项目也可以把 strings.NewReader 换成文件、网络连接或其他 io.Reader。关键点是先保存要跳过的长度，再同时判断两个返回值。

package main

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

func main() {
    // 用固定前缀模拟协议头，Discard 会真正消费这四个字节。
    r := bufio.NewReader(strings.NewReader("HEADpayload"))
    const headerSize = 4

    // 返回值同时描述实际消费量和消费过程中的错误。
    discarded, err := r.Discard(headerSize)
    if err != nil || discarded != headerSize {
        fmt.Printf("跳过失败：discarded=%d err=%v\\n", discarded, err)
        return
    }

    // 前缀已被消费，后续读取从正文开始。
    body, err := r.ReadString('\\n')
    fmt.Printf("body=%q err=%v\\n", body, err)
}

这个例子中，输入没有换行符，所以最后一次 ReadString 可能带着 io.EOF 返回正文。那是后续读取到输入末尾的状态，不代表前面的 Discard(4) 失败。把每一次调用的错误和语义分开处理，排查时会清楚很多。

短读取时要看 discarded 和 err

如果请求跳过的数量大于剩余输入，Discard 会尽量消费现有字节，然后返回实际数量与错误。此时 discarded 是比错误文本更直接的证据：它说明调用没有完成目标长度。

package main

import (
    "bufio"
    "fmt"
    "io"
    "strings"
)

func skipExactly(r *bufio.Reader, n int) error {
    // 负数不是“什么也不做”，应让调用方尽早看到参数错误。
    if n 

调用方如果只写 if err == nil，容易漏掉“消费量不足但底层 Reader 暂时没有返回典型错误”的处理分支。固定头、长度字段和协议分隔区域都建议封装成类似 skipExactly 的小函数，把长度契约集中起来。

Discard、Peek、Read 和 io.ReadFull 怎么选

我自己的判断是：协议头已经验证过、又不需要保留内容时用 Discard；还要判断内容就用 Peek；需要把字节放进调用方缓冲区时用 Read 或 io.ReadFull。不要把“跳过”写成读取到临时切片再丢弃，那会让意图和内存行为都变得不清楚。

常见问题

Discard 会不会一定只操作内部缓冲区？ 不一定。只有请求数量不超过当前已缓冲字节数时，官方才保证不会读取底层 Reader；更大的请求可能继续向底层读取。

Discard 返回的字节切片在哪里？ 没有切片返回值，它只返回实际跳过数量和错误；如果还要检查内容，应先使用 Peek 或直接读取。

为什么不能用 Discard 判断协议头是否正确？ 因为它不比较内容。应先 Peek 固定长度并比较，确认后再调用 Discard 消费。

短读取时应该重试 Discard 吗？ 先根据错误和协议判断是否还能等待更多输入。对已经到达 EOF 的输入盲目重试没有意义；如果业务契约是“必须读满”，应保留实际数量并向上层返回明确错误。