GEORADIUS 返回空结果最常见原因是经纬度顺序写反，必须经度在前、纬度在后；而高德/百度等地图API默认是纬度在前、经度在后，导致坐标存入错误位置。
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，不是按地理距离排的。你看到的“看起来有序”只是巧合，不能依赖。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 加
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 坐标，结果会系统性偏移几公里——这问题不会报错，只会让你查不到人。
