list属性与datalist的id必须字符级完全一致，大小写、连字符等差异均导致静默失效；option必须有非空value值才能匹配；原生仅支持前缀匹配，模糊搜索需JS实现；移动端兼容性差，建议JS方案为主、datalist为降级fallback。
list属性和id必须字符级完全一致
这是90%失效问题的根源。浏览器不会报错，也不会警告，只是静默忽略绑定——你敲字、聚焦、检查DOM，都看不到下拉，但根本原因可能只是list="cities"对应了<datalist id="Cities">（大小写不一致），或list="city-list"而实际id是"cityList"（连字符 vs 驼峰）。list不是CSS选择器，它只做字符串精确匹配。
务必检查：
-
input的list值与datalist的id逐字符比对（含空格、连字符、大小写） -
datalist不能放在input内部，也不能被display: none隐藏（可用visibility: hidden或position: absolute; left: -9999px移出视口） -
input的type必须是支持类型：text、search、url、email等；type="string"或未声明type时绑定无效
option必须带非空value才能参与匹配
写<option>北京</option>看起来没问题，但浏览器会跳过这个选项——因为匹配逻辑只读取value属性，不看标签内文本。textContent仅用于显示，不参与检索。
正确写法只有这一种：
立即学习“前端免费学习笔记（深入）”；
-
<option value="Beijing">北京市</option>✅（输入“Bei”可匹配） -
<option value="beijing">北京市</option>✅（注意大小写影响匹配结果） -
<option value="">北京市</option>❌（空字符串等同于无值） -
<option>北京市</option>❌（无value，完全不参与）
label属性不影响匹配，仅在部分浏览器中改变下拉显示文本，不要依赖它做筛选依据。
原生datalist不支持模糊搜索，JS动态重写是唯一解法
所谓“模糊搜索”是常见误解。浏览器原生只做前缀匹配（startsWith()），输入“hrome”无法匹配value="Chrome"，输入“bj”也无法匹配“Beijing”。子串匹配（includes()）、拼音、大小写无关、远程加载，全得靠JS实现。
关键操作不是“增强datalist”，而是“替换它的内容”：
- 监听
input事件（不是change，后者失焦才触发） - 用
document.getElementById("your-datalist-id").innerHTML = ""清空旧选项 - 对原始数据做
.filter(item => item.toLowerCase().includes(query.toLowerCase())) - 循环生成
<option value="${item}">${displayText}</option>并插入 - 防抖必须加：高频输入下，用
setTimeout+闭包timerId确保只执行最后一次过滤
注意：动态插入后，部分旧版Edge/IE11可能不自动弹出下拉，可临时补input.focus()强制刷新，但别滥用。
移动端和Safari兼容性必须降级兜底
iOS Safari对datalist支持极弱：Safari 12.1之前基本不显示，16.4+才逐步稳定；即使新版，也常出现聚焦无响应、键盘弹起后建议不出现、上下键导航失效等问题。
生产环境不能只靠原生行为：
- 若需可靠体验，应默认启用JS方案（自定义
div+ul下拉），把datalist仅作为轻量级降级 fallback - 检测
'list' in document.createElement('input')判断基础支持，再结合navigator.userAgent识别iOS/Safari版本 - 避免在移动端依赖
label属性或复杂样式——原生下拉框样式不可控，也无法加图标、分组或高亮
真正麻烦的不是怎么写，而是怎么让不同设备上用户看到一致的提示行为：原生机制不可控，JS接管才是可控起点。
