如何在Firestore中查询与用户技能兴趣匹配度最高的职位文档

已知你当前的存储结构如下，用户和职位文档均以数组形式存储标签字段：

// 用户文档示例
skills: ['computers', 'blah-blah']
interests: ['whatever']

// 职位文档示例
skills: ['computers', 'other-skill']
interests: ['whatever', 'hiking']

首先明确前提：Firestore原生查询能力不支持直接计算两个数组的交集大小、按交集数量排序，不要尝试堆叠多个array-contains条件硬实现——单查询最多支持10个数组查询条件，且逻辑是必须同时包含所有指定值，既做不到模糊匹配计数，查询成本还会随标签量指数级上涨，完全不可用。

下面给两个生产环境验证过的可落地方案，按你的数据规模选就行：

方案1：小规模数据集（职位总量<10000）：前置过滤+内存计分排序 #

适合MVP阶段、职位库体量不大的场景，代码量极小，维护成本为0，我自己做的垂直类招聘小程序早期用这个方案跑了8个月没出问题：

• 第一步：拉取匹配候选集
  把当前用户的skills和interests合并成去重的标签列表，用array-contains-any做两轮查询：一轮匹配职位的skills字段，一轮匹配职位的interests字段，把两轮返回的结果按职位ID去重，得到所有至少有1个标签重合的候选职位集。

  注意：array-contains-any单次最多支持传入10个匹配值，如果用户的标签总数超过10个，拆成多批查询再合并结果即可。查询前可以先加一层过滤条件，比如只取最近3个月发布的、状态为招聘中的职位，进一步压缩候选集大小。

• 第二步：内存计算匹配分排序
  遍历拉回的候选职位，分别统计技能重合数、兴趣重合数，可以按业务需求给不同维度加权（比如技能重合1项计2分，兴趣重合1项计1分），最终按总分倒序排列，取前N条返回给前端即可。
• 前置准备：给职位集合的skills、interests、publishTime字段建单字段索引，单查询延迟基本稳定在50ms以内，万条以内数据的内存计分耗时不超过10ms，完全满足前端交互要求。

方案2：中大规模数据集（职位总量≥10000）：接入搜索引擎做匹配排序 #

如果职位库量级上来了，全量拉候选集内存计分的延迟会明显上涨，这时候别自己硬写倒排索引、预计算分数的逻辑——数据同步一致性问题、更新逻辑的坑多到踩不完，直接用成熟的全文搜索服务是性价比最高的选择：

• 用Firestore官方提供的搜索扩展，把职位集合的文档实时同步到Typesense/Algolia这类搜索引擎，同步逻辑不用自己写，配置完字段映射就能自动处理新增、更新、删除的职位数据。
• 搜索引擎原生支持数组字段的交集匹配、重合度计分，你只需要在查询时传入当前用户的技能、兴趣标签列表，给两个维度配置好权重（比如技能权重设为2，兴趣权重设为1），就能直接返回按匹配度从高到低排好序的职位列表，还能叠加发布时间、薪资范围、地点等自定义加权规则，灵活度极高。
• 十万级甚至百万级的职位库，查询延迟基本都能控制在30ms以内，比自己实现的匹配逻辑性能高一个量级。

实操避坑提示 #

• 所有标签入库前必须做标准化处理：统一转小写、去特殊符号、做同义词映射（比如把JS、Javascript、js统一映射为javascript），不然会出现大量语义相同但写法不同的标签漏匹配，我之前踩过这个坑，上线后匹配率直接低了30%，查了半天才定位到问题。
• 不要给完全不重合的职位做计分计算，前置过滤步骤一定要做，能省90%以上的无效计算。
• 匹配分规则不用一开始就做的特别复杂，先跑通基础的标签重合计数，后续再慢慢叠加用户行为权重、职位标签权重就行。

内容的提问来源于stack exchange，提问作者whit3.oc7opus