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></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 是一样的，但前者更易读、更不易被截断。