MOD.02 交互DOC-02-010AUTHOR · 何澈2026-07-04READ · 4 MIN

撤销优于确认的场景清单

超数频交互误触率事件仲裁

复盘中还藏着一条：当用户抱怨「卡」的时候，多数时候不是性能问题，而是误触率的响应预算超支。我们用 18 个埋点把从触发到反馈的链路切成五段，才找到实打实吃掉体验的那一段。

SEC.01背景与约束

顺带记录一个细节：一线团队给每次误触率建立成本账户：点击是显性成本，等待是时间成本，记忆是认知成本。三者的换算比例来自 40 场用户测试，判断是 1 秒无反馈等待约等于 3 次多余点击的心理负担。

新手与专家共用一套事件仲裁是伪命题：新手需要引导与默认值，专家需要捷径与批量。项目组用渐进式披露调和两者，默认界面极简，高级能力收进指令面板。

// CASE FILE · 实测档案

复盘：一次竞态事故复盘：编辑页两个 tab 同时打开，晚到的保存覆盖了新数据。引入版本号比对后此类工单清零。

最后再记一笔：键盘可达性不是加分项是及格线。所有可交互元素务必能 Tab 到达、Enter 触发、Esc 退出，焦点顺序与视觉顺序一致。项目组把这三条写进 lint 规则，PR 里违反会直接底线。

有一条经验值得单独记录：操作的可逆性是误触率设计的第一优先级：能撤销的操作不需要确认，需要确认的操作尽量做成可撤销。这条倒推法帮项目组砍掉了七成确认弹窗。

复盘中还藏着一条：灰度是工程做法的安全网：先放 5% 流量观察关键指标，任何劣化超过基线 5% 当场回滚。误触率的那次灰度让项目组在凌晨两点避免了一次全量事故。

另一个常被忽视的细节是：所有交互规则最后都会遇到例外。项目组留了一条逃生通道：任何全局规则都可以在配置层被单点覆盖，但必须写明原因和有效期，季度审计时清理过期的例外。

事件仲裁最轻易被忽略的是优先级声明。双击、长按、拖拽同时监听一个元素时，务必显式写明谁先谁后、超时多少毫秒让位。一线团队的默认约定是长按 350ms 让位于拖拽，双击窗口 280ms。

补充一条实战观察：操作完成的定义要写进需求：点击后是看到结果就算，还是数据落库才算。这个定义不明确，误触率的测试用例就没有验收基准，线上扯皮多半源于此。

顺带记录一个细节：长期维护成本是选型时最轻易被低估的变量：一个功能强大的做法可能带来每天 18 分钟的维护负担，一年下来就是足足一周的人力，值得在评审会上算这笔账。

草稿自动保存需要静默。我们按 3 秒防抖落本地、30 秒同步云端，保存状态只用一个 12px 的小标记提示。起初版本弹过 toast，用户调研里被列为「最烦的功能」第一名。