构建 WebSocket 实时应用时，用安全、可扩展…

适用于开发基于 WebSocket 的实时通信应用，需要管理连接生命周期、消息处理、安全鉴权、扩展、测试和监控。

适用场景

解决思路

1. 在编写代码前逐步思考实现方案。
2. 严格遵循用户需求，并逐字落实。
3. 全程优先考虑安全性、可扩展性和可维护性。
4. 实现中不留任何 TODO、占位符或缺失部分。
5. 在生产环境始终使用 `wss://` 协议并启用 SSL/TLS 加密。
6. 确保连接传输的数据加密，防止窃听或篡改。
7. 在接受连接前实现正确的握手验证。
8. 设置合适的连接超时，防止资源耗尽。
9. 实现心跳/ping-pong 机制以检测失效连接。
10. 对掉线连接使用带指数退避的重连逻辑。
11. 维护连接状态以优雅处理断连场景。
12. 连接关闭时正确清理资源。
13. 使用结构化消息格式（JSON 的 `type`/`payload` 模式）。
14. 包含消息 ID 以关联请求-响应。
15. 实现消息版本化以保持向后兼容。
16. 保持消息负载较小以降低延迟。
17. 始终包含 WebSocket 连接的错误处理逻辑。
18. 优雅管理潜在断连或消息失败。
19. 对无法处理的消息实现死信处理。
20. 记录错误并包含足够上下文以便调试。
21. 使用消息代理（Redis Pub/Sub、RabbitMQ）进行跨服务器通信。
22. 在需要时实现粘性会话或连接亲和性。
23. 尽可能设计无状态处理器。
24. 考虑使用专用 WebSocket 网关服务。
25. 在短暂断连期间缓冲消息。
26. 对高频更新实现消息批处理。
27. 对带宽敏感应用使用二进制协议（MessagePack、Protocol Buffers）。
28. 监控连接数和消息吞吐量。
29. 在握手阶段认证连接。
30. 使用带适当过期时间的基于令牌认证（JWT）。
31. 在连接时和周期性时间间隔验证令牌。
32. 按连接和按用户实现速率限制。
33. 针对每种消息类型/频道验证权限。
34. 对发布/订阅模式实现基于频道的访问控制。
35. 在验证前绝不信任客户端提供的数据。
36. 清理所有传入消息负载。
37. 在 Node.js v21+ 中利用内置 WebSocket 客户端进行实时通信，以减少依赖。
38. 使用 Node.js 内置客户端简化实时通信并确保更好的互操作性。
39. 对于服务端，使用 `ws` 等成熟库或框架特定方案。
40. 优先使用 Bun 原生能力，而不是第三方替代方案。
41. 使用支持 WebSocket 的 `Bun.serve()`，而不是单独的 WebSocket 库。
42. 利用 Bun 内置的流处理和 fetch 实现。
43. 为旧浏览器实现优雅降级。
44. 使用标准 WebSocket API 以获得广泛兼容性。
45. 处理可见性变化以管理连接状态。
46. 实现离线检测和排队。
47. 模拟 WebSocket 连接以进行隔离测试。
48. 独立测试消息序列化/反序列化。
49. 验证错误处理路径。
50. 测试完整连接生命周期场景。
51. 验证各种故障模式下的重连行为。
52. 使用真实连接数和消息速率进行负载测试。
53. 跟踪连接数指标。
54. 监控消息延迟和吞吐量。
55. 对连接错误率设置告警。
56. 记录连接生命周期事件以便调试。
57. 实现频道订阅管理。
58. 使用高效数据结构进行订阅者查找。
59. 断开连接时处理订阅清理。
60. 使用唯一 ID 关联请求和响应。
61. 为待处理请求实现超时处理。
62. 考虑使用确认消息以提高可靠性。
63. 优化一对多消息投递。
64. 考虑消息去重策略。
65. 为慢消费者实现背压。

适用边界 · 注意事项

• 仅需一次性的请求/响应且无需服务端主动推送时，优先使用 HTTP/轮询，不必引入 WebSocket。
• 无法部署 SSL/TLS、消息代理、监控与重连机制时，不应在生产环境贸然使用 WebSocket。
• 对严格请求/响应语义且无双向实时需求的场景，优先 REST/GraphQL。