关键在于将地理坐标转为可比数值（如球面距离），Stream仅组织逻辑；需预计算距离字段或延迟计算+缓存，filter放sorted前并用limit优化，注意空值拦截、避免装箱、慎用parallelStream。
直接用 Stream API 对地理位置变量做“距离排序过滤”，关键不在 Stream 本身，而在于你如何把地理坐标转成可比、可算、可排序的数值——比如两点间球面距离（单位：米或千米）。Stream 只负责管道式组织逻辑，真正耗时的是距离计算和比较。下面分三块说清楚：怎么准备数据、怎么写过滤+排序、怎么避免常见坑。
确保地理坐标有统一结构并预计算或延迟计算距离
别在 sorted() 里反复调用 Haversine 公式；更别让 filter() 每次都算一遍。推荐两种方式：
-
预计算距离字段：如果参考点固定（比如“用户离公司总部的距离”），提前为每个位置对象加一个
distanceToCenterdouble 字段，初始化时算好。后续 filter 和 sorted 都直接用这个值，极快又稳定。 -
延迟计算 + 缓存：若参考点动态变化（如“当前用户所在位置”），可封装一个带缓存的距离计算器，配合
map()把原始位置对象转成含距离的临时对象（如DistanceWrapper），再继续流式处理。
用 filter() 做距离阈值过滤，sorted() 做升序/降序排列
假设你有一组 GeoPoint 对象（含 lat/lon），已通过 map 转为带距离的 DistanceEntry：
List<DistanceEntry> nearbySorted = points.stream()
.map(p -> new DistanceEntry(p, calculateDistance(p, centerLat, centerLon)))
.filter(entry -> entry.getDistance() <= 5000) // 5公里内
.sorted(Comparator.comparingDouble(DistanceEntry::getDistance))
.collect(Collectors.toList());
注意：
- filter() 放在 sorted() 前，先缩小数据量，避免对十万条全量数据排序；
- 若要最近的前 10 个，结尾换成 .limit(10)，比全排序再取 sublist 更高效。
处理空值、精度与性能边界
真实场景中容易出错的几个点：
-
空坐标必须拦截：在 map 或 filter 中加判空，例如
.filter(p -> p != null && p.getLat() != null && p.getLon() != null)，否则 Haversine 计算会抛 NPE 或返回 NaN。 -
避免重复装箱：用
comparingDouble而非comparing，防止 Double 对象频繁创建；距离字段建议用 primitive double。 - 大数据量慎用 parallelStream()：Haversine 计算是 CPU 密集型，小到中等数据（
核心就这三点：结构清晰、计算前置、顺序合理。不复杂但容易忽略。
