如何使用GeoFire或GeoFirestore查询距离多个点位最近的点

完全可以通过GeoFire搭配Realtime Database，或是GeoFirestore搭配Firestore实现该需求，两种方案分别对应Firebase的两类数据库，可根据你的现有技术选型直接选择。

两类Geo工具库的核心原理都是将经纬度坐标转换为可排序的Geohash字符串存入数据库，原生支持按「中心点坐标+查询半径」快速检索范围内的所有点位，无需自行实现经纬度距离计算逻辑，适配你的外卖场景步骤如下：

1. 存储层预处理：将所有在岗配送员的实时位置按照对应库的要求存入数据库，库会自动生成Geohash索引用于后续查询
2. 候选配送员初筛：计算所有待取餐餐厅+用户配送地址的整体几何中心点，以该点为中心设置查询半径（可根据城市配送范围设置为3~10km），直接调用Geo库的范围查询接口，快速拉取范围内的所有可用配送员，得到候选池
3. 最优配送员二次排序：对候选池内的配送员单独计算总配送路径成本（配送员当前位置→所有取餐餐厅→用户地址的总距离，可叠加配送员当前订单负载等权重），排序后取成本最低的即可

• GeoFire + Realtime Database方案：你当前使用的[纬度, 经度]二元数组格式和GeoFire要求的存储格式完全匹配，无需额外做格式转换，查询直接调用geoFire.queryAtLocation(centerArray, radius)方法即可返回匹配结果
• GeoFirestore + Firestore方案：需要先将二元数组转换为Firestore原生的GeoPoint类型存储，转换逻辑为new GeoPoint(纬度, 经度)，查询时传入对应GeoPoint实例作为中心点即可

• Geo类库本身仅支持单个中心点的范围查询，不原生支持同时匹配多个目标点的复合距离查询，因此必须先通过范围查询拿到足够的候选池，再做二次路径成本计算，不要直接用Geo查询返回的最近单个配送员直接派单，很可能出现不顺路无法覆盖所有取餐点的问题
• 配送员的位置更新可搭配数据库的实时监听能力实现，当配送员位置变动时可自动重新触发最优配送员匹配，保证派单合理性
• 二次路径成本计算建议放在Firebase Cloud Functions服务端执行，不要在客户端计算，既可以避免客户端性能瓶颈，也能防止数据被篡改保证派单公平性

内容的提问来源于stack exchange，提问作者Ahmed Elrefaey