Go io.LimitedReader 读满后如何复用：剩余字节与 EOF 判断的边界

处理固定长度帧时，io.LimitedReader 很容易被误读成“读到上限就结束”。实际上，N == 0 只说明这一层配额用完，底层输入可能还有下一帧；只有读取结果明确给出 io.EOF，才能把它当作输入结束来处理。

为什么读满上限不代表输入已经结束

假设一条输入由“长度为 5 的帧 + 下一段数据”组成。把同一个 io.LimitedReader 读到 N == 0 后，最多只能得出“这一帧的预算用完了”。如果继续拿它读，结果会是 0, nil；这不是底层流发出的 EOF，而是限制器主动挡住了读取。

limited := &io.LimitedReader{R: src, N: 5}
buf, err := io.ReadAll(limited)
fmt.Println(string(buf), limited.N, err)

这段代码适合读取一段已知上限的数据，但不适合用 N == 0 判断连接是否结束。两种状态要分开记录：remaining 是本段还剩多少配额，EOF 才是底层输入的结束信号。

用 N 和读取结果拆开固定长度帧

读取固定长度帧时，可以把“帧长”作为一次解析的边界，先创建 io.LimitedReader，再通过读取字节数检查是否完整。下面的 readFrame 只负责当前帧，调用方仍然持有原始输入 src，所以帧后的字节不会被当成当前结果。

func readFrame(src io.Reader, size int64) ([]byte, error) {
    limited := &io.LimitedReader{R: src, N: size}
    data, err := io.ReadAll(limited)
    if err != nil {
        return nil, err
    }
    if limited.N != 0 {
        return nil, io.ErrUnexpectedEOF
    }
    return data, nil
}

这里的判断顺序很重要：底层读取先处理真实错误，读取成功后再看 N。如果输入提前结束，io.ReadAll 通常会把短读表现为成功返回但数据不足，因此用剩余的 N 把它转换成明确的 io.ErrUnexpectedEOF。

连续帧解析时怎样保留下一段输入

连续解析的关键是“每帧一个限制器”。第一帧读完后，原始 src 的读取位置已经停在下一帧开头；下一轮用新的长度创建新的 LimitedReader，不要复用已经归零的对象。

如果协议要求每一帧都必须完整，短读应立即停止，并把已经读出的数据丢弃或交给上层恢复逻辑。不要继续读取下一帧，否则错误会被推迟到更难定位的位置。

三个边界用例值得放进测试

输入刚好等于帧长

N 应归零，返回数据长度等于帧长，下一次解析应从新的输入位置开始。

输入比帧长短

N 保持大于零，调用方应得到 io.ErrUnexpectedEOF，而不是把半帧当成有效结果。

输入包含两帧

第一轮只能取走第一帧，第二轮使用新的 LimitedReader 后才能读到第二帧；这能检验是否错误复用了已耗尽的限制器。

常见问题

io.LimitedReader 能判断网络连接关闭吗？

不能单靠 N 判断。它只约束本次读取的最大数量，连接是否关闭仍要看底层读取结果和协议状态。

为什么不直接比较返回字节数和 size？

字节数能说明本次拿到了多少，但 N 能直接说明限制层是否还欠数据；两者结合更容易区分完整帧和提前结束。

读取下一帧要重建限制器吗？

要。每个限制器都绑定一段独立预算，上一帧读完后重建对象，底层 src 仍可继续向后读取。

把配额耗尽和输入结束分开处理

io.LimitedReader 适合把协议边界落实到读取路径，但它不会替调用方完成协议状态机。记录 N、保留底层读取结果、按帧重建限制器，再用短读测试验证，才能避免把半帧、尾部数据和真正 EOF 混在一起。