悬停触发延迟与误触发的权衡
别名: hover delay · 悬停延迟 · 误触发
概念解释
悬停延迟（hover delay，也叫 dwell delay）是指针进入对象到系统显示预览或执行悬停动作之间的等待时间。短延迟让反馈显得灵敏，却容易把"路过"误判成"有意悬停"；长延迟能过滤掉这种偶然经过，代价是用户要多等一会儿，并且在等待期间不确定自己的动作有没有被系统接收到。
机制
系统本质上是把"停留了多久"当作"有没有意图"的替代信号——这是一个信号检测问题：阈值越低，越容易识别出真正的意图（高灵敏度），但也越容易把无意的路过算作触发（低特异性）；阈值越高则反过来。指针速度、移动方向、对象排布密度、菜单的几何形状和当前任务都会改变"停多久才算有意"的合理答案，所以任何单一固定延迟本质上都只是一种折中，不存在对所有场景都最优的数值。
工程上常见的做法不是只靠一个计时器，而是把方向和速度也纳入判断：被多次公开分析过的一类网站顶部导航菜单，用的不是固定悬停延迟，而是持续预测指针的运动轨迹——只要指针正朝着当前展开的子菜单方向移动，即使暂时划过了别的菜单项也不会立刻切换，等轨迹偏离才响应。这类做法用运动方向替代纯计时，能在密集菜单里显著减少误触发，但也让系统行为更难预测和调试。
怎么研究
在浏览、目标查找和层级／级联菜单任务中系统地操控延迟数值，记录预览出现次数、误触发率、等待时间、因误触发导致的回退动作和任务完成率。方法论上要区分两类看起来相似的停留：用户主动等待预览出现，和用户因为不确定是否已经触发而僵住不动——只看平均任务时间无法把这两者分开，需要结合操作日志或眼动的时间戳做更细的切分。
边界
关键状态不应该因为设置了延迟而变得实质上不可达；如果某条信息只能靠悬停超过某个时间才能看到，且没有其他入口，延迟本身就成了一道隐形门槛。密集排列的列表和级联菜单里狭窄的移动通道，可能需要方向或轨迹判定而不只是计时——纯计时在这些场景下会持续产生误触发，无论怎么调数值都难以两全。触屏没有普通意义上的连续悬停，因此这里讨论的延迟阈值不能直接套用到长按判定上，两者面对的是完全不同的输入信号。
怎么落地
- 给预览和破坏性较低的弹层设置延迟；对已经获得键盘焦点或指针明确指向的对象，给出比悬停更清晰、更即时的反馈，不要用同一套延迟逻辑对待两种确定性不同的情况。
- 在密集菜单中把进入方向、移动速度和安全通道结合起来判断，而不是只靠停留计时，减少指针穿越邻近选项时的误触发。
- 收集真实使用中"触发后立即离开"和"等待超过延迟却没有使用预览内容"这两个比例，前者提示延迟太短，后者提示延迟太长或内容没有价值，据此调整默认值而不是凭经验拍数字。