GEOSEARCH 默认不按距离排序，因设计为“先过滤后排序”，需显式指定 BYDISTANCE ASC/DESC；经纬度顺序、单位、参数位置等均需严格符合规范，否则报错。
为什么 GEOSEARCH 返回的结果默认不按距离排序？
因为 GEOSEARCH 的设计逻辑是「先过滤，后排序」——它只保证返回在指定地理范围内的点，但不自动按距离升序排列。除非显式要求，否则结果顺序由内部数据结构（zset 的 score 排序）决定，和地理位置无关。
常见错误现象：GEOSEARCH 查出 5 个地点，但最近的排在第 4 位；用 GEORADIUS 迁移过来的人会下意识以为它也带 ASC 默认行为，其实不是。
- 必须加
BYDISTANCE才能启用距离排序 -
BYDISTANCE必须和SORT参数搭配，单独写无效 - 不加
ASC或DESC会报错：ERR syntax error
GEOSEARCH 距离排序的最小可用命令格式
最简可行命令长这样：
GEOSEARCH mygeo -2.5 51.5 10 km BYDISTANCE ASC
注意几个硬性条件：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 经纬度必须是
lon lat顺序（经度在前，纬度在后），反了会导致坐标飞到南极附近 - 单位只能是
m、km、mi、ft四种，写meter或kilometers直接报错：ERR unsupported unit -
BYDISTANCE和ASC/DESC必须成对出现，缺一不可 - 如果还想要距离数值，得额外加
WITHDIST，否则只返回成员名
用 GEOSEARCH 做「附近且评分 > 4.5」的复合查询时要注意什么？
GEOSEARCH 本身不支持属性过滤，所谓「复合查询」其实是两步：先用 Geo 拿 ID 列表，再用 MGET 或管道查业务字段。容易踩的坑在于边界控制：
- 别在客户端用
GEORADIUS+ 循环查详情——GEOSEARCH的COUNT是对地理结果限制，不是对最终业务数据限制 - 如果要严格限制「最多返回 10 个满足评分条件的地点」，得在应用层做截断，Redis 不提供跨维度的
LIMIT -
COUNT参数位置很关键：必须放在BYDISTANCE ASC之后，否则被当成排序参数忽略 - 实测发现，当
COUNT 10配合大范围（如100 km）时，Redis 可能先算出几百个点再截断，CPU 消耗比预想高
PHP/Python 客户端调用 GEOSEARCH 时的典型陷阱
很多客户端库（比如 redis-py 4.5+）把 BYDISTANCE ASC 当成布尔参数或关键字参数处理，导致拼错命令。
- Python 中不要写
r.geosearch("mygeo", longitude=-2.5, latitude=51.5, radius=10, unit="km", sort="ASC")—— 这会丢掉BYDISTANCE，实际发的是非法命令 - 正确写法是显式传参列表：
r.geosearch("mygeo", -2.5, 51.5, 10, "km", "BYDISTANCE", "ASC") - PHP 的
predis同样要求手动展开参数，$client->geoSearch("mygeo", -2.5, 51.5, ["radius" => 10, "unit" => "km", "sort" => "ASC"])会失败 - 所有客户端都需确认是否已升级到支持 Redis 6.2+
GEOSEARCH语法的版本，老版本直接抛Command not found
距离计算本身用的是 Haversine 公式，精度够城市级使用，但别指望亚米级；真正卡住人的往往不是算法，而是参数顺序、单位拼写、客户端封装层级这些一眼扫过去就错的地方。
