多端同步与离线优先：本地缓存、同步协议与冲突解决

设备矩阵与使用模式：
□ 手机：随时写、随手拍、高频短互动
□ 平板：长文创作、浏览
□ 桌面/Web：运营、后台、批量管理
□ 多设备同时在线：手机写、平板看、Web 管理

一致性需求分级：
□ 强一致：支付、计费、订单（不可冲突）
□ 最终一致：帖子、草稿、互动（可短暂不一致，最终收敛）
□ 无所谓：缓存类数据（过期可接受）

微型博客典型对象的一致性等级：
□ 内容/草稿：最终一致（核心）
□ 互动计数（点赞数）：最终一致 + 可近似
□ 会话/登录态：必须同步（安全相关）
□ 个性化设置：最终一致 + 低冲突

用户体验原则：
□ 本地永远可写：没网也能创作，不打断
□ 写入立即可见：乐观更新，不等服务器
□ 冲突尽量少打扰：自动合并 > 弹窗让用户选
□ 同步透明：进度可见（「已同步/待同步」）

架构目标：
写本地 → 同步云端 → 推其他端 → 多端收敛
（读多写多的数据也要做到「处处一致」）

本地缓存设计：
□ 存储选型：SQLite / IndexedDB / 本地 KV
  · 移动端：SQLite（结构化、事务）
  · Web：IndexedDB
□ 数据分层：热数据内存 + 温数据本地库 + 冷数据云端
□ 缓存失效：本地数据与云端版本比较 → 更新

乐观更新流程：
用户操作 → 本地立即生效（UI 更新）→ 记入待同步队列
  → 网络恢复 → 发送服务器 → 服务器确认 → 队列清项
  → 失败 → 保留队列 + 提示重试

乐观更新的要点：
□ UI 反馈：写入立即反映，但可标记「待同步」
□ 幂等：重试不会产生重复数据（客户端生成唯一 ID）
□ 顺序：同一对象的多笔操作按序发送

待同步队列（Outbox）：
□ 持久化：队列存本地数据库，App 杀掉不丢
□ 状态机：pending → sending → sent / failed
□ 重试策略：指数退避 + 上限
□ 合并优化：同一对象的连续编辑可合并（只发最新版本）

常见坑：
□ 本地写入成功、同步失败 → 用户以为发了其实没发
□ 多端同时编辑 → 冲突（见第 4 节）
□ 缓存无限膨胀 → 设置容量上限 + 淘汰策略

版本跟踪：
□ 版本号（单调递增）：简单但无法表达「并发」
□ 版本向量（Version Vector）：
  · 每个设备一个计数器：{phone: 5, web: 3, pad: 2}
  · 向量比较：A ≤ B 当且仅当 A 每个分量 ≤ B
  · 可判断：谁领先 / 谁落后 / 是否并发
□ Lamport 时钟：加时间戳，适合事件排序，不擅长冲突判定

同步判定：
□ 某端版本 ≤ 云端版本 → 服务器领先 → 拉取更新
□ 某端版本 > 云端版本 → 本地领先 → 上传
□ 两者不可比（并发）→ 需要合并（冲突解决）

CRDT（无冲突复制数据类型）：
□ 目标：并发编辑也能收敛到同一结果，无需中心仲裁
□ 常见类型：
  · 计数器（Counter）：点赞数 → G-Counter（只增）
  · 集合（Set）：关注列表 → 添加/删除标记
  · 文本/列表（LWW 或多值）：草稿 → 按「最后写入者胜」
□ 原理：合并操作满足交换律/结合律/幂等
  · 任何顺序合并结果一致

CRDT 工程取舍：
□ 通信开销：元数据（版本/墓碑）随数据增长
□ 复杂度：实现与调试难度高
□ 适用：小对象、低频编辑 → 值类型用 CRDT 很划算
□ 不适用：高冲突、强业务规则的场景 → 中心仲裁更简单

冲突解决策略谱系：
1. LWW（Last-Write-Wins）：最后写入者胜
   · 最简单，但不总是正确（旧设备晚同步可能覆盖新内容）
   · 改进：以服务器接收时间为准，而非客户端时间
2. 字段级合并：不同字段的冲突分开处理
   · 手机改了标题、平板改了正文 → 两者都保留
3. 结构化合并（CRDT）：按 CRDT 规则自动收敛
4. 用户介入：冲突不可自动解决时让用户选
   · 提供「保留我的版本 / 保留对方版本 / 手动合并」

选择原则：
□ 冲突代价低（计数、设置）→ 自动（LWW/CRDT）
□ 冲突代价高（长文本、业务数据）→ 自动合并优先，兜底用户介入

合并工程质量：
□ 冲突记录：被合并掉的版本要留痕（可恢复）
□ 合并预览：用户介入前展示差异（diff）
□ 多版本保留：草稿可保留多个分支（类似版本历史）
□ 合并测试：并发场景的测试套件（同字段/跨字段/同版本）

社交对象冲突示例：
□ 帖子编辑：手机改正文、Web 改标题 → 字段级合并
□ 互动计数：点赞并发 → G-Counter 加合并
□ 关注/取关：并发添加与删除 → 以时间线/意图为准

E2EE 数据模型：
□ 明文只存在于用户设备，服务器存密文
□ 密钥对：每用户生成公钥/私钥（私钥不离开设备）
□ 多端密钥分发：
  · 每端有独立密钥对
  · 端 A 分享数据给端 B：用 B 的公钥加密
  · 新设备加入：通过已信任端（或恢复码）获得密钥
□ 服务器角色：只做存储与转发，无法解密内容

实现挑战：
□ 搜索：密文下如何全文搜索 → 客户端搜索 / 可搜索加密（SSE）
□ 缩略图：图片密文无法服务端生成缩略图 → 客户端生成 + 单独加密
□ 多端协作：密钥共享机制（群组/多设备）

密钥生命周期：
□ 密钥生成：注册时生成，恢复码（助记词）备份
□ 密钥轮换：设备丢失/怀疑泄露 → 重生成 + 重加密
□ 密钥吊销：旧设备不再信任 → 吊销其密钥

工程要点：
□ 端 SDK 统一封装加解密，业务无感
□ 密文元数据：消息元数据（发件人/时间）通常不加密（性能与排序）
□ 合规：E2EE 与内容审核/举报的矛盾 → 客户端审核 / 报告机制

增量同步设计：
□ 增量协议：客户端上报「本地版本」→ 服务器返回「差集」
□ 同步锚点：cursor / since_id（自某点以来的变更）
□ 变更日志：服务器端记录每个对象的变更流（append-only）
  · 客户端拉取：since < 某游标的所有变更
  · 客户端合并：应用到本地，更新本地版本

补丁（Patch）传输：
□ 文本补丁：Myers diff / 操作变换（OT）编辑操作序列
□ 二进制补丁：图片/附件的增量（块级去重）
□ 补丁比全量小几个数量级 → 省流量、省时间

变更日志设计：
□ 对象 ID + 版本 + 变更类型（create/update/delete）
□ 墓碑（Tombstone）：删除也记一条，供其他端收敛
□ 日志清理：超过同步窗口的日志归档/压缩

同步性能指标：
□ 同步体积：首次全量 vs 增量的大小比
□ 同步延迟：从「其他端变更」到「本端可见」的时长
□ 拉取频率：心跳 / 推送触发 / 本地操作触发

实现注意：
□ 游标语义：since 游标要稳定（不能因日志清理跳变）
□ 大附件：先同步元数据，图片/视频按需懒加载
□ 断点续传：大批量同步可中断恢复

同步触发链路：
本地变更 → 上传服务器 → 服务器广播 → 推送其他在线端
  → 离线端下次唤醒时拉取

推送通道：
□ 长连接（WebSocket）：实时性好，适合在线端
□ 系统推送（APNs/FCM/Web Push）：端不在前台时的唤醒
□ 拉取轮询：低成本兜底（低实时性场景）

推送内容设计：
□ 轻推送：只推「对象 ID + 新版本号」，客户端再拉取
□ 重推送：直接带变更数据（小对象）
□ 推送合并：批量变更合并成一条（防推送风暴）

同步基础设施组件：
□ 变更广播服务：订阅（客户端感兴趣的频道）
□ 变更队列：变更进队列 → 异步推送（削峰）
□ 端状态管理：在线/离线/长离线，不同策略

一致性与规模：
□ 订阅模型：客户端订阅「关注对象 + 自身相关」的变更
□ 扇出：一个创作者更新 → 推给所有订阅端（大 V 用订阅分发）
□ 去重：同一对象的多次变更合并推送

失败处理：
□ 推送失败 → 进入「待拉取」状态（端下次主动同步）
□ 离线期间的变更 → 增量拉取补上
□ 推送通道不可用 → 降级为轮询

离线优先设计原则：
□ 一切操作本地可完成：创作、编辑、互动、设置
□ 网络只是同步手段，不是可用性前提
□ 离线状态是常态：地铁、隧道、弱网是默认环境

离线能力覆盖：
□ 读：本地缓存展示最近内容（可标记「过期」）
□ 写：Outbox 队列累积，恢复后同步
□ 互动：点赞/评论先本地生效，恢复后合并
□ 媒体：图片/视频按需下载，弱网降清晰度

恢复流程：
断网 → 本地操作累积 → 网络恢复
  → 增量同步（拉取云端变更 + 上传本地变更）
  → 冲突合并 → 收敛到一致 → 清除「待同步」标记

恢复的工程细节：
□ 恢复优先级：先同步会话/账号状态，再内容，再媒体
□ 同步顺序：依赖关系（先建对象，再挂互动）
□ 恢复进度：用户可见的「同步中」状态与进度
□ 弱网优化：请求合并、压缩、断点续传、自适应重试

离线监控：
□ 离线时长分布：多少用户在离线多久
□ 离线操作量：离线产生的写入比例
□ 恢复成功率：恢复后数据完整性的校验

多设备会话管理：
□ 会话状态：登录态在哪些设备有效，可见可管理
□ 设备列表：用户可查看/吊销某台设备（安全）
□ 会话迁移：从旧手机迁到新手机（QR 扫码 / 恢复码）

多端状态同步对象：
□ 阅读进度：A 设备读到哪 → B 设备接着读
□ 草稿状态：草稿在多个设备间同步（核心对象）
□ 设置/偏好：主题、通知设置、内容过滤
□ 编辑中的内容：跨端接力创作（光标/选择）

状态迁移场景：
□ 换机：新设备完整接管（账号数据 + 密钥 + 设置）
□ 多端接力：手机开始写，Web 继续写
□ 端冲突：两端同时改设置 → 按同步协议合并

工程实现：
□ 设备注册：每端唯一 device_id + 密钥绑定
□ 状态版本：阅读进度等用「版本 + 时间」同步
□ 迁移流程：
  · 验证（扫码/密码/恢复码）→ 绑定新设备
  · 密钥迁移（E2EE 场景）→ 数据全量/增量拉取
  · 旧设备降级/吊销

安全底线：
□ 新设备登录要通知其他设备（「有设备在你附近登录？」）
□ 设备吊销要立即生效（Token 撤销 + 推送通知）