感觉 Go 圈造 WS 库的积极程度有种 JS 圈造前端框架的劲头
github.com/gorilla/websocket
github.com/gobwas/ws
github.com/coder/websocket
github.com/olahol/melody
github.com/lxzan/gws
github.com/lesismal/nbio
...
这有必要这么多轮子吗？还是每个都解决了什么特殊问题。
一直觉得 Go 标准库很强大，为什么却不好好维护一个 WS 啊？

这么多轮子最少的 star 还有 1.5k ，不太理解。。。

造轮子跟开发者个人想法有关，跟整个生态关系不大。有的人觉得现有的不好用，有的人觉得现有的性能不足，有的人想锻炼自己。。etc

还行吧，ws 不是很大的 framework ，甚至可以说是 lib 库，常用的多几个选择不好么。

因为用 golang 实现 websocket 协议比较容易，同时应用需求又很旺盛，所以同时有很多实现。

因为简单，和 json 库一样。

难点的、像用户态网络栈就 gvisor 可用

按照协议分层来讲，其他是实现 websocket 协议，melody 是基于 gorilla 之上的对 websocket 的封装，使用上方便些。

按照为了解决的问题分类，gobwas/ws 和 nbio 是为了海量连接数的场景，为了解决标准库方案在高承载量场景下的内存 OOM 和 GC STW 问题、节约更多硬件成本、让服务更稳定。
但 gobwas/ws 本身的设计和实现是存在缺陷的，因为它的 IO 接口仍然是阻塞的，所以 IO 循环中如果有 1 个或多个慢连接就会导致其他连接也跟着排队，个别欧洲团队用它做内网还凑合、因为内网爆这种问题少，但公网没那么稳定，所以非常不适合用于公网商业项目、属于冒险行为。nbio 没这个问题。

coder/websocket 号称很多优化很快，但实测、跟其他基于标准库连接的方案相比，算是性能最拉垮的了

相关内容和测试：
www.hesudu.com/t/945827
github.com/lesismal/go-websocket-benchmark

BTW ，gorilla 被用的最广，但涉及到广播的，仍然需要自己封装，要注意避免循环中的阻塞，这通常需要自己封装额外的写协程，就是这个地方，我见过很多人实现的有问题，比如实现的不好导致僵尸连接

第一个 websocket 的库应用最广，但是有一段时间宣布因为没有维护者归档了一段时间，很多人估计有迁移过
其他的没用过了

gorilla 之前看了好像停更了

是的、当初好像是 archive 了一段时间，然后 fasthttp 和字节家都 fork 了分支，但后来 gorilla 又活了

感谢科普！

就我自己用官方的自带库？

算是 go 的一个问题（发展阶段必经之路），百花齐放，但都不太好用（或者说没有压倒性的优势）。
http 框架更多

或许这是好的现象，但确实不利于项目选型，用着用着就不维护了

国内 gin 最多?

1.ws 难度不大
2.没有更好的项目混经验，拿 ws 刷经验值

Set 的实现也一大堆

那不一定，看用户数还是 服务数 字节是自己的 hertz （也开源了）

http 我用自带库感觉挺好用的倒是，不复杂的需求都够用了。我一直觉得 go 标准库的文档写得特别好。

我一直以来写 Go 都是优先官方库，但是看文档发现他们自己说不建议用 pkg.go.dev/golang.org/x/[email&＃160;protected]/websocket 然后他们推荐了一个库感觉维护得更一般。。 github.com/coder/websocket

＃18 自带库没问题，但主要是没有规范化 容易每个项目自己封装。比如发起 http 请求，有人为了方便封装个 post json ，但突然要传文件 又封装个 post file

还有一个场景就是基础库一般都性能拉胯，json 这个就很明显

怎么说呢, 比如我从 JAVA 生态迁过来后，发现很多库都没有，就会自己写。
主要还是因为 go 写库太方便了，于是大家都开始造轮子

多就是好, 你不会真喜欢少就是多的理念吧?

还是每个开发者的喜好不同，也可能是对于暴露的功能的要求不同，比如我之前也自己造过一个…