Go io.CopyN 写入归档文件时如何确认目标长度

归档服务把对象流写入文件时，最容易漏掉的检查不是“文件有没有生成”，而是“文件是否真的拿到了期望的字节数”。Go 的 io.CopyN 已经给出了清晰契约：返回的 written 等于 n 且 err == nil，才表示指定长度复制完成。短源会得到 io.EOF，写端异常则保留原错误；目标文件即使已经存在，也不能因此视为成功。

先把 io.CopyN 的成功条件写成判断式

io.CopyN(dst, src, n) 会尝试复制最多 n 个字节，并返回实际写入量与最早遇到的错误。官方实现基于受限读取器；当源数据提前结束且还没有其他错误时，函数会把错误补成 io.EOF。因此归档代码不应只判断 err == nil，也不应只比较文件大小：

written, err := io.CopyN(dst, src, expected)
// written 记录实际写入量，err 记录复制期间最早出现的错误。
if err != nil || written != expected {
	return fmt.Errorf("archive copy incomplete: written=%d expected=%d err=%w", written, expected, err)
}
// 两个条件同时满足，才允许进入后续的目标文件核对。

正常返回时，written == expected 与 err == nil 是一对相互印证的信号。把它们拆开记录很有价值：日志里能看出是源数据不足、目标写失败，还是调用方把期望长度算错了。

三种返回状态不要混成一个“复制失败”

尤其要注意：目标实现可能先写入一部分内容，随后返回磁盘、权限或网络文件系统错误。此时 written 不是零，目标路径也可能已经出现，但它仍然不是可提交的归档。io.CopyN 的返回值描述的是复制事实，不负责替你回滚文件。

先写临时文件，再把长度检查变成提交门槛

归档文件最好使用同目录临时名，例如 backup.tar.tmp。同目录有利于后续重命名保持在同一文件系统内；失败分支统一关闭并删除，正式文件名只在完整复制后出现。

func writeArchive(dstPath string, src io.Reader, expected int64) error {
	tmpPath := dstPath + ".tmp"
	f, err := os.OpenFile(tmpPath, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0o600)
	if err != nil {
		return fmt.Errorf("open temp archive: %w", err) // 创建失败时没有可清理的目标。
	}
	cleanup := func() {
		_ = f.Close()       // 失败路径尽力释放文件描述符。
		_ = os.Remove(tmpPath) // 不让半截归档留在正式目录。
	}

	written, copyErr := io.CopyN(f, src, expected)
	if copyErr != nil || written != expected {
		cleanup()
		return fmt.Errorf("copy archive: written=%d expected=%d err=%w", written, expected, copyErr)
	}
	if err := f.Close(); err != nil {
		_ = os.Remove(tmpPath) // Close 也可能报告缓冲或底层写入错误。
		return fmt.Errorf("close temp archive: %w", err)
	}
	info, err := os.Stat(tmpPath)
	if err != nil || info.Size() != expected {
		_ = os.Remove(tmpPath) // 元数据不符时拒绝提交。
		return fmt.Errorf("archive size mismatch: size=%d expected=%d err=%w", infoSize(info), expected, err)
	}
	if err := os.Rename(tmpPath, dstPath); err != nil {
		_ = os.Remove(tmpPath) // 重命名失败时继续清理临时产物。
		return fmt.Errorf("commit archive: %w", err)
	}
	return nil
}

func infoSize(info os.FileInfo) int64 {
	// Stat 失败时返回 -1，避免错误日志再次解引用空接口。
	if info == nil { return -1 }
	return info.Size()
}

示例中的 infoSize 只是为了让错误信息在 Stat 失败时仍安全；生产代码也可以先分支判断 err，再访问 info.Size()。关键顺序是：复制计数判断、关闭文件、Stat 长度、最后重命名。

提交前再核对一次目标长度

written == expected 是复制层信号，Stat().Size() == expected 是文件层信号。大多数本地文件写入中两者会一致，但把两层信号都保留下来，能更早暴露目标路径、关闭阶段或存储实现异常。若归档还带校验和，可在同一个临时文件上完成校验，仍然不要提前暴露正式文件名。

期望长度来自 HTTP Content-Length、对象元数据或归档索引时，要先确认它代表的是字节数而不是字符数。未知长度的流不适合直接套用“必须等于 expected”的规则，可改用 io.Copy 后记录实际长度，或在协议层先补齐长度信息。

常见问题

io.CopyN 返回 io.EOF 时目标文件还能继续用吗？

不建议。它说明源在达到期望长度前结束，目标可能是部分文件；应删除临时文件并让上层重新获取或报告数据不完整。

written 等于 expected 但 err 不为 nil 怎么处理？

按失败处理。成功契约要求两个条件同时成立；保留原错误，检查目标写入实现和关闭阶段，不要仅凭字节数提交。

为什么不直接写正式文件名？

写入中断会留下一个看似存在但内容不全的文件。临时文件配合最后一次重命名，能让读取方只看到已通过长度检查的归档。