Socket.IO 与 WebSocket 协议不兼容，必须前后端均使用对应 SDK；Socket.IO 自带重连、ACK、广播等能力，但开销更大；WebSocket 更轻量高效，适合性能敏感场景。
别用 new WebSocket() 去连 Socket.IO 服务端，也别用 io() 去连原生 ws:// 服务——两者协议不兼容，连上也会立刻断开。
Socket.IO 连不上？先确认你用的是不是配套协议
Socket.IO 不是 WebSocket 的“升级版”，它是一套独立协议栈，前后端必须都用 socket.io SDK。常见错误包括：
- 前端写
new WebSocket('ws://localhost:3000')，后端跑的是socket.io→ 立刻报Connection closed before receiving a handshake response - 前端用
io('http://localhost:3000')，后端是原生ws模块（如wsnpm 包）→ 控制台无报错，但socket.connected始终为false
验证方式很简单：服务端启动后，访问 http://localhost:3000/socket.io/，如果返回一段 JSON（含 sid 和 upgrades 字段），说明是 Socket.IO 服务；如果 404 或返回 HTML，则是原生 WebSocket 服务。
WebSocket 丢包/断连时得自己兜底，Socket.IO 默认就带这些
原生 WebSocket 只管建连和收发帧，其余全靠手动补：
- 网络抖动导致断连？
WebSocket不会自动重试，得监听onclose后自己调new WebSocket() - 消息发出去没回执？
WebSocket没 ACK 机制，要实现可靠传输就得加序列号 + 超时重发 - 想给所有在线用户广播？得自己维护
Set<websocket></websocket>并遍历send()
socket.io 把这些都封装好了：reconnection 默认开启，emit('msg', data, callback) 支持回调确认，io.emit() 一行广播全量，socket.join('room') + io.to('room').emit() 直接分组推送。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
Socket.IO 的“降级”不是兼容 WebSocket，而是放弃它
当检测到 WebSocket 不可用（比如被企业代理拦截、旧浏览器不支持），socket.io 会主动切到 HTTP 长轮询（transport=polling）。这不是“优雅降级”，而是切换通信范式：
- 延迟明显升高：每个消息都要走完整 HTTP 请求周期
- 连接数翻倍：每个客户端至少维持两个 polling 连接（一个发、一个收）
- 服务端内存压力更大：长轮询连接无法像 WebSocket 那样轻量复用
这个过程对开发者透明，但生产环境若大量 fallback 到 polling，说明网络环境或部署配置有问题，不能当作常态容忍。
性能敏感场景优先选 WebSocket，业务迭代快就选 Socket.IO
二者性能差在协议头和逻辑层：
-
WebSocket帧头最小 2 字节，纯二进制传输，适合高频小包（如游戏帧同步、传感器数据流） -
socket.io每个包自带类型标记、命名空间、ACK ID 等元数据，实测比原生多 20–50 字节开销 - 高并发下，
socket.io服务端需额外处理心跳、缓冲、房间索引等，CPU 和内存占用更高
真正容易被忽略的点是：Socket.IO 的「省心」是有代价的——它把复杂度从客户端搬到了服务端和协议设计里。一旦你需要定制传输语义（比如自定义压缩、端到端加密、与非 JS 客户端互通），反而会被它的封装卡住。这时候，回到 WebSocket 协议本身，可能更可控。
