GeoHash比直接存经纬度更适合范围搜索，因其将二维空间查询降维为字符串前缀匹配，避免实时计算haversine距离；但存在边界漏点、邻接格子需取全8个、二次过滤必须用球面距离、位数影响内存与精度等关键细节。
GeoHash 为什么比直接存经纬度更适合范围搜索
因为数据库或内存里做“两点距离计算”成本太高，每次都要算 haversine 或近似公式；而 GeoHash 把二维坐标转成字符串前缀，相同前缀的点大概率在邻近区域——这就把“空间查询”降维成“字符串前缀匹配”。但注意：GeoHash 是近似编码，边界处会漏点，不能替代精确距离过滤。
- 精度由位数决定：
encode(lat, lng, 5)约 5km 精度，7位约 150m - 同一 GeoHash 值可能对应多个不连通区域（如跨赤道/本初子午线时）
- 用
geohash2（Python）或node-geohash（JS）这类库，别手写编码逻辑
Map 结构里怎么存 GeoHash 才支持快速范围查
如果只是用 Map<string t></string> 存“一个 hash → 多个对象”，那只能查精确 hash，没法查“周围 8 个邻接格子”。实际得配合预计算邻接关系 + 多 key 查询。
- 对目标位置生成主 hash 和 8 个邻接 hash（用库的
neighbors()函数） - 每个对象存入 Map 时，同时写入它所属的 *所有* 可能 hash（比如按 5 位和 6 位各存一次，兼顾召回与精度）
- 查范围时，取全部邻接 hash，用
map.get(hash)分别取值，再用真实经纬度做二次距离过滤（避免跨格误差）
常见漏点：邻接格子没覆盖全 or 距离二次过滤写错
现象是“明明在圈内，却搜不到”。典型原因有两个：一是只取了 4 个正向邻接格（上/下/左/右），漏了 4 个斜角；二是二次过滤用了欧氏距离而非球面距离，导致高纬度偏差极大。
- 必须调用库的完整
neighbors(hash)，它返回 8 个 hash，不是自己拼字符串 - 二次过滤务必用
haversine_distance(lat1, lng1, lat2, lng2)，别用Math.sqrt((x1-x2)**2 + (y1-y2)**2) - 如果用 Redis，优先考虑
GEOADD/GEORADIUS，自己实现 Map+GeoHash 仅适合小数据量或离线场景
性能陷阱：GeoHash 位数越高，Map key 越多，内存越碎
存 7 位 hash 比 5 位多出约 100 倍 key 数量——每个对象要写进更多 bucket，Map 查找变慢，内存占用飙升。这不是理论问题，实测 10 万点存 7 位 hash 后 Map 占用超 200MB。
- 生产环境建议固定用 5 或 6 位，查完再用真实坐标筛
- 不要为单次查询动态生成不同位数 hash，统一预计算好存起来
- 如果对象带权重或需排序，别在 Map 里塞数组，改用
Map<string set>></string>配合外部索引
地理范围搜索真正卡住人的，从来不是 GeoHash 编码本身，而是邻接格子的完整性校验、二次距离公式的选型，还有那个容易被忽略的“位数—内存—精度”三角权衡。写完记得拿边界案例（比如北极点、国际日期变更线附近）跑一遍。
