Go io.LimitReader 怎样处理可选字段

读取二进制协议里的可选字段时，先读取存在标记，再读取字段长度，最后用 io.LimitReader 包住当前输入。这样即使字段内容异常，也不会让本次读取无限制地吞掉后续字段。需要注意的是，LimitReader 只负责把最多可读的字节数限制为 N，它不会自动告诉你“数据是否真的凑够了”；要判断字段是否截断，应继续配合 io.ReadFull。

可选字段不存在时直接返回；字段存在时先检查声明长度，再用 io.LimitReader 限定范围，并用 io.ReadFull 验证实际字节数。正常结束、长度超限和输入截断要分别处理。

官方地址：https://pkg.go.dev/io#LimitReader

下面用一个简单的消息格式演示：第一个字节是是否存在，接着两个字节是大端长度，后面才是可选内容。示例只讨论字段边界，不把它扩展成完整协议实现。

先把可选字段的输入边界说清楚

假设消息中的可选字段采用下面的布局。存在标记为 0 时，字段没有内容；标记为 1 时，后面必须跟一个长度和对应数量的字节。

这类格式最容易出现两个问题：字段不存在时仍然尝试读取长度，以及字段声明长度过大时直接把输入当成普通流读取。前者会把后续字段误当成当前字段，后者则会放大恶意或损坏输入的影响。

io.LimitReader 负责限制本次最多读取多少

io.LimitReader(r, n) 返回一个新的 Reader。它从底层读取器 r 获取数据，但最多返回 n 个字节；达到上限后，受限读取器表现为读到末尾。这个行为适合把一个大输入切出当前字段的边界。

limited := io.LimitReader(src, int64(fieldLen))

// limited 最多暴露 fieldLen 个字节，后续字段不会被这次读取直接消费。
buf, err := io.ReadAll(limited)
if err != nil {
	// 真实服务中按协议错误或连接错误记录上下文。
	return nil, err
}

但是，如果底层只有 5 个字节而长度前缀写的是 8，io.ReadAll 可能把已经读到的 5 个字节和一个正常结束状态交给调用方。若协议要求“必须完整拥有 8 个字节”，仅靠 ReadAll 就不够，需要预先分配固定长度缓冲区，再调用 io.ReadFull。

用 io.ReadFull 判断字段是否被截断

下面的解析函数先处理存在标记，再读取大端长度，并拒绝超过业务上限的字段。对实际内容使用 io.LimitReader，同时用 io.ReadFull 要求它填满目标缓冲区。这样可以区分“字段不存在”“字段完整”和“输入提前结束”。

package main

import (
	"encoding/binary"
	"errors"
	"fmt"
	"io"
	"strings"
)

const maxOptionalLen = 128

func readOptionalField(src io.Reader) ([]byte, error) {
	var present [1]byte
	if _, err := io.ReadFull(src, present[:]); err != nil {
		// 连存在标记都不完整，说明消息头已经截断。
		return nil, fmt.Errorf("读取可选字段标记: %w", err)
	}
	if present[0] == 0 {
		// 标记为 0 时不再读取长度，后续字节留给下一个字段。
		return nil, nil
	}
	if present[0] != 1 {
		return nil, fmt.Errorf("未知的可选字段标记 %d", present[0])
	}

	var lengthBytes [2]byte
	if _, err := io.ReadFull(src, lengthBytes[:]); err != nil {
		// 长度前缀不完整时，不能猜测字段大小。
		return nil, fmt.Errorf("读取可选字段长度: %w", err)
	}
	fieldLen := int(binary.BigEndian.Uint16(lengthBytes[:]))
	if fieldLen > maxOptionalLen {
		// 先拒绝超限长度，避免为异常输入分配过大的缓冲区。
		return nil, fmt.Errorf("可选字段长度 %d 超过上限 %d", fieldLen, maxOptionalLen)
	}

	limited := io.LimitReader(src, int64(fieldLen))
	buf := make([]byte, fieldLen)
	if _, err := io.ReadFull(limited, buf); err != nil {
		// ErrUnexpectedEOF 表示声明长度大于实际剩余数据。
		return nil, fmt.Errorf("读取可选字段内容: %w", err)
	}
	return buf, nil
}

func main() {
	field, err := readOptionalField(strings.NewReader("\x01\x00\x05hello"))
	if err != nil {
		if errors.Is(err, io.ErrUnexpectedEOF) {
			fmt.Println("可选字段被截断")
		}
		return
	}
	fmt.Printf("field=%q\\n", field)
}

代码里 fieldLen == 0 也会安全工作：创建零长度缓冲区后，io.ReadFull 立即返回，字段结果是空切片。若业务要区分“存在但为空”和“不存在”，应同时保留存在标记，不要只依赖返回的切片长度。

为什么不能只用 ReadAll 判断完整性

io.ReadAll(io.LimitReader(src, n)) 适合“最多读取 n 字节，剩多少取多少”的场景，例如截取预览、限制日志片段或读取非固定长度的可选尾部。但长度前缀协议通常表达的是“后面必须有 n 字节”，这时必须把完整性当成协议条件。

处理后续字段时要保留消费位置

可选字段解析完成后，底层读取位置应该刚好停在下一个字段的起点。标记为 0 时，函数只消费一个标记字节；标记为 1 时，再消费两个长度字节和声明的内容。不要为了“确认没有更多数据”额外读取一个字节，否则可能提前吞掉后续字段。

如果协议还需要校验字段后是否有固定结束符，可以把结束符作为下一层解析器的职责；当前函数只负责可选字段自己的边界。职责拆开后，LimitReader 的限制范围更容易和协议文档对应。

常见问题

io.LimitReader 会在长度不足时自动返回错误吗？

不会。它只把最多可读字节数限制为 N。如果业务要求固定长度完整到达，应使用 io.ReadFull 检查实际读取数量和错误。

字段不存在时还要创建 LimitReader 吗？

不需要。先读取存在标记，标记表示不存在就直接返回，避免把后续字段的长度字节误当成当前字段。

长度前缀很大时可以直接交给 LimitReader 吗？

不建议。先做业务上限检查，再创建缓冲区和受限读取器；限制读取范围不能替代对内存分配和协议长度的控制。

ReadFull 为什么比 ReadAll 更适合这个例子？

因为示例的长度前缀表示“必须有这么多字节”。ReadFull 会要求目标缓冲区填满，输入提前结束时能够暴露 io.ErrUnexpectedEOF。