当用户上午在办公室电脑上回复客户消息，下午在地铁用手机打开同一会话时，最怕看到的是历史记录缺胳膊少腿，或者顺序乱成一团。消息漫游要解决的就是让同一账号在多台设备间共享完整、有序的聊天记录。这件事在传统即时通讯中由服务端集中存储来保证，但在React构建的Web应用中，由于浏览器的无状态特性和网络的不确定性，实现起来比想象中复杂得多。
消息漫游的核心难点
消息漫游的第一道坎是可靠性。用户可能在地铁隧道里发送一条消息，网络瞬间断开，请求发出去但服务端没有响应；也可能服务端已经写入成功，但客户端在收到确认前就崩溃了。这种场景下，如果没有妥善的重试与幂等机制，就会出现消息丢失或重复。
第二道坎是顺序性。同一会话中，消息可能来自多个设备，每个设备本地生成的时间戳并不可靠，因为用户可能手动改过系统时间，或者不同设备的时钟本身就有误差。如果客户端单纯按本地时间排序，就会出现后发送的消息排到前面，或者对话上下文错乱的严重问题。
第三道坎是状态同步范围。消息漫游不仅包含新消息，还包含已读状态、撤回、编辑、删除等元数据。React本身只是视图层，它不负责持久化，也不负责网络同步。开发者必须在React之外构建一个独立的存储与同步层，才能让组件在重新挂载后依然能拿到完整的历史数据。这也正是本文要探讨的重点。
本地消息库设计：用IndexedDB撑起离线历史
localStorage虽然简单，但容量只有5MB左右，且只能存字符串，完全不适合存放大量消息。IndexedDB是浏览器内置的非关系型数据库，容量远大于localStorage，支持索引、事务和游标，是保存消息历史的理想选择。考虑到原生API过于繁琐，建议使用Dexie.js封装，让代码更符合日常开发习惯。
在设计消息对象时，需要包含几个关键字段：全局唯一的消息ID、会话ID、发送者ID、内容、客户端时间戳、服务端序号以及消息状态。其中服务端序号是消息在服务端全局递增的版本号，也是后续增量同步的核心依据。我们在Dexie中为消息存储建立索引，例如会话ID加时间戳的复合索引，以及单独的服务端序号索引。
import Dexie from 'dexie';
export const db = new Dexie('chatDatabase');
db.version(1).stores({
messages: 'id, conversationId, timestamp, serverSeq',
syncState: 'id, lastSeq, lastPullTime'
});
上面的代码创建了消息表和同步状态表。messages表以消息ID作为主键，conversationId和timestamp用于按会话查询历史消息，serverSeq则用于后续按序号拉取增量。syncState表保存每个会话已同步到的最大服务端序号，这样下次启动时只需要从这个位置继续拉取，不需要全量加载。
在React组件中，可以通过Dexie的liveQuery实现响应式读取，使消息列表自动跟随本地数据库变化。这样即使不依赖Redux或Context，也能让界面在数据写入后立刻更新。同时，由于IndexedDB是异步API，建议将数据库操作封装成独立的Repository模块，避免在组件中散落大量数据库逻辑。
增量同步协议：用版本号代替全量拉取
如果每次进入会话都请求全部历史消息，服务端压力大，客户端加载慢，还会浪费大量流量。正确的做法是采用基于版本号的增量拉取。服务端为每个会话维护一个递增的序号字段，每当新消息进入会话，序号加一。客户端记录该会话已拉取到的最大序号，再次同步时请求该序号之后的消息。
这样同步流程就变得非常清晰：进入会话时，先从本地数据库读取syncState中的lastSeq，然后向服务端发送带有会话ID和lastSeq的请求。服务端返回大于lastSeq的消息列表以及最新的序号。客户端把这些消息批量写入本地库，再更新syncState，整个过程中不需要把全量数据拉一遍。
async function pullIncremental(conversationId, lastSeq) {
const url = `/api/messages?conv=${conversationId}&after=${lastSeq}`;
const resp = await fetch(url);
const data = await resp.json();
return {
messages: data.messages,
latestSeq: data.latestSeq
};
}
上述函数返回的latestSeq就是服务端当前的最大序号。客户端拿到新消息后，先按serverSeq排序，再通过Dexie的事务批量写入。如果同一条消息已经被推送过，那么写入时会因为主键冲突而被覆盖，不会产生重复数据。最后将latestSeq写入syncState，完成一次增量同步。
这里还要注意网络异常时的处理：如果请求中途失败，lastSeq保持不变，下次同步时重新拉取即可。因为lastSeq在本地是单调递增的，服务端不会重复返回已经消费过的消息。这种基于游标的同步方式天然具备断点续传能力。
实时推送与断线补偿的双通道策略
增量拉取可以保证最终一致性，但实时性不足。用户发送一条消息后，如果等待下一次拉取才看到，体验会很迟钝。因此需要引入WebSocket建立长连接，让服务端实时推送新消息。React组件中可以在useEffect里创建WebSocket实例，并在依赖项变化时清理连接。
当WebSocket收到新消息时，客户端将消息写入本地IndexedDB，同时更新syncState。如果消息不是当前会话的，只需要更新数据库和对应会话的未读数，不需要立即刷新界面。这种设计让实时消息与历史记录走同一条本地数据通道，避免出现两套状态。
import { useEffect, useRef } from 'react';
export function useMessageSync(conversationId, onNewMessage) {
const socketRef = useRef(null);
useEffect(() => {
const socket = new WebSocket('wss://ipipp.com/ws');
socketRef.current = socket;
socket.onmessage = (event) => {
const msg = JSON.parse(event.data);
if (msg.conversationId === conversationId) {
onNewMessage(msg);
}
};
return () => socket.close();
}, [conversationId, onNewMessage]);
}
WebSocket连接不可能永远稳定，断线重连是必备能力。常见策略是在socket.onclose中设置定时器，间隔几秒后自动重连。重连成功后，不能只依赖推送，因为断开期间可能产生了大量消息，必须主动调用一次增量拉取，把断线期间的消息补回来。这个补偿逻辑可以放在onopen回调中，也可以放在重连成功后单独触发。
另一种更优雅的方案是引入消息序号确认机制。客户端每次收到推送并写入数据库后，向服务端上报当前已同步到的序号。服务端通过比对所有端的确认序号，来决定是否需要向某个设备重新推送补偿消息。这样既能实现实时推送，又能避免遗漏。
冲突处理与幂等去重，保障多端一致
多端同时在线时，冲突几乎不可避免。例如用户在电脑端撤回了一条消息，手机端也发起了同样的撤回操作，这时服务端可能收到两个撤回请求。如果处理不当，客户端会先看到消息消失，刷新后又出现，造成严重的不一致体验。
解决并发冲突必须依靠幂等机制。最简单有效的办法是让客户端生成全局唯一ID，并将该ID作为消息的主键。服务端在写入前检查主键是否已存在，如果存在则直接丢弃或返回已有消息。对于撤回、编辑这类操作，可以给每条消息增加一个操作序列号，采用最后写入者获胜的策略，即序列号大的操作覆盖序列号小的操作。
async function upsertMessages(messages) {
await db.transaction('rw', db.messages, async () => {
for (const msg of messages) {
const existing = await db.messages.get(msg.id);
if (!existing || msg.operationSeq > existing.operationSeq) {
await db.messages.put(msg);
}
}
});
}
上面的事务代码保证了同一条消息不会被重复插入，同时操作序号较大的数据会覆盖旧数据。由于整个过程处于同一个Dexie事务中，即使发生异常，数据库也能回滚到一致状态。注意这里使用了async/await循环，虽然性能不是最高，但胜在逻辑清晰且安全。
除了业务操作冲突，消息顺序也可能出现不一致。服务端序号是权威排序依据，因此客户端在展示消息列表时，必须先按serverSeq排序，再按本地时间戳排序。对于尚未同步到服务端的待发送消息，可以暂时使用负数的临时序号，并标记为待发送状态，等服务端确认后再更新为真实序号。
最后，多端一致性的验证不能只靠手工测试。建议在开发环境引入消息注入工具，模拟乱序、重复、延迟等网络异常，或者使用自动化测试框架对同步逻辑做集成测试。只有经过充分验证，消息漫游功能才能真正让用户在不同设备间无缝切换。