敏感字段不应进入草稿
别名: 草稿脱敏 · 密码不进草稿 · draft excludes secrets · no CVV in autosave
概念解释
草稿为了抗中断把值写下盘或送上服务器，于是多出一份比提交结果活得更久、保护更弱的副本。敏感字段不进草稿指密码、支付验证码、证件正反面、一次性口令这类一旦落盘就难以收回的项，在自动保存时被排除；提交仍可带上它们。人回来时这些框是空的，需要再填一次。这条不讨论长表要不要保存、状态指示怎么写，只讨论草稿里什么不能有。浏览器把支付信息写进自动填充库，是另一套数据源。
机制
草稿的威胁面和提交成功后的正式记录不同：本地存储会被同机其他页面、备份和取证读到；服务端草稿常比正式库少加密、多副本、少审计，而且会在人以为「我没提交」时已经离开设备。敏感值的危害是泄露而不是丢失，中断代价（再填一次密码）远小于副本代价。第二层是排除必须在写盘之前，不是写了再删：移动端备份、日志、崩溃转储会在「稍后清理」之前已经复制。界面还要避免假装它们被保存了——状态说「已保存」而密码框看起来有值（用圆点填满），人会以为关窗口也安全，下一次打开发现是空的，或更糟：圆点来自未排除的真值。一次性口令和 CVV 的正确形态是：草稿里没有，字段空，提交时再问。
怎么研究
审查草稿载荷（本地存储、接口、崩溃日志），列出哪些字段出现。用场景测试：保存后换一台设备、导出备份、打开开发者存储面板。
自变量：字段类型（密码 / CVV / 证件影像 / 普通文本）、排除发生在客户端还是只在展示层隐藏、草稿是否进备份。 因变量：敏感值是否出现在任何草稿载荷、用户是否以为敏感项已被保存、排除后因重填导致的放弃。
不要只看界面有没有圆点。圆点可以是 CSS，底下仍是明文。安全审查比完成率实验更能抓住这一条。放弃率上升要和泄露事件分开记，不能用「重填麻烦」否决排除。
边界
医疗长表里的症状描述对恢复很重要，对泄露也很重要：应进加密的服务端草稿并受正式记录同级的访问控制，而不是进本地明文。用户主动点「记住密码」是密码管理器的范围，不是表单草稿。完全在可信内网、禁止本地存储的专用终端，排除名单可以缩短，但仍不要把 CVV 和 OTP 写入任何可导出的草稿。已提交成功的正式库不是草稿，保留规则走正式数据政策。
怎么落地
- 在写草稿的序列化里维护排除名单：密码、OTP、CVV、证件影像、支付账号全文；提交请求可以包含它们，草稿请求必须剥离。
- 恢复草稿后这些字段保持空，不要用圆点或截断值假装还在；必要时就地写「此项需再次填写」。
- 检查本地存储、崩溃日志和备份通道，确认排除发生在第一次写盘之前。
- 验证：填入密码和 CVV，触发自动保存，打开存储面板和草稿接口，载荷里没有这些值。恢复草稿后两框为空。故意把密码写入本地存储作为反例，确认发布检查会拦住。