原生 input 的 list 属性配合 datalist 仅提供静态、浏览器内置的下拉建议，不支持动态更新、输入过滤或跨浏览器一致体验，需严格匹配 id 且推荐 type="text"；动态补全必须用 JS 自定义实现。
input 标签本身不支持智能补全，靠的是 list 属性 + datalist
HTML 原生 input 没有“自动补全”逻辑，所谓“自动补全”实际是浏览器对 list 属性的响应行为：它会把关联的 datalist 中的 option 作为下拉建议项展示。这个过程完全由浏览器控制，不触发 JS 事件，也不过滤匹配内容——匹配和渲染都是浏览器内部做的。
常见错误是以为加了 list 就能“输入即过滤”，结果发现所有 option 全部显示、或根本没反应。原因通常是：id 没对上、datalist 放错位置、或者用了不支持的 type（如 type="number" 在部分浏览器中会忽略 list）。
-
input的list属性值必须严格等于datalist的id（大小写敏感） -
datalist可以放在文档任意位置，但不能嵌套在input内部 - 推荐用
type="text"或type="search"；type="email"、type="url"等可能兼容性不佳
如何让补全项动态更新？原生方案做不到，必须换思路
原生 datalist 是静态的，DOM 渲染后就不能“实时更新建议列表”。想实现搜索时动态拉取、按输入内容过滤、甚至带远程请求，就必须放弃纯 HTML 方案，改用 JS 控制的下拉菜单（比如监听 input 事件 + 绝对定位 div + 手动渲染选项）。
这时候 input 只负责输入，补全 UI 完全自定义。你可能会看到一些库（如 awesomplete、select2）封装了这类逻辑，但底层仍是替换掉原生下拉行为。
- 不要试图给
datalist动态innerHTML后期待浏览器重绘——多数浏览器不会响应 - 如果只是少量固定选项（如省份、状态枚举），静态
datalist足够轻量且无障碍友好 - 需要键盘导航（上下键选中）、回车确认、ESC 关闭？这些都得自己用 JS 实现
兼容性与可访问性要注意哪些硬伤？
datalist 在 Chrome/Firefox/Edge（Chromium）中表现接近，但在 Safari 上长期存在 bug：输入时下拉不出现、或只在失焦后才显示。iOS Safari 基本不支持该交互。这意味着如果你的用户群包含大量苹果设备用户，原生方案几乎不可用。
可访问性方面，屏幕阅读器对 datalist 的支持不一致——有些会读出全部 option，有些完全跳过。而手写下拉组件可以加 role="listbox"、aria-expanded、aria-activedescendant 等明确语义，可控性高得多。
- Safari 15.4+ 开始部分修复，但仍有延迟或触发条件苛刻的问题
-
autocomplete="off"会禁用原生补全，但不影响datalist——两者机制不同 - 别依赖
oninput或onchange捕获datalist选择：用户点击选项时，input值改变，但不会触发额外事件
简单可用的静态补全示例（别抄错 id）
下面这段代码能跑通的关键就两点：一是 input 的 list 值和 datalist 的 id 完全一致；二是 option 的 value 是唯一可被补全的内容（label 属性仅用于显示，不参与匹配）：
<input type="text" list="browsers" placeholder="输入浏览器名"><datalist id="browsers"><option value="Chrome"></option> <option value="Firefox"></option> <option value="Safari"></option> <option value="Edge"></option></datalist>
注意：option 不需要 label，也不需要闭合标签；多个相同 value 会导致补全混乱；空格开头或结尾的 value 可能导致匹配失败。
真正难的不是写出来，而是判断什么时候该用原生 datalist，什么时候必须切到 JS 方案——边界往往在“要不要异步”“支不支持 Safari”“有没有键盘操作要求”这三点上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
