await不能直接替换事件回调，但通过async/await+Promise封装+状态机设计，可将被动回调流重构为主动声明式异步流程，提升解耦性、可读性与错误处理能力。
await 本身不能直接“平滑”替换事件回调，但配合 async/await + Promise 封装 + 状态机设计，可系统性解耦、提升可读性与错误处理能力。核心不是语法替换，而是将“被动响应式”的回调流，重构为“主动声明式”的异步流程控制。
把长连接生命周期转为可 await 的 Promise 链
传统写法中，onopen/onmessage/onerror 回调分散、状态隐含、错误易丢失。应先封装连接建立、心跳保活、消息接收等关键阶段为返回 Promise 的函数：
- connect(): 返回一个 Promise<WebSocket>，内部监听 onopen，reject onerror，并设置超时；
- waitForMessage(filter?): 返回 Promise<any>，内部用 once（或临时 listener）捕获下一条匹配消息，自动清理；
- sendWithAck(msg, timeout = 5000): 发送后等待服务端 ACK 响应，超时 reject；
这样，原本嵌套在 onmessage 里的分支逻辑（如“收到 status=ready 后发 config”），就能变成清晰的 await 序列：
await connect();await waitForMessage({ type: "handshake" });
await sendWithAck({ type: "get_config" });
const config = await waitForMessage({ type: "config" });
用 async 函数替代回调嵌套，显式管理状态跃迁
长连接常需维护“connecting → connected → syncing → active → reconnecting”等状态。不要靠全局变量+回调修改 flag，而应让每个 async 函数代表一个**有明确入口、出口和失败路径的状态阶段**：
- async function handleConnected(ws) { ... } —— 专注处理已连通后的初始化交互；
- async function handleSyncing() { ... } —— 封装全量同步逻辑，成功则进入 active，失败则抛出 SyncError；
- 主流程用 try/catch 捕获阶段异常，并触发统一重连策略，而非在每个回调里写 if (err) reconnect()；
状态跃迁变得可追踪、可测试：你清楚知道当前执行到哪一阶段，以及它失败时会走到哪里。
用 AbortController 协调长期监听与主动取消
传统回调中，关闭连接时需手动 removeEventListener，容易遗漏。利用 AbortSignal 可让 await 操作具备“可中断性”：
- waitForMessage() 接收 signal 参数，在 signal.aborted 时自动 reject；
- 心跳定时器、轮询任务、长时间 pending 的 waitForMessage，全部关联同一 signal；
- 当调用 disconnect() 时，只需 controller.abort()，所有关联 await 自动退出，无需手动清理；
这解决了“连接已断，回调还在等消息”的经典竞态问题，也让资源释放更确定。
保留事件回调做底层驱动，但不暴露给业务逻辑
不要消灭事件回调——WebSocket 底层就是事件驱动。正确做法是：在最底层（如 WebSocketAdapter 类）用 onmessage/onerror 收集事件、分发给 Promise resolve/reject 或 signal abort；上层业务代码只与 async 函数交互，完全感知不到事件存在。
这种分层让重构可渐进：先封装好 adapter，再逐个模块将回调调用替换成 await 调用，不影响其他模块运行。
