【OpenHarmony/HarmonyOs 】ArkUI 搜索体验实战：防抖联想、URL 识别与兴趣推荐

前言

导航首页的搜索框不应只会“点击后跳到搜索引擎”。优秀的搜索体验需要判断用户输入的是关键词还是网址、及时给出联想、过滤本地收藏，并且避免每输入一个字符就请求网络。本文拆解 LinkOS 链界中的搜索与推荐实现。🔍

一、搜索输入的三种意图

用户输入内容通常属于三类：

1. HarmonyOS ArkTS：普通关键词，应跳到搜索引擎；
2. developer.huawei.com：域名，应直接打开；
3. https://github.com：完整链接，也应直接打开。

因此输入变化时不能立即统一搜索，而要先做意图识别。

二、把输入规范化为 HTTPS URL

privatenormalizeInputToHttpsUrl(strInput:string): string |null{ const raw = (strInput ||'').trim();if(!raw)returnnull;if(raw.startsWith('https://'))returnraw;if(raw.startsWith('http://')) {return`https://${raw.substring('http://'.length)}`;} const domainLike =/^[a-z0-9.-]+\.[a-z]{2,}([/:].*)?$/.test( raw.toLowerCase() ); return domainLike ? `https://${raw}` :null; }

这里有两个业务选择：一是无协议域名默认补https://；二是把 HTTP 尝试升级为 HTTPS。这样可以让所有后续链路遵守应用的安全约束。

正则只承担“快速判断像不像域名”，不是完整 URL 解析器。生产环境还应考虑国际化域名、IPv6、端口、非法字符以及目标站点是否真的支持 HTTPS。

三、260ms 防抖降低请求量

privaterecommendSuggestSeq:number=0;privatescheduleRecommendSuggestFetch(input:string):void{constq = input.trim();this.recommendSuggestSeq+=1;constseq =this.recommendSuggestSeq;setTimeout(async() => {if(seq !==this.recommendSuggestSeq)return;awaitthis.fetchRecommendSuggest(q); },260); }

这是一种轻量的“序列号防抖”。每次输入都会增加序列号，旧定时任务即使到期，也会因为序列号不一致而退出。

为什么还需要处理响应乱序？假设请求 A 先发、请求 B 后发，但 A 的网络响应更晚回来。如果没有版本校验，旧结果可能覆盖新结果。因此更完整的方案应在发起请求和写入状态时都校验序列号，或者使用可取消请求。

四、只在合适的时候获取联想

if(!query || query.length <2||this.isLikelyUrlQuery(query)) {this.recommendSuggestList = [];this.recommendSuggestLoading =false;return; }

空输入、单字符和 URL 都不请求联想。这样既减少接口压力，也避免用户明确输入网址时弹出无关关键词。

项目通过 Axios 请求 Bing 建议接口，并最多保留 8 条：

constresp =awaithttp.get(`https://api.bing.com/osjson.aspx?query=${encodeURIComponent(query)}`);if(Array.isArray(resp.data) && resp.data.length>=2) {constsuggestions = resp.data[1];// 校验数组与字符串类型后，再写入 @State}

解析外部 API 时不能假定结构永远正确。数组层级、元素类型和空值都应检查；失败时清空联想并保持页面可继续使用。

五、本地搜索使用加权排序

简单的includes()只能判断匹配与否，无法区分结果质量。项目为标题和 URL 设置不同分数：

let score =0;if (title.startsWith(q)) score +=20;if (url.startsWith(q)) score +=10;if (title.includes(q)) score +=5;if (url.includes(q)) score +=3;

随后先按得分降序，再按更新时间降序。于是“Git”搜索中，以 Git 开头的标题会排在 URL 中偶然包含 Git 的站点之前；同分时，最近编辑内容优先。

这种规则容易解释、无需额外依赖，也适合几十到几百条本地收藏。数据更多时，可将标准化文本预计算，或交给数据库索引完成。

六、搜索词与网址使用不同动作

关键词被编码后交给搜索引擎：

privatebuildSearchUrl(query:string):string{return`https://cn.bing.com/search?q=${encodeURIComponent(query.trim())}`; }

encodeURIComponent()很重要。空格、中文、&等字符如果直接拼接，会破坏查询参数，甚至引入参数注入问题。

而候选网址会直接进入统一的openUrl()，先安全检查，再统计访问并跳转 WebView。所有入口复用同一函数，避免某条路径漏掉安全校验。

七、兴趣推荐不等于 AI 推荐

项目还会根据用户兴趣组合本地候选站点。早期产品完全可以采用“兴趣标签 → 候选表 → 去重 → 排序”的可解释规则，不必一开始就引入复杂模型。

推荐系统至少应遵循：

• 相同 URL 只出现一次；
• 用户自定义站点优先级高于系统预置；
• 用户明确隐藏的内容不再推荐；
• 推荐理由可以展示，例如“因为你选择了开发工具”；
• 没有兴趣数据时提供稳定的默认集合。

八、交互状态不可缺少

一个完整搜索面板至少要覆盖：

• 输入为空：隐藏建议；
• 正在请求：显示轻量加载提示；
• 请求失败：不阻塞本地搜索；
• 无本地结果：显示空状态与添加入口；
• URL 已收藏：按钮显示“已添加”并禁用；
• 危险链接：弹窗说明已拦截。

这些状态往往比“请求成功的主路径”更影响真实体验。🌟

九、总结

搜索体验是一条小型数据流水线：输入清洗 → 意图识别 → 防抖 → 本地匹配/远程联想 → 加权排序 → 安全打开。将每一步拆成纯粹的小函数后，逻辑更容易测试，页面代码也更容易阅读。对 HarmonyOS 导航、知识库或本地文件检索应用，这套方法都可以复用。