Echo 的 websocket.Connect 本质是 gorilla/websocket.Upgrader.Upgrade 的薄封装，自动传入请求响应但丢失原始 *http.Request 访问能力，不支持子协议协商与压缩配置；Gin 无内置 WebSocket，手动集成易因中间件污染响应头导致握手失败；Beego 和 Iris 封装受限于固定鉴权与强制压缩；nhooyr.io/websocket 必须直连 HTTP mux，无法复用框架中间件。
Echo 的 websocket.Connect 和原生 gorilla/websocket.Upgrade 本质区别
Echo 的 websocket.Connect 并非独立实现，而是对 gorilla/websocket.Upgrader.Upgrade 的一层薄封装。它自动提取 c.Response() 和 c.Request()，省去手动传参，但底层仍调用同一套握手逻辑和连接对象。
关键差异在于上下文传递：Echo 封装后丢失了原始 *http.Request 的完整访问能力，比如无法在升级前读取自定义 header（如 X-User-ID）做鉴权——你得提前在中间件里解析并塞进 context；而直接用 gorilla/websocket，可在 CheckOrigin 或升级前任意位置读取 request 全量字段。
-
websocket.Connect返回的*websocket.Conn与gorilla/websocket.Conn完全一致，所有读写方法（ReadMessage、WriteJSON等）行为无差别 - 如果你依赖
Upgrader.Subprotocols协商子协议（如"json"或"protobuf"），Echo 封装不暴露该字段，必须绕过它、手写升级逻辑 - Echo 的封装默认禁用压缩（
EnableCompression: false），而 gorilla 默认也是关的，但容易误以为“框架帮你开了”
Gin 没有内置 WebSocket 支持，所谓 “Gin + WebSocket” 实际是手动集成
Gin 官方库不提供任何 WebSocket 相关类型或函数。网上常见代码如 gin.Context.Writer 直接传给 Upgrader.Upgrade，本质是把 Gin 的 response writer 当作 http.ResponseWriter 用——这能跑通，但存在两个隐藏风险：
- Gin 中间件可能已写入部分响应头（比如
Content-Type、Cache-Control），而 WebSocket 升级要求响应头干净，否则握手失败，错误信息通常是http: response.WriteHeader on hijacked connection - 若启用了 Gin 的
Recovery或日志中间件，它们会在 upgrade 后继续尝试写日志或 panic 捕获，导致 panic 或连接中断 - 正确做法是：在路由 handler 开头就调用
c.Status(101)并立即返回，或确保 upgrade 前没触发任何 write 操作
Beego 和 Iris 的 WebSocket 封装都绕不开 gorilla/websocket 底层
Beego v2+ 的 WebSocketController 和 Iris 的 websocket.Handler 都是语法糖。它们内部初始化一个 gorilla/websocket.Upgrader，再把请求丢进去升级。好处是统一了生命周期管理（比如自动关闭连接、绑定 session），但代价是丧失配置自由度：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- Beego 强制使用其内置的
CheckOrigin实现（只比对 Host），无法替换为自定义逻辑；若需 Origin 白名单，得改源码或弃用封装 - Iris 的
websocket.Handler默认启用压缩，且不可关闭——哪怕你只传文本小消息，也会触发 zlib 压缩，CPU 白耗；而原生 gorilla 可精确控制CompressionLevel - 两者都不支持
HandshakeTimeout设置，超时由 HTTP server 全局 timeout 决定，容易导致大量半开连接堆积
nhooyr.io/websocket 无法被主流框架“封装”，必须直连 HTTP mux
nhooyr.io/websocket 设计上就不适配 http.Handler 接口。它的 Accept 函数接收 http.ResponseWriter 和 *http.Request，但会立即调用 ResponseWriter.Hijack() 并接管底层 net.Conn——这意味着它不能嵌入 Echo/Gin/Beego 的中间件链，因为 hijack 后中间件无法再写响应或修改 header。
真实部署时，你只能把它注册到裸 http.ServeMux 或 net/http.Server 的 handler 上，或者用框架的 “raw handler” 能力（如 Echo 的 e.Any("/ws", rawHandler)）绕过中间件。一旦混用框架 session 或 auth 中间件，就得自己从 request 解析 token、绑定用户，没法复用框架已有逻辑。
这个限制不是缺陷，而是设计取舍：它牺牲了易用性，换来了零拷贝和更低 GC 压力。如果你需要 10w+ 连接，就得接受这种“裸写”模式；如果只是几百个内部连接，强行用 nhooyr 反而增加维护成本。
