题干与适用场景
实时协作服务有数万长连接，当前使用第三方 WebSocket 库。Node.js 22.4 将 WebSocket 标记为稳定，团队希望减少依赖。请说明兼容性、连接生命周期、背压、认证、可观测性和回滚方案。
面试官考察点
考察你是否区分 API 稳定与生产链路成熟，能否设计连接上限、心跳、广播背压、优雅关闭和安全升级，并用真实指标验证替换收益。
回答前需要澄清的问题
先确认客户端协议、代理是否支持 WebSocket、消息大小和峰值连接；再问认证续期、跨节点广播、断线重连与区域故障。还要确认现有库依赖的扩展能力和必须保留的行为。
30 秒回答
“我会先做 API 与协议差异清单，确认 Node 22.4+ 运行时、代理和客户端兼容。服务端为每连接设置认证、心跳、空闲和消息大小限制，广播通过有界队列处理背压，关闭时先拒绝新连接再排空。先影子和小比例实例比较连接成功率、断线率、P95 延迟、内存与 CPU，并保留第三方库开关可快速回退。”
分步骤深入解答
验证运行时与协议
Node 文档说明 WebSocket 在 v22.4.0 起不再是实验特性；仍需锁定 Node 版本、客户端握手、扩展、代理超时和 TLS 配置。
设计连接生命周期
连接建立时完成身份与权限校验，设置最大空闲、心跳和关闭码。服务重启使用排空窗口，先停止接收新连接，再向客户端发送重连提示。
处理背压与消息大小
每连接维护有界发送队列，达到阈值时丢弃可重建消息、降级或断开慢消费者。限制帧和聚合消息大小，避免单个客户端占满事件循环和内存。
保证认证与授权
握手验证短期凭证，消息级操作再次检查租户和资源权限。凭证续期失败应关闭连接并要求重新认证，不能只依赖初始登录。
设计横向扩展
节点只保存连接本地状态，跨节点事件经消息总线路由；为订阅建立版本或游标，重连可补发遗漏事件而不是重复全量广播。
灰度、监控与回滚
先在内部租户和 1% 流量启用，比较握手失败、连接存活、重连、队列丢弃、P95 延迟、内存和 CPU。保留旧实现配置，发现协议或资源回归立即切回。
高质量示范回答
我不会因为 API 稳定就直接替换。先锁定 Node 22.4+、代理和客户端兼容性，再设计握手认证、心跳、空闲超时、消息上限和有界发送队列。跨节点只共享事件与游标，重连补发缺口。灰度阶段比较握手成功率、断线/重连、队列丢弃、P95、内存和 CPU，旧库保持可切换，指标回归就回滚。
常见错误
把稳定 API 等同于完整替代
第三方库可能提供扩展、压缩或重连行为；必须列出差异并验证客户端。
没有慢消费者策略
无界队列会耗尽内存；应限制队列、丢弃可重建消息或断开连接。
只在握手时授权
长连接期间权限可能撤销；敏感操作需要消息级校验或策略版本。
重启时立即杀连接
这会制造重连风暴；使用排空、抖动和明确关闭码。
追问及应对
如何控制重连风暴？
返回明确关闭原因，客户端使用指数退避和随机抖动，服务端对 IP、租户和账号设置速率限制。
什么时候保留第三方库？
若需要原生 API 未覆盖的扩展、压缩、代理兼容或成熟监控，替换收益不足就继续使用，并记录评估边界。
如何测试背压？
注入慢客户端和突发广播，观察队列上限、丢弃策略、事件循环延迟和内存曲线。
如何保证跨节点顺序？
为每个订阅流分配单调游标，消息总线携带版本；客户端按游标检测缺口并请求补发。