原生 HTML 仅能通过 + 实现静态前缀匹配建议，但不支持异步、模糊搜索、样式控制及 Safari 兼容性差；真实场景需用 fetch + input 事件防抖（300ms）、AbortController 取消冗余请求，并动态渲染带键盘导航的绝对定位浮层。
原生 HTML 无法直接实现带建议的搜索框——必须配合 JavaScript 动态渲染下拉列表，且需手动处理聚焦、键盘导航、防抖和点击选中逻辑。
怎么用 input + datelist 快速实现基础建议（但限制多）
datelist 是唯一原生支持建议的 HTML 方案，但它只做静态匹配、不支持异步、不响应输入变化，且浏览器兼容性差（Safari 不支持 filter 行为）。
- 必须搭配
input[list="xxx"]和<datalist id="xxx"></datalist>使用 - 选项只能写死在 HTML 中，
<option value="xxx"></option>的value决定匹配内容，label不参与搜索 - 用户输入时，浏览器仅做「前缀匹配」，无法模糊匹配或高亮关键词
- Chrome 会自动展开下拉，但无法控制样式、位置或键盘上下键行为
<input list="search-suggestions" placeholder="搜产品..."> <datalist id="search-suggestions"> <option value="iPhone 15"> <option value="MacBook Air"> <option value="AirPods Pro"> </datalist>
为什么 fetch + keydown 防抖是主流做法
真实场景中，建议数据来自后端接口，用户每敲一个字都发请求会压垮服务，必须加防抖；同时要避免 input 事件在中文输入法未完成时触发（如拼音上屏前就查“zhong”，结果为空）。
- 监听
input事件比keyup更合理：能捕获粘贴、剪切板操作 - 但必须加判断：
if (event.isComposing) return，跳过中文输入法中间状态 - 防抖用
setTimeout+clearTimeout最轻量，延迟建议设为300ms，太短易漏，太长感知卡顿 - 每次请求前应取消上一次未完成的
fetch，可用AbortController实现
下拉列表 DOM 怎么组织才方便交互和样式控制
不能用 select 模拟，也不该把建议塞进 input 的 title 或 placeholder。标准做法是动态生成一个 <div class="suggestions"> 浮层，绝对定位在 input 下方。<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p>
<ul>
<li>浮层 <code>id 建议用 suggestions-{inputId}，便于绑定和清理
<button type="button"></button> 而非 <a></a> 或 <div>：天然支持空格/回车触发、键盘焦点管理、无障碍（<code>role="option" 可选）
mousedown（而非 click）防止 blur 后丢失选中——因为点击瞬间 input 会先失焦，再触发 click，中间可能清空浮层ArrowDown/ArrowUp 切换 focus，Enter 触发选中，Escape 关闭浮层容易被忽略的边界情况
真正上线时，90% 的 Bug 出现在这些地方：输入为空时没清空建议、窗口 resize 后浮层错位、移动端软键盘弹起遮挡建议、用户快速连打导致请求乱序、后端返回空数组但浮层未隐藏。
- 每次更新建议前，先
element.innerHTML = ""清空旧 DOM，别用removeChild循环删 - 浮层定位不要只靠
getBoundingClientRect()算一次，要监听scroll和resize重算（或用position: fixed+ 手动 offset） - 移动端务必加
touchstart事件监听，iOS Safari 对mousedown支持不稳定 - 用
Promise.allSettled或请求 ID 标记来丢弃过期响应，避免旧请求覆盖新结果
最麻烦的从来不是渲染列表，而是让键盘、鼠标、触控、输入法、缩放、屏幕阅读器全部协同工作——建议列表看似简单，实则是前端交互细节密度最高的组件之一。
