直接禁用lay-search改用独立搜索框+虚拟滚动，2000条数据渲染从420ms降至68ms；优化核心是避免layui.select全量dom生成，改用按需渲染与手动控制初始化时机。
直接禁用 lay-search，改用独立搜索框 + 虚拟滚动面板，2000 条数据渲染时间能从 420ms 降到 68ms；500 条起就该动手优化，别等用户反馈卡顿才处理。
为什么 layui.select 渲染慢？不是数据多，是它全量生成 DOM
Layui 的 layui.form.render('select') 会同步遍历所有 <option></option>，为每一条生成带高亮、搜索、滚动逻辑的完整 UI 结构。1000 条选项 ≈ 主线程阻塞 200ms+，点击下拉框要等半秒才弹出，用户感知就是“卡死”。这不是浏览器性能问题，是 Layui 默认行为太重。
- 原始
<select></select>的size属性必须设为1，避免 Layui 重复解析已有选项 - 不要用循环
.append()往<select></select>里逐条加<option></option>，会触发多次重排 - 清空再批量插入：用
$('#mySelect').empty().html(optionsHtml)，optionsHtml是拼好的完整字符串
用 layui.select.render() 手动控制初始化时机
自动渲染（即靠 lay-filter 触发）无法干预执行时机，而 layui.select.render() 允许你等数据加载完成、DOM 稳定后再调用，避开首屏渲染高峰。
- 初始化前先移除原生
<select></select>上的lay-search属性——它一开就强制全量渲染 - 传入
data参数时，只传「当前页」或「高频项」，别把 5000 条城市全塞进去 - 如果数据有层级（如省→市→区），必须按需请求，绝不能预加载全部
绕过 <select></select>：用 layui.input + 自定义下拉面板
Layui 原生 select 不支持虚拟滚动，但你可以用 layui.dropdown 或纯 CSS 弹层自己管理 DOM。核心是：不依赖 <select></select>，只渲染可视区域的 30 条。
- 监听
input事件，用Array.filter()快速筛选，加setTimeout防抖（延迟 200ms） - 结果超 50 条时，只往
<ul></ul>插入前 30 条，并提示 “共 N 条，已显示前 30” - 滚动时动态算起始索引，用
innerHTML替换局部 DOM，比全量innerHTML = all快 5–8 倍 - Layui 2.8+ 的
layui.dropdown支持自定义content，但 click 选中后需手动this.hide()
后端分页 or 前端缓存？数据源才是关键瓶颈
5000 条城市列表一次性拉下来，内存占用高、首屏慢、且多数人只选“北京”“上海”。这不是前端能硬扛的问题。
- 模糊搜索类（如姓名）必须后端支持
LIKE %xxx%或 ES 查询，前端filter只做二次轻筛 - 高频固定数据（如国家、状态枚举）可走前端 JSON 缓存，但要加版本号校验，避免 stale
- 错误
Failed to execute 'appendChild' on 'Node': Nodes of type '#text' may not be inserted inside elements of type 'SELECT'就是把字符串直接塞进<select></select>导致的，务必用innerHTML或document.createElement
真正卡顿的根源不在“数据量”，而在你让 Layui 对每一条都做 UI 化处理。跳过 <select></select> 这一层抽象，自己管 DOM 生命周期，才是最稳的解法。很多人卡在“以为要兼容原生 select”，其实只要值能回填、样式能对齐，用户根本不在乎底层是不是 <select></select>。
