必须用useRef保存WebSocket实例，因useState或闭包变量会导致重复连接、内存泄漏及InvalidStateError；发消息前须校验readyState===WebSocket.OPEN，并用useSWRSubscription替代手写逻辑更稳妥。
直接在 useEffect 里 new WebSocket() 启动连接，不加引用保护和状态校验，90% 的 React WebSocket 应用会在页面切换、组件卸载或网络抖动时出问题——不是收不到消息，就是重复连接、内存泄漏，或者 ws.send() 报 InvalidStateError。
为什么不能把 WebSocket 实例存进 useState 或闭包变量
WebSocket 对象必须用 useRef 保存，这是硬性要求，不是“建议”。useState 或普通变量每次渲染都会生成新副本，导致事件回调（比如 onmessage）里调用的 setState 指向的是旧渲染周期的状态，而此时组件可能已卸载；更危险的是，如果没锁住实例，useEffect 可能连续触发多次连接，旧连接还没关，新连接又建上了。
必须做到：
-
wsRef.current在useEffect内赋值，且只赋一次（不要在事件回调里重赋） - 清理函数中显式调用
wsRef.current?.close()，不能依赖浏览器自动回收 - 发送消息永远走
wsRef.current?.send()，绝不用局部变量ws—— 它大概率是上一轮渲染留下的“僵尸引用”
readyState 校验不是可选，而是发消息前的必检动作
WebSocket.OPEN 是唯一安全的发送状态。真实场景中，网络抖动、服务端重启、页面切后台再切回，都可能导致 readyState 落在 CONNECTING、CLOSING 甚至 CLOSED。此时调 send() 就会抛 InvalidStateError，并中断整个事件流。
正确做法是：
来自 Vercel Engineering 的 React 和 Next.js 性能优化指南。用于编写、审查或重构 React/Next.js 代码以确保最佳性
- 接收消息时，统一用
typeof event.data === 'string' ? JSON.parse(event.data) : null，并包裹try/catch - 发送前检查
wsRef.current?.readyState === WebSocket.OPEN，不满足就跳过，并打warn日志（别 throw） - 高频操作（如拖拽坐标同步）必须节流，例如用
setTimeout+clearTimeout控制 1 秒内最多发 1 条
useSWRSubscription 比手写 useEffect 更稳，但用法有坑
如果你的数据本质是“持续推送 + 按需消费”（比如行情、日志流、协作光标），useSWRSubscription 是比裸 WebSocket Hook 更合适的选择：它内置连接生命周期绑定、错误退避重试、未挂载组件自动取消监听，还跟 SWR 缓存天然打通。
但要注意：
- 不要在
useSWRSubscription回调里手动new WebSocket()后不返回清理函数——连接永不释放 - 推送数据必须调
next(null, data)，出错必须调next(error)，否则 SWR 不会更新 error 状态 - URL 变更会自动触发重新订阅，但如果服务端不支持多路复用，频繁切换 key 可能引发连接风暴
最常被忽略的一点：消息收发必须做类型守卫和防抖校验。服务端偶尔发错格式（比如 Blob 或 ArrayBuffer）、前端误调多次 send，都会让 UI 崩溃或卡死——这不是边缘情况，而是线上高频报错来源。
