GEOSEARCH是当前稳定可用的周边搜索命令，GEORADIUS已被标记为deprecated；其返回空或不准主因是GEOADD经纬度顺序颠倒、单位缺失、坐标系未转换（如GCJ-02未转WGS84）或坐标越界。
GEOSEARCH 是当前稳定可用的周边搜索命令，GEORADIUS 已被标记为 deprecated，新项目不要用。
为什么 GEORADIUS 返回空或距离不准
不是 Redis 有问题，而是写入和查询时三个关键点没对齐：
-
GEOADD必须严格按「经度在前、纬度在后」顺序，写成39.915 116.404（纬度先）会让北京落到南美洲 - 所有查询命令必须显式指定单位，比如
5 km；漏写单位会默认按米解析，5就只查了 5 米 - 前端地图 SDK（高德、百度）返回的是 GCJ-02 坐标系，而 Redis GEO 内部按 WGS84 计算，不转换偏差可达 500 米以上
- 经纬度超出合法范围会静默失败：
longitude必须在 [-180, 180]，latitude必须在 [-85.05112878, 85.05112878]，超界不报错但返回空数组
GEOSEARCH 的正确用法（Redis 6.2+）
它统一了查询入口，支持两种起点和两种形状，比 GEORADIUS 更可靠：
- 起点用
FROMLONLAT（推荐）：直接传用户当前坐标，如FROMLONLAT 120.149993 30.334229 - 起点用
FROMMEMBER：适合“查看某店铺附近的其他店铺”，如FROMMEMBER shop:101 - 形状选
BYRADIUS（圆）或BYBOX（矩形），后者对地图瓦片、行政区划更友好 - 必须加
WITHDIST和WITHCOORD，否则前端拿不到距离和坐标渲染 Marker - 排序必须显式写
ASC，否则结果无序，“最近的 10 个”无法保障 - 分页靠
COUNT+WITHDIST配合应用层处理，Redis 不支持 offset 分页
示例命令：GEOSEARCH shop:geo:F&F FROMLONLAT 120.149993 30.334229 BYRADIUS 10 km WITHDIST WITHCOORD ASC COUNT 20
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Spring Data Redis 怎么调用 GEOSEARCH
Spring Data Redis 2.6+ 才原生支持 GEOSEARCH，低版本会抛 UnsupportedOperationException：
- 确认依赖版本：
spring-boot-starter-data-redis≥ 2.6.0，对应 Redis Java Client（Lettuce）≥ 6.1.0 - Java 中不能直接用
redisTemplate.opsForGeo().search(...)—— 它还没封装GEOSEARCH，得走execute()调原生命令 - 参数顺序容易错：Lettuce 的
geoSearch方法要求先传 key，再传GeoSearchCommand对象，其中from和by必须非空 - 返回值是
List<GeoSearchResponse>，每个元素含member、distance、coordinate，别漏判 null
只存 ID，完整数据去哪查
Redis GEO 只负责快速圈出「附近有哪些店铺 ID」，不存详情：
- 店铺名称、图片、评分等字段存在 MySQL 或 MongoDB，用 ID 批量 JOIN 或 IN 查询
- 避免把大字段塞进 GEO，否则 ZSET score 计算失真，
GEOSEARCH结果漂移 - 如果并发高、延迟敏感，可对热门店铺做二级缓存（如
shop:101→ JSON），但注意缓存一致性 - 坐标精度建议 ≥6 位小数，
120.149993比120.15准确一个数量级，GEOHASH 单元格更细
最易被忽略的一点：GEOHASH 精度不由你配置，而由输入坐标的浮点位数和 Redis 内部编码共同决定；传 120.149993 和 120.149993000 在 Redis 里算出来的 score 是一样的，但前者更易读、更不易被截断。
