【寻迹校园 HarmonyOS NEXT 实战 23】相反类型召回与稳定 Top 3：候选列表为什么先做门禁再排序

m0_74969023

351人浏览 · 2026-08-21 02:30:31

m0_74969023 · 2026-08-21 02:30:31 发布

【寻迹校园 HarmonyOS NEXT 实战 23】相反类型召回与稳定 Top 3：候选列表为什么先做门禁再排序

这是“寻迹校园 HarmonyOS NEXT 实战”系列第 23 篇。本文沿着 getMatchBundle() 的真实执行顺序，说明丢失记录为什么只召回拾得记录、候选状态如何门禁、Top 3 应该在何时截断，以及当前仅按分数排序时同分顺序还缺少什么工程保证。

相反类型召回与候选门禁原创封面图

上图为原创生成的流程插画，不是应用截图。左侧的丢失与拾得记录先经过类型、状态和自排除门禁，只有合法候选才能进入评分、排序与 Top 3。

一、召回和排序是两个不同阶段

很多列表实现直接把所有记录算分并排序，看起来只有一条链。业务上应明确拆成：

召回：决定哪些记录有资格参与；
排序：决定合法候选的相对位置；
截断：决定本次界面展示多少条；
解释：说明排序原因和冲突；
失效：权威记录变化后重新计算。

召回错误会把非法记录带入后续所有阶段；排序错误只影响合法候选的顺序。两者的风险和测试方法不同。

二、为什么必须召回相反发布类型

丢失记录的目标是寻找拾得记录，拾得记录的目标是寻找丢失记录。因此门禁是 report.reportType !== query.reportType。

若不做这一步，两条“丢失黑色双肩包”可能因为分类、地点和日期都一致而获得高分，但它们只能说明两个人都在找包，不能形成认领对象。

相反类型门禁属于领域规则，应放在 ReportService。页面临时隐藏同类型条目并不安全，因为小艺适配器、测试或其他入口仍可能调用同一候选数据。

三、为什么要排除查询记录自身

report.id !== query.id 看似多余，因为相反类型已经会排除自身。保留它仍有价值：

明确表达候选不能是查询对象本身；
防止未来类型兼容、历史脏数据或迁移错误破坏假设；
让测试和评审一眼看到自排除契约；
后续若扩展“相似记录合并”，不会意外复用错误逻辑。

冗余门禁只要语义清晰且成本极低，可以作为防御式约束；但不能用它掩盖数据层主键或类型错误。

四、状态门禁决定记录是否仍具备业务资格

当前候选只接受 OPEN 和 CLAIMING：

状态	是否召回	原因
`OPEN`	是	正在公开展示和匹配
`CLAIMING`	是	正在处理申请，仍可解释当前记录，但新动作受 Service 门禁
`DRAFT`	否	尚未发布
`RESOLVED`	否	已完成交接，不应产生新候选
`WITHDRAWN`	否	发布者已停止公开与匹配
`HIDDEN`	否	治理流程已隐藏

是否让 CLAIMING 继续出现在候选中属于产品策略。当前代码允许展示，但 ClaimService 会阻止对非 OPEN 记录再次提交认领，避免重复申请。

五、正确顺序是门禁、评分、排序、截断

当前实现顺序如下：

const candidates: MatchCandidate[] = reports
  .filter((report: ItemReport) => report.id !== query.id && report.reportType !== query.reportType &&
    (report.status === ReportStatus.OPEN || report.status === ReportStatus.CLAIMING))
  .map((report: ItemReport) => this.scoreCandidate(query, report))
  .sort((left: MatchCandidate, right: MatchCandidate) => right.score - left.score)
  .slice(0, 3);

如果先 slice(0, 3) 再排序，结果取决于 Repository 原始顺序，高分候选可能永远进不了前三；如果先评分再过滤，非法记录会消耗计算并可能进入中间数据；如果页面再做一次截断，不同调用方会看到不同集合。

业务 Service 应返回完成门禁与排序的候选契约，页面只负责展示。

六、为什么当前选择 Top 3

比赛演示中，Top 3 能在手机屏幕上保持较低的认知负担，也能让用户逐条查看相似点与冲突。小艺适配器同样最多取前三条并压缩到 240 字，保证显式复制内容短、可读、可脱敏复核。

Top 3 不是算法正确性的证明，也不是所有场景的永久上限。若真实校园数据中多个相似物品集中出现，三条可能造成漏看；若只有低质量候选，展示三条又可能制造噪声。

正式产品可以增加“查看更多”，但第一屏和 AI 摘要仍应保持有限集合。

七、当前“稳定 Top 3”还缺一个显式二级键

代码只比较 right.score - left.score。当两个候选同分时，比较器返回 0，顺序会继承输入列表的相对顺序；但业务代码没有把 Repository 排序规则和同分行为写成明确契约。

因此当前可以说“按分数降序且同分通常继承上游顺序”，不能声称“跨数据源、跨版本绝对稳定”。若 Repository 从内存回退改为数据库查询，或者查询未固定 ORDER BY，同分前三可能变化。

一个更明确的比较器可以使用分数、事件时间、创建时间和 ID：

function compareCandidate(left: MatchCandidate, right: MatchCandidate): number {
  if (left.score !== right.score) return right.score - left.score;
  if (left.report.createdAt !== right.report.createdAt) {
    return right.report.createdAt - left.report.createdAt;
  }
  return left.report.id.localeCompare(right.report.id);
}