用Stream API对轨迹点距离聚合的核心是reduce滑动配对：以double[]{0.0}为累加器，每次计算a.distanceTo(b)后返回b推进链式处理；并行需慎用，仅多轨迹场景适用；预处理建议filter去噪、map转单位；可封装为Collector复用。
直接用 Stream API 对海量轨迹点做距离聚合，核心是避免索引遍历、不新建包装类、不中断流式结构——关键在 reduce 的滑动配对技巧和状态容器的轻量使用。
用 reduce 实现相邻点距离累加
轨迹数据本质是有序点列，聚合目标是 ∑distance(p₀→p₁) + distance(p₁→p₂) + …。传统 for 循环靠下标取前后点，而 Stream 中没有索引，需让 reduce 模拟“滑动窗口”：
- 传入一个双元素数组
double[]{0.0}作为可变累加器载体 - 在
reduce((a, b) -> {...})中，每次把a.distanceTo(b)加到累加器里 - 返回
b（不是a），确保下一轮的a就是当前的b，实现点链推进 - 注意：输入流不能为空，需提前判空；
distanceTo方法需在坐标类中已定义
处理超大数据时启用并行需谨慎
轨迹数据量达百万级时，并行流看似能提速，但此处不推荐直接用 parallelStream()：
- reduce 的滑动逻辑依赖严格顺序，
parallelStream().reduce无法保证相邻点成对出现 - 若强行并行，必须改用线程安全的分段计算+合并策略，例如先按固定长度切分路径段，每段内顺序计算长度，再汇总
- 实测表明：对单条长轨迹，并行反而因拆分/合并开销更慢；仅当处理成千上万条独立轨迹时，并行
stream().map(this::calcPathLength).sum()才有收益
结合过滤与预处理提升实用性
真实轨迹常含噪点、重复点或无效坐标，建议在聚合前嵌入清洗步骤：
- 用
filter(p -> p.isValid() && !p.isDuplicateOf(prev))去除异常点（需配合自定义状态或用distinct()配合重写equals） - 用
skip(1).limit(n)截取子路径做局部分析，比如只算最近 100 个点的移动距离 - 若需单位统一（如 GPS 经纬度转米），可在
map步骤中调用 Haversine 或投影转换函数，再进入 reduce 累加
替代方案：用 Collectors 自定义收集器（适合复用场景）
当多个地方都要计算路径长度，可封装为可复用的 Collector：
- 用
Collector.of(()->new double[]{0.0}, (arr, p)->{}, (a,b)->{}, arr->arr[0])搭建骨架 - 实际需保存上一个点，因此内部状态应为
Point[] last = {null}，在累积逻辑中判断是否跳过首点 - 相比 reduce 写法，自定义 Collector 更易测试、可组合（如同时统计总长+最大步长+停留点数）
