Go's io package 中的大部分输出方法都返回(int, error)，例如io.Writer 的Write([]byte) 方法和io.WriteString(io.Writer, string) 函数。但是，一些输出方法，例如io.WriterTo 的WriteTo 方法，会返回(int64, error)。这使得在不存储中间值并将其从int 类型转换为int64 的情况下以Write 或WriteString 实现WriteTo 很不方便。造成这种差异的原因是什么？
【问题讨论】：
标签： go io output standard-library
WriteTo 复制的数据可能超过 int32 字节。
使用io.Reader 和io.Writer 接口，数据量受给定切片大小的限制，对于当前架构而言，该切片的长度受int 的限制。
【讨论】：
WriterTo 和Writer 接口的其他包的情况下，我的猜测是作者可能已经直觉到WriterTo/ReaderFrom 接口有更大的潜力来处理大量数据。跨度>
WriterTo 可能正在复制大于 2GB 的文件或类似的文件。但是，为什么不在各处使用int64 以保持一致性呢？
int，而不是在较少的情况下将所有内容都转换为int64在某些系统上可能。 Read 和 Write 中的值以切片的长度表示，通常用于对切片进行索引。换一种方式会有更多的转化。
Writer.Write() 方法的签名：
Write(p []byte) (n int, err error)
它写入 slice 的内容。引用自spec: Slice types：
切片是底层数组的连续段的描述符...
众所周知，切片有一个底层数组。再次引用Spec: Array types：
长度是数组类型的一部分；它必须计算为一个非负常数，该常数可由
int类型的值表示。
因此，数组的最大长度受int 类型的最大值的限制（32 位架构为2147483647，64 位架构为9223372036854775807）。
回到Writer.Write() 方法：因为它写入了传递的切片的内容，所以保证写入的字节数不会多于适合int 的内容。
现在WriteTo.WriteTo()方法：
WriteTo(w Writer) (n int64, err error)
没有提到切片或数组。您无法保证结果将适合 int，因此 int64 是完全合理的。
示例：BigBuffer
想象一个BigBuffer 实现，它临时将数据写入数组或切片。该实现可以管理多个数组，以便如果一个已满（例如达到最大 int），则继续另一个。现在如果这个BigBuffer实现了WriteTo接口，你调用这个方法将内容写入os.File，结果将超过最大int。
【讨论】：
WriteTo 的随机类型，用于可能具有 >31 位表示的事物（例如，表示/保存 2.01 GB 视频的类型；或愚蠢的 type Zeros int64被定义为写出那么多零的类型）。