用户正在修改表单时，后台刷新覆盖了输入，通常说明临时草稿与已保存记录共用了同一状态。
本文使用浏览器 JavaScript、HTML 与局部演示数据。前端复杂性常来自状态与异步关系，而不是组件数量。本文把服务器业务事实、页面查询条件和用户临时编辑分别表达，避免多个界面位置互相覆盖。
1. 从现象推到机制
服务器记录是已确认事实，编辑模型是尚未提交的意图。进入编辑时复制必要字段并保存版本，取消丢弃草稿，保存成功才更新事实。深层对象如果只做浅复制，仍可能共享可变子对象。
图中的四个节点分别表示服务器事实、编辑草稿、版本提交、保存取消。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用订单备注编辑演示两个模型，刷新时只更新事实并提示冲突，不自动覆盖用户输入。保存请求携带原版本。
1
2
3
4
5
var saved = { id: 1, remark: "old", version: 3 };
var draft = { remark: saved.remark };
// cancel: discard draft
// save: send draft + expected version
// success: replace saved with verified response
先用不连接真实业务的小页面观察状态迁移，保存每次输入与渲染结果。组件拆分之后仍需验证整体任务，不能只检查每个按钮能响应。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 后台事实刷新而用户仍编辑 | 草稿不能被静默覆盖 |
| 用户点击取消 | 服务器事实保持不变 |
| 保存时版本已变化 | 应提示冲突并重新核对 |
对照 1：后台事实刷新而用户仍编辑
草稿不能被静默覆盖。观察时记录两个状态对象是否独立。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：用户点击取消
服务器事实保持不变。观察时记录临时修改是否已污染原对象。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：保存时版本已变化
应提示冲突并重新核对。观察时记录请求版本与服务端版本。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
草稿保存到浏览器还涉及隐私和期限。敏感字段不应无条件持久化，退出账号时也要处理本地残留。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“保存时版本已变化”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
