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。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 用户上报的 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 管理有效期。

• 推荐组合方案：用 ZADD 维护一个按时间戳排序的有序集合（如 "geo:active:user_ids"），每次 GeoAdd 后同步 ZADD 当前时间戳；定时任务用 ZRANGEBYSCORE 清理超时项，并用 GEOREM 删除过期用户
• 不要在每次查询前主动清理——GEORADIUS 不过滤过期数据，得靠应用层逻辑跳过无效用户（比如查到用户后，再 HGET 其状态字段判断是否在线）
• 如果微服务多实例部署，避免多个实例同时触发清理，可用 Redis 锁（SET key val NX EX 30）确保单例执行

为什么 GEODIST 计算两点距离不准

Redis 的 GEODIST 返回的是球面距离（单位米），但实际场景中“附近”常指道路距离或步行可达性。直接用它做筛选阈值，会导致大量用户被误判为“不可达”。

• GEODIST 结果是大圆距离，平坦地形误差小，但城市峡谷、跨江跨山时偏差明显；若业务对精度敏感（如外卖骑手匹配），必须接第三方路径 API（如高德 /v3/direction/walking）二次校验
• Go 调用 redis.Client.GeoDist 时，单位参数只能是 "m"、"km"、"mi"、"ft"，传错会返回 nil 和错误 redis: nil reply
• 别在循环里反复调 GEODIST 算所有候选人的距离——先用 GEORADIUS 拿粗筛结果，再对 Top-K 做精算

真实场景里，Geo 查询性能瓶颈往往不在 Redis 本身，而在结果去重（同一用户多设备上报）、状态过滤（用户设置“隐身”）、以及下游服务调用链路的耗时叠加。这些没法靠一个 GEORADIUS 解决，得在 Go 层用 sync.Map 缓存最近活跃用户状态，或用布隆过滤器快速排除无效 ID。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！