Java Stream 流本身不直接支持地理计算，但可通过预计算距离、filter 前置校验与筛选、sorted 前加 limit 等策略高效处理 GPS 坐标范围查询，避免实时 Haversine 计算和无效排序。
Java 中 Stream 流本身不直接支持地理计算，但可以高效组织对 GPS 坐标数据的范围筛选——核心是把“距离判断”转化为可流式处理的数值条件，再借助 filter + 预计算或缓存策略完成。
先统一坐标结构，确保 lat/lon 可安全读取
真实场景中，空值或非法坐标（如 lat=999.0）极易导致 Haversine 计算异常或 NaN。必须在流开头就拦截：
- 用 filter 检查非空和有效范围：.filter(p -> p != null && p.getLat() != null && p.getLon() != null && Math.abs(p.getLat()) <= 90 && Math.abs(p.getLon()) <= 180)
- 若原始对象不可改，建议封装一层校验工具方法，避免重复逻辑
把距离计算前置，别在 filter 或 sorted 里实时算
每次调用 Haversine 公式都涉及三角函数，反复计算会严重拖慢性能。推荐两种做法：
- 参考点固定时（如查“离某门店5km内”）：初始化阶段就为每个 GeoPoint 算好 distanceToStore 字段，后续 filter 直接用 .filter(p -> p.getDistanceToStore() <= 5000)
- 参考点动态时（如“当前用户位置”）：用 map 提前转成带距离的中间对象，例如 .map(p -> new DistanceEntry(p, haversine(p.getLat(), p.getLon(), userLat, userLon)))
filter 放 sorted 前，且配合 limit 控制结果规模
排序是 O(n log n) 操作，十万条坐标全排再取前10个，远不如先筛再排：
立即学习“Java免费学习笔记（深入）”；
- 正确顺序：stream → filter（按距离阈值）→ sorted（按距离升序）→ limit(20)
- 错误写法：先 sorted 再 filter，既浪费 CPU，又无法利用 limit 短路优势
- Comparator 用 comparingDouble 而非 comparing，避免 Double 包装对象创建开销
慎用 parallelStream，小数据串行更稳
Haversine 是纯 CPU 运算，看似适合并行，但实际要注意：
- 数据量小于 1 万时，parallelStream 带来的线程调度和合并开销可能抵消收益
- 若 distance 计算已预缓存，再并行反而增加竞争；只有延迟计算且数据量大（≥5 万）时才考虑
- 务必保证 haversine 方法是无状态、线程安全的（不依赖共享变量或随机数）
