直接为 input 添加 list 属性并指向 datalist 的 id 即可原生显示下拉建议，但仅支持大小写敏感的前缀匹配，且 datalist 必须有闭合标签、id 与 list 值一致，不提供输入限制或模糊搜索能力。
如何让 input 元素显示下拉建议列表
直接给 input 加上 list 属性，并指向一个 datalist 的 id，浏览器就会在聚焦输入框时显示建议项。这个行为是原生支持的，不需要 JS 就能触发，但仅限于用户手动输入时匹配前缀（不是模糊搜索）。
常见错误是把 datalist 写成自闭合标签（<datalist />），它必须有开始和结束标签；另一个典型问题是 list 属性值和 datalist 的 id 不一致，导致完全不生效。
-
datalist必须放在文档中（可以不在input附近），但不能放在select、textarea或其他表单控件内部 - 每个
option只能用value属性提供建议值，label属性可选，用于显示更友好的文本，但不会影响匹配逻辑 - 用户点击建议项后，
input的值会被设为对应option的value，不会触发change事件，只触发input事件
datalist 和 select 的关键区别在哪
datalist 是“建议”，不是“限定”——用户仍可自由输入任意内容，哪怕不在列表中；而 select 是强制从选项中选择。这点常被误用：有人想做「只能选列表里的值」，却只用了 datalist，结果校验还得靠 JS 补全。
另外，datalist 不会响应 disabled 属性（它本身没这个属性），也不能通过 CSS 伪类如 ::-webkit-listbox 深度定制下拉样式，浏览器控制权远大于 select。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 若需限制输入范围，必须配合 JS 校验 + 后端兜底，
datalist本身不提供约束力 -
select支持分组（optgroup），datalist不支持 - 移动端 Safari 对
datalist的支持较弱（iOS 15.4 之前不显示建议），Android Chrome 表现稳定
为什么 typed 值没匹配到 datalist 里的项
匹配规则非常简单：只比对用户当前已输入的字符串是否为 option[value] 的**开头子串**（case-sensitive）。比如 value="apple"，输 App 就不会出现，输 app 才会。
没有自动忽略空格、没有拼音匹配、没有大小写归一化。这也是最常被吐槽“不智能”的原因。
- 若需大小写无关匹配，得用 JS 动态生成
option（例如同时写apple和Apple），但注意这会让列表冗余 - 不能用正则或通配符，
value必须是完整字符串 - 如果
input类型是number或email，部分浏览器会禁用datalist建议（Chrome 115+ 已修复number类型的支持）
兼容性和 fallback 怎么处理
IE 完全不支持 datalist，Edge 12–18 支持但有渲染 bug（建议项重叠）。所以只要有 IE 用户场景，就必须准备降级方案。
最稳妥的 fallback 是用 JS 检测支持性：!!document.createElement('datalist').options，为 false 时动态插入一个 select 或启用 autocomplete 插件。
- 不要依赖
Modernizr这类重型库做单一特性检测，一行判断足够 - 服务端渲染时，避免把
datalist写在noscript里——它和 JS 无关，禁用 JS 后依然可用 - 无障碍方面，
datalist本身不提供 ARIA 支持，若需读屏兼容，得额外加aria-autocomplete="list"和aria-controls指向容器
