附近的人这类基于位置的服务，本质上是给定一个中心点坐标和半径，找出落在该范围内的其他坐标点。MongoDB对这类需求提供了原生的地理空间支持，核心是GeoJSON格式的位置数据和2dsphere索引。GeoJSON是一种基于JSON的地理数据编码规范，点、线、面都可以表示，其中Point类型正好用来存用户的经纬度。以文档结构为例，一个用户的位置字段可以写成{ type: "Point", coordinates: [116.404, 39.915] }，注意coordinates数组的顺序是经度在前、纬度在后，这一点与常见的纬度在前习惯相反，写反了会导致查询结果完全错误。
2dsphere索引专门为这种GeoJSON数据设计，它会把球面坐标映射到内部的可搜索结构上，让$near、$geoWithin、$geoIntersects等操作符可以直接利用索引快速过滤。相比传统的2d索引，2dsphere考虑地球曲率，更适合跨较大范围的经纬度距离计算，而2d索引则基于平面坐标，通常用于小范围或者自定义投影场景。因此做附近的人功能时，首选2dsphere，并且在创建索引时就要指定字段的GeoJSON类型。
理解MongoDB的地理空间索引与GeoJSON
2dsphere索引的底层实现基于S2库或类似的地理哈希算法，并不是简单地把经纬度当作两个独立的数字建B树索引。它会把地球表面划分成不同粒度的单元格，每个单元格有一个唯一的标识，查询时先通过中心点和半径确定可能覆盖的单元格集合，再在这些单元格内做精确的距离过滤。这种方式避免了全表扫描，即使集合里有数百万用户，附近的人查询也能保持在毫秒级别。
在使用GeoJSON时，有几个容易忽略的细节需要特别留意。首先，coordinates数组必须符合经度范围-180到180、纬度范围-90到90，MongoDB不会自动纠正越界值，写入时可能成功但查询时产生奇怪的结果。其次，字段名可以任意，但为了语义清晰一般命名为location或position。最后，同一个集合中一个字段是GeoJSON对象，另一个字段是普通数字并不会影响索引创建，但2dsphere索引只能作用于GeoJSON结构，普通数字坐标需要改用2d索引。
举例来说，假设有一个users集合，每个用户文档包含username和location字段。创建2dsphere索引的Node.js代码如下：
const { MongoClient } = require('mongodb');
async function createGeoIndex() {
const client = new MongoClient('mongodb://127.0.0.1:27017');
await client.connect();
const db = client.db('location_app');
const users = db.collection('users');
// location字段必须存储GeoJSON Point对象
await users.createIndex({ location: '2dsphere' });
console.log('2dsphere索引创建成功');
await client.close();
}
createGeoIndex();这段代码先连接到本地MongoDB，然后对users集合的location字段建立2dsphere索引。如果集合中已有不符合GeoJSON格式的文档，创建索引时会报错，所以通常在建索引之前需要清理或修正旧数据。
在Node.js中存储与查询位置数据
把位置数据写入集合时，可以按照GeoJSON的Point格式组织好文档再调用insertOne或insertMany。为了后续查询方便，建议除了坐标之外，再存一个反向的地理编码信息，比如城市名称或者街道描述，这样前端展示时不需要额外请求地图服务。下面是一个批量插入模拟用户的示例：
async function insertMockUsers() {
const client = new MongoClient('mongodb://127.0.0.1:27017');
await client.connect();
const db = client.db('location_app');
const users = db.collection('users');
const mockData = [
{ username: 'alice', location: { type: 'Point', coordinates: [116.407, 39.904] } },
{ username: 'bob', location: { type: 'Point', coordinates: [116.403, 39.914] } },
{ username: 'carol', location: { type: 'Point', coordinates: [116.418, 39.901] } },
{ username: 'dave', location: { type: 'Point', coordinates: [116.390, 39.920] } }
];
await users.insertMany(mockData);
console.log(`插入了 ${mockData.length} 条用户数据`);
await client.close();
}
insertMockUsers();查询附近的用户最直接的方式是使用$near操作符。$near会参考2dsphere索引，返回按距离由近到远排序的文档，并且可以配合$maxDistance限制最大搜索半径。需要注意的是，$near不能与find的sort同时使用，但可以配合limit限制返回数量。例如以天安门广场坐标[116.397, 39.908]为中心，查找2公里内的10个用户：
async function findNearbyUsers() {
const client = new MongoClient('mongodb://127.0.0.1:27017');
await client.connect();
const db = client.db('location_app');
const users = db.collection('users');
const center = { type: 'Point', coordinates: [116.397, 39.908] };
const radiusInMeters = 2000;
const nearby = await users.find({
location: {
$near: {
$geometry: center,
$maxDistance: radiusInMeters
}
}
}).limit(10).toArray();
console.log(nearby.map(u => u.username));
await client.close();
}
findNearbyUsers();$near返回的结果不会包含实际距离值，如果需要把距离展示给用户，可以在聚合管道中使用$geoNear阶段。$geoNear必须是聚合的第一阶段，它会为每个文档附加一个distanceField字段，里面是计算出的距离，单位是米。同时$geoNear也支持query参数做额外的过滤条件，以及spherical选项，不过对于2dsphere索引，spherical默认为true。下面这个示例计算并返回每个用户与中心点的距离：
async function findWithDistance() {
const client = new MongoClient('mongodb://127.0.0.1:27017');
await client.connect();
const db = client.db('location_app');
const users = db.collection('users');
const result = await users.aggregate([
{
$geoNear: {
near: { type: 'Point', coordinates: [116.397, 39.908] },
distanceField: 'distance',
maxDistance: 5000,
spherical: true
}
},
{ $limit: 10 },
{ $project: { username: 1, distance: 1, _id: 0 } }
]).toArray();
console.log(JSON.stringify(result, null, 2));
await client.close();
}
findWithDistance();distance字段默认以米为单位，如果需要公里，可以在后续阶段除以1000。另外，$geoNear必须使用在已经创建了2dsphere索引的字段上，否则会报错。对于移动端用户上报的位置，可能来自GPS或基站，精度参差不齐，存储时不必做太多裁剪，查询时再通过maxDistance控制返回范围即可。
优化附近的人查询性能与精度
当用户量达到百万级别时，单纯依靠2dsphere索引已经能应对大多数查询，但仍有几个优化点值得关注。首先是索引字段的选择，除了location之外，如果经常按城市或区域过滤，可以考虑创建复合索引，比如{ city: 1, location: '2dsphere' }，这样在相同城市内做附近查询时，先利用普通索引缩小范围，再走地理索引，整体扫描的文档数会显著下降。
其次是半径限制策略。附近的人通常有一个最大距离，比如社交应用常设置为5公里，超过这个距离的用户没有展示必要。设置合理的maxDistance不仅能减少返回数据量，还能缩短查询时间。如果业务允许，还可以结合分页，但$near默认不支持skip，需要用$geoNear配合$skip实现，不过深度翻页的性能依然不佳，建议用基于时间或距离游标的方式替代传统页码。
关于距离计算精度，2dsphere索引内部采用WGS84椭球模型，计算的是球面距离，对于国内范围的应用已经足够精确。但要注意，如果中心点和目标点都非常接近，比如同一个建筑物内，几十米的误差可能对业务有影响。此时可以结合一些网格算法，比如将坐标先转换成平面投影坐标，再利用平面距离公式，但会牺牲一点跨区域的准确性。一般情况下，直接使用MongoDB返回的距离值就可以满足附近的人需求。
最后，从数据写入角度，客户端上报位置时应该做基本的合法性校验，过滤掉经度或纬度严重越界的数据。同时，可以定期清理长时间不活跃的用户位置记录，避免集合无限膨胀。对于需要实时更新的场景，可以使用MongoDB的updateOne配合$set更新location字段，索引会自动维护，不需要重建。