GEORADIUS 返回空结果通常因坐标顺序错误，必须经度在前、纬度在后；默认不排序，需加ASC/DESC；单位必须显式指定；同一member重复GEOADD会覆盖旧坐标。
GEORADIUS 返回空结果？先检查坐标存入格式是否正确
Redis 的 GEORADIUS 不会报错，但返回空数组时，八成是数据没存对——它只接受「经度在前、纬度在后」的顺序，和常见地图 API（如高德、百度）的「纬度在前、经度在后」相反。
- 用
GEOADD存位置时，必须写成GEOADD users 116.48 39.92 "uid:1001"（经度 116.48，纬度 39.92） - 如果误写为
GEOADD users 39.92 116.48 "uid:1001"，坐标就飞到南极附近，GEORADIUS自然查不到 - 可用
GEOPOS验证：执行GEOPOS users "uid:1001"，看返回的经纬度是否落在合理地理范围内
GEORADIUS 查询结果乱序？默认不按距离排序
默认情况下，GEORADIUS 返回的是无序集合，不是按“由近到远”排好的。你看到的顺序取决于 Redis 内部哈希桶遍历逻辑，不能依赖。
- 加
ASC参数才能升序（最近的在前）：GEORADIUS users 116.48 39.92 5 km ASC - 加
DESC才降序（最远的在前） - 不带
ASC/DESC时，即使加了WITHDIST，距离字段也和元素一一对应，但元素本身不排序 - 如果业务需要分页（比如“加载下一页”），别用
count+ 偏移，而应结合STORE或STOREDIST缓存结果再切片，否则多次查询可能因并发写入导致结果漂移
查不到 500 米内的人？注意单位和精度限制
GEORADIUS 的距离单位只有 m（米）、km、mi（英里）、ft（英尺）四种，没有 cm 或 nm；而且 Redis Geo 使用的是 Geohash，5 位精度约 2.4km，7 位才到约 19m——它天生不适合亚米级场景。
- 写
GEORADIUS users 116.48 39.92 500 m是对的，但写500不带单位会报错：ERR wrong number of arguments for 'georadius' command - 如果用户真实距离 499 米，但因 Geohash 边界落在相邻格子，可能被漏掉——这不是 bug，是空间索引固有特性
- 高精度需求（如共享单车找附近车）建议用 PostGIS 或专有地理数据库，Redis Geo 更适合“3km 内门店”这类容忍百米误差的场景
并发写入导致 GEOADD 覆盖？同一个 key 多次存相同 member 会静默更新
GEOADD 对同一 member 重复执行，不是报错或忽略，而是直接覆盖旧坐标——这在用户频繁移动上报时容易引发“查到的位置明显滞后”问题。
- 例如用户 A 上次在朝阳门（116.43, 39.91），现在上报到国贸（116.48, 39.92），两次
GEOADD都用"uid:1001"作 member，后者必然覆盖前者 - 但如果上报延迟或乱序（比如旧坐标后到），就会把新位置又刷回旧位置
- 解决方法不是禁用重复写入，而是加时间戳校验：应用层判断新坐标的时间戳是否更新，再决定是否调用
GEOADD - Redis 本身不提供“仅当更新时才写”的原子操作，这点必须由业务兜底
Geo 功能看着简单，但坐标顺序、排序控制、单位显式声明、以及 member 覆盖语义，这四点只要错一个，查询就悄无声息地失效。调试时别只盯命令语法，先用 GEOPOS 和 GEODIST 把实际存进去的数据摸清楚。
