geo命令查不到围栏内点主因是geoadd坐标顺序写反（应为经度在前、纬度在后），导致点落入错误地理位置；电子围栏半径单位须显式指定m/km等，不可用meter；geohash可用于万级围栏的前缀粗筛；georem不支持按时间删除，需业务层结合时间戳或有序集合实现过期清理。
Geo命令写入位置时为什么查不到围栏内点？
Redis 的 GEOADD 写入的是「经纬度对」，但顺序是 经度 纬度 —— 和常见地图 API（如高德、Leaflet）的 [纬度, 经度] 数组顺序相反。写反会导致点落在非洲内陆或大西洋里，GEORADIUS 自然查不到。
- 务必确认数据源坐标顺序：CSV/数据库字段、前端
map.getCenter()返回值、GPS 设备原始输出 - 用
GEOPOS验证写入结果：GEOPOS your_key "member_name"，返回的经纬度应与你预期地理位置匹配 - 中国范围内，经度范围约 73–135，纬度约 4–54；若返回值明显越界（如纬度=120），基本可断定顺序颠倒
电子围栏半径单位选 meter 还是 km？
GEORADIUS 和 GEORADIUSBYMEMBER 的 unit 参数必须显式指定，且只接受 m（米）、km（千米）、mi（英里）、ft（英尺）。不写或写错（如 meter）会直接报错 ERR unknown unit。
- 国内电子围栏常用 100m–500m 精度，优先用
m，避免浮点换算误差 - 注意：Redis Geo 使用 Haversine 公式计算球面距离，结果是「地面直线距离」，不考虑海拔或道路绕行 —— 这不是 bug，是设计使然
- 如果围栏需覆盖复杂地形（如跨山体、隧道），单靠 Geo 不够，得叠加 GIS 路径分析
如何用 GEOHASH 实现高效范围预筛选？
当围栏数量达万级，每次 GEORADIUS 全量扫描会变慢。GEOHASH 返回的 base32 字符串具备地理邻近性：前缀相同越多，物理距离越近。可用来做粗筛。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
GEOHASH获取目标点的 hash 值（如"wx4g0bfsyx0"），再取前 4–5 位作为「区域码」存入额外 set - 查询时先
SMEMBERS area:wx4g0拿出可能相关的围栏 key 列表，再对这批 key 逐个GEORADIUSBYMEMBER - 别直接用完整 hash 比较 —— Redis 没有原生 geohash 范围查询，硬扫
SCAN+ 字符串匹配反而更慢
删除过期电子围栏时为什么 GEOREM 不生效？
GEOREM 只能删 member，不能按时间删。Redis Geo 本身不支持 TTL，围栏过期必须自己维护。
- 不要依赖
EXPIRE给整个 key 加过期 —— 一旦 key 过期，所有围栏瞬间消失，无法做渐进清理 - 推荐方案：每个围栏 member 命名带时间戳后缀（如
fence:shanghai:20240520），配合定时任务用ZRANGEBYSCORE扫描有序集合（若你把时间存为 score）或用SCAN匹配 pattern - 注意
GEOADD的 score 是内部用于排序的 double 值，不是业务时间戳 —— 别误把它当有效期字段用
Geo 结构省去了空间索引的运维成本，但「围栏动态增删+时效控制+精度边界」这三件事，得靠业务层兜底。没有银弹，只有权衡。
