georadius返回结果不准或为空，根本原因是坐标系（须wgs84）、经纬度顺序（先经后纬）、单位（须小写如km/m）未对齐；默认不排序，需显式加asc/desc；且不支持属性过滤，需结合外部存储二次筛选。
Redis 的 GEO 类型能快速实现“附近的人”类需求，但直接套用 GEOADD/GEORADIUS 很容易返回错乱结果——根本原因不是命令不会用，而是坐标、单位、精度和边界条件没对齐。
为什么 GEORADIUS 返回的不是最近的 10 个？
默认单位是米（m），但很多人传入经纬度时没校验坐标系（WGS84 是唯一支持的），或误把百度/高德坐标（GCJ-02）直接塞进去，导致物理距离偏差几百米甚至几公里。另外，GEORADIUS 不保证按距离排序，必须显式加 ASC 才能从近到远排。
-
GEORADIUS默认不排序，要加ASC或DESC参数才按距离排序 - 输入经纬度必须是 WGS84 坐标系；若原始数据来自高德/百度，需先用开源库（如
gcoord）转换 - 半径单位有
m（米）、km（千米）、mi（英里）、ft（英尺），写错单位会导致范围爆炸式扩大或缩小 - Redis GEO 使用 geohash 编码，52 位精度对应约 1 米误差，但
GEORADIUS实际返回的是矩形区域内的点再过滤，存在“角上漏检”可能（极小概率）
GEOADD 存坐标时，经度和纬度顺序不能颠倒
Redis 强制要求：GEOADD key longitude latitude member。把纬度当经度传，整个地图就偏移了——北京会跑到大西洋上。这不是 Redis 的 bug，是地理坐标系的基本约定。
- 记住口诀：“先经后纬”，和日常说“东经、北纬”一致，
longitude在前，latitude在后 - 如果用程序批量导入，务必在插入前校验：
-180 ≤ longitude ≤ 180，-90 ≤ latitude ≤ 90，否则GEOADD静默失败（返回 0） - 同一个
member多次GEOADD会更新位置，适合实时上报用户移动轨迹
如何查“5 公里内评分 ≥4.5 的咖啡店”，且按距离升序？
Redis GEO 本身不支持属性过滤（比如评分、品类），必须组合外部存储。典型做法是：用 GEO 存 ID，用 Hash 存详情，再用 GEORADIUS + HGET 二次筛选。
GEORADIUS coffee:geo 116.481 39.996 5 km WITHDIST WITHCOORD ASC COUNT 100
上面命令拿到最多 100 个 ID 和距离，再用程序遍历这些 ID 去查 HGET coffee:profile <id> score category</id>，过滤出 score >= 4.5 AND category == "cafe"，最后按距离截取前 10 条。
- 别用
COUNT 10直接限制——可能这 10 个全被评分过滤掉了；应适当放大（如COUNT 100）再内存过滤 - 如果并发量大，建议把常用筛选条件（如品类）也做 GEO 分片，例如
coffee:geo、restaurant:geo分开存，减少无效扫描 - 注意
WITHDIST返回的距离是球面距离（Haversine 公式），单位与查询时指定一致，可直接用于前端显示
生产环境必须处理的三个边界问题
真实业务中，GEO 查询卡顿、结果为空、距离不准，八成出在这三处。
- 空集合：首次启动或数据未导入时，
GEORADIUS返回空数组，但业务代码没判空，直接取[0]报IndexError - 超时风险：半径设为
1000 km且数据量大时，Redis 可能扫描大量 geohash 桶，建议服务端加TIMEOUT 1000参数防阻塞 - 用户定位漂移：手机 GPS 定位误差常达 10–50 米，前端传坐标前应做简单平滑（如取最近 3 次定位均值），避免用户原地不动却反复触发“位置变更”逻辑
真正难的不是调通命令，而是让每一次 GEORADIUS 返回的距离数字，在地图上画出来刚好贴着用户指尖划过的那个圆圈——这需要坐标系、单位、精度、过滤逻辑全部咬合，缺一不可。
