\_onConnect 一定先于任何 onMessage 触发，因 WebSocket 协议要求状态变为 OPEN 后才可收发消息；所有 send() 和 onMessage 绑定必须在 \_onConnect 内或之后执行，否则可能丢失消息或逻辑错乱。
WebSocket 连接成功后 _onConnect 和 onMessage 的触发时机
连接建立完成的瞬间，_onConnect 一定先于任何 onMessage 触发。这是 WebSocket 协议层决定的：只有 TCP 握手 + HTTP Upgrade 成功、状态变为 OPEN 后，才可能收发消息。
常见错误现象是：在 _onConnect 回调里立刻 send()，但服务端还没收到；或误以为 onMessage 可能“抢在”连接就绪前到达。
-
_onConnect是连接就绪的唯一可信信号，不是“差不多连上了”，而是readyState === 1 - 所有主动发送（
send()）、监听消息（onMessage）都应放在_onConnect内或之后执行 - 如果服务端在 Upgrade 完成后立即推送欢迎消息，那第一条
onMessage紧跟在_onConnect之后——但顺序仍是严格先后，不存在并发或乱序
为什么有些场景看起来 onMessage “先到了”
实际并非事件顺序错乱，而是代码逻辑把监听绑定写在了连接之前，且服务端在连接建立后快速下发了消息，导致视觉上像“先收到”。本质是监听注册早、事件触发晚，但触发时间点仍严格依赖连接完成。
- 错误写法：
ws.onMessage = handler; ws.connect();—— 监听虽早注册，但底层没有 readyState 保护，部分 SDK 会丢弃连接过程中的消息 - 正确做法：只在
_onConnect中设置onMessage，或确保 SDK 支持“自动缓存未就绪时的消息”（需查文档确认） - Chrome DevTools 的 Network → WS → Frames 面板可验证：第一条 Frame 时间戳永远晚于 Connection Established 时间戳
_onConnect 不触发？先检查这三件事
这不是事件顺序问题，而是连接根本没成功。别急着调顺序逻辑，先定位是否真的进到了就绪态。
- 检查
ws.readyState值：0（CONNECTING）卡住说明 DNS、跨域、代理或服务端拒绝；2（CLOSING）或 0（CLOSED）说明已失败 - 看浏览器控制台有没有
WebSocket connection to 'xxx' failed错误，这类报错优先级高于任何回调 - 确认 URL 协议是
wss://（HTTPS 页面不能用ws://），路径和 query 参数拼写无误（比如漏了?token=xxx导致服务端直接断连）
多个回调共存时的执行保障
原生 WebSocket 只有 onopen、onmessage 等标准属性；_onConnect 通常是封装层（如 Socket.IO、自研 SDK）加的钩子。它的触发时机取决于封装实现，但只要它叫 _onConnect，就该语义等价于原生 onopen。
- 如果 SDK 文档没明确说
_onConnect是“连接完成且 readyState 就绪”，那就得翻源码或打日志验证——有些库把它设在 upgrade 请求发出后、响应未返回前 - 不要混用原生
onopen和封装层的_onConnect，容易因执行上下文不同导致状态不一致 - 真正需要强顺序保障的业务逻辑（比如登录后发心跳），应该把整个流程串在同一个回调里，而不是拆到多个事件中靠“顺序”赌运气
顺序本身不复杂，难的是确认你用的那个 _onConnect 到底是不是真正的就绪信号——这点最容易被忽略。
