GEORADIUS 默认不排序，需显式加 ASC 才返回最近10人；必须用 WITHDIST 获取距离、WITHCOORD 获取坐标；GEOADD 顺序为经度+纬度+member，且 member 应用业务ID避免重名或敏感信息。
为什么直接用 GEOADD + GEORADIUS 不一定返回“最近的10人”
很多人以为往 Redis 里塞完位置，调一次 GEORADIUS 就能拿到按距离排序的“最近10人”，结果发现返回顺序是乱的——GEORADIUS 默认不排序，只按内部存储顺序返回。必须显式加 ASC 或 DESC 参数，否则即使加了 COUNT 10，也可能是随机10个在半径内的人。
另外，GEORADIUS 返回的是 member 名（比如用户ID），不是坐标或距离。如果需要展示“距您2.3公里”，得额外用 GEODIST 算，或者一步到位用 WITHDIST 选项。
- 务必加
ASC：保证最近的排前面 - 加
WITHDIST才能附带距离字段，单位默认是米 - 加
WITHCOORD才能拿到经纬度，用于前端地图打点 - 注意：Redis GEO 的精度受 double 浮点数限制，实际误差在 1 米内，对“附近的人”足够用
GEOADD 插入时用用户ID当 member，但别存昵称或手机号
member 是唯一键，也是后续查询的依据。用 user:123 这类业务ID最稳妥；如果存昵称，重名会导致覆盖；存手机号虽唯一，但暴露敏感信息，且长度长、内存占用略高。
插入命令形如：GEOADD users_geo 116.480579 39.987589 user:1001，注意顺序是 经度 纬度 member——和常见“纬度优先”的直觉相反，错位会导致位置偏移上千公里。
- 经度范围 -180 ~ +180，纬度 -90 ~ +90；超限会报错
(error) ERR invalid longitude, latitude - 同一 member 多次
GEOADD会更新位置，适合移动场景（如实时定位） - 不要为每个用户单独建 key，全放在一个 GEO key（如
users_geo）里，否则无法跨 key 做半径查询
用 GEORADIUSBYMEMBER 查“以某用户为中心的附近人”更自然
前端通常想查“我附近的人”，而不是“某个固定坐标附近的人”。这时用 GEORADIUSBYMEMBER 更直接：它先根据 member 查出其坐标，再以此为圆心做半径搜索。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
例如查用户 user:1001 周围 3 公里内最多 20 人：GEORADIUSBYMEMBER users_geo user:1001 3 km WITHDIST WITHCOORD ASC COUNT 20。比先 GEOPOS 再 GEORADIUS 少一次 RTT，也避免中间状态不一致。
- 如果 member 不存在，命令直接返回空数组，不会报错
- radius 单位支持
m（米）、km、mi（英里）、ft（英尺），别混用 - 注意：Redis 3.2+ 才支持
GEORADIUSBYMEMBER，旧版本只能手动查坐标再发GEORADIUS
性能瓶颈不在 GEO 命令本身，而在数据量大时的内存与网络开销
Redis GEO 底层用 Sorted Set 实现，GEORADIUS 时间复杂度是 O(N+log(M))，N 是半径内元素数，M 是总元素数。只要 N 不爆炸（比如市中心设 500m 半径，通常就几十到几百人），速度很快。
真正卡住的往往是：返回 1000 个用户 ID 后，业务层还得逐个查 HGETALL user:123 拿昵称头像——这会产生大量额外请求。应该提前把必要字段冗余进 GEO 查询结果，或用 Lua 脚本原子合并。
- 避免在 GEO key 里塞海量僵尸账号，定期用
ZREM清理过期用户（GEO 本身不支持 TTL，得靠外部逻辑） - 如果并发查的人多，考虑加一层本地缓存（如 Caffeine），缓存“某用户ID → 附近人列表” 30 秒，减轻 Redis 压力
- 千万级用户时，单个 GEO key 可能达百 MB，主从同步和 RDB 快照会变慢，需评估分片（如按城市前缀拆成
geo:bj、geo:sh）
最常被忽略的一点：GEO 功能依赖 Redis 的地理编码精度，而它假设地球是完美球体。对于跨赤道或高纬度区域（如北欧），两点间大圆距离误差会略大于平面投影算法——不过对“附近的人”这种场景，影响远小于定位设备本身的 GPS 误差。
