原生 datalist 无法加载远程数据，因其纯静态 dom 机制，仅初始渲染时读取 option，不响应后续 dom 更新，且不支持 async、src 等网络属性；动态更新需清空、创建、挂载 option 元素，并注意 xss、浏览器兼容性及防抖；当需键盘导航、点击回调、服务端搜索或样式定制时，应放弃 datalist，改用 aria 自建下拉或组件库。

为什么原生 datalist 不能直接加载远程数据

它压根没设计网络能力——datalist 是纯静态 DOM 机制，浏览器只在初始渲染时读取一次 option 子节点，之后无论你用 fetch 拿到多少新数据，它都不会自动感知、也不会重绘下拉面板。

常见错误是：发完请求、清空再塞入新 option，但下拉框还是旧的。原因不是代码没执行，而是浏览器对已展开的 datalist 面板不响应 DOM 更新（尤其 Chrome 和 Safari）。

• 不支持 async、src 或任何属性触发远程加载
• option 必须是真实 DOM 元素，不能靠字符串拼接后赋给 innerHTML（有 XSS 风险，且部分浏览器会忽略无 value 的项）
• IE 完全不支持，Edge 12–18 行为不可靠，Safari 对动态更新极其迟钝

如何用 JS 动态更新 datalist 的 option

核心动作就三步：清空、创建、挂载。但每步都有坑。

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

• 清空必须用 dataList.innerHTML = '' 或遍历 removeChild，别用 dataList.textContent = ''——它不清除节点，只删文本
• 每个 option 必须显式设置 option.value = 'xxx'；写成 <option>xxx</option> 而不设 value，在 Chrome 115+ 和旧 Edge 中建议可能完全不出现
• 新增要用 document.createElement('option') + textContent 或 setAttribute('value', ...)，避免直接 innerHTML += '<option value="..."></option>（XSS 漏洞）
• 移动端 Safari 在快速连续输入时容易卡住更新，建议加防抖：延迟 200ms 再执行更新逻辑

input 输入时如何触发 datalist 刷新

监听 input 事件是最直接方式，但要注意触发时机和匹配逻辑本身不归你管——datalist 只做前缀匹配，JS 刷新只是换一批候选，不改变这个规则。

• 不要监听 keydown 或 keyup，它们在中文输入法下会漏掉组合字符（比如“火”字还没上屏就被触发）
• 每次更新 datalist 后，已展开的下拉框通常不会重绘；如需强制刷新，可临时 input.blur() 再 input.focus()，但会打断用户操作流
• 服务端返回的数据若含拼音字段（如 {name: "Chrome", pinyin: "chang"}），得在 JS 里自己做模糊过滤，datalist 不提供该能力
• 如果用户输完回车或 Tab 填入了某个 option 的值，input.value 就是那个 value；但你无法通过事件知道“他点的是第几个”，只能靠比对前后值变化来推测

真正该放弃 datalist 的时候

当你需要以下任一能力时，说明它已经超出能力边界：

• 键盘方向键导航选项（datalist 不支持 role="option" 或 aria-activedescendant）
• 点击选项后执行回调（没有 select 事件，change 又太晚）
• 服务端搜索联想（带分页、高亮、拼音/错别字容错）
• 样式定制下拉面板（CSS 无法穿透到内部，各浏览器渲染差异大）

这时候该用 <div> + <code>fetch + ARIA 自建下拉，或引入成熟组件库（如 @headlessui/react 的 Combobox）。datalist 的价值只在轻量、降级、无需 JS 即可用的场景——一旦需要控制权，它就该退场了。