单击与双击语义嵌套导致的等待延迟
别名: 双击延迟 · click ambiguity · deferred single click
概念解释
当单击和双击作用在同一个对象上，且两者代表不同结果时，系统就会遇到单—双击歧义延迟（single-double click ambiguity delay）：第一次点击刚发生的瞬间，系统没有办法立刻判断这是一次独立完整的单击，还是即将到来的双击的前半部分，只能二选一——要么等双击窗口彻底关闭再确认，要么先按单击执行，等第二击真的出现时再撤销或升级这个结果。
机制
两种手势共享完全相同的前缀：第一次点击的动作和事件，在双击真正发生之前，和单纯的一次单击是无法区分的。选择"等待"能保证不会先做出错误的单击副作用，但代价是每一次单击都被平白无故拖慢；选择"立即执行"能保持界面的响应感，但如果紧接着真的来了第二击，就要在视觉上撤销刚才的效果或者把结果升级，用户会看到一次短暂的闪烁甚至状态回跳。这个延迟的绝对大小直接继承自双击时间阈值本身——为动作较慢的用户放宽双击窗口，代价之一就是放大了这种嵌套语义带来的等待，两个设计决策互相牵连，不能分开调。
怎么研究
对比三种方案：等待确认后再执行、立即执行但保证可逆、把两个功能拆成完全独立的操作入口，测量单击的响应时间、双击的成功率、发生撤销或回滚的次数、伴随的视觉闪烁感知，以及用户对"系统听没听懂我的意思"的主观可控感。分析时要把单击占绝大多数的工作流和双击占绝大多数的工作流分开统计——如果把两者混在一起算平均值，占多数的那种操作的真实体验代价会被少数的另一种操作平均掉，看不出实际影响。
边界
如果单击和双击最终导致的结果可以安全合并（比如都只是切换同一种可逆视觉状态），或者第一次点击本身只改变了一个容易撤销的临时状态，这种歧义的代价就很小，可以放心选择"先执行再纠正"的策略。但破坏性操作、会发出网络请求的动作，以及涉及多对象选择状态切换的场景，不适合先执行再猜测第二击会不会到来——一旦请求已经发出或者选择状态已经污染，撤销不再是免费的。触控设备上的双击（双点按）还会天然和系统缩放手势、原生的多选交互产生冲突，这类冲突不是这段延迟能解决的，属于另一层问题。
怎么落地
- 不要把两个高频、时间敏感且都很关键的功能同时嵌套在单击和双击上——只要其中一个是低频操作，都应该单独给一个入口。
- 如果确实保留了嵌套语义，让第一次点击产生的反馈本身可逆，并且给出"正在等待可能的第二次点击"的轻量提示，而不是让界面在这段等待期看起来毫无反应。
- 用真实使用中单击和双击各自的实际比例去测量等待成本和撤销频率，而不是假设两者各占一半；必要时把双击对应的功能拆成单独的按钮、右键菜单项或快捷键，从根本上绕开这个歧义。