HTML原生<input type="search">不触发实时搜索，需手动监听input事件、加防抖、取消 pending 请求、限制最小输入长度；其唯一优势是语义化、无障碍支持及自动清除按钮。
HTML原生<input type="search">不触发实时搜索
浏览器自带的搜索框只是个输入控件，敲回车或点放大镜图标才提交表单，不会在你每按一个键时发请求。它没有内置监听逻辑，也不绑定input事件，更不处理防抖、请求节流或响应渲染——这些全得你自己写。
常见错误现象：
— 页面放了个<input type="search">，以为加了name="q"就能自动“实时”；
— 直接监听change事件，结果用户还没输完就失焦触发了（比如切窗口），搜出一堆空或半截词；
— 用keyup但没做防抖，连打“react”触发了6次请求，后端返回乱序，UI反复闪。
实操建议：
— 必须手动监听input事件（不是change）；
— 加至少300ms防抖，用setTimeout或clearTimeout控制；
— 每次发起新请求前，取消上一个未完成的fetch（可用AbortController）；
— 输入长度＜2时不发请求，避免噪音查询。
实时搜索必须自己实现异步交互链路
所谓“实时”，本质是「输入→防抖→请求→解析→更新DOM」这一整条链路的可控闭环。HTML搜索框只负责最前端的输入呈现，中间三步完全空白。
立即学习“前端免费学习笔记（深入）”；
使用场景差异：
— 纯静态页面配<form>跳转：适合SEO优先、无交互需求的搜索页；
— SPA中下拉联想（如GitHub仓库搜索）：必须用fetch + Promise + then或async/await；
— 输入即显筛选结果（如本地JSON过滤）：可跳过网络请求，但依然要监听input并重绘列表。
性能影响点：
— 不设请求取消机制，快速输入易堆积pending请求，内存泄漏风险；
— 响应数据没做缓存（如相同关键词重复搜），浪费带宽；
— 渲染大量DOM节点（如联想项超50条）不虚拟滚动，滚动卡顿明显。
search类型输入框的唯一实际价值：语义与基础体验
它跟type="text"渲染几乎一样，区别只在三点：
— 在Safari/iOS上自动显示清除按钮（×图标）；
— 屏幕阅读器识别为搜索意图，提升无障碍访问；
— 表单提交时，部分浏览器会把值编码为q=xxx而非search=xxx（取决于name属性）。
别指望它帮你省代码。如果你需要清空按钮，type="search"确实比手写<button onclick="el.value=''">简洁；但一旦涉及实时行为，它和type="text"在JS层面毫无区别——都得靠addEventListener('input', ...)驱动。
容易被忽略的边界情况
真实项目里，这几个点常被跳过，上线后才暴露：
— 用户粘贴文本（paste事件）没监听，导致粘贴后不触发搜索；
— 中文输入法组合字阶段（如“zhong”还没选“中”）就触发input，搜出无效词；
— 移动端软键盘收起时blur，但用户可能想继续输，不该在此刻强制提交；
— 后端返回空数组或报错时，UI没降级展示“暂无结果”或错误提示，留白或报红屏。
建议统一处理：
— 同时监听input和paste；
— 对中文输入加compositionstart/compositionend拦截；
— 所有请求包装成try/catch，失败时保留上次有效结果或显式提示；
— 清除按钮点击后，除了清空value，还要手动触发一次input事件，确保防抖逻辑重置。
