C3.04.2Drag slop versus scroll direction lock设计研究
拖拽起始阈值与滚动方向判别的竞争
别名: 拖动抢手势 · 滚动锁方向 · drag versus scroll
概念解释
对象已经允许被拖时，手指刚动的那几毫米既像要开始拖拽，也像要开始滚动。识别器通常各设一道门槛：拖拽看位移是否走出 slop，滚动还看这位移是否足够“主轴化”。两道门槛谁先满足，谁就锁住后续所有 move。竞争发生在武装之后的第一段运动里，不是发生在长按等待里。
机制
滚动识别器喜欢尽早锁方向，好让内容立刻跟手、斜向抖动被投影到主轴。拖拽识别器则想多看一会儿，确认这不是一次翻页。若滚动先锁，本意横向搬到另一列的动作会被吃成竖向翻页；若拖拽 slop 太小，一次想翻页的微动会把行揭起来。方向锁一旦生效，后续即使画出明显的横向分量也改不了归属——这是为了滚动稳定，却让拖拽在锁定期内没有上诉权。嵌套的横向列表会再插入第三名竞争者，判别顺序变得更苛刻。
怎么研究
在竖向列表里放置可横向拖出的行（或可拖到另一槽位的项），系统变化拖拽 slop、滚动方向锁的角度窗和锁定期。因变量为：本意拖却滚了、本意滚却拖了、斜向 30° 手势被投影错轴的比例。同步记录哪一个识别器在第几个 move 事件上声明 capture。只看最终是否到达正确槽位，会漏掉中途被滚动锁“绑架”后又侥幸回来的轨迹。
边界
编辑模式或明显的拖动手柄可以让滚动识别器在该触点上直接弃权，竞争消失。全屏画布没有滚动父级时，这条竞争也不存在。系统级返回手势从边缘起步，会在列表拖拽之前再插一杠，属于另一组边缘问题。触控笔的 barrel 按钮按下再动，等于硬件层先武装，软件 slop 竞争显著减弱。
怎么落地
- 为列表内拖拽划出与滚动相反或正交的主轴（横拖出、竖滚动），并让拖拽 slop 略宽于滚动的方向锁窗口，避免翻页抢先。
- 一旦拖拽武装成功，显式取消父级滚动的 capture；一旦滚动已锁，就不要在中途把触点抢回给拖拽。
- 让人连做二十次：十次只翻列表，十次把指定行拖到指定槽。用日志看 capture 花落谁家，而不是只看最终画面。斜向进入的那几次最能暴露锁得太早还是 slop 太紧。