datalist 提示失效的四大原因：id 必须严格匹配 list 属性（大小写、空格、拼写均不可错）；option 的 value 决定输入值而非文本内容；iOS Safari 等移动端支持极差；仅 text/search 等可自由输入的 input 类型有效。
list 属性必须严格匹配 datalist 的 id
不写对 id，list 就等于没写。浏览器不会报错，也不会显示任何提示——它直接跳过整个逻辑。常见失效场景包括：list="city-list" 对应的却是 <datalist id="cities">，或大小写错成 id="City-List"，甚至多一个空格（id="city-list "）都会断开关联。
-
list值只能是页面中真实存在的datalist的id，不能是class、name或任意字符串 -
datalist必须在 DOM 中（哪怕放在</body>前），不能靠 JS 动态插入后才设置list - 建议把
datalist放在input后面并加defer，或确保 DOM 加载完成后再操作，避免部分老浏览器回溯失败
option 的 value 决定用户选中后输入框填什么
用户点击或回车选中某项时，输入框最终显示的内容，由 <option> 的 value 属性决定，不是 text 内容。比如 <option value="shanghai">上海</option>，选中后输入框值是 "shanghai"，不是 "上海"。这点容易被忽略，尤其在需要提交英文 code 而展示中文名的场景。
- 如果
<option>没写value，则取其文本内容作为值（如<option>北京</option>→ 输入框填"北京"） - 多个
<option>可以共用value，但语义混乱，不推荐 -
value为空字符串（value=""）会导致输入框清空，慎用
移动端和 Safari 的提示行为差异大
iOS Safari 几乎不显示下拉提示框，即使 list 和 id 完全正确；Android Chrome 多数支持，但常隐藏下拉箭头，用户不知道有提示功能。这不是 bug，是原生 datalist 的设计限制：它只做前缀匹配，不支持模糊搜索、高亮、键盘导航（↑↓/Enter）等交互。
- 不要依赖
datalist实现关键业务逻辑（如城市选择必须校验），得配合 JS 补充验证 - 需要完整体验时，优先用
<select>或第三方组件（如 Choices.js、TomSelect） - 若坚持用
datalist，至少给 input 加placeholder提示用户“可输入建议项”
input 类型必须兼容 datalist
datalist 只对部分 input 类型生效：text、search、url、tel、email、number 等支持文本输入的类型可以；password、hidden、checkbox、radio 等明确不接受自由输入的类型，浏览器会忽略 list 属性。
立即学习“前端免费学习笔记（深入）”；
- 常见误用：
<input type="number" list="nums">—— 多数浏览器不显示提示（尽管规范未禁止） - 最稳妥组合是
type="text"或type="search"，兼容性最好 - 使用
type="search"时，部分浏览器会自动添加清除按钮，注意样式冲突
datalist 的关联看似简单，但 id 匹配、value 语义、移动端表现、input 类型限制这四点，任一出错都会让提示静默失效，且无控制台报错可查。调试时别只看 HTML 结构，务必用 DevTools 检查 input.list 是否指向有效元素，并手动输入前缀验证是否触发匹配。 
