GraphHopper整合SpringBoot的多途径点路径规划与TSP优化实践

简介：一套基于Java SpringBoot与GraphHopper库构建的多途径点路径规划系统源码，面向有一定Java后端基础、需要实现物流配送、多点导航或巡检路线优化等场景的开发者。压缩包共23个文件，主要包含4个Java源文件、2个OSM地图数据文件、Maven构建配置（pom.xml及mvnw脚本）、GraphHopper运行所需的索引与图数据文件（如nodes、edges、location_index等）以及若干配置说明文档，整体约31.72MB。当前已有325人学习下载。这套源码完整展示了SpringBoot集成GraphHopper的关键流程：从OSM地图数据加载、路网图构建到多途经点查询接口的封装，同时给出了路径计算所需的核心参数配置与图数据持久化方案。开发者可直接参考项目结构，理解各文件在路径规划链路中的具体作用，并基于现有代码扩展业务逻辑、调整路径算法策略或接入新的地图数据源，适合作为二次开发、毕业设计或课程设计的基础工程。

1. 多途径点路径规划不是地图 API 的活：GraphHopper + SpringBoot 能自己干

接到一个配送调度需求：某快递站每天有三十多个派件点，车辆从站点出发，送完所有点再回站，之前一直用地图厂商的路线 API 挨个算相邻点耗时，再人工排顺序，排一次要半小时，高峰时根本排不过来。我接手后第一反应是找路线规划 SDK，对比了一圈发现自托管的 GraphHopper 是投入产出比最高的方案——它是纯 Java 写的开源路由引擎，能直接嵌进 SpringBoot 工程，吃 OpenStreetMap 格式的道路数据，本地就能批量算两点间耗时；多点顺序规划则是在它提供的耗时矩阵接口之上再套一层优化算法，把“先算距离再排顺序”两步彻底自动化。

这套东西打通之后，排三十个点的路线从半小时压缩到几秒，不用为每次调度付 API 调用费，也没有外网依赖，数据全在本地。核心组件只有三个：GraphHopper 负责路网图构建和单点路由计算、SpringBoot 负责把引擎包成 HTTP 服务、TSP 顺序优化算法负责把多途径点排序。适用对象很明确：自建配送调度、外勤巡检、农机田间路径规划这类需要批量、反复计算多点路线的系统。看完这篇，你能把最小可跑的 GraphHopper 服务嵌进自己的 SpringBoot 工程，并亲手实现一个多途径点顺序规划接口。

2. GraphHopper 选型与数据准备：为什么是它，而不是别家路由引擎

2.1 自托管路由引擎的定位：先搞清楚 GraphHopper 能干什么

GraphHopper 是一个 Java 实现的开源路由引擎，核心能力有三块：解析道路数据、构建路网图、按不同交通方式计算两点或多点之间的路线与耗时。它不是在线服务，而是一个嵌入式的 Jar 包，你的 SpringBoot 进程启动时调用它的 API 就能完成路网加载，之后每次路由请求都在本地内存里计算，不走任何外呼。

选它之前我对比过几种方案。纯调用在线地图厂商的路线 API 当然最省事，但多途径点场景下要反复调用批量接口，费用和配额都是问题，而且有些业务数据不能出内网。另一类是自建 OSRM 服务，它性能很强但有独立的 C++ 进程和 HTTP 服务，和 Java 工程是两套体系，部署运维要多管一个组件。GraphHopper 和 SpringBoot 是同语言、同进程，路网和路由逻辑全在一个 JVM 里，对单机几千点规模以内的业务足够用，部署也最简单。

架构上它把“路网数据文件”和“内存中的图对象”分开处理：启动时一次性读取.osm.pbf格式的道路数据，解析后构建十字路口节点和路段边组成的图；路由请求时在这个图上做双向 Dijkstra 或 A* 搜索。这里说的图是图论里的图，不是图片，存储结构和检索效率直接决定路由耗时。你的 SpringBoot 服务里只需持有 GraphHopper 单例，所有请求线程共享同一个图对象，这也是它嵌入式用法高效的原因。

2.2 道路数据怎么落到本地：从 .osm.pbf 到 GraphHopper 图

GraphHopper 要跑起来，第一步是准备道路数据。最常见的数据格式是.osm.pbf，它是 OpenStreetMap 数据的二进制压缩格式，体积比同内容的 XML 小好几倍，解析也更快。国内大区级路网数据通常几百 MB，全国级需要几个 GB，不要一上来就想全量加载，按业务覆盖范围裁剪数据更务实。

数据来源渠道有几种，但不要下载整个国家的文件塞进内存，启动时构建图会非常慢且吃内存。我一般先按城市或省份边界裁剪，用 osmium 这类命令行工具可以把大区域切成小区域，只保留业务涉及的范围。GraphHopper 虽然自带数据处理工具，但裁剪在数据准备阶段做更灵活，后面改业务边界也不用重新构建整个图。

拿到.osm.pbf后，GraphHopper 需要把它“导入”并构建成自己的图存储格式。运行时配置解析器会读取道路标签（等级、限速、单行道等），然后做节点合并和边缘计算。这个构建过程耗时取决于数据量：一个城市级文件通常在几十秒到几分钟，区域级可能要几个小时。构建好的图会写到本地目录，下次启动如果目录存在且数据没变，就直接加载序列化后的图，启动时间从几分钟降到几秒。

2.3 图构建的三个核心参数：图存储目录、交通方式、内存映射模式

GraphHopper 的初始化参数直接决定内存占用和路由准确性。第一个是图存储目录，指定后引擎会把构建好的图落盘，重启不用重新解析原始道路数据。第二个是交通方式，GraphHopper 的每种交通方式对应一套道路可走性与速度配置，汽车模式跳过步行道、走机动车道，步行模式则是另一套规则，选错模式会导致路线完全不同。

内存映射有两种模式：RAM_STORE把整个图载入堆外内存，路由最快，但数据量大时占用偏高；MMAP是内存映射文件，按需加载，适合图较大而内存有限的环境。单机并发不高、图在 500 MB 以内，用 RAM_STORE；图超过 1 GB，MMAP 更稳妥，能省下大量内存。

我通常会关闭CH（Contraction Hierarchies）预处理——预计算会让单点路由快一个数量级，但对多途径点的矩阵批量计算场景，CH 加速效果并不明显，反而增加构建时间和内存。多途径点规划的核心是频繁调用路径替代算法算矩阵，用不带 CH 的普通图更直接。

看一下典型的初始化配置代码，在用 SpringBoot 之前先在独立方法里验证参数是否合理：

// 初始化 GraphHopper 引擎，核心配置项 public GraphHopper initGraphHopper() { GraphHopper hopper = new GraphHopper(); // 数据目录：存放 .osm.pbf 原始数据 hopper.setOSMFile("/data/osm/beijing-latest.osm.pbf"); // 图存储目录：构建后的图落盘位置 hopper.setGraphHopperLocation("/data/graph-cache/beijing"); // 编码方式：支持汽车、步行等多种方式，逗号分隔 hopper.setEncodedValuesString("car,foot"); // 内存映射模式：有 RAM_STORE 和 MMAP 两种可选 hopper.setMemoryMapped(false); // 不启用 CH 预处理，降低构建开销 hopper.setCHEnabled(false); hopper.importOrLoad(); return hopper; }

代码里setEncodedValuesString定义图里预计算哪些编码属性，car 和 foot 是两种最常见的编码方式，对应不同道路通行能力。importOrLoad()是关键方法：数据没导入过就执行导入并保存，导入过就直接加载。这个过程会打印详细的日志，第一次运行观察日志里的导入进度和耗时，能帮你判断数据量级是否匹配当前机器配置。

3. SpringBoot 里把 GraphHopper 跑起来：从配置类到可调用的路由接口

3.1 依赖与 Bean 初始化：让引擎随应用生命周期启动

SpringBoot 工程引入 GraphHopper 很简单，核心就一个依赖：com.graphhopper:graphhopper-core。版本要和你下载的源码对应，这一点容易翻车，GraphHopper 的 Java 版本要求偏高，JDK 8 在较新版本上会直接运行失败，建议 JDK 11 或 17。另一个隐蔽问题：GraphHopper 依赖了若干第三方库，如果你的工程里也用了低版本冲突库，会出现NoSuchMethodError，启动时注意看异常栈，优先调整 GraphHopper 传递依赖的版本即可。

Bean 初始化上，用@Configuration定义一个GraphHopper单例，@Bean(initMethod = "importOrLoad")让它随 Spring 容器启动自动完成图加载。不要每次请求都 new 一个 GraphHopper，那等于每次重新加载路网，内存会爆。下面是标准的初始化配置类：

@Configuration public class GraphHopperConfig { @Value("${graphhopper.osm-file}") private String osmFile; @Value("${graphhopper.graph-location}") private String graphLocation; @Bean(initMethod = "importOrLoad", destroyMethod = "close") public GraphHopper graphHopper() { GraphHopper hopper = new GraphHopper(); hopper.setOSMFile(osmFile); hopper.setGraphHopperLocation(graphLocation); hopper.setEncodedValuesString("car"); hopper.setMemoryMapped(true); hopper.setCHEnabled(false); return hopper; } }

配置项被拆分到了application.yml，便于不同环境切换数据目录。注意destroyMethod = "close"，应用停机时释放底层文件句柄和内存映射资源，反复重启部署时不会出现文件锁问题。setMemoryMapped(true)对大图更友好，但首次路由请求会偏慢，因为页面数据是懒加载的，预热一次就好。

启动后日志里如果出现Using memory mapped files和Finished loading graph，说明图加载成功。之后所有线程共享该单例，路由计算是并发的，但引擎内部对图读取做了线程安全处理，不需要额外加锁。

3.2 封装单点路由计算：从经纬度到路线详情

最基础的能力是两个经纬度之间的路线。调用GraphHopper是GHRequest/GHResponse模式：创建请求、设置起终点经纬度、指定编码方式、发送到引擎，然后检查响应是否有异常。这里有一个最容易忽视的坐标顺序问题：GraphHopper 的 API 统一是纬度在前、经度在后，也就是(lat, lon)，和国内很多系统习惯的(lng, lat)正好相反。

我封装的服务类接收业务侧的(lng, lat)，在进入 GraphHopper 之前转成(lat, lng)，避免调用方因为坐标顺序搞混而返回完全离谱的路线。完整代码：

@Service public class RouteService { private final GraphHopper graphHopper; public RouteService(GraphHopper graphHopper) { this.graphHopper = graphHopper; } public RouteResult route(double fromLng, double fromLat, double toLng, double toLat) { // GraphHopper 使用纬度在前经度在后的顺序 GHRequest request = new GHRequest(fromLat, fromLng, toLat, toLng); request.setProfile("car"); // 限制搜索范围，避免歧义点导致路由绕远 request.setHint("ch.disable", true); GHResponse response = graphHopper.route(request); if (response.hasErrors()) { String errorMsg = response.getErrors().toString(); throw new IllegalStateException("路由计算失败: " + errorMsg); } ResponsePath path = response.getBest(); return new RouteResult(path.getDistance(), path.getTime(), path.getPoints().toLineString(false).toString()); } }

setProfile("car")指定用哪种编码方式，必须是在初始化时setEncodedValuesString里声明过的，否则抛异常。path.getPoints().toLineString(false)把轨迹点序列转成 WKT 格式的 LineString 字符串，前端地图直接按这个串绘制路径，省去自行序列化的麻烦。getDistance()返回的是米，getTime()返回的是毫秒，两个值后续计算矩阵时都要用到。

这个接口本身不复杂，但它验证了整个 SpringBoot 集成链路是否通——配置类有没有加载、坐标转换有没有问题、GraphHopper 能不能算出路线。集成新引擎时务必要先把单点路由跑通，再谈多途径点。

3.3 距离矩阵计算：多途径点规划的数据底座

单点路由只能解决 A 到 B，多途径点规划需要知道任意两点之间的耗时，于是 GraphHopper 的矩阵计算接口就该登场了。它避免你写双层循环逐个调用单点路由——一次请求算出所有点对之间的耗时和距离，内部会做批量优化，耗时只有逐个调用的几分之一。

GraphHopper 矩阵 API 要构建一个MatrixRequest，设置所有点的经纬度、编码方式，然后执行。返回的矩阵是二维数组，下标与原数组一一对应。这里要注意：MatrixRequest不是GHRequest，它在底层会复用团簇算法对区域内的点做批量计算，所以如果业务上确实只需要某几个点之间的两两耗时，用矩阵接口比循环单点路由合适得多。

public long[][] getTimeMatrix(List<Point> points) { List<GHPoint> ghPoints = points.stream() .map(p -> new GHPoint(p.getLat(), p.getLng())) .collect(Collectors.toList()); MatrixRequest matrixRequest = new MatrixRequest(); matrixRequest.setPoints(ghPoints); matrixRequest.setProfile("car"); // 只需要耗时数据，不返回路径几何形状，降低传输和计算开销 matrixRequest.setOutArrays(Arrays.asList("time", "distance")); matrixRequest.setFailFast(false); MatrixResponse matrixResponse = graphHopper.matrix(matrixRequest); long[][] result = new long[ghPoints.size()][ghPoints.size()]; for (int row = 0; row < matrixResponse.getTimes().length; row++) { // 逐行拷贝耗时矩阵，行下标是起点，列下标是终点 result[row] = matrixResponse.getTimes()[row]; } return result; }

setOutArrays只声明time和distance，别再加weight这类内部字段，多了白白增加计算量。setFailFast(false)很关键，矩阵中只要有一个点无法到达，整个请求会直接失败；把它关掉后能拿到部分结果，哪些点不可达在响应里标记出来，方便业务层单独处理异常点。矩阵结果保存在内存中，几十个点时就是一个N x N的二维数组，后续顺序优化算法直接基于这个矩阵运算，不再碰 GraphHopper。

4. 多途径点顺序规划：耗时矩阵 + 最近邻 + 2-opt 是性价比最高的组合

4.1 把多点问题拆成 TSP：为什么要先算矩阵再排顺序、不能直接在图上搜索

明确了矩阵接口之后，核心问题浮现：给三十个派件点和一个起点，怎么决定先送哪个、后送哪个？路线规划问题的本质是旅行商问题（TSP）——找一个经过所有点且总耗时最短的顺序。注意，这不是在地图图上做一次简单搜索能解决的，因为需要经过的点有多个，而且顺序未知，搜索空间是排列组合级别的。图搜索（如 A*）只能解决“从 A 到 B 的最短路径”，解决不了“经过 A、B、C、D 并以 E 结束的最短路径顺序”。

TSP 的解法分精确算法和启发式算法。精确算法（如动态规划 Held-Karp）在 20 个点左右就开始吃力，几十上百点的场景完全不可用。实际工程里贪心最近邻给出一个不错的基础解，再用 2-opt 局部搜索优化，这种组合在几十点规模下能跑到接近最优，耗时也短，是性价比最高的方案。更复杂的模拟退火和遗传算法在这个规模下收益有限，反而让代码复杂度和调参成本大幅上升。

业务上还要考虑起点和终点的约束。最常见场景是“从站点出发，送完所有点再回站点”，这是一个闭合 TSP，起点和终点都是站点本身；另一种是“不回站点，送完就地收工”，这就是路径 TSP。约束不同，算法里的矩阵取值方式就不同——闭合 TSP 在计算总耗时时要加上“最后一个点回到起点”的耗时。

4.2 先用最近邻快速生成初始顺序：几分钟的高质量可行解

最近邻的思路很朴素：从起点出发，每次选择离当前点耗时最短的下一个未访问点，走完所有点后得到一条路径。它本质是贪心策略，单次运行结果是确定的，执行时间只有几毫秒到几十毫秒（取决于点数），解的质量通常不超过最优解的 20% 偏差，作为 2-opt 的初始解完全够用。

关键点在于矩阵的构建方式——我们需要拿到任意两点之间通过路网的真实驱动耗时，而不是直线距离。这就是第 3 章里矩阵接口的价值：把三十个点的经纬度一次性传入，GraphHopper 返回两两之间的驾驶耗时，这个耗时已经考虑了路网、红绿灯和道路等级，比欧氏距离靠谱得多。

最近邻算法实现如下：

public List<Integer> nearestNeighbor(int startIndex, long[][] timeMatrix) { int n = timeMatrix.length; boolean[] visited = new boolean[n]; List<Integer> route = new ArrayList<>(); int current = startIndex; route.add(current); visited[current] = true; while (route.size() < n) { int next = -1; long minTime = Long.MAX_VALUE; for (int i = 0; i < n; i++) { if (!visited[i] && timeMatrix[current][i] < minTime) { minTime = timeMatrix[current][i]; next = i; } } if (next == -1) { // 剩余的节点不可达，直接退出并保留部分路径 break; } route.add(next); visited[next] = true; current = next; } return route; }

timeMatrix[current][i]的语义是“从当前节点到节点 i 的耗时”，所以贪心选择时只需要扫描当前行。startIndex是起点在矩阵中的下标，需要在矩阵接口调用前维护好“原始点列表”和“下标”的对应关系，规划完成后按这个关系把下标翻译成真实的经纬度点即可。不可达点时直接 break 是因为failFast(false)之后矩阵里会有Long.MAX_VALUE，继续循环只会卡死，不如提前结束并把这个情况上报给业务层。

4.3 2-opt 局部搜索：用两两交换把路径磨到接近最优

最近邻得到一个初始解，但问题很明显：贪心的短视行为经常导致某条路走了回头路，或者绕了一个大圈。2-opt 的思想是：取当前路径中的两条边，断开后反向连接重排，如果新路径的总耗时更小就采纳。反复执行直到没有可以改进的交换为止，收敛之后路径基本定型。

2-opt 最核心的改进点是“倒序”操作。看当前路径序列，如果交换位置i和j之间的路径段，需要把这段倒过来，而不是简单换两个节点——因为路径中某段的方向决定了车辆实际走的道路方向。用路网耗时矩阵检查倒序前后的总耗时，保留更优的那个。2-opt 嵌入实现：

public List<Integer> twoOpt(List<Integer> route, long[][] timeMatrix) { List<Integer> best = new ArrayList<>(route); long bestTime = calculateTotalTime(best, timeMatrix); boolean improved = true; while (improved) { improved = false; for (int i = 1; i < best.size() - 1; i++) { for (int j = i + 1; j < best.size(); j++) { List<Integer> candidate = twoOptSwap(best, i, j); long candidateTime = calculateTotalTime(candidate, timeMatrix); if (candidateTime < bestTime) { best = candidate; bestTime = candidateTime; improved = true; } } } } return best; }

twoOptSwap把[i, j]这段反转后重新拼接，实现方式很常规：前半段保留，中间段倒序，后半段保留。calculateTotalTime按顺序遍历路径累加相邻节点耗时，如果路径是闭合 TSP，还要把最后一个点和第一个点的耗时也加进去——这是调参时最容易漏掉的一块。

2-opt 的单轮时间复杂度是 O(n²)，加上外层循环，在 30 个点的规模下通常是几十毫秒级的，完全够用。它做不了全局最优，但能保证解质量在 5% 偏差以内，对绝大多数配送调度场景绰绰有余。

4.4 多途径点接口落地：把矩阵和优化算法串成一个 HTTP 接口

整个流程串到 SpringBoot 里，对外暴露一个 HTTP 接口：接收一组经纬度点，返回排序后的路线。这里我增加了一个“强制回起点”开关，因为很多业务场景是车辆出去必须回站点，也有场景是送完就地下班，两种需求用一个开关控制，算法实现上只在总耗时计算时多加/少加一条回到起点的边。

接口设计考虑了批量规划场景的调用方式：一次传入所有点，服务端同步计算，返回带有顺序标记的路线列表。由于矩阵计算和 2-opt 都在内存里跑，几十点级别的接口响应时间通常在数百毫秒，足够交互式使用。

@RestController @RequestMapping("/api/route") public class MultiPointRouteController { private final RoutePlanningService planningService; public MultiPointRouteController(RoutePlanningService planningService) { this.planningService = planningService; } /** * 多途径点路径规划接口 * @param points 起点 + 途径点列表 * @param returnToStart 是否返回起点 */ @PostMapping("/plan") public PlanResult plan(@RequestBody PlanRequest request) { List<Point> points = request.getPoints(); boolean returnToStart = request.isReturnToStart(); return planningService.planOrder(points, returnToStart); } }

RoutePlanningService.planOrder内部依次执行：转换 GHPoint 列表、调用矩阵接口、最近邻生成初始顺序、2-opt 优化、把下标翻译成经纬度、计算总耗时。整个流程把 GraphHopper 引擎、矩阵接口和 TSP 算法串成一个业务闭环。服务层接口返回值里包含排序后的点列表、每段路线耗时和总耗时，业务方可以直接按这个结果生成调度单或导航路线。

planOrder 核心流程拆解

你会发现真正的规划逻辑并不在 GraphHopper 里，而是发生在这个服务类中。GraphHopper 只负责回答“这两点之间开车多久”，顺序怎么排，是你自己的 TSP 算法说了算。

5. 避坑：GraphHopper 集成里最常见的 5 个翻车点

5.1 坐标顺序搞反，路线全部横穿地图

现象：从北京到天津的路线算出来横跨了中国版图，或者路线自动绕了上千公里。

原因：GraphHopper 的 GHPoint 构造器明确是(lat, lon)，很多业务系统主键存的是(lng, lat)，直接反转传入后本应向北的路变成了往东，图搜索完全错乱。

解决：在进入引擎之前统一做一次坐标转换，并且写单元测试锁定：给定已知经纬度的 A/B 两点，验证计算出的距离在合理范围内。我吃过一次亏之后，在这个转换方法里加了强校验——如果纬度超过 90 或者经度超过 180，直接抛异常，宁可开发期炸掉也不要线上错。

5.2 道路数据精度不够，压根搜不到点

现象：某几个点报Could not find point，但经纬度看着明明在市区。

原因：.osm.pbf 数据的精度和详细程度取决于数据源本身。有些区域道路缺失或断头路太多，GraphHopper 在图上找最近的可行走边失败，就会报点不可达。这种情况在郊区、新建开发区特别常见。

解决：先把点投影到图上，查看GraphHopper返回的最近边和投影点，确认是否有道路数据；如果有路但断头，则手动补录几条道路或者调整点坐标到实际道路位置。工程上给业务方提供一个“地图选址”功能，让他们在地图上选点而不是填坐标，能从源头规避这个坑。

5.3 强制回起点时总耗时少算一段

现象：接口返回的总耗时明显偏短，对比实际跑下来的时间差了将近半小时。

原因：闭合 TSP 要求“最后一个点回起点”这一段路的耗时也要计入总和，但实现里只算了路径内部相邻点的耗时，少了最后一段返程。这个在代码 review 阶段特别容易漏，因为看起来路径已经“结束”了。

解决：在calculateTotalTime方法里增加一个布尔参数returnToStart，闭合时把timeMatrix[last][first]加上。同时接口返回的明细里单独列出一个“返程耗时”字段，让业务方能看出这半小时是怎么来的。

5.4 CH 预计算打开导致启动极慢、内存吃紧

现象：启动时构建图明显变慢，日志显示 CH preprocessing 卡了很久，内存占用翻倍。

原因：和第 2 章说的一样，CH 预计算会为每个节点算跳表，构建时间和内存开销都很高。多途径点场景下主要调矩阵接口，单次路由用的不多，CH 收益有限，但它造成的构建负担是实打实的。

解决：初始化配置关掉 CH，hopper.setCHEnabled(false)。如果确实有个别高并发单点路由需求，可以单独为那个接口准备一个带 CH 的引擎实例，两个引擎共享同一份图数据目录，互不干扰。

5.5 内存映射模式下首次请求特别慢

现象：服务启动后第一个路由请求要等好几秒甚至几十秒，后面的请求就正常了。

原因：MMAP 模式下图数据是懒加载到内存的，哪条路被搜索到了才把那部分数据页加载进来。首次请求覆盖的路段多，相当于把所有道路数据都触达了一遍，自然慢。

解决：应用启动后做一次“预热”调用，随便算一条短线路，让底层把常用图页加载完。或者直接用RAM_STORE模式，启动时全部载入，第一次请求和后面一样快。内存够的话优先 RAM_STORE，省心。

6. 进阶：加一个“一键优化”按钮前，先搞懂这些技巧

多途径点规划从能跑到好用，中间还有几个提升体验的小改动。第一个是把 2-opt 的迭代上限露出来。当途径点数超过五十个时，完全收敛可能要几十轮，而实际业务里 2-opt 前几轮效果最明显，后面几轮收益很小。我习惯设置一个最大迭代次数（比如 5 轮），配合improved标志位，耗时可控，解质量也只有百分之几的差距。

第二个技巧是复用矩阵计算结果。同一个小区的多个配送点，耗时矩阵可能长时间不变，而 GraphHopper 的矩阵计算是有成本的，尤其点多的情况下。如果你的输入点集相对固定，把矩阵结果缓存起来，点集变化时才重新计算。可以用简单的ConcurrentHashMap加一个版本号来实现，点在缓存里就直接跳到 TSP 优化阶段。

第三个技巧是异步化长任务。五十个点以上的规划，矩阵计算加 2-opt 可能要几秒，同步阻塞 HTTP 请求会让前端一直转圈。一个老板键做法：接口先返回任务 ID，后端用线程池执行规划，完成后把结果写到内存缓存，前端轮询拿结果。这和直接用同步接口相比，用户体验差别明显。

车辆容量约束是另一个常见扩展方向。目前算法只优化耗时，不关心车能不能装下所有货。如果你的业务里每辆车有载重上限，那这就从 TSP 变成了 CVRP（带容量约束的车辆路径问题），需要在排顺序时同时检查已分配点的累计重量。最简单的做法是分桶——按顺序贪心塞进多辆车，每辆车满负荷后开下一辆，再用 2-opt 分别优化每辆车的顺序。

我做这套系统的过程中最耗时的不是算法本身，而是把坐标顺序、数据精度、返程耗时这些细节打磨对。这些坑不填掉，再快的最优算法都给不了业务可用的结果。规划接口上线之后，配送员的实际行驶距离和我算出来的路线差距稳定在 10% 以内——说明路网速度假设和实际匹配良好。

后续如果你遇到“某些点搜不到”“总耗时不对”“启动慢得离谱”这类问题，按第 5 章的排查顺序过一遍，大多数能直接解决。如果你要更大规模的点集，上千个点那种，建议改用专门的 VROOM 和 jsprit 这类开源求解器，配合 GraphHopper 做路网前处理，依然能把整套链路留在自己的工程里。希望帮到你。

本文还有配套的精品资源，点击获取