GeoOperations 是 Spring Data Redis 提供的地理空间操作接口，需通过 RedisTemplate.opsForGeo() 获取，不可直接 new；member 重复会覆盖旧坐标；georadius 空结果多因单位枚举误用、坐标系偏差或序列化问题。
GeoOperations 是什么，为什么不能直接 new 它
GeoOperations 是 Spring Data Redis 提供的地理空间操作抽象接口，封装了 Redis 的 GEOADD、GEORADIUS 等命令。它不是工具类，也不能直接 new 实例——必须从 RedisTemplate 或 ReactiveRedisTemplate 中获取。常见错误是试图手动构造或注入未配置的 GeoOperations，结果抛出 NullPointerException 或 IllegalArgumentException。
正确做法是：确保已配置好 RedisTemplate<string object></string>（注意 key 和 value 类型需一致），再调用其 opsForGeo() 方法获取实例：
RedisTemplate<String, String> redisTemplate; // 注意泛型匹配 GeoOperations<String, String> geoOps = redisTemplate.opsForGeo();
关键点：
- 泛型必须是
<String, String>或<String, YourValue>，但YourValue必须能被RedisSerializer序列化（纯字符串最安全） - 如果用
RedisTemplate<String, Object>却存入自定义对象，geoAdd会静默失败或写入乱码，导致后续georadius查不到数据 - Spring Boot 2.0+ 默认使用
LettuceConnectionFactory，无需额外配置即可支持 GEO 命令
添加位置数据时，member 参数为什么不能重复
Redis 的 GEOADD 命令要求每个 member 在同一个 key 下唯一。在 GeoOperations.geoAdd() 中，若重复插入相同 member（比如两次都用 "shop-101"），新坐标会覆盖旧坐标——这不是 bug，而是 Redis 原生行为。容易误以为“没生效”，其实是被覆盖了却没察觉。
典型场景：
- 门店系统定时同步位置，用固定 ID 作为
member，本意是更新，但忘了日志记录，导致调试时怀疑代码没走通 - 用户签到位置用手机号作
member，但同一用户多次签到，后一次必然覆盖前一次，丢失历史轨迹
解决建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 需要保留历史？改用时间戳拼接：
"user-123-202405201430" - 仅需最新位置？确认业务允许覆盖，并在调用前加日志：
log.debug("Updating geo for member: {}", member) - 批量添加时，用
geoAdd(key, Collection<GeoLocation<String>>)，避免循环中反复获取GeoOperations实例
georadius 返回空列表，但数据明明存在
调用 geoOps.radius() 或 geoOps.radiusByMember() 返回空，大概率是单位或参数类型不匹配。Redis GEO 命令对距离单位（m、km、mi、ft）和排序方式（ASC/DESC）敏感，而 Spring 封装时若传错枚举值，会直接忽略条件或返回空。
常见陷阱：
- 误传字符串
"km"而非RedisGeoCommands.DistanceUnit.KILOMETERS—— 接口只认枚举，字符串会被当无效参数丢弃 - 用
GeoRadiusCommandArgs.newGeoRadiusArgs().includeDistance().includeCoordinates()但没调用.sortAscending()，而实际想按距离由近到远排，结果默认无序，前端分页取前 10 条可能全是远的 - 坐标精度问题：前端传来的经纬度是 GCJ-02（国内高德/腾讯坐标系），而 Redis 存的是 WGS-84（GPS 原始坐标），偏差可达 500 米，搜索自然找不到
实操检查项：
- 打印实际执行的 Redis 命令：
redis-cli --raw -p 6379 GEOPOS your-key member确认存入坐标是否合理 - 用
GEODIST your-key member1 member2 km手动验证两点距离，反推 radius 参数是否足够 - 单位统一用枚举：
RedisGeoCommands.DistanceUnit.METERS，别自己拼字符串
性能瓶颈常卡在序列化和连接池上
高频调用 geoRadius 时，响应延迟突然升高，往往不是算法问题，而是 RedisTemplate 的序列化器或 Lettuce 连接池配置不合理。
具体表现与对策：
- 大量
StringRedisTemplate混用：如果项目里同时存在StringRedisTemplate和泛型为Object的RedisTemplate，且都操作 GEO 数据，StringRedisTemplate的StringRedisSerializer无法反序列化二进制坐标，导致radius结果为空或解析异常 - Lettuce 连接池未配置：默认单连接，高并发下线程阻塞在
get connection，表现为偶发超时。需在application.yml显式配lettuce.pool.max-active: 20 - 结果过大未截断：
radius(...).count(1000)会把 10km 内所有点全查出来再内存截取，应改用count(100)让 Redis 层面限制数量
真正影响性能的，往往是序列化器选错、连接池太小、以及没让 Redis 做好过滤。GEO 索引本身是 zset 实现，O(log N) 查询效率很高，别过早怀疑它。
