datalist 不是真正的“搜索建议”，因其仅支持浏览器原生的 value 前缀匹配，不支持模糊搜索、拼音首字母、实时过滤或服务端联动，本质是静态选项提示而非动态建议框。
为什么 datalist 不是真正的“搜索建议”
datalist 只在用户输入后，由浏览器原生匹配 option 的 value 前缀（从开头严格匹配），不支持模糊搜索、拼音首字母、实时过滤或服务端联动。它本质是“静态选项提示”，不是“搜索建议框”。常见错误是期望它像 select 那样下拉展开全部选项，或以为输入“北”能匹配“北京市”“北海道”——实际只匹配 value 以“北”开头的项。
- 浏览器仅触发一次匹配，不监听输入变化事件
- 无法控制弹出位置、样式或延迟
- Chrome 和 Firefox 行为略有差异（如 Firefox 不支持空值 fallback）
如何用 datalist 实现基础自动完成
必须配合 input 的 list 属性使用，且 datalist 的 id 要与之对应。重点在于数据组织方式：所有候选值需预先写死在 HTML 中，或通过 JS 动态注入 option 元素。
<input type="text" list="cities" placeholder="输入城市名"> <datalist id="cities"> <option value="北京"> <option value="上海"> <option value="深圳"> </datalist>
- 每个
option只能有value属性，不支持label或额外数据 - 若想显示别名（如“BJ → 北京”），只能把“BJ 北京”作为 value，但会破坏前缀匹配逻辑
- 移动端 Safari 对
datalist支持有限，部分机型不显示建议列表
什么时候该放弃 datalist 改用 JS 实现
只要需求中出现以下任一关键词，datalist 就不再适用：实时请求、防抖、高亮匹配字符、分组、键盘导航（上下键）、点击选中后触发回调、兼容 IE11 以外的旧浏览器。
- 需要调用 API 获取建议？必须用
fetch+input事件监听 - 想让“sh”匹配“上海”“深圳”“杭州”？得用字符串包含判断，而非原生前缀匹配
- 要求按热度排序或带图标？
datalist无 DOM 控制权，无法插入img或添加 class
兼容性与无障碍注意事项
datalist 在 Chrome 20+、Firefox 4+、Edge 79+ 中可用，但 Safari 直到 12.1 才完全支持，iOS Safari 12.2 起才稳定。更重要的是，屏幕阅读器对它的支持不一致：NVDA 通常可读出选项，但 VoiceOver 可能跳过整个列表。
- 不能依赖
datalist作为唯一输入方式，需提供完整选项页面或手动输入兜底 - 如果后台有敏感词过滤逻辑，前端用
datalist暴露全部候选值等于白名单泄露 - 测试时务必在真机 Safari 上验证弹出时机——它常比 Chrome 慢半拍或直接不触发
datalist 最适合内部管理后台的固定枚举输入（如状态类型、部门名称），且团队明确接受其限制。一旦涉及用户级搜索体验，JS 方案虽重一点，但可控性高得多。 
