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

前言

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

一、搜索输入的三种意图

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

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

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

二、把输入规范化为 HTTPS URL

private normalizeInputToHttpsUrl(strInput: string): string | null {
  const raw = (strInput || '').trim();
  if (!raw) return null;
  if (raw.startsWith('https://')) return raw;
  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 防抖降低请求量

private recommendSuggestSeq: number = 0;

private scheduleRecommendSuggestFetch(input: string): void {
  const q = input.trim();
  this.recommendSuggestSeq += 1;
  const seq = this.recommendSuggestSeq;

  setTimeout(async () => {
    if (seq !== this.recommendSuggestSeq) return;
    await this.fetchRecommendSuggest(q);
  }, 260);
}

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

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

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

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

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

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

const resp = await http.get(
  `https://api.bing.com/osjson.aspx?query=${encodeURIComponent(query)}`
);

if (Array.isArray(resp.data) && resp.data.length >= 2) {
  const suggestions = 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 的站点之前；同分时，最近编辑内容优先。

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

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

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

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

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

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

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

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

推荐系统至少应遵循：

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

八、交互状态不可缺少

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

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

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

九、总结

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