Go io.CopyN 读到 EOF 怎么判断：短读、字节数与错误处理

固定长度复制最容易误判的地方，不是 io.CopyN 本身，而是把“返回了若干字节”和“已经拿到完整 n 字节”当成了一回事。实际判断要同时看 written 和 err：写满目标长度时是成功，源数据提前结束时通常是 io.ErrUnexpectedEOF，底层读取失败则保留那个真实错误。

判断固定长度复制是否完整，先比较 written == n，再按 err 区分成功、短读和底层故障；不要只用 err == nil 推断数据已经符合业务长度。

先把固定长度复制的边界说清楚

假设一个上传分片协议约定每段是 8 字节，接收端调用 io.CopyN 只想从 Reader 搬运这 8 字节到 Writer。这里的“成功”不是“Writer 有过写入”，而是恰好写入 8 字节。

var dst bytes.Buffer
written, err := io.CopyN(&dst, src, 8)
if err == nil && written == 8 {
    // 这一段长度完整，可以进入下一步校验。
}

written 是实际写入的字节数。它适合做第一道边界确认：如果只搬了 5 字节，即便目标缓冲区已经有内容，也不能当成完整分片。

源数据不足时，为什么不是普通 EOF

当 Reader 在目标长度之前耗尽，io.CopyN 会把“没读满 n 字节”表达成 io.ErrUnexpectedEOF。这比单纯看 io.EOF 更有业务价值，因为调用方关心的是固定长度契约被打破。

下面的分支把完整复制、短读和其他读取错误分开。短读可以等待后续分片或标记上传不完整；其他错误则应该保留原错误，方便定位文件、连接或自定义 Reader 的问题。

func copyChunk(dst io.Writer, src io.Reader, n int64) error {
    written, err := io.CopyN(dst, src, n)
    switch {
    case err == nil && written == n:
        return nil
    case errors.Is(err, io.ErrUnexpectedEOF):
        return fmt.Errorf("chunk too short: got %d, want %d: %w", written, n, err)
    case err != nil:
        return fmt.Errorf("copy chunk: wrote %d of %d: %w", written, n, err)
    default:
        return fmt.Errorf("copy chunk: wrote %d of %d", written, n)
    }
}

图中的分支只对应这段代码里的三个稳定节点：io.CopyN 产出 written，再用 n 判断是否写满，最后把 io.ErrUnexpectedEOF 归到短读路径。没有写入完整长度时，后续校验不应继续假设数据可用。

完整复制、短读和底层错误怎么选处理策略

可以把返回值看成一条很短的决策链。Reader 提供输入，io.CopyN 按 n 限制最多复制多少，Writer 接收实际数据，最后由 err 告诉调用方复制过程是否在长度边界前中断。

• 完整复制：written == n 且 err == nil，可以进入校验或提交。
• 短读：written 且错误可由 errors.Is(err, io.ErrUnexpectedEOF) 识别，应记录实际长度。
• 其他错误：不要改写成“文件太短”，保留错误链中的原始原因。

这条数据路径解释了为什么日志里至少要保留 written、n 和 err：只记一个错误字符串，后续无法知道是源数据少了，还是 Writer 或底层 Reader 中途失败。

几个看似合理、实际会漏边界的写法

只判断 err == nil

在正常的标准实现里，写满 n 字节时确实会返回 nil，但业务代码仍建议把 written == n 写出来。这样长度契约不会被隐藏在实现细节里，换成自定义 Writer 或增加审计字段时也更容易复核。

把所有非 nil 错误都当成短读

io.ErrUnexpectedEOF 只说明固定长度没有满足。网络读取错误、文件读取权限问题或 Writer 返回的错误，应该保留错误链，不然监控会把不同故障聚成一个“分片不完整”。

复制完短数据仍然提交

短读留下的字节可能是有用的诊断样本，但它不是完整分片。提交前应再次确认实际长度，必要时丢弃临时缓冲区或等待协议层的补发。

把判断落到可验收的调用清单

1. 调用前明确 n 的单位和来源，避免把字节数与记录数混用。
2. 调用后记录 written 与 err，至少区分完整、短读和其他错误。
3. 用 errors.Is 判断 io.ErrUnexpectedEOF，不要依赖错误文本完全相等。
4. 只有 written == n 且 err == nil 时，才把结果交给下一步校验或提交。

相关问题

io.CopyN 会不会读取超过 n 字节？

它的目标是复制最多 n 字节；调用方仍应确认 Writer 的实际写入结果，并按返回值处理提前结束或底层错误。

为什么要用 errors.Is 判断 ErrUnexpectedEOF？

业务层可能给错误增加上下文，errors.Is 能沿错误链识别短读原因，比直接比较错误字符串稳妥。

总结

io.CopyN 的关键不是记住一个错误名，而是把长度、实际写入量和错误原因放在同一条判断链上。先看 written 是否达到 n，再区分 io.ErrUnexpectedEOF 与其他错误，固定长度复制的验收边界就清楚了。