ZREM不能直接删除Geo数据，因为它只删除ZSET中的member名称，而非按经纬度范围删除；必须先用GEORADIUS等命令查询出目标member，再调用ZREM精确删除。
为什么 ZREM 不能直接删 Geo 数据
Redis 的 GEOADD 其实是把经纬度转成 GeoHash，再塞进一个有序集合（ZSET），所以位置点本质是 ZSET 的 member，score 是 GeoHash 值。但 ZREM 删除的是 member，不是“某个坐标附近的所有点”——它不认经纬度，只认你当初 GEOADD 时传进去的 member 名字。
常见错误现象：ZREM mygeo "116.48,39.92" 失败，因为 "116.48,39.92" 根本不是 member，只是你记混了；真正存进去的可能是 "poi:1024" 这种业务 ID。
- 必须知道原始
member名才能用ZREM精确删除 - 如果 member 是动态生成或已丢失，
ZREM就无从下手 -
GEORADIUS或GEORADIUSBYMEMBER只读不删，不能替代清理动作
怎么安全批量清理过期或失效的 Geo 点
没有内置“按距离删”或“按时间删”的命令，得靠组合操作。核心思路：先查，再删。重点是避免误删、漏删，以及防止大 key 扫描阻塞。
- 用
GEORADIUS mygeo 116.48 39.92 10 km WITHCOORD WITHDIST拿到候选 member 列表（加WITHDIST方便判断是否真在范围内） - 对返回结果做业务过滤，比如排除
status:active的点，或检查关联的 hash 字段HGET poi:1024 expired_at - 把最终要删的 member 攒成数组，用
ZREM mygeo member1 member2 member3一次性删（别单条循环调用，性能差且易超时） - 如果点太多（>500 个），拆成多批，每批不超过 100 个，避免单次命令过大触发慢日志
ZREM 在 Geo 场景下的性能和兼容性注意点
ZREM 本身是 O(M×log(N))，M 是要删的 member 数，N 是 zset 总量。但实际影响更大的是：Geo 查询 + 删除的组合链路是否原子、是否可重试。
- Redis 6.0+ 支持
GEORADIUS的STORE参数，可以把结果存到另一个 zset，方便后续ZREM——但注意这个新 zset 不带 Geo 信息，只是纯 member 列表 - 集群模式下，
GEORADIUS是 hash-tag 路由的，必须确保 key 名含{...}，否则可能跨 slot 报错CROSSSLOT Keys in request don't hash to the same slot - 不要在 Lua 脚本里嵌套大范围
GEORADIUS+ 循环ZREM，脚本执行太久会卡主节点；改用客户端分页拉取再删更稳
最容易被忽略的“失效”定义
所谓“失效”，往往不是 Redis 层面的 TTL（zset 本身不支持 per-member 过期），而是业务逻辑认定：比如用户注销、设备离线、缓存写入时间超过 24 小时。这些状态不在 Geo 结构里，得额外维护。
- 别指望
EXPIRE mygeo 3600来控制点的生命周期——整个 zset 过期，所有点一起丢，太粗暴 - 推荐方案：用
HSET poi:1024 lat 39.92 lng 116.48 updated_at 1717023456存元数据，删的时候先HGET判断，再ZREM - 如果用 RedisJSON 或 RedisTimeSeries，反而更难跟 Geo 命令联动，现阶段纯 string/hash + zset 组合最可控
真正麻烦的从来不是删动作本身，而是你怎么确定“该删谁”——坐标没变，但背后的业务实体早没了，这才是清理逻辑绕不开的坎。
