大量选项需搜索与分组而非长下拉
别名: 长下拉 · searchable select · 选项分组
概念解释
选项多到无法一屏扫完时，控件要从「滚动长名单」改成能搜、能分组的选择器。长下拉把整份名单塞进一个面板，看起来是同一组件的自然延长，其实已经把任务从选择变成了在无结构列表里的视觉搜索。国家、雇员、商品类目、权限点都过这个坎。搜索解决「我知道名字」；分组解决「我不知道名字但知道属于哪一类」。两者常要一起，单独加长滚动条不够。
机制
无结构名单上的搜索时间随长度恶化：目光要经过大量无关项，滚动会丢掉已看过的位置。Hick 式的选择时间在项可同时看见时才有意义；项藏在折叠面板的远处时，时间被滚动和反复定位主导。分组把名单变成可跳过的块，用户先选块再在块内比。搜索把名单变成查询，用户用已有的名字或缩写换回一项，不再线性扫。
只有长下拉时，两种策略都被关掉。会拼的人靠浏览器页内查找，但原生 select 往往截获按键做首字母跳转，页内查找还用不了；不会拼的人只能滚。于是集合越大，越只有「记得开头几个字」的人能完成。
怎么研究
用同一份长名单比较：纯滚动下拉、带分组的面板、带搜索的面板。任务分两种：已知目标名、只知类别。
自变量：有无搜索、有无分组、名单长度、是否允许拼音或缩写。 因变量：完成时间、放弃率、选错近邻（同首字母）的次数、滚动深度。
已知名任务上搜索应显著缩短时间；只知类别任务上分组应显著缩短。若两项都没有改善，说明搜索或分组的匹配规则本身有问题，而不是「长下拉其实够用」。
边界
名单虽长但有稳定的空间或时间结构（二十六字母索引、日历）可以用索引代替全文搜索。穿梭框、树、级联是另一些对付大集合的结构，匹配规则是「不要只加长下拉」，不是「必须做成带搜索的 select」。搜索若只匹配前缀、不分词，对中文和多词英文名会假失败，用户会退回滚动并认为搜索坏了。无障碍上，原生长 select 的选项暴露给辅助技术的方式与自绘列表不同，换成自绘时要补齐角色和过滤结果播报。
怎么落地
- 为超过一屏的选项提供搜索框，并为有自然类别的集合提供分组或索引。
- 不要用「再滚一滚」作为唯一策略；滚动可以留下，但不能当检索。
- 搜索与分组同时存在时，过滤应在组内进行，空组隐藏，避免搜完还对着空组名发呆。
- 验证：各找一名「知道全名」和「只知部门」的人。前者离开搜索就做很慢、后者离开分组就做很慢，说明匹配对了；两者都去滚长名单，说明还在用错误的控件延长线。