在 MongoDB 的聚合管道里，$point 是一个专门用来生成 GeoJSON Point 对象的表达式。它的返回值不是普通数组，而是一个结构固定的文档，包含 type 字段和 coordinates 字段。很多数据表会把经度和纬度拆成两个独立字段存储，例如 longitude 和 latitude，这样虽然便于普通查询，却无法直接用于地理空间索引和距离计算。$point 的价值就在于，它允许在聚合阶段把这两个字段组合成标准的 GeoJSON 点，供后续输出、入库或与地理查询配合使用。
一、$point 的语法与坐标顺序陷阱
从 MongoDB 5.0 开始，聚合管道中可以直接使用 $point 表达式。它的基本语法是接收一个 coordinates 参数，该参数必须是一个包含两个数值元素的数组。第一个元素代表经度，第二个元素代表纬度。GeoJSON 规范始终坚持经度在前、纬度在后，这与很多日常表达习惯正好相反，因此也成了最容易出错的地方。
在 $point 出现之前，开发者通常用 $arrayToObject 或 $literal 手工构造 GeoJSON 对象，例如手动拼接 type 和 coordinates 字段。这些方式虽然可行，但要额外处理 type 字段，还容易漏掉数组嵌套层级。$point 直接输出标准结构，可读性明显更好。
db.places.aggregate([
{
$project: {
_id: 0,
name: 1,
geoPoint: {
$point: {
coordinates: [ "$longitude", "$latitude" ]
}
}
}
}
])
如果一条文档的 longitude 是 116.404，latitude 是 39.915，上述管道会输出 geoPoint 为 { type: 'Point', coordinates: [ 116.404, 39.915 ] }。可以看到 type 字段自动填充为 Point，coordinates 仍然保持数组形式。这样得到的对象可以直接用于 GeoJSON 数据交换，也可以作为后续地理计算的基础。
另一个容易忽略的点是，coordinates 数组里的两个值必须是数字。如果数据库里存成字符串 '116.404'，$point 不会做隐式转换，后续地理函数可能直接报错。可以在 $point 之前用 $toDouble、$toInt 等操作符显式转换。
{
geoPoint: {
$point: {
coordinates: [
{ $toDouble: "$longitude" },
{ $toDouble: "$latitude" }
]
}
}
}
二、在管道中与 $geoNear 配合使用
$geoNear 是聚合管道中处理地理空间数据最常用的阶段。它根据 2dsphere 索引计算文档与指定点之间的距离，并写入 distanceField。一个常见的误区是尝试把 $point 直接塞进 $geoNear 的 near 字段里，希望根据前一个阶段的字段动态确定圆心。实际上 $geoNear 的 near 参数是查询参数，不接受聚合表达式，因此不能直接写成 near: { $point: { coordinates: ['$lon','$lat'] } }。
db.orders.aggregate([
{
$geoNear: {
near: { type: "Point", coordinates: [ 116.404, 39.915 ] },
distanceField: "distanceToCenter",
spherical: true,
key: "location"
}
},
{
$project: {
_id: 0,
orderId: 1,
distanceToCenter: 1,
backupPoint: {
$point: {
coordinates: [ "$pickupLongitude", "$pickupLatitude" ]
}
}
}
}
])
这段代码先把 orders 集合中每个文档到中心点的距离计算出来，再用 $project 输出规范化的备用点。$point 在这里的作用不是参与距离计算，而是把原本分散的经纬度字段整理成统一格式，方便后续 API 返回或与其他系统对接。
如果确需根据动态坐标做距离排序，建议在应用层先查询出目标坐标，再作为常量传入 $geoNear；或者分两步聚合：先用 $match 取到参考点，再在应用层发起第二次带 near 常量的聚合。直接依赖 $point 动态生成 near 不只会语法报错，还可能让查询优化器完全无法使用 2dsphere 索引。
三、从分离经纬度迁移到 GeoJSON 字段
对于已经存在大量数据的集合，直接在查询时用 $point 生成 GeoJSON 不会带来索引收益，因为聚合管道中的动态生成字段不能被 2dsphere 索引识别。正确做法是通过 updateMany 配合聚合更新，把分离的经度和纬度固化到一个新字段 location 中，然后为这个字段创建索引。
db.orders.updateMany(
{},
[
{
$set: {
location: {
$point: {
coordinates: [ "$pickupLongitude", "$pickupLatitude" ]
}
}
}
}
]
)
更新完成后，再建立 2dsphere 索引：
db.orders.createIndex({ location: "2dsphere" })
这样后续的 $geoNear、$geoWithin 查询可以直接使用 location 字段，并真正走地理索引。如果数据一直保持分离字段，地理查询只能做普通数值范围计算，无法利用球面距离和索引加速。迁移时也建议分批执行 updateMany，避免一次性更新大量文档造成主库压力。
四、常见错误与排查思路
第一个高频错误是纬度经度颠倒。中国用户习惯说北纬 39.9、东经 116.4，于是可能把 latitude 放在前面。GeoJSON 的坐标顺序是经度在前、纬度在后，写反后距离计算会完全偏离。尤其是使用 $centerSphere 或 $geoWithin 时，这种错误不会立即报错，而是静默返回错误结果，排查起来更隐蔽。
// 错误：数组第一个元素写成了纬度
{
$point: {
coordinates: [ "$latitude", "$longitude" ]
}
}
第二个错误是忽略类型。coordinates 必须是数字数组，不能是带空格的字符串或十进制数字字符串。先用 $type 检查字段类型，或通过 $toDouble 在管道中统一转换，能提前规避很多运行时异常。
第三个常见问题是误以为 $point 能创建索引。它只是表达式，只在管道执行期间返回对象；真正的索引仍然要基于集合中已经持久化的 GeoJSON 字段。日志中如果出现类似 point must contain numeric or string coordinates 的错误，优先检查字段顺序和类型。把这些基础细节处理清楚之后，聚合管道里的地理空间数据处理会顺畅很多。
MongoDB聚合管道$point点坐标GeoJSON坐标顺序修改时间：2026-09-24 20:36:57