MongoDB的地理空间查询没有想象中那么复杂，但要真正用好一个操作符，必须回到它的数据结构和索引模型上。$box虽然名字叫矩形区域，实际它并不采用GeoJSON的球面几何算法，而是走2d平面索引的坐标比较逻辑。理解这一点之后，再把它放到聚合管道的$match阶段，就能稳定地圈出一块矩形范围内的坐标点。
一、$box的几何语义与2d索引前提
$box接收两个坐标点，第一个代表矩形的左下角，第二个代表右上角。坐标格式使用传统坐标对，也就是数组形式的[经度, 纬度]或[x, y]。它会把位置字段完全落在矩形内的文档全部返回，包括刚好压在边界线上的数据。这种包含边界的逻辑是平面几何的常规做法，和GeoJSON多边形查询存在细微差异。GeoJSON默认走球面几何，而$box使用平面几何，因此它必须依赖2d索引，而不是2dsphere索引。
在集合上创建2d索引非常简单，示例如下：
db.places.createIndex({ location: "2d" })2d索引会把传统坐标对编码为平面网格，适合城市级、区域级的小范围数据。如果数据本身是GeoJSON对象，并且使用2dsphere索引，那么$box不能直接工作，需要改用$geometry配合Polygon。这是因为2dsphere期望GeoJSON结构且支持球面计算，而$box是平面矩形操作符，两者的数据模型不兼容。
另一个容易踩坑的地方是坐标顺序。传统坐标对始终是经度在前、纬度在后，但不少外部数据源习惯把纬度写在前面。如果存储字段是[纬度, 经度]，查询却写成[经度, 纬度]，结果很可能是空集，或者返回完全错误的区域。这一点必须先核对数据写入端的坐标顺序。
二、在聚合管道中使用$match搭配$box
$box不是聚合管道中的独立阶段，它必须出现在$match阶段的条件里。$match负责过滤输入文档，把它放在管道最前面可以让索引尽早介入，减少后续$group、$sort等阶段需要处理的数据量。下面是一个典型场景：筛选出某个矩形区域内的商户，并按品类统计数量。
db.places.aggregate([
{
$match: {
location: {
$geoWithin: {
$box: [
[-74.0, 40.7],
[-73.9, 40.8]
]
}
},
status: "active"
}
},
{
$group: {
_id: "$category",
count: { $sum: 1 }
}
},
{
$sort: { count: -1 }
}
])这段管道首先通过$geoWithin和$box圈定矩形范围，同时用status字段过滤有效商户，然后按品类分组统计数量，最后按数量倒序排列。$box在这里只是$match内部的一个条件，语法和普通find查询完全一致。实际业务中，矩形边界通常由前端地图的视野范围或者用户手动圈选的围栏决定，应用层只需要把两个坐标点拼接进查询对象后传给aggregate即可。
需要注意的是，$match中的$box条件不能直接引用文档里其他字段的值。如果希望让矩形范围动态地基于每条文档变化，就要使用$expr配合其他地理空间表达式，但那样会失去索引优势，性能会明显下降。更合理的做法是在应用层计算出边界坐标，再作为字面量传入聚合管道。
如果还希望配合其他字段进行过滤，可以创建包含2d字段的复合索引。需要特别记住，在复合索引中如果包含2d字段，这个2d字段必须放在索引定义的最前面，否则MongoDB无法把它用于地理空间查询。例如可以创建{ location: "2d", category: 1 }，但反过来{ category: 1, location: "2d" }则无法被$box使用。
三、$box与$geoWithin、$geoIntersects、$geometry的边界差异
$geoWithin是一个外层操作符，$box只是它支持的其中一种区域表达方式。除了$box，它还可以配合$center、$polygon等操作符，但这些同样只用于2d索引。$geoIntersects则主要用来判断GeoJSON对象之间的相交关系，通常配合2dsphere索引。两者不要混用，否则会遇到索引类型不支持的报错。
如果文档位置字段存储的是GeoJSON的Point对象，并且使用2dsphere索引，那么查询矩形区域时应该使用$geoWithin配合$geometry定义Polygon，而不是$box。以下是GeoJSON写法的示例：
db.places.createIndex({ location: "2dsphere" })
db.places.find({
location: {
$geoWithin: {
$geometry: {
type: "Polygon",
coordinates: [[
[-74.0, 40.7],
[-73.9, 40.7],
[-73.9, 40.8],
[-74.0, 40.8],
[-74.0, 40.7]
]]
}
}
}
})下面的表格可以更清晰地展示二者的区别：
| 操作方式 | 支持索引 | 几何模型 | 典型场景 |
|---|---|---|---|
| $box | 2d | 平面矩形 | 城市网格、配送范围、小区域围栏 |
| $geometry + Polygon | 2dsphere | 球面多边形 | 大范围地理围栏、需要精确球面距离 |
性能上，2d索引在小范围平面数据上计算更快，内存占用也更低；2dsphere的球面计算复杂度更高，但能提供更准确的地理结果。如果业务范围限制在几十公里内，且坐标存储为传统数组，$box完全够用。如果需要跨城市、跨国家甚至全球范围的精度，就必须迁移到GeoJSON加2dsphere。迁移时不能只改索引，文档结构也要从数组改为GeoJSON对象，否则2dsphere无法解析。
四、边界处理、性能调优与调试建议
$box默认包含边界，也就是说坐标恰好落在矩形边线上的点也会被匹配出来。如果业务严格要求排除边界点，直接调整数据库查询并不方便，可以在查询后追加过滤，或者更实际一点，把矩形范围略微缩小，例如给左下角坐标各加一个极小值，给右上角坐标各减一个极小值。数值精度问题同样值得关注，浮点数比较可能造成边界附近的点被误判，如果对边界极其敏感，可以考虑把坐标存储为固定小数位的整数，例如乘以10的6次方后取整，这样比较结果更稳定。
性能调优的第一步是确认索引确实被使用。可以在聚合管道末尾追加explain，或者使用db.collection.explain("executionStats").aggregate(...)查看执行计划。如果stage显示为COLLSCAN，说明没有走2d索引，需要检查字段名、索引类型以及$box表达式是否写错。$match放在管道最前面，能够最大化索引过滤效果，但如果矩形范围很大，匹配文档占比过高，优化器有时会选择全表扫描，这是正常现象。此时可以缩小矩形范围，或者结合其他选择性强的条件来改善查询。
调试空结果时，建议先不要直接改聚合管道，而是用简单的find查询确认数据能否返回。例如先执行同样的$box查询，看是否能拿到结果，再嵌入聚合管道。常见空结果原因包括：索引类型不对、位置字段不是数组、坐标顺序写反、字段名不匹配等。2d索引字段可以存储数组或旧式文档，但推荐使用数组，并且数组长度必须为2，超出长度会导致索引异常或查询报错。把这些细节排查到位，$box在聚合管道中的表现会非常稳定。