需配合实现原生搜索建议，通过list属性与严格匹配（大小写敏感），仅支持前缀匹配；javascript方案则监听input事件、动态渲染列表，并需处理ime、定位、可访问性等细节。
input 元素如何触发搜索建议下拉列表
原生 <input> 不自带联想词下拉，必须配合 <datalist></datalist> 或 JavaScript 手动实现。用 <datalist></datalist> 是最轻量、语义正确且无需 JS 的方案，但仅支持静态匹配（浏览器自动过滤），不支持异步加载或模糊搜索。
-
<input list="suggestions">必须与<datalist id="suggestions"></datalist>的id严格一致，大小写敏感 - 所有候选词用
<option value="xxx"></option>写入，value属性值才会被匹配和填充，text content不参与匹配 - Chrome / Edge 支持较好；Firefox 仅在 focus 后按向下键才显示；Safari 对空格、中文首字匹配不稳定，建议避免用全角字符做首项
用 JavaScript 动态渲染联想词时 DOM 结构怎么写
动态方案需自己管理 <div class="autocomplete"> 容器 + <code><ul></ul> + 多个 <li>，关键在于位置同步和焦点控制。不要用 position: absolute 硬写 top/left，而应基于 input 元素实时计算 offset。
- 监听
input事件（不是keyup），避免漏掉粘贴、IME 输入等场景 - 每次更新前清空
<ul></ul>子节点，否则旧选项残留；插入新<li>时统一加tabindex="-1"，方便键盘导航 - 用
input.getBoundingClientRect()获取 input 位置，再通过getComputedStyle拿到 border/padding，确保下拉框顶部对齐 input 底边 - 点击
<li>后要主动input.focus()并触发input事件，否则 React/Vue 等框架可能无法捕获值变更
为什么输入中文时联想词不触发或错位
根本原因常是事件时机与输入法（IME）状态冲突。中文输入法在组合阶段（如拼音未上屏）会先发 compositionstart，此时 input.value 还是旧值，若立即查词就会漏匹配。
- 必须监听
compositionstart暂停联想请求，等compositionend后再执行查询 - 移动端 Safari 对
composition事件支持不全，可 fallback 到setTimeout延迟 100ms 再查，避开 IME 组合期 - 若下拉框高度随内容变化，iOS 上可能出现滚动错位——给容器加
transform: translateZ(0)强制硬件加速可缓解 - 避免在
input上设font-size: 0或line-height: 0，这会让 iOS 计算 input 高度为 0，导致下拉框定位失效
aria-label 和 role 怎么配才能让屏幕阅读器正常读联想词
只加 role="listbox" 不够，必须配套 aria-expanded、aria-activedescendant 和每个选项的 role="option"，否则 NVDA/JAWS 会跳过整个列表或读错状态。
-
<input aria-autocomplete="list" aria-controls="suggestion-list">中aria-controls必须指向下拉容器的id - 下拉容器用
<div role="listbox" id="suggestion-list">，初始 <code>aria-expanded="false"，展开时改为"true" - 当前高亮项需动态设置
aria-activedescendant="option-2"，并确保对应<div role="option" id="option-2"> 存在 <li>每次键盘移动焦点时，不仅要改样式，还要调用 <code>element.setAttribute('aria-selected', 'true')，否则 VoiceOver 不会朗读选中态
实际中最容易被忽略的是 IME 期间的状态同步和屏幕阅读器的 aria 属性联动——这两处出问题，用户要么看不到建议，要么听到“无结果”却明明有选项。
