既然围棋有通道，我想知道为什么标准库似乎没有被设计成也使用它们来进行IO。
有阅读器和写入器类型来代替，但是使用通道会有什么问题呢？
一个函数可以返回一个字节片的通道（假设单字节，甚至是单比特的返回效率太低），并接收一个用于取消请求的通道和一个用于错误报告的通道。
-好奇的Go新手。
通道很适合在goroutine之间进行通信。当一个程序做一些简单的事情时，比如说读取stdin，对流做一些事情，然后把结果输出到stdout--那么使用通道就是矫枉过正了，不必要地损害了性能。
只要标准库没有在某些地方提供一些特定的goroutines相互通信的东西，就没有很好的理由对简单的操作进行建模，比如像那些 io.Reader 或 io.Writer 使用通道，各自拥有一个基于通道的方法集（API）。
此外，在需要的地方，可以将简单的实现包装在通道中，而反过来，要将通道实现 "解包 "回其基元是不可能的。另外，Go的作者显然喜欢explicitness，导致性能瓶颈无法被隐藏（而且令人惊讶）。
我认为还有一个原因 io.Reader 和 io.Writer 存在的原因是它们在单线程层面发挥得很好；通道几乎只用于goroutine间的通信，或多线程模型。在有些情况下，你可能可以互换使用它们，但它们的设计是为了解决2个不同的挑战。io.Reader 和 io.Writer 也有EOF的概念，而EOF是不容易用信道复制的，除非你在信道上加了一个单独的协议--当然这只是一种矫枉过正的做法.P.S.关闭信道也不等于EOF，因为关闭信道就无法在未来使用它。