$geoNear是唯一合法的距离计算与排序操作符，必须作为聚合第一阶段且集合需有2dsphere索引；near参数须为GeoJSON Point格式，coordinates顺序为[经度,纬度]，distanceField可指定距离字段名，默认单位米并升序返回。
用 $geoNear 正确替代 $distance 计算地理距离
MongoDB 不允许在普通聚合阶段（如 $project）里直接调用地理距离函数；$distance 本身不是合法的聚合操作符，常见错误是误写成 { $distance: { ... } } 导致语法报错。真正能计算并排序距离的，只有 $geoNear 阶段——但它有硬性前提：必须是聚合管道的第一阶段，且集合必须有 2dsphere 索引。
实操建议：
- 先确保目标字段（比如
location）已建索引：db.places.createIndex({ location: "2dsphere" }) -
$geoNear必须放在aggregate([...])数组最开头，否则会报错"geoNear must be the first stage" - 不能和
$sort、$limit混用在它前面；但可以在它之后接$limit控制返回数量 - 距离单位默认是米，可通过
distanceField指定存入的字段名，例如distanceField: "dist"
$geoNear 的关键参数怎么设才不出错
参数配错会导致查不到结果或距离异常。最常踩的坑是坐标顺序和输入格式不匹配——GeoJSON 要求 [longitude, latitude]，而很多人习惯先写纬度，结果距离变成几千公里。
实操建议：
-
near必须是 GeoJSONPoint对象，不是数组或普通对象：{ type: "Point", coordinates: [116.3974, 39.9093] }✅[116.3974, 39.9093]❌（会被当 legacy coordinate pair，不推荐） -
maxDistance单位是米，设1000表示 1 公里内；不设则不限距，但性能下降明显 - 如果想按升序排（最近优先），不用额外
$sort，$geoNear默认已按距离升序输出 - 使用
spherical: true（默认值），否则在球面坐标下距离会严重失真
为什么不能在 $project 里用 $geowithin 或 $geoIntersects 算距离
这些操作符只做布尔判断（是否在范围内 / 是否相交），不返回数值距离。试图用它们“绕过” $geoNear 限制，最终只能得到 true/false，没法排序。
实操建议：
- 需要“筛选+排序”双需求时，
$geoNear本身支持query参数做前置过滤，例如：query: { status: "open" }，它会在计算距离前先缩小候选集 - 若业务逻辑强制要求距离字段出现在中间阶段（比如后续要参与数值运算），唯一办法是分两步：先用
$geoNear查出带distanceField的结果，再用另一个聚合（或应用层）处理 - 注意
$geoNear会自动添加_id和distanceField字段，原文档字段保持不变，无需手动$addFields
聚合中混用地理位置和其他条件时的性能陷阱
$geoNear 虽快，但一旦配合低效的后续阶段（比如无索引字段的 $match），整个管道可能退化为内存扫描。尤其当 maxDistance 设得过大，又没用 query 过滤，MongoDB 可能加载大量无关文档。
实操建议：
- 把高选择性的非地理条件尽量塞进
$geoNear的query参数里，让索引能联合生效 - 避免在
$geoNear后接$unwind或大数组展开——距离计算结果已按序，再打散会丢失顺序且拖慢速度 - 测试时用
explain: true看执行计划，确认stage是GEO_NEAR_2DSPHERE，而非COLLSCAN - 如果发现
executionStats.nReturned远大于预期结果数，说明地理范围太宽或索引未命中
真正难的不是写对语法，而是让 $geoNear 在复杂查询中依然走索引、不爆内存——这取决于你把哪些条件放进 query，以及坐标输入有没有手抖写反经纬度。
