datalist 必须通过 id 与 input 的 list 属性精确匹配，仅支持同页面、区分大小写的 ID 关联，不跨 iframe、不支持动态插入或 class/name 替代；仅接受 value 非空的 <option> 子元素，不校验输入值是否在列表中，移动端兼容性差，仅为增强提示而非可控控件。
list 属性必须指向同页面存在的 datalist id
直接写 <input list="suggestions"> 是无效的，除非页面里真有一个 <datalist id="suggestions">。浏览器只做简单 ID 匹配，不支持跨 iframe、不支持动态插入后延迟绑定，也不支持 class 或 name 代替 id。
常见错误是拼错 ID（比如 id="suggest" 但 list 写成 "suggestions"），这时输入框就退化成普通文本框，控制台也不会报错——得靠肉眼核对或用 DevTools 检查 input 的 list 属性是否高亮跳转到对应 datalist。
- 确保
datalist在 DOM 中存在，且id与list值完全一致（区分大小写） -
datalist可以放在页面任意位置，不必紧邻input，但不能放在<head>里（部分旧浏览器不识别） - 不要给
datalist设display: none或visibility: hidden，它本就不渲染，但样式干扰可能导致选项不出现
datalist 里只能用 <option>，不能嵌套其他标签
datalist 是纯数据容器，只接受子节点 <option>，且每个 <option> 必须有 value 属性。写 <option>苹果</option> 是合法的，但 <option><span>苹果</span></option> 会被忽略；<option value=""> 也会被忽略（空值不参与匹配）。
注意：Chrome 和 Edge 支持 <option value="1" label="iPhone"> 的 label 属性，但显示时仍以 value 为准；Firefox 不渲染 label，只读取 value。所以别依赖 label 做提示文字。
立即学习“前端免费学习笔记（深入）”；
-
<option value="beijing">北京</option>→ 输入“北”会匹配，“北京”会完整填入 -
<option value="shanghai">上海</option>→ 大小写敏感，输“SHANGHAI”不匹配 - 重复的
value（如两个value="js"）会导致只显示第一个，其余被忽略
输入内容不会自动校验是否在 datalist 选项中
这是最常被误解的一点：datalist 提供的是“建议”，不是“约束”。用户可以输入任意内容，哪怕完全不在 option 列表里，表单照样能提交。它和 <select> 的行为本质不同。
如果业务需要强制选值（比如城市必须从列表中选），就得额外加 JS 校验，或者改用 <select> + 动态生成选项。单纯靠 datalist 无法阻止非法输入。
- 提交前检查
input.value是否存在于datalist.options的value集合中 - 可用
Array.from(datalist.querySelectorAll('option')).some(opt => opt.value === input.value) - 注意 Safari 对
datalist的options集合支持较弱，建议用querySelectorAll替代
移动端兼容性差，iOS Safari 基本不显示下拉建议
iOS Safari 自 iOS 12.2 起才开始有限支持 datalist，但实际体验极不稳定：有时不弹出选项、有时只在聚焦瞬间闪一下、有时根本无视 list 属性。Android Chrome 表现尚可，但软键盘会遮挡建议框，且无滚动支持。
如果你的表单主要面向移动端用户，别指望 datalist 能可靠工作。更稳妥的做法是用 JS 实现一个轻量级 autocomplete 组件（比如监听 input 事件 + 过滤数组 + 绝对定位浮层），或者直接上成熟的库如 awesomplete。
桌面端也需留意：Firefox 在 type="number" 或 type="email" 的 input 上会禁用 datalist，只有 type="text"、"search"、"url" 等才生效。
datalist，得接受它只是个“增强提示”，不是控件。它的价值在于零 JS 实现基础建议，代价是不可控、不可定制、不可靠——尤其当需求涉及校验、样式、交互反馈或移动端时，就得立刻切换方案。 
