datalist 不是 autocomplete 的替代品，因其仅提供静态下拉候选且不自动补全，需手动选择；必须正确绑定 list 属性与 datalist id，仅支持特定 input 类型，浏览器兼容性差，动态过滤需 JavaScript 实现，移动端体验不佳，适合小规模静态列表桌面场景。
为什么 datalist 不是 autocomplete 的替代品？
它根本不会自动补全，只提供下拉候选——用户必须手动点击或用方向键选择，input 值不会被“覆盖”，而是由用户决定是否采纳。很多人误以为加了 datalist 就能像搜索框那样输入即联想，结果发现没反应，其实是没绑定 list 属性或浏览器不触发（比如 Safari 对非 text 类型支持弱）。
关键点：
-
input元素必须有list属性，且值要和datalist的id完全一致（大小写敏感） - 仅对
type="text"、"search"、"url"、"tel"、"email"、"number"有效；type="hidden"或"password"会被忽略 - Chrome 和 Edge 支持较好；Firefox 显示候选但不支持键盘高亮；Safari 仅部分支持（如
text可用，search可能失效）
怎么让 datalist 候选项动态匹配输入内容？
datalist 本身不提供过滤逻辑，所有 option 都静态渲染，浏览器负责模糊匹配（通常为前缀匹配）。若想实现“输入‘北’就只显示‘北京’‘北海’”，必须配合 JavaScript 手动清空/重写 datalist 内的 option。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
input事件（不是change），实时获取当前值 - 用
document.getElementById("my-list").innerHTML = filteredOptions.map(...).join("")替换候选项 - 避免高频操作卡顿：加
requestAnimationFrame或简单节流（如 100ms 间隔） - 注意 IE 不支持
datalist动态更新，需降级为自定义下拉菜单
option 的 value 和 label 有什么区别？
value 是用户最终填入 input 的文本，label 仅用于显示（类似 select 的 option 文本）。如果只写 <option value="shanghai">，下拉里就看不到文字；如果写了 label 但没写 value，选中后 input 会填入 label 内容（部分浏览器行为不一致）。
安全写法：
- 始终显式设置
value，确保数据可控 -
label可选，但若要显示友好名称（如value="bj"+label="北京"），需确认目标浏览器支持（Chrome ≥ 75 支持，旧版 Firefox 忽略label） - 不要依赖 innerText 渲染：有些浏览器会把
<option>北京</option>当作value和显示文本，但语义不明确，易出错
移动端键盘弹出时 datalist 下拉被遮挡怎么办？
原生 datalist 下拉没有 CSS 控制权，iOS 和 Android 都无法调整位置或样式。常见现象是键盘弹起后候选框被顶出可视区，甚至完全不可见。
应对策略：
- 优先检测
navigator.userAgent是否含"Mobile"，移动端直接禁用datalist，改用 JS 实现的下拉面板（可定位、可滚动、可定制样式） - 若坚持用，可监听
focus事件，通过scrollIntoView({ block: "nearest" })尝试滚动 input 到视口中间（效果有限） - 不要尝试用
position: absolute覆盖原生下拉——它不在 DOM 中渲染，CSS 无效
真正轻量级的联想输入，datalist 只适合静态小列表（≤50 条）+ 桌面端场景。一旦涉及动态筛选、多字段展示、移动端适配，就得切到 JS 方案，别硬扛。
