【发布时间】：2013-08-30 08:36:05
【问题描述】：
go.net/websocket 包具有Read() 和Write() 函数，用于通过网络套接字发送和接收消息。为什么它不返回用于发送和接收消息的通道？我觉得像websocket、net 这样的包是使用 go 频道的理想场所。这个设计决策背后的原因是什么？
【问题讨论】：
标签： concurrency websocket go
【发布时间】：2013-08-30 08:36:05
【问题描述】：
我不知道 WebSockets 的确切语义，但总的来说，我认为网络套接字不能很好地映射到通道中。 There was actually a netchan package 尝试在一般频道上执行此操作，但已停止。
我认为尝试通过一个通道实现来支持大量协议会遇到很多问题。消息在哪里开始和结束？通道应该缓冲一个大消息，还是一个块一个块地给它，等等？每个协议的语义差异太大，因此 Go 为您提供了较低级别的套接字读/写，就像您在其他语言中找到的一样，并让您决定如何处理数据。
请注意，我说的是一般的套接字通道。 WebSocket 是一个定义良好的协议，使用通道的实现可能可以很好地工作。至于为什么没有选择频道，最好问问go.net/websocket的作者（试试golang-nuts谷歌群）。我认为这在某种程度上是有道理的，因为它现在的 API 类似于常规的 Go 套接字 API。
请注意，不使用通道不会使 API 非并发。只要连接是在单独的 goroutines 上处理的（它们就是 Go 的 HTTP 服务器），它们就会被同时处理。是否使用频道在这里只是方便的问题。
【讨论】：