扫描依赖顺序遍历，路径长度即成本
别名: 开关扫描 · 扫描路径 · item scanning · switch scanning
概念解释
开关控制把界面收成一条被高亮依次走过的队列：用户等光标走到目标，再按一下开关选中。这种操作叫扫描（switch scanning）。鼠标和触屏付的是瞄准距离；扫描付的是「还要等几步」。路径长度就是每一次操作的价格。
机制
扫描是串行访问。自动扫描按固定节拍前进一步，用户节奏扫描则每按一次开关前进一步。第 n 个可停靠对象的到达成本近似 n 倍节拍，选错之后往往要从头再排一次队。触屏可以把远处的大按钮一次点中；扫描不能按空间远近跳跃——中间每一个可聚焦节点都是必须付的通行费。
这个成本在任务开始前就已经锁死。用户知道要点哪一个，却无法把意图直接映射到位置，只能等队列走到那一格。视觉上紧挨着的两个按钮，在扫描里可能隔着二十步。视觉邻近不等于扫描邻近；扫描邻近由可聚焦顺序决定，通常和键盘焦点顺序同源，但停靠集合并不总一致。
怎么研究
用系统自带的开关控制（iOS Switch Control、Android Switch Access、macOS 切换控制），接一个外接开关或用空格键模拟，记录从固定起点到达指定控件的扫描步数和墙钟时间。
自变量：目标在扫描序列中的位次、自动扫描节拍、用户节奏还是自动节拍。 因变量：步数、时间、选错后重新排队的次数。
用 Tab 顺序做预检可以，但不能替代真扫描。开关控制的停靠集合、是否把容器当成一格，和键盘焦点并不总重合；只测键盘会漏掉「能 Tab 到但扫描器跳过」或反过来的节点。
边界
眼控停留点选、头部鼠标、摇杆直接移动指针都不是顺序扫描，路径长度模型不适用。双开关「移动 + 确认」仍是顺序遍历，但节拍由用户控制，疲劳出在按键次数而不是等待。把节拍设得极快，步数还在，只是时间被压缩，失误会上升。把扫描本身做成关卡机制时，路径长是难度设计，不是缺陷。
怎么落地
- 把高频主操作放进扫描序列的前段，不要让「发送」「播放」排在一长串工具按钮之后。
- 让扫描顺序跟随视觉阅读顺序，避免高亮在屏幕上乱跳，用户才能预估还要等几步。
- 验证：打开系统开关控制，从一个固定起点走到三个核心任务的终点，记下步数。常用任务动辄二三十步，先查是不是把主操作埋到了队尾。