Hyperf中用Redis Geo存店铺坐标需配置Redis连接后调用geoAdd，注意经度在前纬度在后、用纯数字ID、确保Redis≥3.2；查附近店铺时geoRadius参数顺序为key lng lat radius unit options，单位小写且必加SORT才可排序；分页需客户端处理或Lua脚本游标；高并发下建议geoHash粗筛+缓存优化。
Hyperf里怎么用Redis Geo存店铺坐标
Hyperf 默认集成了 hyperf/redis，只要配置好 Redis 连接，就能直接调用 geoAdd 存经纬度。关键不是“能不能用”，而是字段设计和精度控制——比如用商户 ID 作 member，经度在前、纬度在后（Redis Geo 要求顺序是 longitude latitude member），别把 lat/lng 写反。
常见错误：geoAdd 返回值是整数（新增的 member 数量），但很多人误以为返回的是成功/失败布尔值；还有人用字符串 ID（如 "shop:1001"）存，结果后续 geoRadius 返回时带冒号，解析麻烦——建议统一用纯数字 ID 或短哈希。
- 确保 Redis 版本 ≥ 3.2（Geo 命令最低要求）
- 经度范围 -180 ~ +180，纬度 -90 ~ +90；超出会报错
ERR invalid longitude,latitude - 批量写入用
geoAdd多参数（一次最多 100 个点），避免循环单条插入
查附近店铺时，geoRadius 的参数怎么设才不丢数据
最常踩的坑是单位和距离阈值没对齐：geoRadius 第 4 个参数必须是数字，第 5 个才是单位（m 米、km、mi 英里、ft 英尺），写成 ['withdist' => true] 这种数组传参是无效的——Hyperf 的 Redis::geoRadius 是直透 Redis 原生命令，只接受扁平参数列表。
示例正确调用：
$shops = $this->redis->geoRadius('shops:geo', $lng, $lat, 3000, 'm', ['WITHDIST', 'WITHCOORD']);
注意：WITHCOORD 返回经纬度，WITHDIST 返回距离（单位与你传的第 5 个参数一致），但默认不排序；要按距离由近到远，必须加 SORT 参数（Redis 原生支持，Hyperf 也透出）。
- 距离单位写错（比如传
'M'大写）会导致命令失败，报错ERR unsupported unit provided. please use m, km, ft, mi - 未加
ASC或DESC，结果顺序不可控，尤其跨 Redis 实例时更不稳定 - 如果只需要 ID 和距离，加
STORE或STOREDIST可写入新 key，避免传输大量坐标数据
如何避免高并发下 Geo 查询变慢
Geo 查询本身很快，慢通常来自三处：PHP 层拼参数耗时、Redis 网络往返、以及没做缓存导致重复计算。Hyperf 的协程 Redis 客户端能缓解网络问题，但业务层仍需干预。
真实场景中，用户定位精度有限（手机 GPS 误差常达 5–50 米），没必要每次请求都算精确距离。可先用 geoHash 前缀匹配粗筛（比如取 6 位 hash），再对候选集做精细 geoDistance 排序——Hyperf 没封装 geoHash，但可用 Redis::geoPos + 自行编码，或直接调 Redis::eval 执行 Lua 脚本预计算。
- 不要在循环里反复调
geoRadius查不同坐标，合并为单次多中心点查询（用geoRadiusByMember+STORE中转） - 对固定商圈（如「朝阳大悦城周边」），预计算好 geo 区域并存为集合，查时用
sInter快速交集 - 距离展示用
round($dist, 1)即可，别传 float 给前端引发精度争议
Hyperf 配合 Geo 做分页时要注意什么
Redis Geo 命令原生不支持 offset/limit 分页，geoRadius 的 COUNT 参数只是限制返回数量，不是跳过前 N 条。真要分页，得靠游标（cursor）或客户端内存分页——但后者在数据量大时内存爆炸。
推荐做法：用 geoRadius 加 WITHDIST 拿到带距离的原始结果，在 PHP 层按距离分段（比如每页 20 条），记录最后一条的 distance 和 member，下次请求带上这两个值，用 Lua 脚本过滤出“距离更大 or 同距离但 ID 更大”的下一页数据。
- 别依赖
KEYS或SCAN扫 geo key，性能极差且阻塞 Redis - Hyperf 的
Redis::pipeline对 Geo 命令无效，不能批量发geoRadius - 如果业务允许，用 MySQL 5.7+ 的
ST_Distance_Sphere做兜底（当 Redis 故障或需要复杂关联时）
Geo 不是银弹，它快在简单距离圈选，但一旦要叠加营业状态、评分、分类筛选，就得退回到关系型数据库或引入 Elasticsearch。别硬扛。
