高性能实时聊天室核心在于连接稳、路由准、消息轻、体验顺：服务端精准绑定用户与连接，消息直投不广播；客户端主动心跳、断线重连、延迟渲染；必须用WSS，横向扩展需Redis协调。
用 HTML5 的 WebSocket 构建高性能实时聊天室，关键不在“堆功能”，而在于连接稳、路由准、消息轻、体验顺。核心是把长连接真正用好，而不是只把它当个“更快的 AJAX”。
服务端：连接管理必须精准到人
每个用户上线时，服务端要立即完成三件事：校验身份（如解析 URL 参数或握手头里的 token）、分配唯一 userId、将该 userId 与当前 WebSocket 连接实例绑定进内存 Map 或 Redis。不能依赖 session，因为 WebSocket 握手阶段就已完成认证。用户发消息时，服务端只查 to 字段对应的那个连接，直接 send()，不广播、不遍历、不查库——这是低延迟的根本。连接断开时，必须同步从映射表中移除，否则会出现“人已下线，消息还在投递”的问题。
消息协议：结构简单，字段务实
前后端约定统一 JSON 格式，必含四个字段：type（区分 msg/online/offline）、from（发送方 userId）、to（接收方 userId）、content（文本或 base64 图片）。可选加 timestamp（毫秒时间戳，用于客户端排序和本地缓存）和 msgId（防重复、支持已读回执）。避免嵌套过深或携带冗余元数据，单条消息控制在 2KB 内，减少帧开销。
客户端：不靠运气，靠主动兜底
浏览器环境不可控，必须自行处理异常场景：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 建立连接后立即启动心跳：每 25 秒 send("ping")，超时 5 秒未收到服务端 "pong" 就 close 并触发重连
- 页面卸载前调用 socket.close()，防止服务端残留死连接
- 发送消息前检查 socket.readyState === WebSocket.OPEN；若非打开状态，先暂存到内存队列，待重连成功后批量补发
- onmessage 收到消息后，用 requestIdleCallback 延迟渲染，避免大量消息涌入导致 UI 卡顿
部署与安全：WSS 不是可选项
生产环境必须用 wss://，HTTP 页面无法建立 ws 连接。Nginx 反向代理需显式透传升级头：
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
若需横向扩展，连接映射不能只存在单机内存里，应改用 Redis 的 Pub/Sub 或 Stream 模块做跨节点路由协调。单机支撑 3000+ 并发连接是常见基准，性能瓶颈通常出在序列化/反序列化或日志打点，而非 WebSocket 协议本身。
