编辑与查看的状态需明确区分
别名: 记录的编辑与只读 · CRUD 模式混淆 · view versus edit
概念解释
在增删改查里，读取和更新常常共用同一条记录的版面：字段还在，标题还在，人却可能处于只读或可写。状态需明确区分指：当前是在看这条记录，还是在改这条记录，必须能从界面当场判出来，而不能靠「点进去试试能不能改」。它处理的是 CRUD 里读与写两种操作叠在同一表面时的状态问题。查看态和编辑态整页换一套视觉语言、入口要不要按权限隐藏、意外退出保不保草稿，都不在这里展开。
机制
同一套字段布局被两种操作复用时，人默认「我看见的就能改」——这是直接操作的预期，不是疏忽。若只读详情用了输入框的外观、或可写页看起来像文章，操作与后果错位：在只读页里打字没有落盘，人以为保存失败；在可写页里随手改一个标签，却当成预览。模式指示若只在角落，视线停在正文时等于没有指示。CRUD 特有的失败是选错了操作种类：本想读取却提交了一次更新，或本想更新却在只读壳里空忙。通用的「模式要看得见」是另一层机制；这里多出来的是——记录表面同时承担读和写，状态一旦含糊，四类操作里的 R 和 U 会互相污染。
怎么研究
给同一条记录两种外壳（只读详情、就地可写），任务交替为「核对某个值」和「改某个值」，不先告诉被试现在是哪种外壳。
自变量：只读与可写是否共用输入外观、状态标签是否落在正在操作的字段旁、从列表进入时默认落在哪种状态。 因变量：在只读壳里尝试输入的次数、在可写壳里把改动当成未提交预览的次数、完成后问「刚才能不能改」。
实验室里任务指令会泄露状态（「请修改」），要改成目标导向：「确认截止日期」既可以看也可以改。真实产品还要记：有多少次打开详情后立刻再点「编辑」，那是状态默认为只读且入口可发现；若打开后乱点字段，是默认可写却没声明。
边界
创建流程本身就是写，没有「查看这条尚未存在的记录」的对应态，不必强造只读壳。表格单元格就地编辑时，状态是单元格级而不是整页级，区分靠焦点与提交手势，而不是整页横幅。纯媒体阅读器没有更新操作，只读是唯一态。权限不足时人本来就不能写，若界面仍像编辑器，失败会从「状态不清」变成「权限不清」——那是另一类误判。
怎么落地
- 只读详情用静态文本，不要用禁用输入框冒充；进入更新后字段才变成可聚焦控件。
- 从列表点开记录时，默认落在读取；需要更新再走明确的「编辑」动作。默认就地可写的对象（草稿、个人笔记）要在标题区持续标明「正在编辑」，而不是只在进入时闪一下。
- 保存、发布只出现在可写状态；只读状态提供的是关闭、分享、复制，避免两种状态共用同一主按钮文案。
- 验证：把同一记录做成只读与可写两版，请人完成「看截止日期」和「改截止日期」各一次，中途不问现在是哪种。若只读版出现输入企图，或可写版结束后人说「我只是看看」，状态就没有分开。