IO通道与读写器的区别

Question

由于Go语言具有通道，我想知道为什么标准库似乎没有被设计成也使用它们进行IO。

相反，有读取器和写入器类型，但是使用通道会有什么问题呢？

一个函数可以返回一个字节片段的通道（假设单个字节或甚至单个位的返回太低效了），并接收一个用于取消请求的通道和一个用于错误报告的通道。

-好奇的Go新手。

- Bent Rasmussen

Answer 1

通道是在 goroutine 之间进行通信的好方法。当程序执行简单操作，例如读取 stdin，对流进行处理并将结果输出到 stdout 时，使用通道会过度设计，不必要地影响性能。

只要标准库没有在某个地方提供特定于 goroutine 之间通信的功能，就没有理由使用通道来模拟像 io.Reader 或 io.Writer 这样简单的操作，或者具有基于通道的方法集（API）。

此外，在需要的情况下，可以将简单实现包装在通道中，而相反地，“解包”通道实现回到其原始状态是不可能的。此外，Go 作者显然喜欢明确性，这导致性能瓶颈不被隐藏（并且令人惊讶）。

- zzzz

---

所以我理解你的观点有两个方面：1）在这种情况下，通道将成为性能瓶颈，2）通道会隐藏IO，设计师不喜欢这样。进行读写器与通道的性能测量将是有趣的，以了解实际性能惩罚的程度 - 当然要意识到编译器可以针对简单情况进行优化，并且随着时间的推移，优化将变得更加复杂。Rob Pike已经谈论过通道的性能优化机会。 - Bent Rasmussen

Answer 2

我认为io.Reader和io.Writer存在的另一个原因是它们在单线程级别上表现良好；通道几乎专门用于协程间通信或多线程模型。虽然有些情况下可以互换使用，但它们的设计目的是解决两个不同的挑战。 io.Reader和io.Writer还具有EOF的概念，这很难通过通道轻松复制，除非您在通道上叠加一个单独的协议-这当然只会增加负担。 P.S.关闭通道与EOF也不同，因为关闭通道会防止将来使用它。

- Ashford Nichols

Answer 3

我的这个包将io.Reader和io.Writer封装成一个通道。

换句话说，它创建了一个线程安全的缓冲区。

换句话说，它是一个通用的管道。

https://github.com/latitov/milkthisbuffer

- latitov