E3.14.4transfer list scan cost at scale设计
选项数量很大时穿梭框的扫描成本仍然很高
别名: 穿梭框性能 · dual list scan · 大集合穿梭
概念解释
双列并不能把大集合变短。左右各一千行时，用户仍要在两份长名单里找名字，扫描成本几乎是单列的两倍，还要外加搬动。穿梭框解决的是「已选与未选分开」，不是「集合变小」。数量过线之后，没有搜索、分组、虚拟滚动和明确的空态，穿梭框只是把长下拉的痛苦铺成两栏。这一条是容量边界：语义仍对，效率已经崩。
机制
视觉搜索时间随显示行数上升。两列同时可见，注视要在栏间跳跃，额外付出一次空间转换。滚动条各管各的，位置记忆是两套，刚在左边看到的名字滚走后，右边并不能帮忙。没有搜索时，已知名字的任务退化为两遍线性扫；只知类别时，两列若都不分组，类别线索也没有。渲染上千行还会让滚动掉帧，扫描被性能噪声打断，人会更早放弃。
「看见已选全貌」在右列超过一屏后同样失效：全貌变成「理论上在某一滚动位置」。这时穿梭框保留了移交隐喻，丢掉了全貌承诺，必须靠搜索和计数把全貌改成可查询。
边界
子集很小、源集合很大，是最常见的不对称：右列仍可一览，左列必须能搜。不要因为右列舒服就认为整个控件可扩展。虚拟滚动保性能，但页内查找、滚动条映射、快速滑动时的空白会出问题，需要另补。穿梭框不是唯一的大集合方案：带分组的穿梭、可搜索的穿梭、或改成「搜索加入 + 已选清单」往往比两列裸名单更好。权限矩阵、表格勾选在二维属性上扫描更优，不必挤进双列。
怎么落地
- 为可能过百的列提供搜索和分组，并把已选数量钉在列头。
- 源大、目标小时，优先强化左列检索，右列保持完整名单。
- 行数上到会卡顿时用虚拟滚动，同时保留搜索，不要只靠滚。
- 验证：用真实体量的名单做一次「加入三个已知名字、再核对右列有没有漏」。离开搜索就做不到，或滚动中途放弃，就是扫描成本已经压过双列的好处。