autocomplete属性仅影响表单内输入框的历史记录填充，无法实现动态建议列表；需监听input事件，结合fetch、防抖和缓存实现真正的自动补全。
搜索框自动补全用 autocomplete 属性就行？别急，它只对表单有效
HTML 原生 autocomplete 属性（如 autocomplete="on" 或 autocomplete="search"）不会让自定义搜索框弹出建议列表。它只影响浏览器对表单字段的**历史记录填充行为**，比如用户之前在同域名下输过的搜索词，且必须满足：字段是 <input type="search"> 或 <input type="text">、在 <form></form> 内、用户曾提交过该表单。仪表盘里常见的独立 <input> 搜索框，不包 <form></form>，基本没反应。
真正要实现“输入时动态显示匹配项”，得自己控制建议列表的显隐和渲染。核心思路是监听 input 事件，查数据，更新 DOM。
用 fetch + debounce 防止高频请求打崩后端
每次按键都发请求，用户连打 “react” 五个字，可能触发 5 次 fetch，后端压力大，前端还容易收到乱序响应（比如“reac” 的响应比 “react” 先到，覆盖了正确结果）。必须加防抖。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用
setTimeout手写简单防抖：每次输入清掉上一个定时器，只保留最后一次输入后 300ms 的请求 - 请求地址建议带缓存头，比如后端返回
Cache-Control: public, max-age=60，相同关键词 1 分钟内不重复请求 - 如果补全数据量小（Array.filter() 本地匹配，更快更稳
DOM 渲染建议列表时，必须处理焦点与键盘导航
光渲染 <div class="suggestions"> 不够。用户要用方向键上下选、回车确认、ESC 关闭——这些交互不实现，体验就断层。<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>keydown 监听：ArrowDown 移动高亮项，Enter 触发选中，Escape 隐藏列表
<button type="button"></button> 而不是 <div>，天然支持键盘聚焦、空格/回车点击，无障碍友好
<li>用 <code>aria-expanded 和 aria-controls 关联搜索框与列表，屏幕阅读器能感知状态变化IE11 或旧版 Safari 下 fetch 报错？先检查 Promise 和 fetch 是否存在
仪表盘常需兼容老系统。IE11 完全不支持 fetch，部分旧 Safari 对 AbortController 支持不全。不能只写 fetch(...).then(...) 就完事。
- 运行前检测：
if (!window.fetch || !window.Promise)，不支持就降级为XMLHttpRequest - 防抖用的
setTimeout没问题，但记得在组件卸载（比如路由跳转）时clearTimeout，避免内存泄漏 - 如果用到
AbortController取消请求，旧浏览器需引入 polyfill，或改用XMLHttpRequest.abort()
补全逻辑本身不复杂，难的是边界情况：输入为空时清空列表、点击页面其他地方关闭列表、异步请求失败时展示 fallback 提示、移动端软键盘收起后自动隐藏建议——这些细节堆起来，才是真实项目里最耗时间的部分。
