Go 怎样读取固定长度的协议载荷

Go 读取固定长度协议载荷时，小载荷可用 io.ReadFull 填满指定长度的缓冲；需要流式写出时，可用 io.LimitedReader 限制读取范围，再检查剩余的 N。关键是：限读只保证不超过上限，不保证底层一定提供了这么多字节；只检查 io.ReadAll 或 io.Copy 的 error 是否为 nil，会漏掉提前 EOF。

这不是一个需要等待新版本的能力。标准库已经提供了组合这些语义的基础组件。对于“长度头部已经读出，接下来读取载荷”的场景，先把长度约束、完整性判断和后续帧边界分开，比手写一次 Read 更容易说明正确性。

Go 官方标准库地址：https://pkg.go.dev/io

最多读取和必须读满不是一回事

假设协议头声明本条载荷有 12 字节，连接中后面还可能跟着下一条消息。当前任务既不能把下一帧读进载荷，也不能将 7 字节后断流当成成功。这里只讨论已经确定长度后的字节读取，不设计头部编码、校验和或重连协议。

一次 Reader.Read 返回少于请求长度的数据并不一定是错误。反之，LimitedReader 到达 N 字节时，会把当前视图表现为 EOF；底层提前 EOF 也能使它结束。两种情况都可能让上层“读到结束”，所以要么选择有读满语义的函数，要么自己检查剩余额度。

小载荷先检查长度，再用 ReadFull

下面的函数接受 int64 长度，先拒绝负数和超出应用上限的值，再分配精确长度的缓冲。示例上限 1 MiB 是演示策略，不是标准库或所有协议的统一规定。调用方应按业务容量另定限制。

package payload

import (
    "fmt"
    "io"
)

const MaxPayload int64 = 1  MaxPayload {
        return nil, fmt.Errorf("载荷长度不合法: %d", size)
    }
    // 长度上限在转成 int 和分配内存之前检查。
    buf := make([]byte, int(size))
    n, err := io.ReadFull(r, buf)
    if err != nil {
        return nil, fmt.Errorf("载荷不足或读取失败，期望 %d，已读 %d: %w",
            size, n, err)
    }
    return buf, nil
}

代码放在自己的模块中即可作为 payload 包使用。成功返回时，切片长度就是声明长度。失败返回 nil 而不是半条载荷，但底层 Reader 中已读取的字节不会自动回退；错误里保留 n 用于说明进展。对于普通 EOF 情况，完全没读到所需字节会得到 io.EOF，读到一部分后结束则是 io.ErrUnexpectedEOF。其他底层错误保留原样的错误链。

size 为 0 时不需要读任何字节，应成功得到空载荷。如果协议禁止空载荷，应在长度检查里显式拒绝零值，而不是等待 ReadFull 给出协议层错误。对预期结果的这些说明来自 API 契约和示例结构，本文没有把未执行代码包装成运行日志。

流式载荷用 LimitedReader 保留剩余额度

载荷需要写入临时文件或其他 Writer 时，不必先把整个载荷放进内存。下面的函数与前一段代码放在同一个包内，复用 fmt、io 和 MaxPayload。它先保留原始复制错误，只有复制正常结束后，才判断 N 是否已经归零。

// CopyPayload 将当前载荷写到 dst，不消费后续帧。
// 调用方必须处理失败时已经写出的部分数据。
func CopyPayload(dst io.Writer, src io.Reader, size int64) (int64, error) {
    if size  MaxPayload {
        return 0, fmt.Errorf("载荷长度不合法: %d", size)
    }
    limited := &io.LimitedReader{R: src, N: size}
    written, err := io.Copy(dst, limited)
    if err != nil {
        // 保留真正的读写错误，不用截断错误覆盖它。
        return written, fmt.Errorf("复制载荷失败，已写 %d: %w", written, err)
    }
    if limited.N != 0 {
        // io.Copy 把正常 EOF 当作结束，因此必须另查剩余长度。
        return written, fmt.Errorf("载荷截断，剩余 %d: %w",
            limited.N, io.ErrUnexpectedEOF)
    }
    return written, nil
}

LimitedReader.N 表示还允许读取多少字节，而不是已经写出了多少字节。正常完成时剩余额度为 0；底层提前 EOF 时，io.Copy 可能返回 nil，但 N 仍大于 0，此时本函数将其转换为载荷截断错误。这里不需要再多读一个字节去“确认 EOF”，因为下一字节可能正是下一帧的头部。

如果 Writer 失败，N 的减少量也不能被当成可靠的落盘量：数据可能已经从输入读出，但并未全部写入目标。因此保留 io.Copy 返回的 written 和 error，不用一个笼统的“长度不符”掩盖写入失败。

和直接 Read、ReadAll、CopyN 怎样选择

若不需要展示剩余额度，CopyN 往往更简洁。本文保留 LimitedReader，是为了让“限制范围”和“判断读满”两个责任能分别看见。不要为了统一返回值，把任何非 nil 错误都强制改成 io.ErrUnexpectedEOF；超时、连接错误和磁盘写入失败都应该保留原因。

如何避免把下一帧或半成品当成成功

读取长度来自不可信输入时，先判断范围再分配。LimitedReader 本身不会提供超时，如果底层连接一直不返回数据，它也可能一直等待；网络读取期限应由连接层设置。字节额度和时间限制解决的是不同问题。

如果上层已经用 bufio.Reader 读取头部，后续载荷也要使用同一个 bufio.Reader。缓冲层可能已经预取了下一部分输入，绕过它去读原始连接会丢掉这一逻辑连续性。LimitedReader 限制的是对其 R 的读取视图，不是承诺底层网络完全没有预读。

流式函数失败时，目标 Writer 可能已有部分载荷。写文件时可使用临时目标，只有本条完整成功才由调用方提交；不能因为函数返回错误，就以为之前的写入自动撤销。若解析器决定中止当前消息，也不能直接把当前 Reader 的余下内容当成下一帧，除非协议有明确的恢复和分帧策略。

为什么不能读到真实 EOF 再结束一帧

长连接中，真实 EOF 可能意味着对端关闭，而不是一条消息结束。声明长度才是当前载荷的边界；读满后应交还控制权，不能顺手继续 ReadAll。

N 为零就能忽略 io.Copy 的错误吗

不能。剩余额度主要描述输入消耗，目标写入仍可能失败。因此示例先处理复制错误，再检查 N；成功需要两项条件同时成立。

要区分正常断流和载荷缺失吗

要按协议位置判断。尚未开始读取下一条头部时的 EOF 可能是正常关闭；已经读出非零载荷长度后出现 EOF，意味着当前消息没有完成。不要在任意阶段都把 EOF 当作正常结束。

固定长度读取最重要的判断是：范围由声明长度限定，完整性由读满结果或剩余额度确认，错误保留实际原因。这样既不会误收半条载荷，也不会为了探测结束而消费下一条消息。

官方实现参考：https://go.dev/src/io/io.go