Go bufio.Writer.ReadFrom 复制大文件时怎样处理短写

用 bufio.Writer.ReadFrom 复制大文件时，先不要把所有“读到的数据少于缓冲区”都当成短写。Reader 一次返回较少字节属于正常的短读，ReadFrom 会继续读取；真正需要重点检查的是底层 Writer 在 Flush 时是否只接收了一部分数据，以及调用方有没有检查最后一次 Flush 的错误。

稳妥的判断顺序是：先处理 ReadFrom 返回值，再处理 Flush 返回值，最后用返回的字节数和错误类型定位问题。官方文档：https://pkg.go.dev/bufio#Writer.ReadFrom

先判断 ReadFrom 实际走哪条路径

bufio.Writer.ReadFrom 实现了 io.ReaderFrom。它会先检查自己的错误状态，然后判断底层 Writer 是否也实现了 io.ReaderFrom：

• 底层 Writer 支持 io.ReaderFrom，并且缓冲区为空时，调用会把读取工作交给底层的快速路径。
• 如果 bufio.Writer 中已经有数据，先把这部分数据写出去，再决定是否委托底层 Writer。
• 没有快速路径时，ReadFrom 直接把 Reader 读入自己的缓冲区，读满后再由 Flush 写给底层 Writer。

因此，同一段业务代码在写入 bytes.Buffer、普通文件或自定义 Writer 时，底层调用次数可能不同。不要把某一种底层 Writer 的调用次数当成 ReadFrom 的通用保证；应该只依赖它返回的字节数与错误。

把短读、短写和 EOF 分成三类

排查“复制后文件变小”时，建议把现象分为三层：

特别容易误判的是 EOF。源 Reader 返回 EOF 时，ReadFrom 会把 EOF 转成成功结束；如果缓冲区恰好填满，它可能主动 Flush，否则尾部数据仍可能留在 bufio.Writer 内。因此“ReadFrom 返回 nil”并不等于“底层文件已经接收全部数据”。

最小可用写法：ReadFrom 和 Flush 都要检查

对大文件复制，调用方可以保持固定的错误出口。下面的示例不把整个文件读进内存，也不把短读误判为失败：

package main

import (
	"bufio"
	"fmt"
	"io"
	"os"
)

func copyLargeFile(dstPath, srcPath string) error {
	// 源文件只负责提供字节，关闭动作放在打开成功之后注册。
	src, err := os.Open(srcPath)
	if err != nil {
		return fmt.Errorf("打开源文件: %w", err)
	}
	defer src.Close()

	// 创建目标文件后交给 bufio.Writer，避免一次性分配大文件大小的内存。
	dst, err := os.Create(dstPath)
	if err != nil {
		return fmt.Errorf("创建目标文件: %w", err)
	}
	defer dst.Close()

	writer := bufio.NewWriterSize(dst, 256*1024)
	written, err := writer.ReadFrom(src)
	if err != nil {
		return fmt.Errorf("ReadFrom 复制 %d 字节后失败: %w", written, err)
	}

	// ReadFrom 结束时仍可能有尾部缓冲，Flush 是最终写出检查点。
	if err := writer.Flush(); err != nil {
		return fmt.Errorf("Flush 写出 %d 字节后失败: %w", written, err)
	}
	return nil
}

func main() {
	// 真实项目中应把路径来自参数或配置，并在调用处记录错误。
	if err := copyLargeFile("backup.bin", "source.bin"); err != nil {
		fmt.Println(err)
	}
}

这里的 written 是 ReadFrom 已经从 Reader 消费并计数的字节数，不要把它直接当作“磁盘已经持久化的字节数”。只有 ReadFrom 和 Flush 都成功返回，代码才完成了这一层 I/O 的写出流程。

遇到短写时，先看错误发生在哪一层

底层 Writer 的 Write 如果返回的数量小于请求数量且错误为 nil，bufio.Writer.Flush 会把结果转换为 io.ErrShortWrite，并保留尚未写出的那部分缓冲与错误状态。之后继续调用同一个 Writer，通常只会得到同一个错误，不会自动恢复。

可以按下面的顺序定位：

1. 先看 ReadFrom 的 n。如果 n 小于预期且同时有源 Reader 错误，优先检查源文件读取、网络输入或上游解压过程。
2. 再看 ReadFrom 的 err。普通 EOF 会被当作完成处理；io.ErrNoProgress 则说明 Reader 连续返回空结果，没有推进。
3. 最后单独看 Flush。如果 ReadFrom 为 nil 而 Flush 返回 io.ErrShortWrite 或底层错误，问题发生在最终写出，而不是源数据读取。
4. 不要用“目标文件存在”作成功条件。文件已经创建，只能说明打开或创建动作完成，不能证明全部字节写完。

如果 Writer 是网络连接、限流写入器或自定义存储适配器，还要检查它是否遵守 io.Writer 契约：返回的字节数不能超过输入长度；返回少量字节时应同时返回错误，或者让上层得到 io.ErrShortWrite。不符合契约的 Writer 会让任何缓冲策略都难以可靠判断。

反向验证：用结果和清单确认复制没有静默失败

正式任务中可以把成功条件写成一份很短的清单：

• 源文件打开成功，且关闭错误按项目需要记录。
• ReadFrom 返回的错误为 nil，并记录返回字节数。
• 显式调用 Flush，并把它的错误视为最终写出结果。
• 目标文件关闭或同步动作的错误按存储介质要求处理。
• 需要更强一致性时，再用文件大小、校验和或业务记录做独立比对；不要只看进度日志。

结论可以压缩成一句话：ReadFrom 负责把 Reader 的数据搬进缓冲写入链路，短读通常会继续，短写最终要在 Flush 处暴露。复制大文件时，永远同时检查 ReadFrom 和 Flush，并把错误发生的层级记录下来。

相关问题

ReadFrom 返回 nil 后还需要 Flush 吗？

需要。除非你明确知道底层快速路径已经完成全部写出，否则应显式 Flush；这样才能处理仍在 bufio 缓冲区中的尾部数据。

Reader 每次只返回几 KB 是短写吗？

不是。这属于 Reader 的短读，只要返回了正数并且后续仍能推进，ReadFrom 会继续读取。

为什么复制数量看起来正确，目标内容仍不完整？

常见原因是最后一次 Flush 失败，或者调用方只记录了 ReadFrom 的结果而忽略了 Flush。把两个错误出口分别记录即可缩小范围。