C1.22.4Pre-threshold drag feedback设计
按住不放但未超过阈值时，光标不应表现出任何拖动反馈
别名: 拖动反馈 · 阈值内 · 状态一致性
概念解释
按住后但位移尚未超过阈值时，系统仍处在点击候选状态，光标和对象不应表现出任何拖动反馈。若提前出现抓手、半透明预览、对象跟随或插入指示，用户会以为拖动已经开始，随后释放却得到点击结果，造成状态与结果不一致。
机制
拖动识别是状态机：按下后先等待位移条件，跨越阈值才进入 dragging。反馈若在状态转换前泄露了下一状态，会给用户错误的前馈；而一旦用户依反馈调整动作，最终点击分支又会显得像系统反悔。这个问题比"视觉上不好看"更严重的地方在于，一旦用户看见了提前泄露的拖动预览并据此做出反应——比如看到对象已经"跟手"，就顺势把它拖到某个新位置才松手——而系统内部其实从未真正跨过阈值、从未进入拖动状态，那么用户以为发生的事和系统实际记录的事就彻底分岔了：用户以为完成了一次移动，系统却只记录了一次点击，事后也没有任何日志或状态能解释这次分歧从何而来，因为泄露的预览本身从未被系统当作真实状态对待过。
边界
"没有拖动反馈"不等于毫无按下反馈。按钮压下态、对象选中态或可拖动把手可以稳定显示，只要不暗示对象正在移动。某些直接操作可有明确的按住模式，但必须让规则和最终结果一致。长按触发的上下文菜单是一个不冲突的例外：它靠停留时长而不是位移距离来判定，只要长按反馈本身不暗示对象正在被搬动，就不会和"未过阈值不显示拖动反馈"这条规则产生矛盾。
怎么落地
- 将对象位移、拖影、放置指示和拖动光标严格放在跨越阈值之后，阈值判定通过前，系统内部状态和界面呈现必须保持一致。
- 对按下候选使用与拖动视觉不同的轻量反馈，例如仅改变按钮的按压深浅，而不出现任何暗示位置将要改变的效果。
- 验证办法：让参与者进行一系列微小移动后立刻释放的操作，逐次询问他们预期会发生什么，统计预期与实际结果的不一致率——不一致率高，说明视觉反馈在阈值判定完成前就已经泄露了状态。