避免使用io.ReadAll的原因是什么？

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《避免使用io.ReadAll的原因是什么？》，文章讲解的知识点主要包括，如果你对Golang方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

我读过一些关于避免 io.readall 并更喜欢 io.copy 的文章。他们主要通过提到 io.readall 将整个 []byte 从读取器加载到内存中，而 io.copy 有一个用于读取数据的固定缓冲区来证明这一建议的合理性。但问题是：

假设我正在读取 io.readcloser 类型的 http 响应正文。假设输出不是 json 格式，而是原始二进制响应。有两种方式读取内容

var buffer bytes.Buffer 
_, err := io.Copy(&buffer, res.Body) 
// assuming we checked for error
return buffer.Bytes()
--
bytes, err := io.ReadAll(res.Body)
// assuming we checked for error
return bytes

现在两者有什么区别。我相信，由于我返回读取的字节，因此这两种方法是相同的。我想知道在这种情况下 io.copy 方法是否比其他方法有任何优势。

正确答案

这不是一个答案，因为我更喜欢 readall 而不是 copy，而是一个扩展评论。

我创建了 16 mib（16777216 字节）sample.txt 文件并将其用于基准测试：

func benchmarkreadall(b *testing.b) {
    for i := 0; i < b.n; i++ {
        in, _ := os.open("sample.txt")
        io.readall(in)
        in.close()
    }
}

func benchmarkcopy(b *testing.b) {
    for i := 0; i < b.n; i++ {
        buf := &bytes.buffer{}
        in, _ := os.open("sample.txt")
        io.copy(buf, in)
        in.close()
    }
}

输出：

goos: linux
goarch: amd64
pkg: example.org
cpu: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
BenchmarkReadAll-32           26      45445764 ns/op    102635996 B/op        43 allocs/op
BenchmarkXxx-32               48      23985133 ns/op    67108544 B/op         21 allocs/op

readall 具有更多分配，因此在重新分配中消耗更多内存：要读取 16 mib，它会来回分配/重新分配 102 mb，与 copy 相比多出 50%。

我仍然更喜欢 readall，因为它的名称不言自明。在小文件上，更好的名称胜过较差的性能。

到这里，我们也就讲完了《避免使用io.ReadAll的原因是什么？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！