GEORADIUS返回空或不准确主因是经纬度顺序错误（须经度在前、纬度在后）或单位未显式指定；需严格按geoadd key lon lat member写入，georadius命令必须带m/km等单位，且注意坐标系一致性。
为什么 GEORADIUS 返回结果为空或不准确
常见现象是调用 GEORADIUS 后没返回任何成员，或返回的坐标明显偏离预期。根本原因通常是：经纬度顺序反了（Redis 要求先经度后纬度），或单位参数未显式指定导致默认用米但业务误以为是公里。
实操建议：
-
geoadd写入时严格按geoadd key longitude latitude member顺序，比如北京国贸：geoadd users 116.48105 39.916567 "user:1001" -
georadius必须带单位，如m（米）、km、mi、ft，漏写会报错或行为异常；例如查 5 公里内用户：georadius users 116.48105 39.916567 5 km - 注意 Redis 的 WGS84 坐标系与你前端地图 SDK（如高德、Mapbox）是否一致；若前端用 GCJ-02 偏移坐标，需先转回 WGS84 再存入 Redis，否则地理距离计算失真
怎么拿到带距离和坐标的完整结果
GEORADIUS 默认只返回成员名，但实际业务常需距离（到中心点多少米）和经纬度（用于前端渲染 Marker）。必须用 WITHDIST、WITHCOORD 修饰符，且顺序不能乱——它们只对紧邻的 GEORADIUS 或 GEORADIUSBYMEMBER 生效。
实操建议：
- 完整命令示例：
georadius users 116.48105 39.916567 5 km WITHDIST WITHCOORD ASC -
ASC/DESC控制按距离升序/降序，不用则无序；若同时要分页，得靠应用层截取，Redis 不支持LIMIT offset count以外的分页逻辑（注意：LIMIT 是可选参数，写在最后） - 响应格式是交错数组：[member, distance, [longitude, latitude], member, ...]，解析时别硬拆成固定长度三元组——有成员可能没
WITHCOORD就不带坐标
GEORADIUSBYMEMBER 和 GEORADIUS 该选哪个
区别不在功能强弱，而在查询入口不同：GEORADIUS 用任意经纬度做圆心，GEORADIUSBYMEMBER 用已存在的 member 名称查其位置再展开半径搜索。后者适合“查某用户附近的人”，避免前端传坐标、减少精度误差和参数校验成本。
实操建议：
- 如果用户 ID 已存在 Geo 集合中，优先用
georadiusbymember users "user:1001" 5 km WITHDIST WITHCOORD - 注意：
GEORADIUSBYMEMBER查不到 member 时静默返回空数组，不会报错，需在业务层判断结果长度是否为 0 来区分“没人”和“用户不存在” - 二者性能几乎无差异，底层都走同样的 GEOHASH 范围扫描，但
BYMEMBER少一次坐标解析，CPU 开销略低
为什么高并发下 GEORADIUS 响应变慢甚至超时
Geo 指令本身是 O(log(N)+M) 复杂度（N 是集合大小，M 是结果数），但真实瓶颈常来自数据分布不均：所有用户挤在同一个城市（如上海），导致单个 GEOHASH 单元格内成员过多，Redis 扫描时遍历成本陡增。
实操建议：
- 避免把全量用户塞进一个 key；按区域分片，例如
users:shanghai、users:beijing，查前先根据用户坐标粗判城市再路由 key - 定期清理过期位置：Redis 没原生 TTL 支持 Geo，需配合
ZREM+ 时间戳 member 名（如"user:1001:1717023600"）或用单独的 Sorted Set 管理有效期 - 不要在大集合上频繁执行
GEORADIUS并WITHCOORD—— 序列化坐标字符串比只返回 member 名开销大不少，能省则省
Geo 功能很轻量，但坐标系、单位、分片这三点一旦出错，调试成本远高于加机器。尤其是坐标系，线上出问题时第一反应不该是查 Redis 配置，而是拿两个已知坐标的点手动算 Haversine 距离，和 Redis 返回值对一遍。
