Go io.CopyN 怎样判断源数据不足

Go 里用 io.CopyN 复制固定长度数据时，不能只看返回的错误类型。判断源数据是否不足，应该同时看 written 和 err：只有 written == n 且 err == nil 才表示目标长度完整复制；如果 written ，说明复制没有达到要求的字节数，再用 errors.Is(err, io.EOF) 区分“源数据提前结束”和其他 I/O 错误。

官方文档：https://pkg.go.dev/io#CopyN

把 io.CopyN(dst, src, n) 当成“最多复制 n 字节”的调用是不够准确的。它的核心契约是：返回的 written 记录实际复制量，written == n 当且仅当 err == nil；因此源数据不足时，先判断数量，再判断错误。

CopyN 的成功条件是数量和错误同时满足

io.CopyN 接收目标写入器、源读取器和目标字节数 n，返回实际写入的 written 与最早遇到的错误 err。固定长度复制的成功条件可以写成一条简单规则：

先用 written 确认源数据有没有少

当调用方要求复制 n 个字节时，written 是最直接的数量证据。即使源读取器一次返回了部分数据，复制过程仍可能把这些数据写入目标，所以不能因为第一次读没有拿满就自行判定失败；要等 CopyN 返回后再比较总量。

package main

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

func main() {
	src := bytes.NewReader([]byte("short"))
	var dst bytes.Buffer

	// 目标是复制 10 个字节，但源数据只有 5 个字节。
	written, err := io.CopyN(&dst, src, 10)
	// 先打印数量，再结合 err 判断是否完成目标长度。
	fmt.Printf("written=%d, err=%v, data=%q\n", written, err, dst.String())
	if written 

这个例子里，目标缓冲区可能已经写入了部分内容，但这部分内容不等于“完整消息”。如果协议要求固定长度帧，调用方应把它当成不完整帧；如果业务允许短输入，则可以根据 written 保存或继续拼接。

用 errors.Is 区分源结束和其他 I/O 错误

源数据不足通常会表现为 io.EOF，但错误可能被包装，所以不要只写 err == io.EOF。使用 errors.Is 可以保留包装错误的判断能力，同时仍然把真正的读取故障交给上层处理。

package main

import (
	"bytes"
	"errors"
	"fmt"
	"io"
)

func copyFixed(dst io.Writer, src io.Reader, n int64) error {
	written, err := io.CopyN(dst, src, n)
	if err == nil && written == n {
		// 数量和错误都符合契约，固定长度复制完成。
		return nil
	}
	if written 

如果源读取器确实在目标长度前结束，用 io.ErrUnexpectedEOF 表达“内容比预期短”会比直接返回裸 io.EOF 更适合上层判断。示例只把源结束转换为短输入；其他错误仍保留原始错误链。

不要把目标端写失败误判成源数据不足

written 只说明没有完成目标长度，不单独说明原因。目标写入器可能在写入过程中失败，或者只接受了部分数据并返回错误。调用方应先检查 err 是否为 EOF，再决定是短输入还是底层 I/O 故障。

在网络连接、文件或管道场景中，错误上下文很重要。建议保留请求编号、文件名或消息类型等业务字段，但不要覆盖原始错误，否则上层无法使用 errors.Is 或 errors.As 继续判断。

零长度和部分结果怎样处理

固定长度复制前，先明确 n 的业务含义。n == 0 通常表示无需复制；负数则不应被当作有效目标长度传入。对于协议帧或文件头，短输入应该尽早返回；对于可选尾部，才可以把短输入转为正常分支。

• 固定长度协议：written 就拒绝当前帧，并保留 io.ErrUnexpectedEOF 语义。
• 可选数据：明确约定 EOF 是正常结束，不能把所有非空错误都忽略。
• 目标写入失败：优先保留原错误，避免日志只写“源数据不足”。
• 部分结果可复用：只有业务允许时才继续使用目标缓冲区中已写入的数据。

一段可直接套用的判断清单

1. 调用前确认 n 是目标字节数，而不是缓冲区容量或元素个数。
2. 调用后先读取 written，判断是否达到 n。
3. 当 written 时，用 errors.Is(err, io.EOF) 判断是否为源提前结束。
4. 保留其他 I/O 错误的原始错误链，并在上层补充资源或请求上下文。
5. 只有数量满足、错误为空时，才把目标内容交给固定长度协议的后续解析器。

相关问题

io.CopyN 返回 err == nil 就一定复制够了吗？

按 io.CopyN 的契约，成功返回时 written == n 且 err == nil。工程代码仍建议把数量判断写出来，让固定长度意图更清晰。

源数据不足时应该检查 io.EOF 还是 io.ErrUnexpectedEOF？

判断 CopyN 的直接返回值时先识别源读取结束；向上层表达“固定长度没有读满”时可以返回或包装 io.ErrUnexpectedEOF，这样更符合协议解析语义。

io.CopyN 会自动回滚已经写入目标的数据吗？

不会。目标写入器已经接受的数据不会因为后续返回错误而自动撤销；需要回滚时，应使用支持回滚的业务缓冲层或临时文件策略。

总结来说，判断 io.CopyN 是否遇到源数据不足，核心不是猜测读取器内部发生了什么，而是按返回契约组合判断：比较 written 与 n，再用 errors.Is 区分 EOF 和其他错误。这样既不会把部分结果误当完整数据，也不会把目标端故障隐藏成短输入。