最近排查一个协同编辑项目时我遇到了一个非常典型的实时网络同步事故两个用户同时修改同一份文档A的改动先到服务端B的改动后到结果B的提交直接把A的成果整个覆盖掉了。从产品视角看这是“编辑冲突”从工程视角看这是同步方案选错了——每个客户端都在提交全量状态服务端没有做顺序裁决冲突处理策略也没设计。这几年代码写下来我越来越觉得实时网络同步的难点从来不在“把数据从A传到B”这一下而在于你怎么定义顺序、怎么合并冲突、怎么扛住抖动。这篇内容我会从原理、场景、方案选型到可落地的代码完整聊一遍实时网络同步。适合正在自研协同功能、直播互动、设备控制后台或者任何需要“多人实时感知彼此状态”系统的开发者参考。我会尽量少讲虚的多给能直接用的链路设计和参数。1. 核心挑战实时网络同步到底在同步什么1.1 “实时”的三个层次事件级、秒级、准实时先得把“实时”这个词拆开。不同业务场景里“实时”的标准差着好几个数量级这也直接决定了你选协议、做架构的出发点。事件级实时指的是用户操作发生后远端要在极短时间内感知到并做出反馈。典型场景包括远程桌面、多人竞技游戏、在线白板笔迹传输、音视频互动中的状态控制。这类场景的端到端时延目标通常在一两百毫秒以内超过这个范围人就能感觉到“卡”和“飘”。事件级实时对链路的每个环节都敏感包括客户端采集频率、网络传输、服务端处理、远端渲染任何一个环节抖动都会放大。秒级实时指的是用户能看到“对方刚刚做了什么”即可多用于聊天消息、弹幕、协同文档中的光标位置广播、实时榜单变化。这个量级下网络往返RTT100ms还是300ms影响不大真正重要的是别丢消息、别乱序、别掉线后补不回来。准实时常见于数据仪表盘、监控告警推送、运营后台的状态刷新允许几秒到几十秒的延迟。这类系统反而更看重批量聚合和可靠投递实时性太高反而会导致大量无效渲染和抖动。搞清楚自己到底需要哪个层次是第一步。我见过不少项目明明是秒级就够的场景硬要上带重传、带纠错的复杂协议结果延迟没降下来稳定性还变差了。1.2 同步的根本矛盾一致性、延迟与可用性实时网络同步的底层博弈其实就是分布式系统里的一致性和可用性博弈。CAP理论大多数人都不陌生但它太抽象我习惯用另一个角度来理解任何一次同步都意味着“你要让多个副本的状态达成一致”而达成一致需要通信通信是需要时间的这个时间在现代网络现实中不可能压缩到零。对这个矛盾更直观的体会是你们有没有见过这样的现象在协同编辑里用户A做完操作后自己的屏幕上立刻显示结果但B那边可能要几十毫秒甚至更久才看到。用户A会觉得系统是“实时”的因为他的操作立刻被渲染了。这里面用到的技术叫乐观更新也就是说客户端不等待服务端确认先在自己的本地视图上应用操作这叫“读自己的写”Read-your-writes。但乐观更新埋了一个坑如果两个客户端基于同一个旧版本各自做了修改服务端合并时怎么处理这就要引入顺序和冲突的概念。具体落到工程里就是下面一个问题。1.3 同步的是状态还是事件这个选择决定了系统复杂度我发现很多实时同步事故的根源都是把“状态同步”和“事件同步”混为一谈。状态同步传送的是“现在长什么样”。比如整个页面的完整数据结构、整张地图的实体列表、整个房间的全部玩家位置。好处是简单、容错好客户端拿到一份快照就能完整恢复坏处是带宽消耗大高频操作下几乎不可用而且全量提交会引发上文中那个“后写覆盖先写”的问题。事件同步传送的是“发生了什么”。比如“玩家A向右移动了3像素”“用户B在第27行插入了两个字”。服务端只需要记录事件序列按序应用到共享状态上再增量广播给其他客户端。这种方式的带宽占用小很多也天然支持回放和审计。用飞机黑匣子来类比最合适黑匣子录的不是飞机每一帧的画面而是操作指令、系统指令和告警事件。只要指令序列是完整的你就能重构出事发过程。实时同步也一样把“发生了什么”传对了状态自然会收敛。实际操作级的同步配合按需快照兜底是目前多人实时协作系统最主流的设计。2. 场景拆解不同领域对实时同步的需求完全不同实时网络同步不是一门通用的“一揽子”技术不同领域对实时性、一致性和可靠性有着截然不同的要求。做方案选型前先看清自己在哪个赛道。2.1 多人协作与在线办公操作级同步加冲突合并协同编辑、在线白板、多人表格这类场景核心诉求是多人同时操作同一份语义化数据文本、画布节点、单元格需要高频增量同步和复杂的冲突合并策略。常见的合并思路有两种一种是用版本号做覆盖仲裁另一种是上CRDT无冲突复制数据类型来实现自动合并。这类场景中的光标位置和选中状态也需要实时同步但它属于高频瞬时数据一般不走持久化逻辑而是直接广播“此人的光标在哪个位置”客户端收到后短暂渲染即可。2.2 金融行情与交易低延迟、高吞吐、强有序行情推送是另一个极端。它要求极低的端到端延迟、极高的消息吞吐同时对消息顺序极度敏感——行情快照如果乱序聚合计算的结果就直接错了。所以这类系统往往使用专门的行情协议、组播或者内存网格技术并且服务端必须为每一条行情分配严格的序列号。如果你在业务里做交易联动、风控同步还有一个额外的要求幂等。网络重发、客户端重连导致的重复消息绝不能造成重复下单或重复扣减。2.3 集群内部分布式状态一致性和选主实时网络同步不止发生在用户端和服务器之间。服务集群内部各个节点之间也需要同步状态比如“哪个节点是主节点”“配置变更是否已经生效”“分布式锁是否释放”。这类同步走的是Raft、Paxos等一致性协议它们解决的是“多个副本如何在故障条件下最终达成一致”的问题。这和用户态实时同步的差异很大。用户态同步允许最终一致性甚至允许临时分叉只要用户感知不到但集群内的状态同步必须保证任何时刻所有节点对“当前是谁在负责”没有分歧否则就会脑裂。2.4 物联网与工业控制确定性优先于实时性物联网场景里的实时同步往往和弱网并存。设备端网络不稳定、带宽有限、时延波动大控制指令却必须可靠送达——你可以容忍慢但不能接受丢。因此这类场景更常用MQTT这类基于发布订阅的协议配合QoS等级来保证消息至少到达一次或恰好一次。工业控制还要多考虑一层指令必须按固定周期到达执行端否则机械臂的运动轨迹都会乱。这种情况下实时同步设计不是怎么“更快”而是怎么“更稳”——固定节奏的同步心跳、超时熔断、本地指令预测都是常用手段。我把这四个场景的关键诉求整理成了下表方便对比场景核心指标同步粒度常用方案一致性要求多人协作低延迟、冲突合并操作事件WebSocket 增量广播强最终一致金融行情微秒级延迟、高吞吐、有序行情数据专有协议/组播/内存网格有序且幂等集群状态一致性、选主、容错状态机日志Raft/Paxos线性一致物联网控制可靠、低带宽、弱网容错状态上报与指令MQTT QoS至少一次3. 方案选型从轮询到 WebSocket、WebRTC、MQTT3.1 短轮询和长轮询为什么被逐渐淘汰早期做实时效果最土的办法就是让客户端每隔几秒请求一次接口拿到最新数据这叫短轮询。短轮询的问题在于空转率极高——80%的请求可能都没有新数据但用户量一大服务端的请求量就被白白打满。而且不管怎么调间隔短轮询都存在“感知延迟”轮询周期就是你的实时性上限。长轮询Long Polling是一种改进客户端发起请求后服务端挂住这个连接一旦有新数据就立即响应如果没有数据则等待一段时间后超时。这种方式把延迟降低了不少但服务端要维护大量挂起的连接长连接数量和实际吞吐之间容易出现资源浪费。看现在的Web基础设施短轮询和长轮询已经很少被用于实时同步了它们只适合低频、非核心的数据刷新。3.2 WebSocket 是通用端同步的主流选择WebSocket 能够成为端到端实时同步的主流核心原因是它跑在TCP之上天然继承了TCP的两个重要特性可靠传输和有序到达。在WebSocket连接上你不需要操心消息会不会丢、会不会乱序这对业务逻辑来说是一个巨大的简化。另一个原因是它的低开销。WebSocket在建立连接时通过HTTP Upgrade协议完成握手之后数据帧头部只有几个字节远比HTTP请求头小得多。这意味着高频小消息比如光标广播、输入框同步在WebSocket上的传输效率很高。再加上浏览器天然支持WebSocket 几乎成了网页端实时通信的默认选项。但WebSocket并不是万能的。它本质上是一条长连接服务端要维护海量连接的内存和CPU开销弱网环境下TCP的队头阻塞也会让延迟变得不稳定。3.3 WebRTC 的适用边界不在通用状态同步WebRTC 主打的是浏览器端点对点传输它可以通过 UDP 打洞进行媒体流的低延迟传输时延往往能做到几十毫秒。它非常适合音视频通话、屏幕共享、P2P文件传输这类场景。但如果你打算用 WebRTC 做状态同步要掂量一下复杂度它需要信令服务器做连接协商还要处理复杂的NAT穿透失败比如对称型NAT下打洞经常失败穿透不行就得走TURN中继带宽成本立刻上去了。WebRTC的数据通道DataChannel确实是可靠的但你想在P2P网络里维护一个多人一致的共享状态就得处理每个节点之间的连接管理、消息路由和去重这比服务端中转要麻烦得多。所以我的结论很明确除非你的核心场景是音视频否则状态同步还是走服务端中转WebRTC 只做媒体流。3.4 MQTT 更适合设备端和弱网环境MQTT 是基于发布订阅模式的轻量级消息协议头开销极小支持QoS分级且专门为高延迟、低带宽、不可靠的网络设计。它在物联网场景里非常流行因为它天然支持设备在线状态感知遗嘱消息和主题隔离按设备ID分发消息。如果你的同步场景涉及移动App后台、嵌入式设备或窄带网络MQTT往往比WebSocket更合适。但它在浏览器端的使用不如WebSocket原生需要通过MQTT over WebSocket桥接也会多一层网关的运维成本。我把这几个方案的选型边界整理成了表格方案是否双向传输可靠性延迟水平适用场景主要短板短轮询半双工可靠秒级以上低频轮询开销大、延迟高长轮询半双工可靠秒级低频推送资源占用高WebSocket全双工TCP可靠毫秒级网页端通用同步弱网队头阻塞WebRTC全双工P2P可靠/不可靠可选极低音视频、P2P信令复杂、穿透成本高MQTT发布订阅QoS 0/1/2毫秒到秒级物联网、弱网浏览器不原生4. 从零实现一个多人实时状态同步服务4.1 核心设计权威服务端加意图上传加增量广播下面我会用Node.js写一个可运行的多人实时位置同步示例来演示实时网络同步的核心链路。这个示例会模拟一个“多人实时共享画板”每个人可以拖动一个方块其他人在自己的屏幕上几乎同时看到方块的移动。这个示例的设计原则是客户端永远只上传操作意图不直接上传状态。也就是说客户端在拖拽时发送的不是“我当前的位置”而是“我正在往这个方向移动”最终位置由服务端校验和仲裁后再广播给所有客户端。这样做有几点好处服务端是唯一权威状态源客户端无法通过伪造数据污染全局状态碰撞检测、业务规则可以统一在服务端实现其他客户端收到的是最终一致的增量而不是每个客户端各自的本地计算结果。4.2 服务端实现示例用 Node.js 搭建状态仲裁层我们使用ws库充当WebSocket服务端。它轻量、稳定并在内存中维护每个房间的状态。// server.js const { WebSocketServer } require(ws); const wss new WebSocketServer({ port: 8080 }); const rooms new Map(); // roomId - { state, clients, ops: [] } let globalSeq 0; function getRoom(roomId) { if (!rooms.has(roomId)) { rooms.set(roomId, { state: { players: {} }, clients: new Map(), ops: [] }); } return rooms.get(roomId); } wss.on(connection, (ws, req) { const roomId new URL(req.url, http://localhost).searchParams.get(room) || default; const room getRoom(roomId); const clientId Math.random().toString(36).slice(2); room.clients.set(clientId, ws); ws.clientId clientId; ws.roomId roomId; // 新客户端连接发送全量快照作为基准状态 ws.send(JSON.stringify({ type: snapshot, clientId, state: room.state, lastSeq: globalSeq })); ws.on(message, (raw) { const msg JSON.parse(raw.toString()); if (msg.type sync) { // 服务端仲裁根据当前 room.state 完成位置更新而不是直接信任客户端 const { x, y } msg.update; const finalX Math.max(0, Math.min(800, x)); const finalY Math.max(0, Math.min(600, y)); room.state.players[clientId] { x: finalX, y: finalY }; const seq globalSeq; const op { seq, opId: msg.opId, clientId, update: { x: finalX, y: finalY } }; room.ops.push(op); broadcast(room, clientId, op); } else if (msg.type pong) { ws.isAlive true; } else if (msg.type resync) { // 客户端请求补偿丢失的消息 const missingOps room.ops.filter((op) op.seq msg.fromSeq); ws.send(JSON.stringify({ type: sync-batch, ops: missingOps })); } }); ws.on(close, () { room.clients.delete(clientId); }); }); function broadcast(room, fromClientId, op) { const payload JSON.stringify({ type: sync, ...op }); for (const [cid, ws] of room.clients) { if (cid ! fromClientId) { ws.send(payload); } } } // 心跳探测30秒检查一次帮助识别死连接 function heartbeat() { for (const room of rooms.values()) { for (const [cid, ws] of room.clients) { if (!ws.isAlive) { ws.terminate(); room.clients.delete(cid); continue; } ws.isAlive false; ws.send(JSON.stringify({ type: ping })); } } } setInterval(heartbeat, 30000);这段代码虽然只有几十行但已经把实时同步的核心机制都体现出来了新客户端连接后拿到全量快照作为起点snapshot日常更新通过增量事件广播sync服务端分配单调递增的序号seq以此确定全房间的全局顺序客户端离线后重新连接时通过resync机制补偿缺失的消息心跳负责清理僵尸连接。这里有一个关键点值得画出来globalSeq是全局顺序的锚点。它由一个单一的服务端实例生成一旦有多个服务端实例这个全局序号就必须改用分布式ID生成器比如雪花算法中的时间序列部分但核心思想不变整个房间内的所有变更必须有一个全序关系。4.3 客户端实现示例乐观更新与消息补偿客户端必须是“聪明的”否则你会在体验上输掉一切。我采用乐观更新策略本地拖拽方块时不等待服务端返回立刻在本地渲染移动效果与此同时把操作意图异步发送给服务端最终以服务端的广播为准进行修正。这样可以保证用户本人的操作零延迟响应其他客户端则通过服务端的增量广播来做同步。// client.js浏览器端代码 const ws new WebSocket(ws://${location.host}/?roomdemo); let myId null; let localSeq 0; let lastSeq 0; let players {}; // 用一个本地集合记录已经发送、尚未被服务端确认的操作 const pendingOps new Set(); const opIdGen () ${Date.now()}_${localSeq}; ws.onmessage (event) { const msg JSON.parse(event.data); if (msg.type snapshot) { myId msg.clientId; players msg.state.players; lastSeq msg.lastSeq; render(); } else if (msg.type ping) { ws.send(JSON.stringify({ type: pong })); } else if (msg.type sync) { // 服务端广播的新状态 players[msg.clientId] msg.update; pendingOps.delete(msg.opId); lastSeq msg.seq; render(); } else if (msg.type sync-batch) { // 补偿消息批量到达 for (const op of msg.ops) { players[op.clientId] op.update; lastSeq Math.max(lastSeq, op.seq); } render(); } }; function sendMove(x, y) { const opId opIdGen(); pendingOps.add(opId); // 先把本地的玩家位置乐观更新为最新 players[myId] { x, y }; render(); ws.send(JSON.stringify({ type: sync, opId, update: { x, y } })); } // 如果发现自己落后了超过阈值主动请求补偿 function maybeResync() { ws.send(JSON.stringify({ type: resync, fromSeq: lastSeq 1 })); } // 渲染逻辑假设页面里有一个画布和方块 function render() { // 遍历 players将每个玩家方块绘制到对应位置 }在这个客户端里pendingOps集合承担了去重和确认的作用只有服务端广播的opId和本地发送的一致才说明这次操作已经被服务端确认可以移出集合。如果长时间没有收到确认客户端就需要主动补偿或重发。4.4 为什么不能用墙上时钟排序Lamport 时钟思想如果你在多人同步系统里用每台设备的本地时间戳来给操作排序等待你的必然是难以复现的乱序问题。两台设备的系统时钟本来就有偏差就算你用NTP校准也无法保证它们的偏差为0。设想一下A的时钟比B的慢了5秒A在物理时序上先执行了修改但B的修改带着一个更大的时间戳先到达服务端服务端按时间戳排序就把A的操作排到后面去了。Lamport 时钟解决的就是这个问题给每个节点一个单调递增的逻辑计数器不依赖物理时间。每个节点发送消息前把自己的计数器加一收到消息时取“自己的计数器”和“消息携带的计数器”两者中的较大值再加一更新本地。这样建立的是一个偏序关系如果操作A在因果上先于操作B那么A的逻辑时钟一定小于B。我的示例中服务端用全局递增的globalSeq来分配消息序号实际上就是一种单机版的Lamport时钟——由服务端充当那个唯一的取号机。去买奶茶时所有人都从同一个取号机拿号不依赖任何人的手表顺序就对了。分布式环境下没有单一取号机时就需要用Lamport时钟或向量时钟来完成同样的逻辑。5. 网络抖动与消息可靠性生产环境里躲不掉的坑5.1 心跳检测与连接保活任何长连接方案都需要处理一件事情连接什么时候算断了TCP断链的发现是非常迟钝的默认情况下可能要等几分钟甚至更久。如果服务端迟迟不清理已经掉线的连接内存和文件描述符就会被拖垮。解决手段是心跳服务端定时向客户端发ping客户端回pong如果在N个周期内没有收到pong就认为连接失效并主动清理。心跳间隔的选择有讲究。太频繁会白白消耗客户端电量和服务端资源太慢会导致掉线感知迟缓。我实测下来一般取15到30秒一个周期连续两个周期无响应判定断开是比较稳妥的组合。同时要注意NAT超时的存在。很多移动网络或家用NAT会在60到120秒内回收没有流量的UDP映射所以心跳间隔不要超过NAT映射的超时时间否则即使应用层还活着底层链路也早已被掐断了。5.2 断线重连与消息补偿WebSocket连接是可能随时断开的客户端必须实现自动重连而且重连不是“重新连上就完事”还要把断开期间丢失的消息补回来。补偿的核心是序号seq。客户端每次收到消息都会记录最新的lastSeq。重连后客户端把自己的lastSeq 1发给服务端服务端把该序号之后的消息从操作日志中捞出来批量回传给客户端。这个方案要求服务端为每个房间保留一个滑动窗口的消息缓冲只保留最近N条比如500条或最近5分钟的消息。超过窗口的消息不再补偿这时客户端必须重新拉取全量快照作为兜底恢复。我在实际项目里一般这样设计重连时先尝试增量补偿补偿失败或序号落后太多就退化为全量快照再同步。5.3 消息去重与幂等性TCP本身保证不丢包但应用层的重试机制会引入重复消息。比如客户端断线后重发操作服务端可能已经处理过这条操作了新连接上又收到一遍。去重的通用做法是引入操作IDopId。每条操作在客户端生成时就带一个全局唯一的ID服务端处理完一条操作后就把它放入去重表。再次收到相同ID的操作时直接丢弃并返回已确认的状态。幂等性比去重更严格它要求同一操作执行多次和执行一次的结果完全一样。比如“把账户余额扣掉5元”就不是幂等操作执行两次会扣两次但“把账户余额设置为100元”就是幂等的。在实时同步中尽量设计幂等操作配合opId去重就能在重传风暴下保证状态正确。5.4 时钟偏移与时间同步在监控层面的应用业务排序我不依赖物理时钟但监控日志和问题排查需要。多个服务端的日志时间如果对不上排障时你根本无法把一次事件的链路串起来。所以我会在基础设施层统一启用NTP时间同步让所有服务端节点的时钟偏差控制在毫秒级以内。NTP的作用范围仅限于监控、日志关联和延迟测量。它不能替代Lamport时钟去做业务排序因为NTP永远无法消除网络传输耗时的不确定性。把这一点刻在脑子里能少踩很多坑。6. 性能优化与规模扩展从几百人到一个集群6.1 广播放大问题一人说话万人听的成本实时同步系统最容易被忽视的成本是广播放大问题。一个用户产生一条操作服务端要把这条操作转发给房间内其他所有用户。假设房间内有1000人一次广播就是999次下行推送。如果每秒钟每个人产生10条操作服务端每秒钟要处理的推送量就是1万条。这还不是最可怕的。如果系统做成“所有用户都在同一个公共房间广播”那消息量就变成了O(n²)级别任何单机都扛不住。所以第一反应必须是区分“公开频道”和“房间私有频道”把广播范围限制在最小业务范围内。6.2 高频输入场景的合并推送思路在鼠标拖拽、手写笔迹、光标广播这类高频操作场景里如果每次mousemove都立刻发送一条消息带宽和服务端压力都是灾难。一秒钟的鼠标移动可能产生几十上百个坐标点但屏幕刷新率决定了大部分中间帧根本没有意义。这类高频更新我建议做合并推送在客户端本地以固定帧率比如每秒10到20次采样并发送坐标中间所有的过渡位置以本地渲染补齐。服务端也可以做类似优化把极短时间内到达的多个操作合并成一个批量事件再广播。这种合并策略能在几乎无损体验的前提下把消息量降低到原来的十分之一甚至更低。6.3 分片与房间化支撑水平扩展的关键当在线人数超过单机能力时最自然的扩展手段是按房间分片——把不同房间的用户分散到不同的服务端节点上每个节点只处理自己负责的那批房间的状态同步。这样消息广播范围天然被限制在一个节点内不产生跨节点的额外通信。跨节点的情况发生在“用户A在房间1用户B在房间2但业务上需要感知彼此”的场景。这时就需要一层消息路由服务或消息总线把跨房间事件转发到对应节点。很多即时通信架构里的“网关层 业务层”分离就是为了解决这个扩展问题。6.4 数据压缩与序列化选型JSON是最直观、最通用的序列化格式但它不是最高效的。在消息量大的场景我会把网络协议里的高频字段从JSON迁移到更紧凑的二进制格式比如MessagePack或Protobuf。实测在我的项目里同样的状态同步消息从JSON换成MessagePack后网络带宽下降了大概40%。如果消息里还有大量的重复坐标或前缀相似的数据再加上一层压缩如zstd或gzip效果会更好。这里要提醒一句序列化优化的收益只有在单条消息超过一定规模或者流量足够大时才明显。几百字节级别的消息优化序列化的收益有限反而会增加调试成本。按需做别为了优化而优化。7. 常见问题排查速查表把我在实际项目中反复遇到的同步问题整理成了一个速查表排查时可以直接对照症状可能原因排查思路常见修复客户端频繁断线心跳超时参数过短 / NAT映射超时查看服务端断线日志时间间隔检查ping-pong周期调大心跳间隔确认真空周期小于NAT超时消息乱序处理异常客户端本地时间戳排序 / 多路径传输检查客户端排序逻辑确认服务端seq是否单调服务端分配全局序号客户端按seq应用事件操作被覆盖客户端提交全量状态而非增量操作复现双人同时编辑抓包看提交内容改为操作事件上传服务端做版本合并广播风暴导致CPU高单个房间用户过多、广播频率过高观察单房间连接数、每秒消息数合并推送房间分片降低采样频率重连后状态回退补偿逻辑缺失、补偿窗口太小模拟断线重连检查lastSeq是否持久化实现增量补偿全量快照兜底App耗电严重长连接心跳太频繁、后台频繁唤醒观察客户端网络活跃时间占比降频心跳使用系统级推送替代长连接7.1 我自己踩过的三个坑第一个坑早期做一个远程桌面协同工具时我用全量快照同步每次屏幕有变动就把整个位图压缩后传给对方。结果是拖一下窗口都卡成PPT带宽被耗得干干净净。后来改成只传有变化的区域坐标和操作事件才把延迟压到可用的100毫秒以内。第二个坑一个协同文档项目最开始每个客户端用Date.now()给操作打时间戳服务端按时间戳排序。结果两台电脑的时钟偏差导致操作顺序经常反转两个人同时编辑同一段文字时的结果完全随机。后来换成服务端统一分配序号问题立刻消失。第三个坑一个设备控制后台没有做幂等处理。网络抖动导致客户端重发了一条“关闭设备”的指令服务端重复执行设备被关了两次而第二次关闭恰好触发了另一个状态异常。从那以后所有控制类操作我都强制要求携带opId并在服务端做去重。7.2 最后一个小技巧如果你在自行实现补偿机制一定记得把客户端的lastSeq做持久化不要只存在内存里。浏览器刷新、App进程被杀内存里的序号就没了。重连后如果不知道自己的位置只能退回全量快照体验和带宽都会变差。而一个小小的本地存储比如localStorage或SQLite就能让绝大多数重连场景走增量补偿这是个性价比极高的优化。