用户在政策快报平台的电脑网页上收藏了一条政策打开手机App发现收藏列表里没有在手机上阅读到一半的政策切换到小程序又要从头开始翻。这种体验在多端产品中并不少见但用户显然不会为此叫好。政策快报平台支持手机端、电脑端、小程序三端数据实时同步。用户在任何一端的行为收藏、阅读记录、申报任务状态都会自动同步到其他端。本文从技术角度拆解这套多端同步架构的设计思路。多端同步的三层架构第一层统一用户身份——同步的前提多端同步的前提是能够识别“这是同一个用户”。方案选型方案实现方式优点缺点传统Session服务端存储会话简单移动端支持差跨端困难JWT Token客户端存储加密令牌无状态易扩展无法主动失效OAuth2.0第三方授权安全性高实现复杂政策快报的选型JWT Token 刷新Token双令牌机制。用户登录后服务端返回access_token有效期2小时和refresh_token有效期7天。access_token过期后使用refresh_token刷新用户无需重新登录。跨端设备绑定json{ user_id: U10001, devices: [ {device_id: web_chrome_xxx, type: web, last_active: 2026-05-24 10:00:00}, {device_id: ios_app_xxx, type: app, last_active: 2026-05-24 09:30:00}, {device_id: miniprogram_xxx, type: miniprogram, last_active: 2026-05-23 20:00:00} ] }用户可以在任意端查看已登录的设备列表并支持远程踢出某个设备。第二层数据同步策略——实时性与成本平衡多端同步的核心挑战在于既要保证数据实时一致又要控制服务器压力和网络流量。政策快报的混合策略数据类型同步策略说明用户基本信息实时拉取每次启动App/打开网页时拉取最新收藏/关注实时推送 轮询兜底操作后立即推送同时每5分钟轮询阅读历史本地缓存 定期上传阅读记录先存本地每10分钟批量上传申报任务状态实时推送状态变更对时效性要求高政策内容按需拉取 CDN缓存政策内容变化频率低无需实时同步实时推送方案WebSocketjavascript// 用户在一个端执行收藏操作 function onCollect(policyId) { // 1. 本地更新UI updateLocalCollectStatus(policyId, true); // 2. 发送API请求 api.collect(policyId).then(() { // 3. 通过WebSocket推送消息到该用户的其他端 websocket.send({ type: SYNC_COLLECT, policy_id: policyId, action: add, timestamp: Date.now() }); }); }其他端收到推送消息后自动更新本地缓存和UI无需用户手动刷新。离线场景处理移动端网络不稳定是常态。政策快报App和小程序实现了离线缓存机制用户浏览过的政策内容自动缓存到本地有效期7天离线状态下的收藏、标记操作先存入本地队列网络恢复后按顺序自动同步到服务端第三层冲突处理——多端同时操作怎么办用户可能在手机和电脑上同时操作或者网络延迟导致先后顺序错乱。需要设计冲突处理规则。政策快报的冲突处理规则场景规则示例收藏/取消收藏以后者为准手机收藏、电脑取消收藏 → 最终为取消收藏阅读进度取最大值手机读到50%电脑读到80% → 同步后显示80%申报任务状态以服务端为准多端同时提交状态变更 → 服务端按接收顺序处理用户资料修改以后者为准加冲突提示多端同时修改手机号 → 提示用户确认版本号机制乐观锁sql-- 用户设置表增加version字段 CREATE TABLE user_settings ( user_id VARCHAR(32), setting_key VARCHAR(64), setting_value TEXT, version INT DEFAULT 1, update_time TIMESTAMP ); -- 更新时检查版本号 UPDATE user_settings SET setting_value new_value, version version 1 WHERE user_id U10001 AND setting_key notification_pref AND version 1;如果version不匹配说明已被其他端更新更新失败客户端需要重新拉取最新数据后再提交。第四层性能优化——让同步“无感”多端同步的终极目标是用户感觉不到同步的存在一切都是“自然发生”的。政策快报的优化手段优化点方案效果接口响应速度Redis缓存热点数据CDN加速静态资源P99响应时间200ms首屏加载关键数据优先加载非关键数据懒加载首屏时间1.5秒网络开销增量同步只传变化的数据Gzip压缩同步流量减少60%弱网体验超时重试3次降级策略优先展示缓存弱网下仍可基本使用架构总览text┌─────────────────────────────────────────────────────────────┐ │ 用户设备层 │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ Web端 │ │ App端 │ │ 小程序端 │ │ │ └────┬─────┘ └────┬─────┘ └──────┬───────┘ │ │ │ │ │ │ │ └───────────────┼──────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ API网关统一入口 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ ┌──────────────┼──────────────┐ │ │ ▼ ▼ ▼ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ 用户服务 │ │ 数据服务 │ │ 推送服务 │ │ │ │(JWT/设备) │ │(CRUD/缓存) │ │(WebSocket) │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ │ │ │ ┌──────────────┼──────────────┐ │ │ ▼ ▼ ▼ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ PostgreSQL │ │ Redis │ │ Kafka │ │ │ │ (主数据) │ │ (缓存) │ │ (消息队列) │ │ │ └────────────┘ └────────────┘ └────────────┘ │ └─────────────────────────────────────────────────────────────┘政策快报平台的多端同步架构仍在持续演进中。下一步的方向包括智能预加载根据用户的使用习惯预判可能在另一端访问的内容提前同步到本地端到端加密敏感数据如企业财务信息在客户端加密后再上传服务端只存储密文离线完整模式在无网络环境下用户仍可完成申报材料的填写和保存网络恢复后自动提交如果你也在从事多端同步或移动端架构相关的开发工作欢迎在评论区交流你在冲突处理、离线缓存或推送服务方面的实践经验。
