应手动调用 layui.select.render() 替代自动扫描，通过 size="1" 隐藏原生下拉、批量写入 optionshtml、配置防抖与输入长度限制、按需加载及后端搜索等方式优化大数据 select 性能。
直接换掉 layui.form.render('select')，别等它自动扫 dom。1000 条数据卡 200ms+ 是框架行为，不是你代码慢。
用 layui.select.render() 手动初始化，跳过自动扫描
Layui 默认会遍历所有 <select lay-search></select> 并同步构建完整 UI，主线程被锁死。手动渲染能控制时机、避开无用 DOM 构建：
- 原始
<select></select>加size="1"属性，让浏览器原生下拉不显示，防止被重复识别 - 数据加载完成后，先清空再一次性写入：
$('#mySelect').empty().html(optionsHtml)（optionsHtml是拼好的字符串，别循环append） - 调用
layui.select.render({ elem: '#mySelect', search: true })显式初始化，传必要配置
关掉 lay-search 或加防抖 + 输入长度限制
lay-search 默认对每次 input 都做全文过滤，大数据下反复计算几百项，CPU 直接拉满：
- 把
layui.debounce(search, 50)改成layui.debounce(search, 300)，更贴合用户输入节奏 - 只在输入长度 ≥ 2 时触发搜索：
if (this.value.length > 1) { searchDebounce(e); } - 清空输入时立刻还原全部选项，不要等防抖结束——这点影响体验，但常被忽略
数据超 2000 条？别硬撑，换方案
Layui 的 select 没虚拟滚动、没懒加载、没远程搜索能力，实测超过 2000 条后，首次展开和滚动都明显延迟：
- 高频固定枚举（如状态、类型）走前端 JSON 缓存，但要加版本号校验
- 有层级关系（省→市→区）必须按需请求，禁用全量预加载
- 模糊搜索类（如人名）必须后端支持
LIKE %xxx%或 ES 查询，前端只做轻筛 - 真要撑万级数据，得绕开
<select></select>：用layui.input模拟搜索框 + 自定义下拉面板，配合layui.dropdown或纯 CSS 弹层
卡顿的根源从来不是“数据多”，而是框架在错误时间把所有数据塞进 UI。优化的关键不在怎么塞得更快，而在让 UI 只处理“此刻需要的那一小部分”。
