2dsphere索引更准是因为它基于球面几何计算真实距离，而2d索引将经纬度视为平面坐标导致百米级误差；其根本优势是数学模型正确，而非单纯提速。
为什么2dsphere索引比2d索引更准，而不是更快
2dsphere索引不是单纯“提速”，而是修正数学模型：2d索引把经纬度当平面x/y，用欧氏距离算“直线”，北京到东京的距离误差可达百米以上；2dsphere基于球面几何，所有距离单位是真实米数，且能跨本初子午线（比如从夏威夷查东京）不崩。性能提升只是结果，根本原因是它没算错——错误的快，不如正确的稳。
常见错误现象：db.places.find({loc: {$near: [116.4, 39.9]}}) 在2d索引下可能漏掉西边5公里内的点，这不是慢，是坐标系错导致逻辑失效。
创建2dsphere索引前必须校验三件事
索引创建失败往往静默发生，等查询时才暴露问题：
- 字段值必须是合法GeoJSON
Point：{"type": "Point", "coordinates": [116.4, 39.9]}，不能是数组[116.4, 39.9]或嵌套对象{lng: 116.4, lat: 39.9} - 坐标顺序必须是
[longitude, latitude]：反写会把北京定位到刚果盆地 - 数值范围必须合规：经度 ∈
[-180, 180]，纬度 ∈[-90, 90]；超出范围的文档插入时不会报错，但建索引时会被跳过，且无提示
建索引命令必须显式带引号：db.places.createIndex({"loc": "2dsphere"})，写成 {"loc": 2dsphere} 会被当作未定义变量报错。
OpenCLI Tool Integration
下载
一款AI开发辅助工具，主要用于使用 OpenCLI 工具，可从各类网站及桌面应用中提取数据、下载媒体内容、控制外部 CLI 工具。支持 Bilibili、知乎、小红书、Twitter/X、Reddit、YouTube、Boss直聘、即刻、微博等 30+ 个平台，以及 Cursor、Codex、ChatGPT、Notion 等桌面应用。当用户需要：从社...，适合需要提升相关任务效率的用户。
$near查询慢？大概率是没加$maxDistance或混用了过滤条件
$near 默认强制走2dsphere索引，但不设上限等于让MongoDB扫描全量地理数据再排序，I/O和CPU双爆表。
实操建议：
- 永远带上
$maxDistance（单位：米）：{loc: {$near: {$geometry: {type: "Point", coordinates: [116.4, 39.9]}, $maxDistance: 5000}} - 如果还要按状态、类型等字段过滤（如
{"status": "active"}），单靠2dsphere索引无法加速，必须建复合索引：db.places.createIndex({"loc": "2dsphere", "status": 1}) - 只查“在某范围内”而不排序，用
$geoWithin+$centerSphere更轻量：{loc: {$geoWithin: {$centerSphere: [[116.4, 39.9], 5/6371]}}（5公里半径，注意弧度换算）
聚合管道里用$geoNear，顺序和结构都不能错
$geoNear 是唯一能在聚合中输出距离字段（如 dist）并保证排序的阶段，但它有两个硬约束：
- 必须是 pipeline 的第一个 stage：
[{$geoNear: {...}}, {$match: {...}}]合法；[{$match: {...}}, {$geoNear: {...}}]直接报错"geoNear must be the first stage" - 过滤条件必须塞进
$geoNear的query字段，不能丢在后面 stage：{$geoNear: {near: {}, distanceField: "dist", query: {type: "cafe"}, maxDistance: 1000}} - 分页必须用
$limit，禁用$skip——$geoNear已完成距离计算和排序，$skip会白白丢弃大量已处理文档
最容易被忽略的是：$geoNear 只能出现一次，且不能和 $near 查询混用在同一语句中。
