I4.02.1autosave interval tradeoff设计
频率需在数据安全与开销间取舍
别名: 自动保存间隔 · autosave frequency · 保存频率 · save interval
概念解释
自动保存多密，决定的是「崩溃时最多丢掉多少」和「系统一直在付多少账」。频率取舍把间隔当成一笔显式交易：间隔越短，未落盘的窗口越小，写入、同步、冲突探测、电量越贵；间隔越长，开销下降，一次中断能吞掉的编辑量上升。长表要不要留草稿是另一件事；这里假定草稿已经在写，只谈这只钟该走多快。
机制
未保存窗口的期望长度大约是间隔的一半——人在间隔正中崩溃，丢掉的是半个周期的键。把间隔从三十秒收到三秒，窗口缩小一个数量级，写入次数上升一个数量级。开销不只是一次磁盘写：服务端草稿要占带宽和版本；每一次写都可能和他人的写碰上；移动设备上周期性唤醒无线是电量。还有一层：写得太密，保存本身变成前台工作，输入会撞上锁、光标跳、输入法重绘，安全是用卡顿买来的。
安全还取决于内容的不可恢复性。一串难以重打的长文、已填到后半的申请，同样三十秒窗口的主观损失远大于改一个开关。所以频率不该是全产品一个数，而该按「丢掉的代价 / 写一次的代价」分段。
边界
只读回看、已经提交成功、内容几乎不再变时，高频写是在制造噪声和覆盖风险，应降到接近零或停掉。本地未登录草稿写得再密，也挡不住换设备——那边的安全要靠账号侧同步，不能用把本地间隔再缩短来补。协作文档里，过密的自动写会把每一次停顿都变成冲突候选，需要合并策略，而不是把间隔当唯一旋钮。电量敏感、按流量计费的网络上，开销项会压过数据安全，应改为「有改动且达到最小间隔」而不是固定节拍空转。
怎么落地
- 按内容不可恢复性分档：短字段可以较长间隔或失焦才写；长文、多步申请用较短间隔，并设「有改动才写」，避免无改动空转。
- 同时看两个量：崩溃时可能丢掉的编辑时长、单位时间的写次数与流量。只优化其中一个会把另一个推到不可接受。
- 服务端写和本地写可以不同频：本地密、远端疏，崩溃用本地顶，换设备用远端顶。
- 验证：在两次保存正中间强制杀进程，确认丢掉的不超过所设窗口，并记录这一分钟实际写了几次。把间隔收到接近每次击键，输入明显卡顿即开销已经压过安全。把间隔放到数分钟，填一段长文再杀进程，丢失量应被判定为不可接受。