GEORADIUS 默认不排序，需显式添加 WITHDIST 和 SORT BY DIST（Redis 6.2+）才能按距离升序返回；Go 客户端需设置 GeoRadiusQuery.Sort="ASC"、WithDist=true，并指定 Count 避免全量扫描。
为什么直接用 GEORADIUS 可能返回乱序结果
Go 微服务调用 Redis 的 Geo 功能时，很多人默认用 GEORADIUS 查附近用户，但发现返回的 []string 或 []interface{} 里坐标顺序和距离无关——因为 Redis 默认不排序，只按内部存储顺序返回。这不是 Go 客户端的问题，是命令本身行为。
- 必须显式加
WITHDIST+SORT BY DIST参数才能按距离升序排（注意：Redis 6.2+ 才支持SORT BY DIST；老版本只能靠客户端二次排序） - Go 的
redis.Client.GeoRadius方法第二个参数是redis.GeoRadiusQuery，其中Sort字段要设为"ASC"，WithDist设为true - 如果漏掉
Count，可能扫全量数据，拖慢响应；建议始终设合理上限（如Count: 100）
如何用 redis.GeoAdd 正确存用户经纬度
存用户位置不能只传 lat, lng，必须保证精度和单位一致。Redis Geo 内部用 52 位整数编码，要求经度范围 -180.0 ~ 180.0、纬度 -85.0511 ~ 85.0511，超出会报错 ERR invalid longitude,latitude。
- 用户上报的 GPS 坐标通常没问题，但若来自某些地图 SDK（如高德），需确认是否已转 WGS-84；百度坐标系（BD-09）必须先纠偏，否则位置漂移几百米
-
redis.GeoAdd第三个参数是geoLocation切片，每个元素含Name（用户 ID）、Longitude、Latitude；Name建议用业务唯一 ID（如"user:12345"），别用昵称，避免重复或特殊字符 - 批量写入比循环单条快得多，用
redis.GeoAdd(ctx, key, locations...)一次提交，减少网络往返
怎样处理高并发下的位置更新延迟
用户移动时频繁更新 Redis Geo，容易因网络抖动或客户端重试导致位置滞后。单纯依赖 SET + 过期时间不行，Geo 没有原生 TTL，得靠额外 key 管理有效期。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐组合方案：用
ZADD维护一个按时间戳排序的有序集合（如"geo:active:user_ids"），每次GeoAdd后同步ZADD当前时间戳；定时任务用ZRANGEBYSCORE清理超时项，并用GEOREM删除过期用户 - 不要在每次查询前主动清理——
GEORADIUS不过滤过期数据，得靠应用层逻辑跳过无效用户（比如查到用户后，再HGET其状态字段判断是否在线） - 如果微服务多实例部署，避免多个实例同时触发清理，可用 Redis 锁（
SET key val NX EX 30）确保单例执行
为什么 GEODIST 计算两点距离不准
Redis 的 GEODIST 返回的是球面距离（单位米），但实际场景中“附近”常指道路距离或步行可达性。直接用它做筛选阈值，会导致大量用户被误判为“不可达”。
立即学习“go语言免费学习笔记（深入）”；
-
GEODIST结果是大圆距离，平坦地形误差小，但城市峡谷、跨江跨山时偏差明显；若业务对精度敏感（如外卖骑手匹配），必须接第三方路径 API（如高德/v3/direction/walking）二次校验 - Go 调用
redis.Client.GeoDist时，单位参数只能是"m"、"km"、"mi"、"ft"，传错会返回nil和错误redis: nil reply - 别在循环里反复调
GEODIST算所有候选人的距离——先用GEORADIUS拿粗筛结果，再对 Top-K 做精算
GEORADIUS 解决，得在 Go 层用 sync.Map 缓存最近活跃用户状态，或用布隆过滤器快速排除无效 ID。 
