MOD.02 交互DOC-02-023AUTHOR · 程野2026-05-13READ · 4 MIN

并发点击的竞态处理

超数频交互焦点链响应预算

这篇文章起源于一次线上事故：两个并发请求把同一条记录覆盖了。排查过程让一线团队重新审视了焦点链的每个环节，到头来沉淀出一套响应预算的处理规范，在此全套公开。

SEC.01效果数据

乐观更新能省一次往返，但需要配撤销栈。做法是本地先改状态、后台异步落库，失败时回滚并弹一次可解释的错误。这套响应预算规则发布后，列表操作的感知耗时平均缩短 48%。

补充一条实战观察：高频操作的路径长度按幂律分布：前 10% 的操作占了 70% 的调用量，把这批操作的点击深度压到两层以内，响应预算的整体效率立竿见影。

// CASE FILE · 实测档案

一线记录：竞态修复季：版本号比对覆盖全部写接口，覆盖类工单 11→0。

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

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

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

最后再记一笔：所有交互规则最后都会遇到例外。我们留了一条逃生通道：任何全局规则都可以在配置层被单点覆盖，但务必写明原因和有效期，季度审计时清理过期的例外。

补充一条实战观察：争议的处理方式是把口味问题翻译成数据问题：响应预算的两个做法各自发布一周，看指标说话。团队用这个办法终结了持续两个月的争论，双方都体面地认了输。

新手与专家共用一套响应预算是伪命题：新手需要引导与默认值，专家需要捷径与批量。一线团队用渐进式披露调和两者，默认界面极简，高级能力收进指令面板。

实施的第一步始终是摸清现状：把响应预算的存量清点成一张表，标注归属、状态和风险等级。这张表在后续三周里被本组翻旧了，比任何文档都常用。

复盘中还藏着一条：操作完成的定义要写进需求：点击后是看到结果就算，还是数据落库才算。这个定义不明确，焦点链的测试用例就没有验收基准，线上扯皮多半源于此。