type="search" 仅提供语义化和基础交互（如清空按钮、系统建议），不实现实时搜索；实时搜索需用 JS 绑定 input 事件、防抖、AbortController 取消请求，并注意跨端渲染陷阱。
input type="search" 不能替代实时搜索——它只是个带清空按钮的输入框，不自带过滤、请求或高亮逻辑。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
type="search" 只负责语义和基础交互
浏览器识别 type="search" 后会自动添加清空按钮、可能启用系统级搜索建议（如 Safari 的历史关键词下拉），但不会：
- 自动监听输入并触发 AJAX
- 过滤页面表格或列表
- 高亮文档中匹配的文字
- 阻止表单默认提交（除非你显式调用 e.preventDefault()）
它和 type="text" 在功能上几乎等价，差异仅在渲染样式、可访问性属性和部分原生行为（如 iOS 上长按弹出“搜索”菜单）。
实时搜索必须靠 JS 主动实现
所谓“实时”，是指用户输入过程中动态响应，这需要你亲手绑定事件并控制节奏：
- 必须用 input 事件（不是 keyup 或 change），否则粘贴、语音输入、删除都会漏掉
- 必须加防抖（例如 setTimeout + clearTimeout），否则每敲一个字就发一次请求，后端会拒绝服务
- 若连续输入，旧请求结果可能覆盖新结果，得用 AbortController 主动取消挂起的 fetch
- 过滤 DOM 内容时，要明确作用范围（比如只查 tbody 里的 tr，别误操作 header 或广告位）
常见混淆点：placeholder 居中、清空按钮失效、聚焦丢失
这些不是实时搜索没写对，而是 type="search" 在不同环境下的渲染陷阱：
- Safari / iOS 默认给 input[type="search"] 加了 padding 和圆角，appearance: none 一加，清空按钮常变不可点——得手动重写按钮样式或换用自定义清空按钮
- placeholder 在部分 Android 浏览器里不垂直居中，别依赖它做视觉对齐基准
- 点击后键盘闪退？大概率是聚焦瞬间触发了 scrollIntoView 或 CSS 动画重排，导致 input 失焦；可用 setTimeout(() => el.focus(), 0) 延迟聚焦绕过
- name 属性漏写，表单提交时参数就消失——这不是 JS 问题，是 HTML 结构缺陷
真正难的从来不是写个“能动”的搜索框，而是让那个小输入框在折叠屏、微信内嵌页、低配安卓机上，每次点击都稳稳唤出键盘、不丢焦点、不误触、不卡顿。这些细节，往往比防抖逻辑更耗时间。
