原生 list 属性仅支持严格前缀匹配且依赖 value 字符串，必须精确匹配 datalist 的 id，option 的 value 是唯一生效字段，仅 type="text" 和 "search" 稳定可用，iOS Safari 不渲染下拉面板。
原生 list 属性无法实现真正的“智能提示”，它只做严格前缀匹配，且仅靠 value 字符串生效；不写 value、大小写不一致、iOS Safari 下拉不显示——这些不是 bug，是规范行为。
list 属性必须严格匹配 datalist 的 id
浏览器不做容错：写成 list="cities" 就必须存在 <datalist id="cities">，少一个字母、多一个空格、大小写错（如 list="Cities" vs id="cities"）、用 class 或 name 代替 id，都会静默失效。开发者工具里搜不到该 id，基本就能定位问题。
-
list值不是 CSS 选择器，不支持#、.等前缀 -
id不能含不可见字符（如全角空格、零宽空格），复制粘贴时易中招 -
datalist可放在页面任意位置（<head>或</body>前），但不能被display: none隐藏，否则 Chrome 会跳过渲染建议面板
option 的 value 是唯一生效字段
<option>Beijing</option> 不会触发任何提示；只有 <option value="Beijing"></option> 才参与匹配。value 决定用户点选后填入输入框的内容，也决定是否能被当前输入“命中”。
- 空
value=""等同于无选项，会被浏览器忽略 -
label属性仅在部分浏览器（如 Chrome）下改变下拉显示文本，但不影响匹配逻辑 - 不要在
value里塞 HTML 或 JSON：value='{"id":1,"name":"Chrome"}'会导致匹配失败或填充异常 - 若需映射别名（如显示 “中文 Chrome” 但提交 “chrome”），只能靠 JS 在
input的change或blur事件里查表转换
哪些 input type 真正可用
别信 MDN 上的“支持列表”——实际项目中，只有 type="text" 和 type="search" 能稳定触发下拉。其他类型要么表现割裂，要么完全失效：
-
type="email"：Chrome 显示键盘邮箱专用键，但datalist建议可能不弹；Safari 更大概率不响应 -
type="number"：要求所有option.value是合法数字字符串（如"42"，不能是"forty-two"），否则整组建议被忽略 -
type="date"、type="time"、type="color"：Chrome 完全不显示下拉，Firefox/Safari 更弱；别浪费时间调试 -
type="password"、type="hidden"、type="checkbox"：规范明确不支持，写了也白写
iOS Safari 下拉面板几乎不存在
这是最常被忽视的兼容性黑洞：iOS Safari 解析 datalist DOM，但不渲染下拉面板。用户看不到你的 option，只能依赖系统键盘词典补全——和你写的 value 毫无关系。
- 检测方式：
!window.HTMLDataListElement || /Mobile.*Safari/.test(navigator.userAgent) - 降级方案必须前置：不能等用户反馈“没提示”，而应在初始化时就判断并加载 JS 实现的 autocomplete 组件
- 桌面端虽支持，但样式不可控——
::-webkit-list-box等伪元素无效，也无法监听“选中某项”事件，所有交互都归结为普通input事件 - 动态更新
datalist后，Safari 极大概率不刷新选项；实操中需手动触发input.blur(); input.focus();，但仍有概率失败
真正容易被忽略的是：你写的每一条 <option value="..."> 都得是纯字符串、非空、大小写精确匹配用户输入，且后端必须重新校验——因为 datalist 不阻止非法值提交，它只是个“参考”。
