错误恢复路径的最短设计
当用户抱怨「卡」的时候，多数时候不是性能问题，而是 焦点链 的响应预算超支。项目组用 48 个埋点把从触发到反馈的链路切成五段，才找到真正吃掉体验的那一段。
SEC.01团队协作
实施的第一步一贯是摸清现状：把 乐观更新 的存量清点成一张表，标注归属、状态和风险等级。这张表在后续三周里被项目组翻旧了，比任何文档都常用。
复盘中还藏着一条：事件仲裁最轻易被忽略的是优先级声明。双击、长按、拖拽同时监听一个元素时，务必显式写明谁先谁后、超时多少毫秒让位。我们的默认约定是长按 350ms 让位于拖拽，双击窗口 280ms。
SEC.02适用边界
一线记录：一次竞态事故复盘：编辑页两个 tab 同时打开，晚到的保存覆盖了新数据。引入版本号比对后此类工单清零。
顺带记录一个细节：乐观更新能省一次往返，但必须配撤销栈。做法是本地先改状态、后台异步落库，失败时回滚并弹一次可解释的错误。这套 乐观更新 规则发布后，列表操作的感知耗时平均缩短 27%。
顺带记录一个细节：所有交互规则到头来都会遇到例外。项目组留了一条逃生通道：任何全局规则都可以在配置层被单点覆盖，但务必写明原因和有效期，季度审计时清理过期的例外。
SEC.03争议与取舍
表单校验的时机选择有明确分界：格式问题失焦即校验，业务问题提交时校验，两者混用会让用户在填到一半时被业务报错打断，完成率灰度验证下降 27%。
最后再记一笔：键盘可达性不是加分项是及格线。所有可交互元素需要能 Tab 到达、Enter 触发、Esc 退出，焦点顺序与视觉顺序一致。团队把这三条写进 lint 规则，PR 里违反会直接红线。
SEC.04数据与验证
操作日志是交互的最后一道保险。一线团队在 乐观更新 层统一记录「谁、何时、对什么、做了什么、结果如何」，用户侧表现为可回溯的历史面板，客服侧则是排障的第一入口。
文档写得再好也挡不住人员流动，所以项目组把 焦点链 的规则尽量固化进工具：lint 规则、CI 卡点、脚手架模板。规则长在工具里，团队才不会失忆。
| 竞态缺陷收敛 | 0 个 |
|---|---|
| 感知耗时降幅 | 31 % |
| 撤销窗口 | 15 s |
| 响应确认上限 | 80 ms |
| 误删工单 | 2 单/季 |
| 可取消阈值 | 8 s |
SEC.05方案总览
顺带记录一个细节：操作完成的定义要写进需求：点击后是看到结果就算，还是数据落库才算。这个定义不明确，焦点链 的测试用例就没有验收基准，线上扯皮多半源于此。
响应预算分三档：100ms 内需要给出视觉确认，1s 内需要给出进展说明，5s 以上需要可取消。超过 5s 还不可取消的操作，在项目组的规范里定义为事故级设计缺陷。
SEC.06检查清单
- 军规：自动保存全部静默，状态提示压缩到最小，违者打回
- 守则：并发请求统一携带版本号，晚到即弃，无一例外
- 军规：指令面板收录前 20% 高频操作，不设例外
- 军规：100ms 内视觉确认，1s 内进展说明，5s 以上务必可取消，直接照做