测试WebSocket异步消息需用mock替代原生构造函数，控制事件时序、验证回调触发与状态更新，覆盖延迟、乱序、错误等边界场景，并结合状态机或事件总线断言预期行为。
测试 WebSocket 异步消息，关键不是等“真实网络响应”，而是控制消息时序、隔离副作用、验证回调/事件是否按预期触发。重点在于让异步行为可预测、可断言。
用 mock WebSocket 替换原生构造函数
避免依赖真实服务或浏览器环境。在 Jest 或 Vitest 中，通过全局替换 WebSocket 构造函数，注入一个可控的 mock 类：
- 它能立即触发 onopen、onmessage、onclose 等事件
- 支持手动调用 send() 模拟服务器下发消息
- 暴露内部状态（如已发消息列表、是否已连接），便于断言
主动触发并验证异步消息处理逻辑
WebSocket 消息处理通常是异步的（比如收到 message 后解析 JSON、更新 UI、触发其他 Promise）。测试时要确保：
- 消息到达后，对应的回调函数被调用（可用 jest.fn() 监听）
- 若处理中包含 await 或 Promise 链，需用 await waitFor(() => expect(...).toBe(...)) 等待状态更新
- 连续多条消息顺序处理正确，不因异步竞争导致状态错乱（例如用 Promise.all 并发处理时注意竞态）
覆盖典型异步边界场景
真实环境中，消息可能晚于预期、重复、乱序或夹杂错误。测试应模拟这些情况：
立即学习“Java免费学习笔记（深入）”；
- 发送一条消息后，延迟 100ms 再触发 onmessage → 验证超时逻辑或 loading 状态是否正确维持
- 连续快速触发两次 onmessage → 检查防抖、节流或队列机制是否生效
- 收到格式错误的 JSON 字符串 → 断言错误被捕获，未导致未处理 rejection 或页面崩溃
结合状态机或事件总线做集成验证
如果业务中 WebSocket 消息会触发状态变更（如从 “idle” → “loading” → “success”），建议把状态流转封装为显式状态机，并对外暴露当前状态 getter：
- 测试中先触发消息，再断言 getState() 返回预期值
- 监听自定义事件（如 dispatchEvent(new CustomEvent('data-updated'))），用 await waitForEvent 等待事件发生
