datalist 在 ios safari 中完全不生效，仅渲染为普通输入框且无任何降级提示；需通过 ua 检测识别并切换为 js 实现的可访问 autocomplete 方案。
datalist 在 iOS Safari 中不是降级为普通输入框，而是基本不生效——下拉建议列表通常完全不显示，且无任何 fallback 提示或自动回退逻辑。
datalist 在 iOS Safari 中的实际表现
-
iOS Safari（截至 2026 年 4 月，包括 iOS 17/18）对
datalist的支持为「名义存在、功能缺失」：-
input元素能正常渲染，list属性也合法，但点击/聚焦后从不弹出下拉选项 - 用户无法通过键盘上下键选择
option，也无法触发任何与列表交互的事件（如select、input的list相关行为） - 没有控制台报错，也没有警告，浏览器静默忽略该特性
-
它不会“降级”成带提示的输入框，也不会自动添加 placeholder 或 tooltip；它就是个纯文本输入框，且开发者必须自行补足体验缺口。
如何检测并应对 iOS Safari 的 datalist 失效
-
判断是否在 iOS Safari 中运行，可用轻量 UA 检测：
const isIOSWebKit = /iPad|iPhone|iPod/.test(navigator.userAgent) && !window.MSStream;
若为 true，应主动禁用
datalist绑定，并切换到 JavaScript 实现的 autocomplete（如基于input+div下拉 +aria-属性）不要依赖 CSS 伪类（如
::-webkit-list-box）试图修复，iOS Safari 不暴露该伪元素-
关键兼容性动作清单：
- 用
aria-autocomplete="list"和aria-expanded手动控制可访问状态 - 用
aria-activedescendant跟踪高亮项，配合键盘导航 - 必须监听
input事件做前缀过滤，不能等浏览器内置匹配 - 移动端需处理软键盘遮挡：下拉容器需动态计算位置，避免被 keyboard 盖住
- 用
为什么不能只靠 datalist 做跨端自动完成
-
它的语义是“建议值集合”，而非“交互控件”：
-
option仅用于填充value，不携带 label/description，也不支持 disabled 或分组 - 不支持模糊匹配、拼音首字母、搜索高亮等真实业务需要的功能
- 服务端无法感知用户是否“选择了建议项”还是“手动输入了相同内容”，因为两者都只是设置
value
-
真实项目中，一旦你发现用户流量里 iOS 占比超 20%，就该把
datalist当作「仅 Chrome/Edge 桌面端的快捷写法」，而非核心方案。
复杂点在于：它看起来是个标准 HTML 特性，但实际行为在各平台差异极大——iOS Safari 不报错、不警告、不降级，只是彻底沉默。最容易被忽略的是，很多团队在桌面端测试完就上线，直到用户反馈“iPhone 上没提示”才意识到问题，而这时已错过无障碍和 SEO 相关的早期设计窗口。
