项目文档、商品、帮助条目：候选项多到列不全，用户心里有词，输入实时筛检最省力。
输入关键词，结果和计数长在物件上
搜索每一步都长在结果区物件上：头部计数随输入实时变、命中片段在标题上高亮、无匹配时物件变空态。先把它们操作出来，再解释为什么。
场景：在项目内容里找一条。输入关键词实时筛检，命中片段高亮、计数长在结果区头部；没匹配时物件变空态；可一键清除回全部。
结果未筛检
全部 6 条- 键盘可访问性清单让 Tab、Enter 和方向键完成主要任务。
- 输入框错误提示把字段、原因和修复方式一起说清。
- 菜单和当前路径保留当前项、权限状态和可观察的导航反馈。
- 移动端导航方案窄屏下保持入口可见，折叠和展开都可操作。
- 搜索结果排序结果应按相关性排序，并说明匹配范围。
- 空状态与恢复没有匹配内容时给出清除和继续探索的下一步。
对照：结果区当前显示全部 6 条，计数贴在结果区头部物件上。原因：关键词为空，未做筛检。下一步：输入「导航」或「键盘」，看结果与计数实时同步。
做搜索时要盯这些
实验台证明的是机制；真正写搜索入口时，用这几条检查边界。
- 结果计数要长在结果物件上把「N 条命中」贴在结果区头部，而不是只写在底部状态栏；用户视线在结果上时就能看到检索是否跑了。
- 命中片段要高亮在标题或摘要里把匹配到的字符高亮，让用户判断为什么这条算命中，而不是只看到一排标题。
- 无匹配要有空态和下一步查不到时保留关键词、说明 0 条，并给出换词或清除的动作，不要让结果区只剩一块空白。
- 说清匹配范围标题、摘要、标签是否都参与匹配要在界面上可推断；否则用户不知道为什么搜不到以为该有的结果。
- 实时筛检与提交都要可达边输边筛能让用户快速收敛；同时保留 Enter 或「搜索」按钮给习惯提交的用户，并用真实 search 语义。
什么时候用搜索，什么时候换别的
判断依据是「数据集多大、用户已知多少、是关键词还是结构化属性」。
用户记得标题里的一个词，搜索替他省去逐页翻找；命中高亮还能确认这条是不是想要的。
按状态、负责人、日期缩小范围用筛选（filter）更可靠；搜索框处理不好「且」关系的多条件。
三五个固定选项用选择器或单选框更直接；搜索反而多一次输入和确认。
怎么用：从输入到判断的最短路径
让计数、高亮、空态和清除都挂在同一个搜索入口上，键盘和读屏都能完成。
- 用真实 search 语义：input type="search" 包在 form role="search" 里，配可见 label，Enter 提交。
- 边输边筛：onChange 实时过滤标题、摘要和标签；数据集大时加 200–300 毫秒防抖，避免每键一次请求。
- 把计数贴在结果区头部物件上（如「3 条命中」），同时用 aria-live 让读屏能念到计数变化。
- 在标题和摘要里把命中片段包成 mark 高亮；颜色只加强，高亮还要靠文字本身可读。
- 无匹配时结果区物件变空态：保留关键词、说明 0 条，给「清除」或「换词」的下一步，不要留空白。
正反例：同一个无匹配关键词，只差结果区怎么处理
目标都是搜一个查不到的词。差别只在结果区物件是否给出可恢复的下一步。
搜「xyz」查不到时，结果区头部计数变「0 条 · 无匹配」，物件变成空态卡，说明哪里都没匹配，并提供「清除并恢复全部」。用户知道检索跑了、没结果，并知道下一步。
这样做搜不到就把输入框清空、结果区什么也不显示，也没有计数和说明。用户分不清是检索还没跑、网络慢，还是真没结果，只能瞎试。
别这么省快速自测
搜索一个查不到的关键词时，结果区最该保留什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。