用户需要比较许多值并谨慎修改时，长表单未必合适，表格反而更友好。
密集界面不应掩盖混乱思路，但有些工作本身就密集：审阅多行、比较列、修改少数值，再一次性保存。表格是工作区，不是装饰。TanStack Table 这类工具应保持 headless，让产品掌握编辑模型。
已修改行数：4
无效行数：1
修正错误前：禁用保存按钮变化应可见，错误应指向具体单元格。用户必须知道看到的是已保存数据、未保存修改，还是保存失败。
我喜欢批量保存，因为它留出审阅机会。简单设置可以即时保存，多个相关值一起改时，先校验整批再提交更稳妥。
状态是难点：原始值、当前值、单元格是否已修改、行是否有效、是否正在保存，以及失败原因，都要明确。否则用户会开始怀疑应用有没有保存工作，这也是产品失败。
反复编辑时，纯鼠标操作很慢。Tab、Enter、Escape、复制、粘贴和可预测的焦点，决定工具是否真正好用。
高级规则编辑器或结构化文本编辑器也一样。无论基于 CodeMirror 还是其他组件，都不应只接收文字然后听天由命，而要帮助理解合法结构、执行前展示错误，并明确高风险操作。
代价是复杂性。密集表格可能成为应用中的小应用，需要无障碍审查、性能维护、校验及修改状态测试。只编辑一两个字段时，普通表单通常更好。
需要跨行比较、同时修改多项、整批校验、快速键盘操作，且错误代价足以支持增加审阅步骤时，我会选择密集表格。
目标并非把更多数据塞进屏幕，而是帮助工作本就繁杂的用户减少错误。