在地铁里修改一笔支出，回到网络稳定的地方后，另一台设备也能看到结果。这段体验包含两件分别完成的事：把修改可靠地保存在当前设备，以及让其他设备收到云端确认后的状态。
与海把本地保存放在前面。网络决定修改什么时候传到其他设备，不应该决定你能不能先记下来。
一次修改怎样到达另一台设备
假设你把一笔午餐支出从 32 元改为 35 元。记录会先写进本地数据库，页面从本地读取结果。同时，待上传的修改进入持久化队列。只要本地数据仍在，临时断网或重新打开 App 不需要让你重新输入这次修改。
联网并开启记录同步后，设备按队列提交操作。服务端验证账号归属、数据格式和当前状态，把接受的修改写入云端，再向同一账号的已连接设备分发变化。其他设备更新自己的本地副本，页面随之刷新。
本地已保存、云端已接受、另一台设备已收到，是三个不同的状态。 设备离线、网络延迟或系统后台限制，都可能让它们之间出现间隔。
为什么不用反复上传整个数据库
日常记录大多是局部变化。修改金额时，没必要把所有日记和习惯重新传一遍。同步链路跟踪已处理进度，持续传递账号范围内的变化；设备恢复连接后继续追赶缺少的部分。
新设备需要先建立本地副本，之后再接收增量。同步进度中的确认点用于判断客户端是否已经接收到某一阶段的云端状态。连上网络本身，还不能证明数据已经追齐。
网络重试会不会产生两笔记录
网络可能在服务端已经保存之后断开。客户端没有收到响应，就会再次提交同一批修改。
与海用设备身份和请求标识识别这次重试，并保存原请求的处理回执。同一个请求、同一份内容再次到达时复用原结果；如果标识相同而内容不同，则拒绝把它当成同一次请求。这能避免响应丢失导致重复执行，但用户主动新建两笔相同支出，仍然是两次独立操作。
两台设备同时修改，采用什么规则
当前 App 的业务记录上传采用本机提交优先策略：服务端接受某台设备提交的修改时，使用该操作携带的字段值。多台设备陆续提交同一字段，后被接受的值可能覆盖先前的值；顺序取决于服务端处理，而不是哪台设备显示的时间更晚。
这里有一个容易误解的细节：一条记录的业务正文可能包含金额、分类、备注等多个属性。正文作为一个字段提交时，覆盖范围可以包含这些属性，不能把它理解为每个输入框都能无损拼接。
例如，A 和 B 都从同一旧版本开始编辑。A 改了金额，B 改了备注；如果两次提交都携带完整正文，后接受的正文可能带回旧金额。因此，重要记录尽量等一台设备同步完成后再到另一台继续修改。
三方比较为什么仍然有价值
同步写入层还提供三方比较策略：对比编辑前的值、云端当前值和这次提交的值。互不冲突的对象属性可以合并；同一路径被双方改成不同值时，保存冲突回执并保持云端当前记录。数组作为整体比较。存在真实冲突时，该条修改不会只写入其中一部分。
这是另一种处理策略，不能拿它来描述当前 App 的默认上传行为。长文本更新也有独立的数据通道，但这不代表所有日记输入框都具备实时多人协作能力。
多端同步的范围
同步围绕同一账号的记录身份展开，手机平台的差异由各端处理。记录中的附件引用和图片文件分开传输，因此文字出现时，图片可能仍在下载。AI 聊天历史也走自己的保存和读取路径，不等同于业务记录同步。
多设备连续使用需要兼容的客户端、同一账号、已开启的同步和有效连接。本文解释这条数据链路，不代表所有桌面端、浏览器端都已经提供完整客户端。
同步会传播最新修改，也可能传播误改。需要保留某个时间点的状态，请继续阅读云备份与完整恢复。