K1.08.3draft persistence设计
未保存内容必须持久化
别名: 草稿持久化 · 未保存内容 · autosave draft
概念解释
人在输入框、编辑器、结账备注里写下、尚未提交的内容是草稿。进程被回收或应用被划掉之后，这些字符必须还能从存储里读回来，而不是只活在内存里的控件状态。视图可以回到正确的那一页，框却是空的——位置对了，劳动丢了。这条只谈未提交内容如何跨死亡存活，不谈进程为什么会被杀，也不谈导航栈和滚动位置怎么恢复。
机制
键盘输入的代价高于点按。一段评论、一条地址、一则未发出的消息，是已经付过的工作，人会用「还在框里」当作已保存。控件状态默认跟进程走：进程没了，EditText / UITextView 里的缓冲也没了。持久化要把草稿写成进程外的记录（本地数据库、文件、系统草稿接口），并且在下一次进入同一编辑器时读回。时机不能等「点发送」：发送是提交，草稿是提交之前的连续快照。冲突会出现在「本地草稿」与「服务器已有一版」之间，但丢失草稿的损害通常大于展示一则需确认的旧稿。从多任务栏划掉在部分系统上会走完整的退出路径，仍应把当时框内的文字视为未保存内容，而不是视为用户主动清空。
边界
密码、验证码、一次性口令不应写入草稿；持久化范围要避开密钥类字段。受管设备或无痕模式可能禁止落盘，这时应在编辑器里明确「关闭后不会保留」，而不是静默丢。协同编辑里他人已提交的新版本会让本地草稿过期，恢复时需要冲突提示，不能直接覆盖远端。极短的检索关键字（三五个字）丢失成本低，不必与长文草稿同一套策略；判断标准是重打代价，不是「是不是输入框」。
怎么落地
- 在编辑器失去前台或输入暂停时，把草稿写入进程外存储；不要只在点「保存」或「发送」时才写。
- 再次打开同一编辑器时自动读回，并用「未发送的草稿」这类可读标记让人知道框里的字从哪来，避免当成系统替自己写了一段。
- 验证：在评论框或订单备注里输入一段无法靠记忆复述的长句，切到短信再回来之前用系统工具杀掉进程。重新进入该编辑器，原句应仍在；若只剩空白，说明存活的是页面而不是内容。