地理位置检索是很多业务系统的核心功能，比如外卖平台查找附近的商家、社交应用推荐附近的人、打车软件匹配周边司机。MongoDB对这类场景提供了原生的地理空间支持，其中聚合管道中的$geoNear阶段是最灵活也最强大的地理查询工具。它不仅支持按距离排序返回结果，还能把计算出来的距离直接输出到文档字段中，甚至可以与后续的聚合阶段组合使用，完成更复杂的统计分析。
地理空间索引：使用$geoNear的前提条件
$geoNear有一个硬性要求：目标集合必须存在地理空间索引，否则查询会直接报错。MongoDB支持两种地理空间索引类型，选择哪一种取决于业务对距离计算精度的要求。
第一种是2d索引，它把地球表面当作平面直角坐标系处理，计算速度快，但只适合小范围、对精度要求不高的场景，比如在一个城市内查找附近的便利店。如果跨越多个时区或大范围检索，平面距离计算会产生明显偏差。
第二种是2dsphere索引，它基于球面几何计算距离，考虑了地球的曲率，精度更高，是实际项目中推荐的方式。2dsphere索引支持GeoJSON格式的数据（如Point、LineString、Polygon），也支持传统的经纬度坐标对。插入数据时可以这样写：
// 插入示例数据，location字段存储GeoJSON格式的坐标点
db.restaurants.insertMany([
{
name: "老王面馆",
location: {
type: "Point",
coordinates: [116.404, 39.915] // 经度在前，纬度在后
}
},
{
name: "川香火锅",
location: {
type: "Point",
coordinates: [116.412, 39.921]
}
}
])
// 创建2dsphere索引，这是使用$geoNear的必要前提
db.restaurants.createIndex({ location: "2dsphere" })需要特别注意坐标的顺序问题。GeoJSON规范要求coordinates数组中第一个元素是经度，第二个元素是纬度。很多开发者习惯性地先写纬度后写经度，导致查询结果完全不对，甚至出现“距离为负”或“找不到任何数据”的诡异现象。这是地理查询中最常见的坑之一。
$geoNear核心参数详解与完整示例
$geoNear必须作为聚合管道的第一个阶段出现，这也是它与其他聚合操作的一个显著区别。它支持多个参数，理解每个参数的含义才能写出正确的查询。
near指定查询的中心点坐标，distanceField指定距离值写入哪个字段，spherical在使用2d索引时需要设为true，而2dsphere索引会自动启用球面计算。maxDistance和minDistance用于限定检索半径范围，query则允许叠加普通查询条件，比如只搜索评分高于4分的商家。limit限制返回数量，includeLocs可以把命中的坐标也输出到指定字段。
下面是一个贴近真实业务的完整示例：查找用户坐标3公里以内、评分不低于4.5分的前10家餐厅，并按距离由近到远排序：
db.restaurants.aggregate([
{
$geoNear: {
near: {
type: "Point",
coordinates: [116.405, 39.917] // 用户当前位置（经度，纬度）
},
distanceField: "distance", // 距离写入distance字段
maxDistance: 3000, // 最大搜索半径，默认单位为米
query: { rating: { $gte: 4.5 } }, // 叠加业务过滤条件
spherical: true, // 启用球面距离计算
limit: 10 // 最多返回10条
}
},
{
$project: {
name: 1,
rating: 1,
distance: 1,
_id: 0
}
}
])返回结果中每条文档都会多出一个distance字段，单位默认是米（可以通过distanceMultiplier换算成千米，设为0.001即可）。由于结果天然按距离升序排列，前端拿到数据后无需再排序，直接展示即可。
还有一个容易被忽略的细节：当查询使用了query条件时，MongoDB可能无法完全利用索引完成过滤，导致扫过的文档数增多。如果集合数据量很大，建议把区分度高的过滤条件放进query的同时，确保相关字段也有索引，或者在maxDistance上做合理收敛，减少无效计算。
$geoNear与$near的区别及常见问题排查
除了聚合管道中的$geoNear，MongoDB的find查询也支持$near操作符，两者功能类似但适用场景不同。$near只做单纯的近邻检索，无法与后续聚合操作组合；而$geoNear是管道阶段，后面可以接$match、$group、$project等任意阶段，比如统计每个距离区间内的商家数量、按区域分组计算平均评分等，灵活性明显更强。
实际使用中几个高频报错值得留意。报错信息unable to find index for $geoNear query说明集合缺少地理空间索引，先执行createIndex即可解决。如果索引类型是2d却传入了GeoJSON格式的Point，会触发坐标格式不匹配的错误，需要保证数据格式与索引类型一致。另外，一个集合上如果同时存在2d和2dsphere两种地理索引，$geoNear必须通过key参数明确指定使用哪一个，否则MongoDB不知道该走哪个索引。
性能层面还有两点优化建议。第一，地理字段尽量只存坐标点，不要把复杂的多层文档塞进去，索引体积越小检索越快。第二，对于海量数据的近邻推荐场景，可以先用maxDistance圈定一个较小的范围，配合limit分批返回；如果范围内结果不足再逐步扩大半径，这种“渐进式扩圈”策略比一次性大范围检索高效得多。
总结一下，$geoNear的实现路径非常清晰：创建2dsphere索引、按GeoJSON规范存入坐标、在管道首位使用$geoNear并配置距离字段和过滤条件。掌握这些要点后，无论是附近的人还是周边服务推荐，都可以用一套方案稳定支撑。