io() 无法连接原生 WebSocket 服务端，因协议不兼容：Socket.IO 使用自定义握手，而原生 WebSocket 只接受标准 Upgrade 请求；反之亦然。
直接用 io() 连不上原生 websocket 服务端，反过来也一样——协议层不兼容，不是配错路径或端口的问题，是根本连不通。
前端用 io() 连不上自己的 ws:// 服务？先确认后端是不是 Socket.IO
常见错误现象：Connection closed before receiving a handshake response 或控制台无报错但 socket.connected 始终为 false。
这是因为 socket.io-client 发起的是自定义握手（含 sid、transport=polling 等参数），而原生 WebSocket 服务端只认标准 Upgrade: websocket 请求头，直接拒绝。
- 如果你后端是 FastAPI 的
WebSocketEndpoint、ws库或uWebSockets，那就不能用io()，必须换new WebSocket() - 如果你后端是
socket.io（Node.js 的socket.io或 Python 的python-socketio），那前端必须用io('http://...')，不能写ws://... - 检查后端启动日志：Socket.IO 服务端启动时会打印类似
listening on *:3000并附带socket.io版本号；原生 WebSocket 一般只打印监听地址，无额外标识
io() 的 URL 写 http:// 而不是 ws:// 是故意的
Socket.IO 客户端默认先发 HTTP 请求做握手，协商 transport 类型（websocket 或 polling），成功后才升级。所以传 ws:// 反而会跳过握手直接建连，必然失败。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 正确写法：
const socket = io('http://localhost:8000');（即使你确定要用 WebSocket） - 如果服务端部署在子路径（如
/api/socket），需显式配置：io('http://...', { path: '/api/socket' })，否则 404 - Nginx 反向代理时，必须透传
Upgrade和Connection头，否则降级为 polling —— 这不是 bug，是设计行为
WebSocket 和 Socket.IO 的关键差异不在“能不能用”，而在“要不要自己扛”
选错不是连不上，而是上线后才发现一堆没处理的边角问题：断网重连卡死、IE11 白屏、消息丢了没回执、广播要自己遍历 client 列表……
立即学习“前端免费学习笔记（深入）”；
- 用原生
WebSocket：你得自己实现心跳（ping/pong）、重连逻辑（指数退避）、连接状态同步、消息序列化与 ACK、多客户端广播管理 - 用
socket.io-client：reconnection: true开箱即用，socket.emit('msg', data, cb)自带回调，io.of('/chat').emit()直接广播，但每个包多 20–50 字节元数据 - 性能敏感且用户全是 Chrome/Firefox 90+？优先
WebSocket；要支持微信内置浏览器或企业内网老旧代理？socket.io的 polling 降级真能救命
最常被忽略的一点：Socket.IO 的“自动重连”默认会重试无限次，且首次延迟仅 1 秒——高并发场景下可能瞬间打爆后端连接数，必须手动调 reconnectionAttempts 和 reconnectionDelay。
