list属性绑定失败的三个静默陷阱：一是list值与datalist的id必须字符级完全一致（大小写、空格、符号均敏感）；二是input的type必须为text/search/email等原生支持类型，number/date等受限类型易失效；三是option必须带非空value属性参与前缀匹配，innertext仅显示且不参与匹配。
list 属性绑定失败的三个静默陷阱
list 属性不报错、不警告，只静默失效——这是最让人抓狂的地方。真正卡住 90% 开发者的不是逻辑，而是细节匹配。
-
list值必须和<datalist id="xxx"></datalist>的id字符级一致：大小写、前后空格、短横线（-）和下划线（_）全算在内。写成list="CityList"却配id="citylist"，就等于没写。 -
input的type必须是浏览器认可的类型：text、search、email、url、tel最稳；number要求<option value="42"></option>这种纯数字字符串，否则 Chrome 可能渲染箭头但不显示选项；date、color、password等一律不生效。 - 动态创建
<datalist></datalist>后，不能用input.list = "myList"——list是只读 IDL 属性，会直接报错；必须用input.setAttribute("list", "myList")。
option 的 value 属性不是可选，而是强制参与匹配的唯一字段
很多人以为 <option>Beijing</option> 就够了，其实它完全不参与匹配逻辑，用户输 “Bei” 也不会出现。
- 只有
value属性的值会被用于前缀匹配（如"Chrome".startsWith("chr")），文本内容（inner text）仅用于显示，且部分浏览器根本不渲染它。 -
value=""或缺失value，等同于该<option></option>不存在——浏览器忽略，也不报错。 -
label属性对<datalist></datalist>无效，它只在<select></select>中起作用；别指望靠它做“显示名/提交值”分离。
原生匹配 ≠ 模糊搜索：前缀匹配的边界与降级时机
浏览器原生只做前缀匹配（少数新版 Chrome 支持子串），输入 “hrome” 找不到 value="Chrome" 是正常行为，不是 bug。
- 大小写敏感性不统一：Chrome 通常忽略大小写，Firefox 和 Safari 表现不一，不能当作兼容特性依赖。
- 空格参与匹配：
value="Chrome OS"不响应 “chrome”，必须输 “Chrome ”（带空格）才触发。 - 真·模糊搜索必须监听
input事件，每次清空<datalist></datalist>的innerHTML，再根据关键词从数据源中筛出新<option></option>插入——不是“增强”，而是“替换”。 - iOS Safari 几乎不渲染下拉面板，检测到
!window.HTMLDataListElement或 UA 含Mobile+Safari，就得立刻切 JS 实现的 autocomplete 组件。
移动端与历史记录的务实处理方案
想用 <datalist></datalist> 做搜索历史？可以，但得接受它的局限：不能自动存、不能远程加载、不能样式定制。
- 历史记录必须靠
localStorage+input.change/blur事件手动存取，且要主动去重、截断（建议最多 10 条），否则下拉过长影响体验。 - 每次更新
<datalist></datalist>后，Chrome 可能延迟生效，Safari 更可能不刷新——实操中加一句input.blur(); input.focus();强制重绘更可靠。 - 所有
<option></option>都得有非空value，且不能塞 HTML 或data-*属性；如需关联 ID 或元数据，只能靠 JS 在change后查表映射。
真正容易被忽略的是：你写的每一条 <option value=""></option> 都得有 value，空值或缺失就等于没写；还有，哪怕 datalist 显示完美，用户仍可手敲任意值——后端校验永远不能省。
