geohash比直接存经纬度更适合范围查询，因其将二维坐标转为具前缀相似性的字符串，支持用submap等区间操作逼近邻近查询，但需查多个相邻单元格并二次距离过滤。
GeoHash 为什么比直接存 [lat, lng] 更适合做范围查询
因为原始经纬度是二维浮点数，用 Map 存键值对时无法天然支持“附近 N 公里”这类查询；而 GeoHash 把二维坐标转成单字符串，具备前缀相似性——相同前缀越多，地理位置越近。这使得你可以用 map.subMap("wx4g", "wx4h") 这类区间操作逼近地理邻近查询。
但要注意：GeoHash 是近似编码，存在边缘误差（比如两个紧邻单元格的编码可能完全不同），且精度随字符串长度增加而提高，但索引体积也线性增长。
- 5 位 GeoHash（约 4.9km 精度）适合城市级粗筛
- 8 位（约 19m）才能支撑 POI 级别定位
- Java 中推荐用
geohash-java库的GeoHash.withCharacterPrecision(lat, lng, 8)，别手写编码逻辑
用 TreeMap 存 GeoHash 字符串时的 key 设计陷阱
不能直接把 GeoHash 字符串当 key 存进 TreeMap 就完事——它只保证字典序，而 GeoHash 的字典序 ≠ 地理邻近性（尤其跨纬度带时）。真实场景中，一次“附近搜索”需要查 8~9 个相邻 GeoHash 单元格，再合并结果。
所以更合理的做法是：以 GeoHash 前缀为 key，value 是 Set<string></string> 或 List<yourdata></yourdata>，例如：map.put("wx4g7x", List.of(poi1, poi2))。
- key 长度统一取 6~7 位，平衡精度与内存占用
- 避免用
HashMap，它不支持范围扫描，subMap()会直接报错 - 插入前务必调用
GeoHash#toBase32()确保编码一致，有些库默认返回 base32，有些返回二进制字符串
查询“附近 500 米”数据时，如何生成正确的 GeoHash 范围集合
直接用中心点算一个 GeoHash 再查 subMap 会漏掉大量真实邻近点——GeoHash 单元格是矩形（实际是球面投影后的近似矩形），且边界不连续。正确做法是调用工具方法获取“覆盖目标半径的所有候选 GeoHash 前缀”，例如 Java 中用 GeoHashUtils.expandToCoverDistance(centerLat, centerLng, 500)（来自 spatial4j）。
- 该方法返回的是字符串列表，如
["wx4g7x", "wx4g7y", "wx4g7z", ...]，共 8~9 个 - 对每个前缀执行
map.get(prefix)或map.subMap(prefix + "0000", prefix + "zzzz")（注意边界字符要选对） - 别信网上随手搜的“手动计算邻接格子”代码，容易漏掉极地/本初子午线附近的翻转 case
内存和性能的真实代价：千万级数据下 TreeMap<string list></string> 的瓶颈在哪
当存储超百万个点，每个 GeoHash 前缀对应几十到上百条记录时，TreeMap 的 key 数量本身不大（通常几万），但 value 的 List 可能成为 GC 压力源——特别是频繁增删改导致 list rehash 或扩容。
- 如果读远多于写，考虑用
ImmutableList替代可变ArrayList - 若需支持按时间排序或分页，不要把所有数据塞进一个 list，改用嵌套结构：
Map<string navigablemap yourdata>></string> - 真正卡顿往往不在 Map 查找，而在后续的“距离重过滤”——GeoHash 只缩小候选集，最终还得用
Haversine公式逐个算球面距离剔除误召
GeoHash 和 Map 的组合不是银弹，它解决的是“快速圈出候选区域”的问题；真正的距离判断、排序、分页，得在内存里二次处理。这点很容易被忽略，直到线上查 1000 个点就超时。
