实现原生搜索下拉，但ie不支持、移动端体验差且无校验；需配合 使用，value 为唯一生效字段；若需兼容或强校验，应改用 js 动态过滤 选项。
用 <datalist></datalist> 实现原生搜索下拉，但注意兼容性
HTML 原生支持带搜索功能的下拉列表，核心是 <datalist></datalist> 配合 <input list="xxx">。它不是传统 <select></select>，而是输入框自动补全——用户可自由输入，也能从下拉选项中点击选择。
常见错误是把 <datalist></datalist> 当成 <select></select> 用，结果发现无法用鼠标点选后“锁定”值（<datalist></datalist> 只提供提示，不控制输入值是否合法）。另外，IE 完全不支持，Edge 12+ 才开始支持，移动端 Safari 从 iOS 12.2 起才可用。
基础写法如下：
<input type="text" list="browsers" name="browser"><datalist id="browsers"><option value="Chrome"></option> <option value="Firefox"></option> <option value="Safari"></option> <option value="Edge"></option></datalist>
注意：<option></option> 不需要 <select></select> 包裹；list 属性值必须和 <datalist id></datalist> 完全一致（大小写敏感）；value 是唯一生效字段，label 属性虽存在，但多数浏览器忽略。
<select></select> 加 JS 模拟搜索：适合需要强校验或 IE 支持的场景
如果必须用 <select></select> 结构（比如后端只认 name+value 的表单提交），又想加搜索，就得靠 JS 过滤 <option></option>。这不是 HTML 自带能力，但实操简单、兼容性好。
关键点在于：不能直接隐藏 <option></option>（部分浏览器不重绘下拉框），而应动态重建 <select></select> 的 <option></option> 子节点，或改用 <div> + <code><ul></ul> 自定义下拉（但那就脱离纯 HTML 表单了）。
简易过滤逻辑示例（配合一个 <input> 搜索框）：
const select = document.querySelector('select[name="city"]');
const options = Array.from(select.querySelectorAll('option'));
const searchInput = document.querySelector('#search-city');
<p>searchInput.addEventListener('input', () => {
const q = searchInput.value.trim().toLowerCase();
// 清空并重建匹配项
select.innerHTML = '<option value="">-- 请选择 --</option>';
options.filter(opt => opt.text.toLowerCase().includes(q))
.forEach(opt => select.appendChild(opt.cloneNode(true)));
});</p>
⚠️ 注意：直接操作 innerHTML 会丢失已选中的 value；更稳妥做法是保留原始 <option></option> 列表副本，每次按需渲染子集。
为什么不用 <select multiple></select> 或 size 属性模拟？
<select size="5"></select> 显示多行选项，但它是静态展开，没有搜索逻辑，也不响应键盘输入过滤；multiple 则允许多选，和“搜索后单选”目标冲突。两者都解决不了“输入关键词快速定位选项”的核心需求。
真实项目中容易踩的坑包括：
- 误以为
<datalist></datalist>提交时会校验值是否在列表中 —— 实际不会，服务端必须自行校验 - 给
<input>设required，但用户输了个不在列表里的词，表单仍能提交（因为输入框非空） - 在
<datalist></datalist>里塞几百个<option></option>，导致输入卡顿（浏览器对datalist的匹配是全量遍历）
移动端体验差异大，别依赖视觉下拉箭头
iOS Safari 点击 <input list> 会唤起键盘 + 底部候选栏，但不显示传统下拉箭头；Android Chrome 则可能显示浮动菜单。用户根本不知道有“下拉可选”这回事，所以必须配文字提示，比如在输入框旁加小字“可输入或从列表选择”。
更关键的是：移动端不支持鼠标悬停或键盘上下键高亮 <datalist></datalist> 选项（只有回车确认），用户只能靠输入联想，或者点开软键盘后手动翻找。如果你的选项词长、易拼错、或同义词多（比如“北京”“北京市”“Beijing”），<datalist></datalist> 几乎失效，这时 JS 方案 + 模糊匹配（如使用 indexOf 或正则）更可控。
复杂点往往不在怎么写，而在要不要写 —— 如果数据量小、用户熟悉业务词、且不需兼容 IE，<datalist></datalist> 是最轻量解法；否则，老老实实上 JS 过滤，别被“纯 HTML”绑架。
