RedisGeo定位攻略：GEORADIUS高效使用教程

Redis的GEORADIUS命令常因经纬度顺序颠倒（必须经度在前、纬度在后，而高德/百度等地图API恰恰相反）、单位缺失、Geohash精度限制及坐标系混用等隐蔽问题导致“查不到人”或结果错乱；它默认不按距离排序、不支持亚米级定位，也不做坐标系转换，适合3公里内轻量级附近查找，但高精度场景应转向PostGIS或混合架构——掌握这些底层逻辑，才能避开静默失败的坑，让“查附近”真正可靠。

GEORADIUS 返回空结果？八成是经纬度顺序写反了——必须经度在前、纬度在后，和高德/百度地图 API 相反。

为什么 GEORADIUS 总是返回空数组

Redis 的 GEORADIUS 不会报错，但静默返回空数组，最常见原因是坐标存入时顺序颠倒。它严格要求「经度（longitude）在前、纬度（latitude）在后」，而多数前端地图 SDK（如高德、百度、Leaflet）默认传参是「纬度在前、经度在后」。

• 正确写法：GEOADD users 116.48 39.92 "uid:1001"（北京朝阳区附近）
• 错误写法：GEOADD users 39.92 116.48 "uid:1001"（坐标落到南大西洋，接近南极）
• 用 GEOPOS users "uid:1001" 验证：返回值若为 [39.92, 116.48]，说明你存错了——Redis 存的是 [经度, 纬度]，但返回格式固定为 [经度, 纬度]，别被表象骗了
• 单位未显式指定也会失败：写 GEORADIUS users 116.48 39.92 500 会报 ERR wrong number of arguments for 'georadius' command，必须带单位，如 500 m

GEORADIUS 查出来的结果为什么不是由近到远

默认不排序。Redis 按 Geohash 编码的内部顺序遍历 ZSET，不是按地理距离排的。你看到的“看起来有序”只是巧合，不能依赖。

• 加 ASC 才按距离升序（最近的在前）：GEORADIUS users 116.48 39.92 1 km WITHDIST ASC
• 加 DESC 是降序（最远的在前）
• 只加 WITHDIST 不加 ASC/DESC，距离字段虽能对上，但元素本身顺序仍是无序的
• 分页慎用 COUNT + 偏移：多次执行 GEORADIUS ... COUNT 20 可能因并发 GEOADD 覆盖导致结果漂移；高频场景建议先 STORE 到临时 key 再切片

查不到 500 米内的人？精度和单位陷阱

Redis Geo 是 Geohash 索引，不是精确几何计算。它适合「3km 内门店」这类容忍百米误差的场景，不适合亚米级定位。

• 单位只有四种：m、km、mi、ft；cm、nm 不支持
• Geohash 7 位精度 ≈ 19 米，但边界切割会导致真实距离 499 米的人被漏掉——这不是 bug，是空间索引固有特性
• 重复 GEOADD 同一 member 会静默覆盖旧坐标；若用户上报乱序（比如延迟的旧位置后到），新位置会被刷回旧位置
• 高精度需求（如共享单车找车、无人机调度）应换 PostGIS 或专用地理数据库，Redis Geo 只负责兜底和快速筛选

该用 GEORADIUS 还是 GEOSEARCH

Redis 6.2+ 推荐优先用 GEOSEARCH，它更语义清晰、功能更强，且是只读命令（GEOSEARCH_RO 可进一步降低主节点压力）。

• GEOSEARCH 支持矩形搜索：GEOSEARCH users FROMLONLAT 116.48 39.92 BYBOX 2 2 km（查 2km×2km 方框内的人）
• GEORADIUSBYMEMBER 本质是 GEOPOS + GEORADIUS，多一次 round-trip；GEOSEARCH 一步到位
• 如果还在用 GEORADIUS，注意它已被标记为 legacy，未来版本可能仅保留兼容性
• 生产环境建议混合使用：Redis GEO 做实时轻量查询，PostgreSQL + PostGIS 做最终校验与复杂分析

真正容易被忽略的点是：Redis Geo 的「附近」是基于球面距离粗算的，但它不会做坐标系转换（比如 WGS84 → GCJ02）。如果你的数据源混用了国测局偏移坐标和标准 GPS 坐标，结果会系统性偏移几公里——这问题不会报错，只会让你查不到人。

今天带大家了解了的相关知识，希望对你有所帮助；关于数据库的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~