多端同步的核心是各端基于统一规则和数据源独立推导一致状态。需分层管理状态：服务端权威、设备局部、用户偏好；采用事件驱动的增量同步机制；用状态机+副作用分离保障逻辑一致；冲突时乐观更新并自动合并。
多端同步的核心不是“把状态复制过去”，而是让各端基于同一套规则和数据源，独立推导出一致的状态。关键在于剥离 UI 层依赖，把可同步的状态收敛到服务端或统一中间层，并通过明确的变更传播机制驱动本地更新。
状态分层：哪些该同步，哪些不该同步
不是所有状态都需要跨端对齐。区分三类状态：
- 服务端权威状态：用户登录态、核心业务数据（如订单状态、文档内容）、配置项——必须以服务端为准，各端只读+带版本号拉取
- 设备局部状态：窗口大小、滚动位置、键盘焦点、临时草稿（未提交）——不跨端同步，也不应尝试同步
- 用户偏好型状态：主题模式、列表排序方式、通知开关——可同步，但需支持端内覆盖（比如手机默认关通知，PC 默认开），用“最后写入优先 + 客户端标记”策略
同步机制：避免轮询，用事件驱动替代
轮询延迟高、浪费资源；直接 WebSocket 全量推送又太重。推荐组合方案：
- 登录/切换账号时，全量拉取一次用户级状态快照（含版本号 v123）
- 后续变更由服务端通过轻量消息通道（如 MQTT 主题
user/{id}/state）推送增量 diff，含操作类型（set/delete）、字段路径（ui.theme）、新值、版本号 - 客户端收到后校验版本号是否连续，跳变则触发一次快照回补，防止消息丢失累积误差
本地状态管理：用“状态机 + 副作用分离”保证一致性
移动端与 PC 端 UI 差异大，但状态逻辑应复用。建议：
- 用有限状态机（如 XState）定义状态流转规则，例如
editorMode: 'view' → 'edit' → 'preview'，各端只订阅状态，不直接操作 DOM 或 View - 副作用（如自动保存、日志上报、UI 动画）全部抽离为独立 service，在状态变更后由统一 dispatcher 触发，避免两端逻辑不一致
- 本地缓存使用带 TTL 的 IndexedDB（PC）或 AsyncStorage（React Native），但仅作容错备份，不作为事实来源
冲突处理：乐观更新 + 自动合并是底线
当两端同时修改同一字段（如两个设备同时编辑文档标题），不能简单“谁最后谁赢”：
- 所有可编辑字段携带时间戳和设备 ID，服务端按逻辑合并（如取最新时间戳，冲突时保留两版并标记
conflicted: true） - 前端展示冲突提示时，显示两版内容+修改人+时间，提供一键采用某版或手动合并入口
- 对非文本类状态（如开关、枚举），采用“最后有效值”策略，但记录操作日志供审计
