react中封装websocket hook是必需的，否则易出现脱离生命周期、重复连接、状态不同步及静默断连等问题；直接useeffect里new websocket会引发清理异常、无重连、多实例三大隐患。
React 中封装 WebSocket Hook 不是“要不要做”的问题，而是“不封装就容易出事”的现实——原生 WebSocket 实例脱离组件生命周期、重复连接、状态不同步、错误后静默断连，这些在真实项目里几乎必然发生。
为什么不能直接 new WebSocket() 放 useEffect 里？
看似最简写法，实则埋了三类坑：
-
useEffect清理函数里调用ws.close()，但组件卸载时ws可能还没初始化完成（比如 URL 动态获取中），导致ws是null或undefined，报Cannot read property 'close' of null - 重连逻辑缺失：网络抖动触发
onclose后，不会自动重试，用户看到的就是“消息停了”，无感知、无反馈 - 多个组件同时调用同一个 Hook 会创建多个独立连接，而不是复用单个长连接——尤其当服务端限制并发连接数时，直接被拒绝
useWebSocket 的核心参数怎么设才不翻车？
如果你用的是 ahooks 的 useWebSocket，或自己封装，这几个参数必须显式控制：
-
onError必须定义：它捕获的是连接建立失败（如 401、DNS 解析失败、跨域拦截），不是onmessage解析错误。漏掉它，控制台报错但你完全不知道哪条链路断了 -
retryOnError: true是默认值，但要配合reconnectInterval和reconnectAttempts：比如设成{ reconnectInterval: 3000, reconnectAttempts: 10 }，避免秒级高频重连被服务端限流 -
shouldReconnect（自定义 Hook 中常用）别写成() => true：登录态过期、token 失效时，应返回false并跳转登录页，否则会无限重连 401
消息收发如何避免闭包陷阱和状态滞后？
这是 React Hook 封装 WebSocket 最隐蔽的雷区：
- 发送函数里直接读取
isConnected状态？不行。因为useCallback创建时捕获的是旧值，即使连接已建立，sendMessage仍可能认为readyState !== WebSocket.OPEN - 正确做法是把
wsRef.current当作唯一信源：if (wsRef.current?.readyState === WebSocket.OPEN)—— 它永远反映当前真实连接状态 - 接收消息时，
onmessage回调里的setMessages要用函数式更新：setMessages(prev => [...prev, data])，否则在快速连发场景下会丢消息（React 18 的批量更新机制会让多次 setState 合并）
如何让整个 App 共享一个 WebSocket 连接？
靠 Hook 自身无法解决多组件共享问题，必须升级为 Context + 单例模式：
- 用
useRef在顶层 Provider 里缓存WebSocket实例，而不是每个 Hook 都 new 一个 - Provider 内部管理重连逻辑，所有消费组件只通过
useWebSocketContext()拿sendMessage和lastMessage，不接触底层实例 - 关键点：连接 URL 和 token 必须在首次 connect 前就准备好；如果 token 异步获取（如从 storage 读），需加
if (!token) return防止空参连接
真正难的从来不是“连上”，而是“连得稳、断得明、重得准、发得对”。很多项目卡在重连策略和状态同步上，不是代码写得少，而是没想清楚：谁该负责清理、谁该决定重连、谁来兜底失败——这些必须在封装层就定死规则，而不是留到组件里补丁式处理。
