WebSocket本身不直接实现协作编辑状态，但提供实时双向通信能力，需结合OT或CRDT同步策略、结构化消息广播、在线状态与光标协同、断线重连机制及体验优化设计来支撑多人协作编辑。
WebSocket 本身不直接实现“协作编辑状态”，但它提供了实时双向通信的底层能力，配合合理的协议设计和状态同步策略，就能支撑多人协作编辑（如在线文档、白板等）。关键不在 WebSocket 多神奇，而在怎么用它传递、合并和收敛编辑操作。
用操作变换（OT）或冲突解决（CRDT）同步编辑内容
多人同时输入时，直接发原始文本或光标位置极易冲突。推荐采用操作序列（Operation-based）模型：
- OT（Operational Transformation）：每个编辑动作（如插入、删除）被封装为带位置和内容的操作对象，服务端按顺序转换、合并后再广播给所有客户端；适合中心化架构，逻辑较复杂但成熟（如 Google Docs 早期方案）
- CRDT（Conflict-free Replicated Data Type）：每个字符/段落带唯一 ID 和向量时钟，客户端本地可独立修改，通过数学规则自动合并，无需服务端协调；更适合 P2P 或高可用场景（如 Automerge、Yjs 库）
用 WebSocket 实时广播状态变更
WebSocket 连接建立后，不是只传“文字”，而是传结构化消息：
- 客户端发送：
{ type: 'insert', pos: 12, text: 'hello', clientId: 'u123' } - 服务端验证、转换（OT）或融合（CRDT），再广播给其他客户端：
{ type: 'update', docId: 'doc1', ops: [...], version: 42 } - 客户端收到后，调用本地编辑器 API（如 Slate、Quill、CodeMirror 的 transaction 或 update 方法）应用变更，同时更新光标、选区等 UI 状态
维护用户在线状态与光标/选区协同
协作不只是内容同步，还要让用户“看见彼此”：
立即学习“Java免费学习笔记（深入）”；
- 连接建立时，客户端发送
{ type: 'join', userId: 'u123', name: '张三', color: '#3a86ff' } - 服务端维护房间内用户列表，并广播加入/离开事件；前端渲染头像、名字气泡或彩色光标
- 光标和选区用轻量心跳+增量更新：每秒最多发一次
{ type: 'cursor', range: { from: 10, to: 15 }, userId: 'u123' }，避免频繁重绘
处理断线重连与状态恢复
WebSocket 断开很常见，不能让协作中断：
- 客户端监听
onclose，启动重连机制（指数退避），同时缓存未确认的操作（pendingOps） - 重连成功后，先向服务端请求最新文档快照 + 版本号，再把本地 pending 操作按版本差做重放或转换
- 服务端需支持“状态快照 + 增量日志”双模式：新连接者拉快照，老连接者只收增量，降低带宽压力
不复杂但容易忽略：协作体验好坏，往往取决于操作延迟感知（加 loading 微动效）、冲突提示（如“对方正在编辑此处”）、以及回滚容错（支持 Ctrl+Z 跨客户端撤销）。WebSocket 是管道，真正让协作“顺滑”的，是背后那套状态管理逻辑。
