必须用2dsphere索引配合GeoJSON点结构，因MongoDB仅识别GeoJSON或坐标对，GEO哈希字符串无法被2dsphere索引解析，建索引后查询始终为空且无报错。
要在MongoDB中实现毫秒级响应的附近商户搜索，必须放弃原始GEO哈希字符串匹配思路，转而用2dsphere索引配合GeoJSON点结构——GEO哈希本身不参与索引构建，仅作为业务层辅助标识或缓存键使用。
为什么不能直接对GEO哈希字段建地理索引
MongoDB的2dsphere索引只识别两种地理数据格式：标准GeoJSON {"type":"Point","coordinates":[lng,lat]} 或遗留坐标对 [lng,lat]。如果你把GEO哈希（如 "wx4g0b"）存在字段里并执行 createIndex({"geohash": "2dsphere"})，MongoDB会静默跳过该字段所有文档，索引看似创建成功，但查询时始终返回空结果，且无任何报错提示。
这一步操作起来很简单，但后果严重：【索引实际未覆盖任何文档，查询永远不命中】。
正确做法：用GEO哈希反解为经纬度再存入GeoJSON字段
第一步：在商户写入时，将前端或定位服务传来的GEO哈希字符串（如 "wx4g0b"）调用标准库反解为经纬度。Python可用 geohash2.decode("wx4g0b")，返回 (116.3974, 39.9093)；注意顺序是 (lng, lat)，不是 (lat, lng)。
第二步：把反解出的坐标构造成GeoJSON Point对象，写入专用地理字段（如 location），而非覆盖原GEO哈希字段：
{"location": {"type": "Point", "coordinates": [116.3974, 39.9093]}}
第三步：对 location 字段创建2dsphere索引：
db.merchants.createIndex({"location": "2dsphere"})
注意：命令中 "2dsphere" 必须加双引号，写成 {location: 2dsphere} 会被当作未定义变量报错。
查询时复用GEO哈希提升缓存效率
方法一：纯地理查询 + GEO哈希后置标注
执行 $near 查询获取最近商户列表，再在应用层批量查出对应GEO哈希值用于前端展示或本地缓存键生成：
db.merchants.find({ location: { $near: { $geometry: { type: "Point", coordinates: [116.3974, 39.9093] }, $maxDistance: 5000 } } })
方法二：GEO哈希前缀快速粗筛 + 地理精排（适用于高并发轻量请求）
先根据用户位置计算出9个相邻GEO哈希前缀（中心格+8邻格），用 $in 匹配 geohash 字段做第一轮快速过滤；再在内存中用 Haversine 公式或 MongoDB 的 $geoWithin 对筛选结果做真实球面距离排序：
{ geohash: { $in: ["wx4g0b", "wx4g0c", "wx4g08", ...] } }
这一步能减少90%以上文档进入地理计算阶段，但【必须确保geohash字段已单独建普通B-tree索引】，否则 $in 扫描仍会变全表扫描。
聚合管道中安全使用$geoNear并输出距离
第一步：确认 $geoNear 是 pipeline 的第一个阶段，且 spherical: true 显式开启（默认为 false，不设就走平面计算）：
[ { $geoNear: { near: { type: "Point", coordinates: [116.3974, 39.9093] }, distanceField: "dist", spherical: true, maxDistance: 5000, num: 50 } }, { $match: { status: "open" } } ]
第二步：如果需按GEO哈希分组统计（如“每个格子有多少家营业中商户”），在 $geoNear 后接 $group，但注意 dist 字段此时已存在，可直接用于条件过滤或排序：
{ $group: { _id: "$geohash", count: { $sum: 1 }, avgDist: { $avg: "$dist" } } }
第三步：最终结果中保留原始GEO哈希字段，便于前端做地图瓦片加载或离线缓存，避免重复解码。
