实时同步机制，2.0 大版本重构后跨端体验明显改善
为什么要重构
在 1.x 时期，Ticking 的同步逻辑主要依赖 HTTP 轮询——每隔几十秒向服务器拉一次最新状态。这个方式在单端使用时够用，但在多端同时在线时容易出现数据冲突：比如两端同时完成了不同的待办，最后谁后同步谁覆盖。
2.0.0 版本重构成了长连接 + HTTP 补偿的双通道：
- 主通道是 WebSocket 长连接——服务器推送变更，几乎实时
- HTTP 作为补偿——长连接断开或切换网络时，自动降级到短轮询
同步速度
2.0 之后的实测表现：
| 操作 | 多端同步延迟 |
|---|---|
| 完成一个待办 | 1-3 秒内其他设备可见 |
| 启动 / 结束计时 | 1-2 秒内可见 |
| 自习室在线状态 | 2-5 秒内其他成员可见 |
| 修改计划排期 | 1-3 秒内所有设备同步 |
网络状况好时基本在 1-2 秒内，移动网络切换时可能有短暂延迟（最多 10 秒），但不会丢失。
冲突处理
两端同时做不同操作时（比如 A 手机完成了待办 X，B 手机同时修改了待办 X 的分组），Ticking 的处理逻辑是以最后一次写入为准——不是按设备优先级，而是按服务器时间戳。这样能保证最终一致性，但极端情况下（比如非常快地在两端交替操作）可能出现短暂的不一致。
离线时的表现
没有网络时：
- 待办添加 / 删除 / 分组移动 → 本地先记下来，恢复网络后自动批量同步
- 计时 → 本地计时不受影响，但统计数据等网络恢复后再同步
- 自习室 → 离线时看不到成员在线状态，恢复后自动刷新
离线期间做的操作有一个最大累积量限制——如果断网超过 24 小时，本地缓存的变更可能会被丢弃（这个上限以官方最新为准）。
隐私与加密
Ticking 声称同步数据经过传输加密（HTTPS / WSS），服务器端存储也做了基础加密处理。但和所有云同步应用一样——如果有安全顾虑，建议定期做本地数据备份（见下一篇数据迁移）。