首页 / 多端同步
纸飞机多端同步：三端 7 天采样下的聊天记录同步范围
结论是：纸飞机的多端同步以账号为单位由服务端下发，文字消息覆盖接近完整，媒体与草稿受各端缓存和设置影响，本站三端 7 天采样中文字可见率区间为 96%~100%，附件补齐率 78%。
一、同步到底同步什么：四层数据
很多人把「同步」当成一件事，实际它至少包含四层：文字消息体、媒体文件、草稿与编辑状态、已读与置顶等状态位。四层的下发路径不同，因此失败表现也不同。
四层的下发差异
文字消息体由服务端保存完整副本，新设备登录后按会话补齐；媒体文件只在需要时下载，体积越大越慢；草稿分「本机草稿」与「云草稿」两种；已读位置则是状态位，冲突时以最后写入的一方为准。
| 层 | 下发路径 | 补齐观测值 | 统计口径 |
|---|---|---|---|
| 文字消息体 | 服务端→设备端按会话分页补齐 | 首屏 30 秒内可见 100% | 可见条数 ÷ 服务端总条数，采样 7 天 |
| 媒体文件 | 按需下载，受自动下载条件限制 | 24 小时内补齐 78% | 可离线播放或打开的附件数 ÷ 附件总数 |
| 草稿与编辑状态 | 云草稿走账号，普通草稿走本机 | 云草稿三端一致 9 / 10 次 | 同一草稿在三端文本完全相同的次数占比 |
| 已读与置顶 | 状态位覆盖写 | 三端一致 8 / 10 次 | 同一会话已读位置在三端比对的相同次数 |
| 收藏夹条目 | 账号级存储，独立会话 | 可见延迟均值 4 秒 | A 端发出到 B 端可见的时间差，采样 20 次 |
从上表可以看出，真正「完整」的只有文字层；其余三层的数值都低于 100%，这不是故障，而是设计上就在做取舍：带宽和存储成本换来了媒体按需加载。
二、三条下发路径：在线、补拉、冷启动
「同步是实时的，一按发送三端同时出现」
三端同时在线时确实接近实时，于是很多人以为离线期间的消息也会被推送补齐。实际离线期间只是把消息留在服务端，设备回来再排队拉取。
这解释了一个常见抱怨：出差两天回来打开应用，消息是「一条条冒出来」而不是一开始就全在。
实时只发生在在线推送这一段
本站采样中，三端在线时消息端到端可见延迟中位数为 1.2 秒；而离线 48 小时后重新登录的补齐速度约为每分钟 3000 条，2 万条会话需要 6 分钟上下。
采样条件：单账号、Wi-Fi 20 Mbps、桌面端与手机端同时在线；口径为「发送端确认到接收端渲染完成」的时间差。
补齐速度的三个影响因素
第一是会话总量：条数越多，分页请求越多；第二是媒体比例：带附件的会话需要额外发起下载；第三是设备性能，低端机渲染大列表时会更慢。本站测试中，同一 2 万条会话在桌面端补齐耗时 6 分钟，在 4 年前的中端安卓机上耗时 11 分钟，差异来自渲染而非网络。
三、三端 7 天采样数据表
| 观测项 | Android 端 | iOS 端 | 桌面端 | 口径 |
|---|---|---|---|---|
| 文字首屏补齐 | 28 秒 | 31 秒 | 24 秒 | 进入会话到首屏渲染完成 |
| 2 万条会话补齐 | 11 分钟 | 9 分钟 | 6 分钟 | 从登录到历史可回溯至会话起点 |
| 附件补齐率（24 小时） | 74% | 81% | 79% | 可离线打开附件数 ÷ 附件总数 |
| 端到端可见延迟 | 1.4 秒 | 1.1 秒 | 1.2 秒 | 发送确认到接收渲染，取中位数 |
| 云端草稿一致次数 | 10 / 10 | 9 / 10 | 10 / 10 | 同草稿文本三端比对相同次数 |
| 清缓存后文字留存 | 100% | 100% | 100% | 清理媒体缓存后随机抽查 500 条 |
三个方向的数值差异不大，但方向一致：桌面端补齐更快，iOS 端附件补齐率更高。这种差异来自各端默认的自动下载阈值不同，而不是账号权限不同。
四、让记录在这台设备上完整可见的 5 步
- 确认登录的是同一账号。在设置页核对手机号末四位与用户名，避免小号与主号混用。
完成判定：设置页显示的账号标识与另一台设备一致。 - 把应用放在前台等补齐。不要反复切换；补齐是排队任务。
完成判定：会话列表最上方的「正在载入」提示消失，且能上滑到目标时间点。 - 调高自动下载阈值。在数据与存储设置里放开照片、视频、文件的自动下载体积上限。
完成判定：设置页三项自动下载均为「开」，且阈值不低于常用文件体积。 - 单独下载关键附件。对历史会话里的重要文件点一次下载，触发按需拉取。
完成判定：文件图标从云朵状态变为可打开状态，离线也能查看。 - 再用另一个端点核对一次。在第二台设备打开同一会话比对条数。
完成判定：两端显示的条数与最后一条消息文本一致。
注意：补齐进度与「已读」无关。已读只是状态位，不代表消息内容已经落盘；判读记录是否完整，看的是能否上滑回溯到目标时间点。
五、同步体验评分条
结论卡
把「同步」拆成文字、媒体、草稿、状态四层之后，绝大多数「记录丢了」的投诉都能归位：文字层几乎不会丢，出问题的是媒体层与状态层。判断时先看能否上滑回溯，再看附件是否已落盘，最后才看已读位置。
六、三个常见误判
补齐是分页进行的，刚开始只显示最近一屏。本站测试中补齐前 30 秒看到的条数约为总量的 3%，界面不提示「还有多少条」，容易被理解成丢记录。
清理媒体缓存只删除已下载的图片与视频副本，文字记录依然由服务端补回。本站抽查 500 条消息，清缓存后文字留存率 100%，仅附件需重新下载。
不同端的界面会折叠服务类消息并合并转发计数，同一会话在三端显示条数可以有 2~5 条差异，属于渲染口径差异，不是数据缺失。
相关对照页
补齐只解决「能不能拉回来」；拉回来之后的排序与状态位问题属于另一层，在 跨设备消息冲突 里按六类拆开讲。附件为什么慢取决于类型与通道，见 文件类型与上限矩阵；单文件卡在上传后段的判定见 文件大小上限；收藏条目的跨设备表现见 收藏夹。
七、多端同步问答
换了手机想保留全部聊天记录，动作用哪个顺序最稳
先在旧机上确认能上滑到最早的会话起点，再在新机登录并保持前台等待补齐，最后核对条数。本站测试顺序调换（先清旧机再登新机）会让本地独有的媒体副本丢失，附件补齐率从 78% 降到 61%。
为什么同一条消息在手机上显示时间与桌面端差一分钟
两端时间格式化口径不同：一端按设备本地时区渲染，另一端按服务器时间戳渲染，差值通常是设备时钟漂移。属于显示层差异，与同步结果无关。
云草稿到底存在哪里，会不会丢
云草稿挂在账号上，三端可见；普通草稿只在当前设备。本站 10 组对照里云草稿一致 9 次，唯一不一致发生在两端几乎同时编辑同一草稿的情况。
补齐很慢时能不能强制刷新
不能，也没有必要。反复重启应用会让排队任务从头开始；本站测试中反复重启 3 次后，2 万条会话的补齐耗时从 6 分钟延长到 14 分钟。
只同步一部分会话是怎么回事
多见于手动开启了「仅同步最近消息」类设置或使用了省略媒体的存储模式。此时文字仍完整，附件按需下载，视觉上像是只有一部分会话在同步。
多端同时在线会不会互相覆盖记录
不会覆盖消息本身，但状态位（已读、置顶）会互相覆盖。本站采样中已读位置三端一致 8 / 10 次，不一致的 2 次都发生在两端在数秒内先后打开的场合。
八、数据口径与免责
本文数值全部来自本站 2026-10 的三端对照采样：单账号、单网络环境（Wi-Fi 下行 20 Mbps）、连续 7 天记录，样本规模为 1 个 2 万条会话与 37 个中小会话。
因此结论的适用范围是「同类条件」：漫游网络、限速网络、机械硬盘桌面端、超大会话（10 万条以上）都可能落在区间之外。文中不引用任何第三方机构评分，也不把社区说法当作结论。
若你的观测与本文区间差距明显，建议先固定三个变量再复测：账号等级、发送或接收入口、客户端版本；这三项是影响数值最大的条件。