list 属性原生支持但渲染不一致：Chrome/Edge 显示下拉箭头并响应键盘，Firefox 仅输入时匹配提示，Safari 直到16.4才有限支持且不自动展开；大小写错误、<datalist> 位置不当、<option> 缺 value、非 text 类型 input 均导致失效；需用 JS 模拟下拉以保兼容。
list 属性本身是原生支持的，但浏览器渲染差异大
list 是 <input> 的标准 HTML5 属性，用来关联一个 <datalist> 元素。它不是 JS 插件，也不需要 polyfill——但问题出在「渲染行为不一致」：Chrome / Edge 会显示下拉箭头并响应键盘上下键；Firefox 只在输入时匹配提示，不显示可点击下拉；Safari（macOS/iOS）长期不支持 list，直到 Safari 16.4（2023 年 3 月）才开始有限支持，且不触发 focus 时的自动展开。
这意味着你不能靠 list 实现“稳定可控的下拉交互”，尤其当用户期望点击输入框就看到全部选项时。
用 datalist + input 搭配时，哪些写法会失效
常见错误写法直接导致匹配失败或完全不提示：
-
id 和 list 值大小写不一致（比如 <datalist id="Cities"> 但 list="cities"）
-
<datalist> 放在 <body> 外或未被解析（如动态插入后没触发重排）
-
<option> 缺少 value 属性（只有文本内容），部分旧版 Chrome 不识别
- 对
input[type="number"] 或 input[type="date"] 使用 list —— 浏览器会忽略，因为类型控件已有内置逻辑
id 和 list 值大小写不一致（比如 <datalist id="Cities"> 但 list="cities"）<datalist> 放在 <body> 外或未被解析（如动态插入后没触发重排）<option> 缺少 value 属性（只有文本内容），部分旧版 Chrome 不识别input[type="number"] 或 input[type="date"] 使用 list —— 浏览器会忽略，因为类型控件已有内置逻辑正确最小可用示例：
<input list="browsers" name="browser"> <datalist id="browsers"> <option value="Chrome"> <option value="Firefox"> <option value="Safari"> </datalist>
要兼容 Safari 和老 Firefox，得降级到 JS 控制的下拉
如果你必须让所有浏览器都显示「点击即展开、支持键盘导航、可自定义样式」的下拉列表，list 就不够用了。此时应主动接管：
- 监听
input 和 focus 事件，根据输入值过滤选项
- 用
position: absolute 容器模拟下拉层，避免 <datalist> 的不可控定位
- 用
aria-expanded、aria-controls 等属性维持可访问性
- 禁用原生
list（删掉 list 属性），防止双重复合行为
input 和 focus 事件，根据输入值过滤选项position: absolute 容器模拟下拉层，避免 <datalist> 的不可控定位aria-expanded、aria-controls 等属性维持可访问性list（删掉 list 属性），防止双重复合行为简单判断是否需降级：
const supportsDatalist = 'list' in document.createElement('input');
返回 false 就说明是 Safari
立即学习“前端免费学习笔记（深入）”；
移动端 iOS Safari 的特殊坑：点击不触发 focus，导致下拉不弹
iOS Safari 在软键盘唤起前，常跳过 focus 事件，也就不会触发你基于 focus 的下拉展示逻辑。解决方法不是等 focus，而是监听 input 的第一次非空输入，或用 touchstart + setTimeout 强制聚焦：
- 给
input 加 onTouchStart="this.focus()"（注意防重复）
- 避免用
blur 关闭下拉，改用点击外部区域 + pointerdown 判断
- iOS 下
scroll 会意外关闭原生 datalist 弹层，JS 方案反而更稳
input 加 onTouchStart="this.focus()"（注意防重复）blur 关闭下拉，改用点击外部区域 + pointerdown 判断scroll 会意外关闭原生 datalist 弹层，JS 方案反而更稳真正难的不是写出兼容代码，而是决定什么时候放弃 list —— 它适合轻量提示，不适合交互核心路径。
