通过维护一个全局递增的序列号（sequence number）并配合 fetch api 的 get 请求实现增量同步。具体做法是在首次请求时获取当前最大序列号，后续请求将该序列号作为参数传递给服务端，服务端仅返回大于该序列号的新数据。这样做可以显著减少网络传输量，避免全量拉取带来的性能瓶颈。
如何设计支持序列号的接口与客户端逻辑
核心在于利用 HTTP 请求头或查询参数传递当前的 lastSeq。客户端在发起请求前，必须先从本地存储或上一次响应中读取最新的序列号。如果本地没有记录，则视为初始状态，请求所有数据。服务端接收到请求后，根据这个序列号过滤数据，只返回更新的部分。这种机制要求数据源具备单调递增的时间戳或自增 ID，以确保顺序的一致性。
const syncData = async (lastSeq) => {
const url = lastSeq ? `/api/data?since=${lastSeq}` : '/api/data';
const response = await fetch(url);
if (!response.ok) throw new Error('Network error');
const result = await response.json();
return result;
};
// 模拟调用
syncData(100).then(data => console.log(data));
上述代码展示了最基础的实现方式。当 lastSeq 为 100 时，URL 变为 /api/data?since=100。服务端应返回包含新数据的数组以及新的最大序列号。客户端需要解析响应中的 newSeq 并更新本地状态。若服务端返回空数组，说明无新数据，此时不应丢弃旧的序列号，而应继续等待下一次轮询。
立即学习“Java免费学习笔记（深入）”；
如何处理并发冲突与数据一致性
在增量同步过程中，最大的风险是网络延迟导致的重复拉取或数据丢失。例如，用户快速切换页面可能导致多个请求同时发出，它们携带相同的 lastSeq，从而获取到相同的数据块。解决这个问题的关键在于引入乐观锁或版本号校验。每次获取数据后，不仅要更新序列号，还要验证返回数据的完整性。如果发现数据断层，应触发全量重新同步。
let currentSeq = 0;
let isSyncing = false;
async function safeIncrementalSync() {
if (isSyncing) return;
isSyncing = true;
try {
const res = await fetch(`/api/data?since=${currentSeq}`);
const json = await res.json();
// 检查数据连续性
if (json.data.length > 0 && json.data[0].seq <= currentSeq) {
throw new Error('Data inconsistency detected');
}
currentSeq = json.maxSeq;
updateUI(json.data);
} catch (e) {
console.error('Sync failed, forcing full reload', e);
await fullReload();
} finally {
isSyncing = false;
}
}
这段代码引入了 isSyncing 标志位来防止并发请求造成的资源浪费和状态混乱。同时，通过检查返回数据的第一条记录的 seq 是否小于等于当前已知的 currentSeq，来检测是否存在数据重叠或丢失。一旦检测到不一致，立即放弃增量同步，转而执行 fullReload() 进行全量重置。这种策略虽然牺牲了少量带宽，但保证了数据的最终一致性。
基于特定输入条件触发的异常处理机制
当服务端返回的 maxSeq 小于客户端本地的 lastSeq 时，通常意味着服务端发生了数据回滚或清理。这是一个严重的异常状态，不能简单地忽略。在这种情况下，客户端必须强制清除本地缓存并重新拉取全量数据。这种边界条件的处理是增量同步稳定性的关键，确保系统不会陷入死循环或持有过期数据。
