Redis原生Geo命令不依赖Geohash前缀索引，而是逐点计算球面距离；需手动分桶（如5位Geohash）查9邻域+应用层过滤，适用于读多写少、固定半径场景，但要注意极点、日期变更线等边界问题。
Geohash 前缀匹配为什么不能直接用于 Redis Geo 范围查询
Redis 的 GEOSEARCH 和旧版 GEORADIUS 命令底层并不依赖 Geohash 前缀做索引查找，而是对所有成员逐个计算球面距离。即使你把经纬度转成 Geohash 存进字符串或有序集合，Redis 也不会自动按前缀加速地理范围过滤。
常见误解是“存 Geohash 就能用 ZRANGEBYLEX 快速取邻近区域”，但问题在于：Geohash 前缀越长，代表的地理矩形越小，而相邻区域可能属于不同前缀（如 ws10 和 ws11），单靠前缀匹配会漏点；更糟的是，赤道附近经度 wrap-around（如 179.9° 和 -179.9°）会导致前缀完全不连续。
- Redis
GEO类命令强制使用球面距离（Haversine），不接受预计算的 Geohash 字符串作为查询条件 -
ZRANGEBYLEX只能用于严格字典序区间，无法表达“以某点为中心、半径 5km”的语义 - 手动用 Geohash 分块后查多个前缀再二次过滤，代码复杂且易出错（比如漏掉跨格网边界点）
真正能提速的 Geohash 辅助策略：预分桶 + 多 key 查询
想利用 Geohash 加速，必须绕过 Redis 原生 Geo 命令，改用自己管理的分桶结构：把每个位置按固定精度 Geohash（如 5 位，约 4.9km 精度）作为 key 后缀，把 member 写入对应 geo:bucket:{hash} 有序集合或集合中。
查询时，先用库（如 Python 的 geohash2 或 Go 的 geohash）算出目标点的 9 个邻近 Geohash（中心格 + 8 方向），再并发查这最多 9 个 key，最后在应用层合并并剔除超距点。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Geohash 精度选 5～6 位较平衡：精度太高（如 8 位）导致桶过多、key 数暴涨；太低（如 3 位）单桶过大，查出来要过滤的无效点太多
- 必须用
ZRANGEBYSCORE或SMEMBERS配合预存的 score（如原始经纬度或时间戳），不能只靠 Geohash 字符串本身排序 - 注意时区/夏令时无关，但需统一用 WGS84 坐标系，否则 Geohash 解码偏差可达百米级
和原生 GEO 命令比，什么场景值得上 Geohash 分桶
原生 GEOSEARCH 在万级成员下仍够快（毫秒级），但一旦集合超过 10 万点，或者 QPS 超过 500，CPU 会明显被距离计算吃满。这时分桶才有意义。
- 适合读多写少、查询半径固定的业务，比如“附近充电桩”（固定 3km）、“门店自提圈”（固定 1km）
- 不适合动态半径（如用户滑动调节“找 1km/5km/10km 内”），每次都要重算邻近格网+多 key 查询，反而更慢
- 写入路径变重：一个点要同时写入
geo:main（原生 GEO）和若干geo:bucket:*，需用 pipeline 或 Lua 保证原子性 - 内存占用增加约 20%～40%，因为每个 member 在多个 bucket key 中重复存在
容易被忽略的边界问题：极点、本初子午线、国际日期变更线
Geohash 编码在纬度 ±90°、经度 ±180° 附近会剧烈抖动。例如北极点附近任意两个相距几十米的点，可能生成完全不同的 5 位 Geohash（因为纬度趋近 90° 时，微小变化导致编码跳变）。
实际线上出现过：格陵兰岛东部某小镇的点全被分到错误 bucket，查“附近 5km”返回空，原因就是用了未处理极区的 Geohash 库。
- 用
geohash2.bbox(hash)拿到边界后，务必检查是否跨越 180° 经线（east < west），若是，需拆成两个区间分别查 - 对纬度 > 85° 或 < -85° 的点，建议单独走 fallback 逻辑（如全量扫描或降级为原生 GEO）
- 别信“通用 Geohash 库都处理了边界”，至少验证过
geohash2（Python）、go-geohash（Go）在 (89.9, 179.9) 和 (89.9, -179.9) 是否生成相邻 hash
