十月补记：本文于 2026 年 10 月 25 日整理并首次发布，页面日期用于归档对应时期的实践；后续修整一并写入。产品开放范围以文中链接的公开说明为准。
用手机拍下一道日语题，回到电脑前接着追问，是我做日语随记与陪练同步时很想保留的场景。
但“资料能同步过去”和“同步时依然好用”，中间还有一段路。一次很小的编辑，如果牵动整份资料重新编码、重新写盘，界面就可能跟着等待。照片一多，这种差别会更明显。
这次整理里，我把注意力从“网络有没有通”往前挪了一步：每次变化，手机究竟在本地重做了多少工作？
改了一条笔记，为什么要搬整本书#
最初把资料整体保存，很容易理解：读出来是一份完整状态，写回去也是一份完整状态。数据少时，这种做法也很直接。
问题出在频率和体积同时增长。改一句说明、更新一次同步位置，都可能让没有变化的照片和旧笔记一起被重新处理。用户做的是一个小动作，系统做的却是一场大搬家。
如果这段工作还占着负责界面响应的主线程，按钮、输入和滚动就会受到影响。于是用户以为“同步网络很慢”，真正的等待却可能发生在发出请求之前。
我把小变化和完整状态分开保存#
可以把完整状态想成一本整理好的账本，把之后的变化想成按顺序追加的小记录。平时只记录变了什么，到合适时机再把这些变化归并成新的完整状态。
这样能减少每次都处理全量资料的机会。编码、计算差异和写盘也放到后台有序执行，让界面尽快继续响应。
但只说“换到后台”还不够。同一条资料的新旧修改，仍要按正确顺序保存；磁盘写不进去时，不能假装已经安全落地。后台工作只是改变执行位置，没有自动解决可靠性。
网络回了旧结果，也不能盖掉新编辑#
用一个自编例子说明：手机把笔记里的“车站”改成“駅”，请求发出后，我又补了一条例句。几秒后，前一个请求的响应才回来。
此时不能因为服务器回了成功，就把本地整条笔记还原成发请求时的旧样子。请求期间新增的例句，仍然属于用户当前的编辑。
同样，响应丢失之后重试，要能认出这是同一项修改，而不是再新增一份。切换账号后，旧会话迟到的结果也不能被写进新账号。这些问题都需要和本地保存一起考虑。
变快之后，怎样确认没有丢东西#
我会把验证拆成两组。第一组看响应性：改动了几条、写了多少、界面是否被阻塞。第二组看恢复：写入中退出、响应丢失后重开、磁盘失败、账号切换，以及损坏资料能否保留并提示。
性能可以先用合成照片和虚构笔记比较，不能为了测卡顿上传真实学习内容。真正手机上的内存、滚动和后台行为，还要再做设备验证；电脑上的计时不能直接代替。
如果改了保存方式，旧版程序能否读取也要提前说明。需要恢复时保留完整资料，不建议用户靠手工删除内部文件来让同步暂时启动。
目前公开说明里的同步范围，是单独开启后的题目照片、普通提问和笔记。朗读录音、学习板和课程进度并不因此全部互通，双端体验也仍有用户设备验收要完成。把卡顿问题解决好，不等于这些范围可以一起扩大。