Go bufio.Reader.Discard 返回跳过字节数不足时怎样判断 EOF

使用 bufio.Reader.Discard 跳过协议头、填充字节或无用字段时，不能只看返回的 error。真正需要同时判断的是 discarded 和 err：当 discarded == n 时，目标字节已经全部跳过；当 discarded 时，即使读到了一部分数据，也只能说明输入在目标位置之前结束或底层读取提前失败。

判断是否完整跳过的核心条件是 discarded == n。请求跳过 20 字节却只得到 12 字节和 io.EOF，应当把它当作截断输入处理，而不是当作“已经跳过成功”。

先把“跳过失败”的现场拆开

假设一个二进制记录的固定头部后面还有 20 字节暂时不用的数据。调用 Discard(20) 时，Reader 会返回实际跳过的字节数和错误：

package main

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

func main() {
	// 输入只有 12 字节，却要求跳过 20 字节，用来模拟截断记录。
	r := bufio.NewReader(bytes.NewReader(bytes.Repeat([]byte{'x'}, 12)))
	discarded, err := r.Discard(20)

	// 先比较数量，再解释错误；数量不足意味着目标边界没有到达。
	fmt.Printf("discarded=%d, err=%v, complete=%v\n", discarded, err, discarded == 20)
	if discarded 

这里最重要的证据不是某一条错误字符串，而是返回数量。io.EOF 只描述底层输入已经没有更多数据；它不能把已经返回的 12 字节自动补成请求的 20 字节。

完整跳过与部分跳过要分成两条分支

Discard(n) 的返回值可以按下面的方式解释：

不要把 err == nil 写成唯一成功条件，也不要把任何非空错误都简单转换为“没有数据”。对于这类定长跳过操作，数量是否达到目标边界才是记录能否继续解析的第一判断。

Buffered 边界解释了为什么有时不会触碰底层 Reader

官方文档明确说明：当 0 时，Discard 可以直接从缓冲区移动读指针，保证成功且不会读取底层 io.Reader。当请求数量超过当前缓冲区时，Reader 才可能继续向底层取数据，直到完成跳过或遇到错误。

这会造成一个容易误判的现场：同一段代码在已经预读足够数据时返回 nil，换成更短的网络输入后却返回 io.EOF。差异不在 Discard 的成功语义，而在于第二次调用必须继续向底层索取数据。

把判断封装成不会吞掉截断信息的函数

如果业务只需要“完整跳过”这个结果，可以封装一个小函数，但不要丢失底层错误。下面的返回值约定是：完整完成返回 nil；数量不足时返回带上下文的错误。

package skip

import (
	"bufio"
	"errors"
	"fmt"
	"io"
)

// SkipExactly 跳过 n 个字节；数量不足时返回可继续判断的错误。
func SkipExactly(r *bufio.Reader, n int) error {
	discarded, err := r.Discard(n)
	if discarded == n {
		// 已到达目标边界；某些 Reader 可能同时带回尾部错误，不能覆盖它。
		return err
	}
	if err == nil {
		// 数量不足本身已经表示失败，避免返回一个误导性的 nil。
		return fmt.Errorf("skip %d bytes: discarded %d", n, discarded)
	}
	if errors.Is(err, io.EOF) {
		// 用 %w 保留 EOF，调用方仍可用 errors.Is 判断截断。
		return fmt.Errorf("skip %d bytes: input truncated after %d bytes: %w", n, discarded, err)
	}
	return fmt.Errorf("skip %d bytes after %d bytes: %w", n, discarded, err)
}

在这个封装里，discarded == n 才表示跳过动作本身完成。如果底层实现同时返回了错误，函数保留该错误，让上层决定是否把它当作记录尾部信号；如果数量不足，则无论错误是不是 io.EOF，都不会继续解析下一字段。

批处理代码里最容易漏掉的三个复查点

• 把请求长度和实际跳过长度一起写入日志，例如 skip=20 discarded=12，不要只记录错误文本。
• 把 io.EOF 与其他读取错误分开统计；前者通常说明输入不完整，后者可能是连接、文件或自定义 Reader 故障。
• Discard 失败后不要假设记录已经移动到下一个字段。若协议允许重试，应保留当前记录边界；若不允许重试，应丢弃当前记录而不是继续解码。

可以把这三个字段放进一次结构化日志：请求跳过数、实际跳过数、错误类型。这样排查“偶发 EOF”时，先能判断是输入确实变短，还是底层 Reader 在中途返回了其他错误。

最后的判断口诀

Discard 不是“调用后没有错误就算成功”的 API，而是一个带有进度信息的定长跳过操作。先看 discarded 是否等于请求值，再用 errors.Is(err, io.EOF) 区分输入提前结束，最后决定当前记录是继续、标记截断还是终止处理。只要守住数量边界，就不会把半条记录误当成完整数据。

相关问题

• Discard 和 Read 的区别是什么？Discard 不把跳过内容交给调用方，而是推进 Reader 的读取位置；它仍然返回实际进度和错误。
• 为什么 Buffered 范围内更容易返回 nil？因为数据已经在缓冲区内，Reader 可以只移动内部位置，不必再次访问底层输入。
• 遇到 EOF 后能继续读吗？是否继续取决于底层 Reader 和协议；对于定长字段，数量不足时当前记录已经不完整，不应直接按成功路径解析。