能，GEORADIUS 的 ASC 确保按真实球面距离由近到远排序，但需 Redis ≥ 3.2、显式传 WITHDIST 验证距离、严格遵循“先经度后纬度”及单位正确，否则排序结果不可信。
GEORADIUS 的 ASC 真的能按距离由近到远排序吗？
能，但前提是别漏掉关键参数，且 Redis 版本 ≥ 3.2。Redis 的 GEORADIUS 默认返回结果就是按距离升序排列的，ASC 实际上是冗余参数（不写也生效），而 DESC 才是显式控制倒序的开关。很多人加了 ASC 还以为“开了排序”，其实只是确认了默认行为。
-
GEORADIUS内部用的是 GeoHash 编码 + ZSET 范围扫描 + 球面距离重校验，最终结果天然按真实球面距离排序，不是靠 score 值粗略排 - 如果没加
WITHDIST，你根本看不到距离值，容易误判“是不是真按距离排了” - 注意：
ASC/DESC只影响结果顺序，不影响范围过滤逻辑——它不会把超距点拉进来再排序，只对落在半径内的点排序
Java 里用 Jedis 调用时，georadius 返回的顺序怎么验证？
别信文档，要自己打日志看。Jedis 的 georadius 方法返回的是 List<georadiusresponse></georadiusresponse>，每个元素含距离、坐标、hash 值（如果带对应参数），但**默认不包含距离字段**。
- 必须显式传
GeoRadiusParam.param().withDist().withCoord().sortAscending()，否则response.getDistance()是null -
sortAscending()对应 Redis 命令里的ASC，不调用它，Jedis 仍会返回升序结果，但语义不明确，后续加count分页时容易出错 - 实操建议：始终带上
withDist()，然后用response.getDistance()打印前 3 条，一眼确认是否由近到远
为什么有时 GEORADIUS ... ASC 返回的第 1 个不是最近的？
常见于用了 count 但没配 WITHDIST，或坐标精度/单位搞错了。Redis 的距离计算是球面模型（Haversine），但如果你传的经纬度反了（纬度当经度、经度当纬度），或者单位用错（比如把 km 当 m 传），结果就完全不可信。
- 典型错误：
geoadd locations 39.9042 116.4074 "Beijing"—— 把纬度放前面了，Redis 要求 **先经度后纬度**，错位会导致所有距离计算偏移数百公里 -
count 5不代表“取最近 5 个”，而是“从排序结果里截前 5 个”，但如果原始数据稀疏（比如半径内总共只有 2 个点），count 5也不会补足 - 性能提示：大范围（如
500 km）+ 高密度数据下，GEORADIUS可能扫描大量 GeoHash 区块，响应变慢；这时建议先用GEORADIUSBYMEMBER+ 缓存中心点，避免重复解析坐标
Spring Data Redis 2.6+ 怎么写才不踩版本坑？
Spring Data Redis 在 2.6 之后重构了 GEO API，老教程里 geoOperations.radius(...) 返回 GeoResults<geolocation>></geolocation> 的写法已废弃，新 API 强制要求构造 GeoRadiusCommandArgs。
- 必须用
GeoRadiusCommandArgs.newGeoRadiusArgs().includeDistance().includeCoordinates().sortAscending().limit(10)，漏掉sortAscending()不报错，但 IDE 提示“method not found”——因为旧版方法名已删 - 注意
RedisTemplate的序列化器：如果 value 是自定义对象，需确保 key 是字符串，否则GEORADIUS返回的 member 名称会是乱码字节（如[B@1a2b3c） - 生产环境建议加
WITHHASH参数调试：用geohash命令比对返回值的 hash 前缀，确认 Redis 是否真在同一个 GeoHash 格子内做筛选
