select大数据量卡顿因频繁DOM操作触发重复重排，应批量插入；联动需最小化变更并保留选中值；移动端多选应避免原生兼容问题，超200项须用搜索或虚拟滚动。
select 元素在大数据量下直接操作 options 或频繁调用 add() / remove() 会严重卡顿，根本原因是浏览器每次修改都触发 layout + repaint，且 DOM 操作未批量合并。
为什么直接循环 new Option() + add() 很慢
每执行一次 new Option() 并调用 select.options.add()，浏览器就要做一次 DOM 插入、样式计算、布局重排。1000 条选项 = 1000 次重排；尤其在旧版 IE 或低配安卓 WebView 中，可能卡住主线程超 500ms。
常见错误写法：
for (let i = 0; i < data.length; i++) {
const opt = new Option(data[i].label, data[i].value);
select.options.add(opt); // ❌ 每次都触发重排
}
正确做法是拼接 HTML 字符串或使用 DocumentFragment 批量插入：
立即学习“前端免费学习笔记（深入）”；
- 用字符串拼接后一次性赋给
select.innerHTML（注意 XSS 风险，需转义） - 或创建
DocumentFragment，把所有optionappend 进去，再一次性 append 到select - 若数据含特殊字符（如引号、
<），必须对label和value做 HTML 实体转义，不能直接插值
联动更新时如何避免重复渲染和状态错乱
表格中多个 select 联动（比如 A 列选中后，B 列选项动态过滤），若每个 change 事件都全量重置 options，用户正在操作的已选值会丢失，且滚动位置重置、焦点丢失。
关键策略是「最小化变更」：
- 只更新真正变化的
option：比对新旧数据 ID 列表，用Set找出新增/删除项，而非清空重填 - 保留用户当前选中值：用
select.value记录旧值，插入新option后再尝试恢复（注意 value 不存在时要 fallback） - 不主动触发
change事件：更新options不等于用户操作，避免误触发下游逻辑 - 如果联动依赖异步数据（如 fetch），加 loading 状态并禁用 select，防止用户重复点击提交无效请求
移动端多选 select 的兼容性陷阱
原生 select[multiple] 在 iOS Safari 和部分安卓浏览器中表现不一致：iOS 不支持键盘多选（Ctrl+Click 无效），且默认不显示勾选图标；安卓部分 WebView 会忽略 size 属性，始终展开全量列表。
真实项目中更稳妥的做法是：
- 放弃原生多选，改用自定义下拉 +
checkbox列表（配合aria-multiselectable保障可访问性） - 若必须用原生，用
size属性控制可见行数（如size="5"），避免无限展开 - 监听
touchend而非click，防止 iOS 上 click 延迟 300ms 导致响应滞后 - 不要依赖
select.selectedOptions获取多选结果——IE11 不支持，应遍历options查selected属性
大数据量联动的本质不是“怎么塞进 select”，而是“哪些数据真该进 select”。超过 200 项就该考虑搜索过滤、分页加载或虚拟滚动方案，而不是硬扛 DOM 渲染压力。
