使用 WebSocket 构建高效的实时协作架构

关键在于构建连接可靠、同步一致、架构解耦的闭环：心跳+退避重连防断连，OT/CRDT保障操作一致性，分层架构（网关/WS服务/业务微服务）与消息分级（聚合低价值数据、ACK高价值操作）确保稳得住、同步准、扛得住。

要用 WebSocket 构建高效的实时协作架构，关键不在“连得上”，而在“稳得住、同步准、扛得住”。它不是简单加个 new WebSocket() 就完事，而是一整套围绕连接生命周期、数据一致性、并发承载的设计闭环。

连接必须可靠：心跳 + 智能重连是底线

很多协作系统上线后掉线频繁，不是代码写错了，而是连接管理没做实。中间设备（如云负载均衡、Nginx、企业防火墙）普遍设置 30–60 秒空闲超时，若心跳间隔等于或大于该值，连接会被静默断开，且不触发 onclose。

1. 服务端主动发 PING，客户端收到后立即回 PONG（别依赖浏览器自动响应）
2. 心跳间隔取路径中所有中间件最小 idle timeout 的 0.6–0.7 倍（例如最小为 45 秒 → 设 25–30 秒）
3. 重连需带退避策略：1s → 2s → 4s → 8s…上限建议 30s；同时加状态锁，避免切后台时反复重连耗资源
4. 重连成功后的第一帧必须是心跳，防止刚连上就因“静默期”被掐断

同步必须一致：操作变换（OT）或 CRDT 是刚需

多人同时拖动同一个图层、同时编辑同一段文本——这类冲突无法靠“最后写入获胜”解决。Penpot、Figma 等工具都采用操作变换（OT）或无冲突复制数据类型（CRDT）来保证最终状态一致。

1. OT 要求所有操作可序列化、可转换，常见于文档类协作（如光标位置、插入/删除动作）
2. CRDT 更适合离线场景和分布式环境，天然支持无中心协调，但实现复杂度略高
3. 无论选哪种，核心逻辑必须下沉到服务端或可信客户端（如 WebAssembly 模块），不能只靠前端“协商”
4. 操作需带时间戳或向量时钟，用于排序与合并，避免因网络延迟导致错序应用

架构必须解耦：WebSocket 不该直接碰业务逻辑

把用户登录、权限校验、文档存储、变更通知全塞进 WebSocket handler 里，短期快，长期崩。高可用协作系统普遍采用分层设计：

1. API 网关层：统一处理鉴权、限流、连接路由（如按文档 ID 分发到对应 WS 实例）
2. WebSocket 服务层：专注连接管理、消息编解码、广播/单播路由，不查数据库、不写日志
3. 业务微服务层：通过 Kafka/RabbitMQ 接收协作事件（如“用户 A 修改了图层 Z”），再触发存档、通知、AI 分析等
4. 消息队列作为缓冲和解耦枢纽，既防雪崩，也支持异步补偿（如断线期间的操作补同步）

消息必须分级：不是所有数据都值得“实时”

画板上的鼠标移动轨迹、文档光标的毫秒级跳动、用户在线状态更新……这些数据频次极高，但价值密度低；而“保存版本”“提交评论”“权限变更”则必须零丢失、强顺序。

1. 对高频低价值消息（如 cursor position），可聚合发送（100ms 内合并为一条）、降采样（每 3 帧发一次）、或走 UDP 辅助通道
2. 对关键操作消息，启用确认机制（ACK）+ 服务端持久化 + 消息去重 ID，确保至少一次送达
3. 前端可按优先级分流：UI 渲染走内存缓存，状态同步走 WebSocket，审计日志走 HTTP 批量上报
4. 避免在单条 WebSocket 连接上传输混合语义的消息体；用 type 字段明确区分，便于后续扩展和监控