Go io CopyN 读到短输入时怎样区分 EOF

io.CopyN 读到短输入时，要一起看 written 和 err：对于非负目标长度，成功意味着写入数量达到目标；输入正常结束却没写够时，通常得到 io.EOF，而不是 io.ErrUnexpectedEOF。已经复制的前缀不会自动撤回。

Go 标准库入口：https://pkg.go.dev/io

CopyN 约定的是数量，不是读到末尾

CopyN 适合“从 Reader 向 Writer 复制指定字节数”的任务。它属于 Go 的 I/O 接口，不是浏览器接口，也不受浏览器兼容表影响；能否用于文件、内存或网络，取决于对象是否满足 Reader、Writer 以及它们各自的读取、写入约束。

这里的目标数记作 want，返回数记作 written。若源实际还有更多数据，CopyN 达到 want 就可以成功；它不需要额外读取一个字节来证明源已结束。因此返回成功不能解释成“整个输入都读完了”。

可以将实现理解为这些静态依赖：CopyN 关联 LimitReader、Copy、源 Reader、目标 Writer 和 written/err 返回值。LimitReader 限制这次复制可读取的字节数，Copy 负责转移数据；达到目标数量时 CopyN 返回成功。这里说明语义，不承诺特定内存分配或零拷贝效果。

先保留字节数，再判断 EOF

下面用固定字符串构造短输入，便于观察数量不足与已写入前缀之间的关系。代码为原创示例，未在本文运行。

package main

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

func main() {
    const want int64 = 6
    var dst bytes.Buffer

    // 只有3字节输入，却要求复制6字节。
    written, err := io.CopyN(&dst, strings.NewReader("cat"), want)
    switch {
    case err == nil:
        fmt.Printf("数量满足: %d\n", written)
    case errors.Is(err, io.EOF):
        // 保留数量；失败并不代表目标缓冲区没有变化。
        fmt.Printf("复制未满且返回EOF: %d/%d，前缀=%q\n",
            written, want, dst.String())
    default:
        // 其他错误原样保留，不能全部改写成EOF。
        fmt.Printf("复制失败: %d/%d，错误=%v\n", written, want, err)
    }
}

在这个内存 Reader 与 Buffer 的组合下，预期 written 为3，目标中已有 cat，错误为 EOF。它是按标准库规则推导的预期，不是实测日志。业务若要求完整6字节，应将这次操作判作失败，而不是看到 EOF 就忽略。

此表固定使用正常的内存读写对象，不能直接套到自定义 ReaderFrom 或故障 Writer 上。错误值与实现是否遵守接口约定同样重要。

短输入为何不是 ErrUnexpectedEOF

ReadFull 面向“把固定缓冲区填满”：未读到任何数据就结束时可返回 EOF，读到一部分但没填满时返回 ErrUnexpectedEOF。CopyN 的职责是向 Writer 复制指定数量，没有自动采用相同的错误分类。若习惯用 ReadFull 的经验判断 CopyN，就容易只检查 ErrUnexpectedEOF 而漏掉 EOF。

协议层可以给数量不足加上更具体的上下文，但应保留原始错误。下面的包装器定义“最多8 MiB 的单次定长复制”；上限是示例业务规则，不是 Go 标准库限制。

package fixedcopy

import (
    "fmt"
    "io"
)

func CopyFrame(dst io.Writer, src io.Reader, want int64) (int64, error) {
    // 拒绝无意义长度，并限制来自外部的长度声明。
    const maxFrame int64 = 8  maxFrame {
        return 0, fmt.Errorf("长度不在允许范围: %d", want)
    }
    written, err := io.CopyN(dst, src, want)
    if err != nil {
        // %w保留EOF或底层错误，调用方仍能用errors.Is判断。
        return written, fmt.Errorf("定长复制未完成，已写%d/%d字节: %w",
            written, want, err)
    }
    return written, nil
}

这个包装器不把所有错误改成 ErrUnexpectedEOF，也不声称 EOF 的来源一定在 Reader。如果应用确实要建立“帧截断”错误类型，应在掌握协议边界、目标写入状态后再映射；不要为了统一提示而丢掉磁盘写入、连接中断等诊断线索。

写入失败不能归类为输入不足

CopyN 的返回值不能完整标记“错误出自哪一端”。通常源短了且正常结束可见 EOF，但自定义 Writer 也可能返回 EOF；目标还可能在写入一部分后报其他错误。若要定位来源，需要由 Reader、Writer 的适配层提供带来源的业务错误或日志，不能单凭 errors.Is(err, io.EOF) 就断言源文件被截断。

标准复制路径遇到 Writer 写少却未返回错误时，会用 io.ErrShortWrite 表达短写；若目标实现 ReaderFrom，CopyN 可以通过该接口复制，目标实现也必须遵守自己的接口契约。不要假设所有 Writer 的内部缓冲、错误时机都相同。

更重要的是，written 是进度信息，不是重试指令。源 Reader 可能已经前进，目标也可能已有前缀。直接把原始 want 再交给同一对对象，会改变数据边界。是否续传需要可恢复偏移、协议设计和目标状态支持；不能靠一个循环把非空错误吞掉。

如果输出必须完整才可供下游使用，可以由业务先写入独立暂存目标，成功并完成该目标要求的 Flush、Close 等动作后再提交；失败则按业务保留或清理暂存数据。CopyN 本身不实现事务、提交、关闭资源或持久化保证。

复制完成之后仍有哪些边界

Reader 一次少读几个字节就算 EOF 吗？

不算。一次 Read 的数量小于缓冲区容量，不代表输入结束。CopyN 负责继续复制，直到达到目标或遇到错误；不要只调用一次 Read 就自己推断定长复制是否完成。

目标长度为0时会怎样？

这是一个零字节任务，可以成功而不读取源。不要利用这种调用探测源是否为空。对于负数或超过业务上限的长度，像 CopyFrame 一样在调用前拒绝，避免把无意义参数交给底层。

使用网络 Reader 会自动超时吗？

不会因为调用了 CopyN 就获得超时策略。若源既不结束也不提供足够数据，调用可能等待；应使用具体连接提供的 deadline 或由业务控制关闭。长度限制只限制数量，不限制等待时间。

err 为 nil，文件就一定完整落盘了吗？

只能说明这次复制满足数量。缓冲 Writer 可能还需要 Flush，文件 Close 也可能报错；若业务要求特定持久化语义，还需调用相应存储接口并处理其错误。资源生命周期归调用方管理。

处理 CopyN 短输入的简明规则是：先记录 want 与 written，再保留 err；不要期待自动的 ErrUnexpectedEOF 分类，不要把 EOF 当成忽略失败的许可，也不要把“已写了一部分”当成可以无条件重试。

参考：Go io.CopyN 文档；Go io 标准库实现。