Go问答：bufio.Reader Discard读取失败后怎样丢弃残留缓冲区怎样在批处理代码中减少额外分配

如果批处理代码用 bufio.Reader 读取分隔记录，某条记录解析失败后，下一次读取经常会从“失败记录的尾部”继续。此时不要为了清空状态反复创建 Reader；更稳妥的做法是先用 Buffered() 取出当前缓冲区可读字节数，再把确认属于残留记录的部分交给 Discard(n)。它返回实际丢弃数和错误，只有两者一起判断，才能知道是否真的跳过了目标范围。

官方资料：https://pkg.go.dev/bufio

• 0 时，Discard(n) 不会读取底层 io.Reader，适合清理已经进入缓冲区的残留字节。
• 如果丢弃数少于请求数，方法会同时返回错误；不要只看 err，也不要把返回的 discarded 当成请求数。
• 批处理要复用同一个 Reader；Reset 适合切换底层输入，不能代替“只跳过当前记录”的 Discard。

先把 Discard 的结果读对

Discard(n) 的语义是跳过接下来的 n 个字节，返回实际跳过的数量和错误。当前缓冲区已经有足够数据时，它只移动内部读位置，不会向底层读取；当请求超过当前缓冲区时，它会继续填充并跳过，直到完成请求或遇到错误。

package main

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

func main() {
	// 让 Reader 先把输入放入自己的缓冲区，便于观察 Buffered 和 Discard 的关系。
	r := bufio.NewReaderSize(strings.NewReader("bad-record|next-record"), 32)
	// 只丢弃已经确认属于失败记录的 11 个字节，分隔符是否包含在内要由协议决定。
	discarded, err := r.Discard(len("bad-record|"))
	if err != nil {
		// 丢弃不足时保留实际数量，避免把下一轮输入误当成完整记录。
		fmt.Printf("discarded=%d err=%v\\n", discarded, err)
		return
	}
	// 成功后再读取下一条记录，避免重复创建 bufio.Reader。
	line, err := r.ReadString('|')
	fmt.Printf("discarded=%d buffered=%d next=%q err=%v\\n", discarded, r.Buffered(), line, err)
}

这里的关键不是“调用了 Discard”，而是先定义记录边界。若失败记录的长度尚未确定，就不能凭感觉丢掉一段固定字节；应该继续寻找分隔符，或让上层协议提供可计算的长度。

读取失败后怎样清理残留缓冲

最容易混淆的是 ReadString 或 ReadSlice 已经返回部分数据和错误。以 io.EOF 为例，EOF 说明底层输入结束，不表示缓冲区中不存在已读到的部分；而 ErrBufferFull 表示分隔符未在当前缓冲区内找到。清理前要先判断这次失败属于哪一个记录边界。

func dropFailedRecord(r *bufio.Reader, delimiter byte) error {
	// Buffered 只报告当前内部缓冲区仍可读的字节数，不会额外读取输入。
	buffered := r.Buffered()
	if buffered == 0 {
		// 没有残留数据时不调用 Discard，直接让调用方处理底层错误或 EOF。
		return nil
	}
	// 这里只能丢弃已经确认属于失败记录的范围，delimiter 由协议层决定是否计入。
	discarded, err := r.Discard(buffered)
	if err != nil {
		return fmt.Errorf("discard %d bytes: %w", discarded, err)
	}
	return nil
}

上面的示例表达的是“清空当前缓冲区”，因此只适合确认缓冲区剩余内容都属于当前失败记录的场景。若缓冲区后面已经包含下一条记录，应该传入精确的边界长度，不能无条件使用 Buffered()。另外，示例中的 fmt.Errorf 需要在完整程序中导入 fmt；正文只保留核心函数，避免用不完整代码伪装成可直接运行的工程。

批处理怎样减少额外分配

批处理的优化重点是复用 Reader 和固定工作缓冲，而不是把每次 Discard 都理解成一次内存分配。标准库的 Discard 主要移动内部索引；真正容易制造分配的是循环里重复创建 bytes.Buffer、把片段转换成新字符串，或为了跳过记录而复制整段数据。

func processBatch(src io.Reader) error {
	// Reader 只创建一次，后续记录都共享同一个内部缓冲区。
	r := bufio.NewReaderSize(src, 64*1024)
	for {
		line, err := r.ReadSlice('\n')
		if len(line) > 0 {
			if parseErr := handleRecord(line); parseErr != nil {
				// 解析失败时只跳过当前已确认的残留，不复制整条记录。
				if _, discardErr := r.Discard(r.Buffered()); discardErr != nil {
					return discardErr
				}
			}
		}
		if err != nil {
			// EOF 可能伴随最后一段无换行文本，先处理数据，再结束循环。
			if errors.Is(err, io.EOF) {
				return nil
			}
			return err
		}
	}
}

生产代码里，handleRecord 应该明确它是否会在下一次读取前保存 line。ReadSlice 返回的切片指向 Reader 内部缓冲，下一次读可能覆盖它；如果要跨轮次保存，才在确定需要时复制。这样才能把“减少额外分配”和“数据生命周期安全”同时保住。

Discard、Reset 和重新创建 Reader 怎么选

负数参数会返回 bufio.ErrNegativeCount；丢弃超出可用输入的范围时，返回的数量可能小于请求数并伴随错误。Discard 之后也不能依赖 UnreadByte 回退，因为官方文档明确把 Discard 视为会使最近一次可回退状态失效的操作。

bufio.Reader Discard 常见问题

Discard 会不会把底层数据全部读进内存？

不会按“全部输入”读入内存。它只在请求量超过当前缓冲时继续填充并跳过；如果请求量不超过 Buffered()，官方保证不会读取底层 Reader。

为什么返回了 discarded 还要看 err？

因为底层输入可能在完成请求前返回 EOF 或其他错误。discarded 只能说明已经跳过了多少字节，不能证明目标长度已经完整跳过。

清理失败记录时直接 Discard(Buffered()) 可以吗？

只有当当前缓冲区的全部剩余内容都属于失败记录时才可以。若其中混有下一条记录，必须按协议边界计算长度，否则会把有效数据一起丢掉。

怎样进一步减少分配？

复用一个 Reader，尽量使用内部切片完成当轮处理；只有需要跨轮次保存时才复制。不要为了跳过数据先构造一个同样大小的临时切片。