Spring Boot旅游线路规划系统：从数据模型到核心算法实战-平芜编程栈

简介：一套基于SpringBoot与MySQL的旅游线路规划系统毕业设计资源包，面向计算机相关专业毕业生、Java学习者及需要快速搭建同类型项目的开发者。系统覆盖地图信息查看与缩放、景点搜索与坐标定位、旅游线路智能推荐、沿途住宿推荐以及导航导游方向指示等用户端功能；管理员下设二级管理员，可完成旅游景点的新增、查看与编辑。资源包共558个文件，以gif演示动图、html页面、xml配置和Java源码为主，辅以css样式、js脚本、sql数据库脚本、mp4录像演示等，整体压缩包约30MB，目录结构完整清晰。已有157人学习下载。配套文档与源码相互对应，Java分层涵盖Controller、Service、Interceptor等典型模块，便于理解SpringBoot项目前后端交互与MySQL数据持久化；既可用于毕业设计答辩和课程设计，也适合作为JavaWeb开发实战练习与二次开发蓝本。

1. 代码能跑只是及格，数据模型才见功力

每年到了毕设季，旅游线路规划系统都是 Java 方向的高频选题，搜索引擎里翻出来一多半是 springboot 全家桶套一个管理后台，点开源码包，无非是用户表、线路表、订单表，加上堆 CRUD 而已。这类项目的通病是太薄：线路规划的核心——按天拆分行程、平衡景点热度与交通耗时、在预算约束下生成组合方案——几乎没有人真正动过。在外面包一条旅游线路容易，写一个能说服答辩老师的“规划算法”难。

这个标题真正值得拆的地方不在这层皮，而在往里两层：第一层是数据模型怎么设计才能支撑“多天、多景点、有顺序”的规划逻辑；第二层是当用户输入“从家出发、玩 3 天、预算 2000、偏好自然风光”时，后端怎么把这些约束变成一条条可落地的线路。本文就是按这个脉络展开的，适合正在做同类毕设的 Java 方向学生，也适合想把“毕设级代码”推向可维护状态的初级工程师。按标题给的源码包为基准，一步一步把表结构、算法和接口设计讲清楚。

2. Spring Boot 旅游线路规划系统的数据模型怎么设计才能不返工

2.1 先认清这个项目与普通 CRUD 后台的本质差异

管理系统与规划系统的最大区别，在于有没有“组合决策”。商品管理、用户管理，本质是单实体增删改查；而旅游线路规划，天然是“多实体关联、带顺序约束”的复合对象。一条线路不能只记录“名称”和“价格”，它必须包含线路顺序，也就是今天去哪几个景点、明天去哪几个景点、住在哪个区域、点与点之间怎么衔接。这个差异直接决定第一批要建的表就不是四张五张能收场的。

我一般会先画一张概念图，把实体分成三层：

基础数据层：scenic_spot景点表、hotel酒店表、city城市表；
规则配置层：line线路主表、line_detail线路明细表（按天排序）、tag标签表；
用户行为层：user用户表、favorite收藏表、order订单表。

三层结构不是摆设，它保证了后续算法逻辑只依赖前两层，第三层再叠加也不会污染核心计算。很多毕设项目表之间藕断丝连，景点里塞一个line_id字段，到头来排重和统计全是坑。

2.2 核心表结构与建表 SQL（直接可抄）

线路明细表是整个规划系统的题眼。它存的结构是“一条父线路 + 多条子行程”，每条子行程属于某一天，有自己的景点顺序。参考建表 SQL 如下：

CREATE TABLE `line` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `name` VARCHAR(100) NOT NULL COMMENT '线路名称', `days` TINYINT NOT NULL DEFAULT 1 COMMENT '行程天数', `start_city` VARCHAR(50) NOT NULL COMMENT '出发城市', `budget_min` DECIMAL(10,2) DEFAULT NULL COMMENT '预算下限', `budget_max` DECIMAL(10,2) DEFAULT NULL COMMENT '预算上限', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1启用 0停用', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `line_detail` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `line_id` BIGINT NOT NULL COMMENT '所属线路', `day_seq` TINYINT NOT NULL COMMENT '第几天，从1开始', `spot_seq` TINYINT NOT NULL COMMENT '当天景点顺序', `spot_id` BIGINT NOT NULL COMMENT '景点ID', `stay_hours` DECIMAL(3,1) DEFAULT 2.0 COMMENT '预计停留小时', `transport` VARCHAR(20) DEFAULT 'CAR' COMMENT 'CAR/BUS/WALK', PRIMARY KEY (`id`), KEY `idx_line_day` (`line_id`, `day_seq`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这两张表的核心设计意图是：线路与景点的关系被展开成显式的明细行，而不是在景点表上挂一个 JSON 字段。line_detail里line_id + day_seq + spot_seq三列联合表达了“结构”，stay_hours + transport表达了这个景点的“消费方式”，规划算法可以直接基于这些字段计算总耗时、总预算和切换成本。做答辩时，这三列能讲出一个完整的组合优化故事，比一句“用 List 存的”有说服力得多。

2.3 一个高频失误：把多天行程压缩成单表字段

参考常见实现，很多同学会忍不住在line表里直接加spot_ids VARCHAR(500)，再用逗号拼接景点 ID。这个方案在页面展示上完全没问题，但一旦进入规划逻辑就寸步难行：求两点间连线耗时需要拆字符串、调整顺序需要重写整个字段、统计线路覆盖的热门景点需要 LIKE 查询。任何一个 5 年以上工程师看到这个设计，都会把它列为重构头号目标。

正确做法是：把“明细”与“主档”拆开。line是主档，关心的是“这条线路叫什么、几天、大概什么预算”这种列表页信息；line_detail是明细，关心的是“具体哪天去哪个景点、待多久、怎么过去”这种详情页与计算信息。二者用line_id关联。前端拿数据时，先查line分页，再根据line_id批量查line_detail组装成树形结构返回给前端。

Spring Boot 中的实现提示：line_detail的批量查询务必用WHERE line_id IN (...)一次查出，再在内存中分组，避免在循环里逐条查库。下面这段 Service 层代码演示了标准的组装逻辑：

public List<LineVO> listLinesWithDetails(int page, int size) { // 1. 分页查线路主档 List<Line> lines = lineMapper.selectPage(page, size); if (lines.isEmpty()) { return Collections.emptyList(); } // 2. 收集所有线路ID，一次性查明细 List<Long> lineIds = lines.stream().map(Line::getId).toList(); List<LineDetail> details = lineDetailMapper.selectByLineIds(lineIds); // 3. 内存分组，按 day_seq -> spot_seq 排序 Map<Long, List<LineDetail>> detailMap = details.stream() .sorted(Comparator.comparing(LineDetail::getDaySeq) .thenComparing(LineDetail::getSpotSeq)) .collect(Collectors.groupingBy(LineDetail::getLineId)); // 4. 组装 VO return lines.stream().map(line -> { LineVO vo = new LineVO(); BeanUtils.copyProperties(line, vo); vo.setDetails(detailMap.getOrDefault(line.getId(), List.of())); return vo; }).toList(); }

这段代码的关键点在全都在第 2 步和第 3 步：先批量查、再内存排序和分组。绝大多数烂代码都死在循环里逐条selectById上，一旦线路数量上千，接口耗时直接以秒计。答辩现场的性能提问，这一处就能撑住。

提示：表结构设计阶段多花一小时，算法阶段省三天。line_detail中的day_seq和spot_seq要定义为 TINYINT 而非 INT，语义更清晰，索引也更瘦。

3. 线路规划系统里的核心算法：多日游的路径编排怎么实现

3.1 把“规划”抽象成图论与约束的组合问题

有了line_detail表，下一步是回答标题里“规划”这个词的实现路径。用户视角的“规划”是输入条件、得到一条可选的线路；后端视角的“规划”是一个约束满足问题。

具体拆解为四个输入与三个输出：

输入一：出发城市（用于确定交通基线和起终点）；
输入二：天数 N；
输入三：预算范围 [low, high]；
输入四：偏好标签集合，如“山水”“人文”“亲子”；
输出一：合法线路列表，每条线路包含 N 天的行程；
输出二：每天的总耗时（景点停留 + 交通切换）；
输出三：每天的总预算（门票 + 酒店 + 餐饮按天摊派）。

实现上，把这套逻辑落到一个独立的RoutePlannerService中，不跟 Controller 或 Mapper 耦合。核心数据结构是“景点连接图”：每个景点是节点，景点之间的边权有两个维度——交通耗时和交通费用。

3.2 贪心 + 回溯：毕设场景下性价比最高的方案

常见的旅游规划算法有三种：贪心、回溯、动态规划。动态规划在这个场景下有一个致命问题：状态维度爆炸。背包问题只有“容量”一个维度的状态，而线路规划至少有“当前景点、当天剩余时间、已用天数、剩余预算、已访问景点集合”五个维度，哪怕把景点总数控制在 50 个以内，状态空间也轻松过亿。所以毕设项目做组合优化，我一般不推动态规划，而是推“贪心构造初始解 + 回溯局部调整”的双阶段方案。

第一阶段（贪心构造）：从起点出发，每天在当前可达景点中，选一个“单位时间体验值”最高的加入当天行程，直到当天时间窗口耗尽，进入下一天；
第二阶段（回溯调整）：当某一天的方案导致整体预算超限或交通时间不健康时，回溯到前一天，换一个次优景点，再继续往下推。

下面是参考实现的核心方法：

public List<List<ScenicSpot>> planRoute(PlanRequest req) { List<ScenicSpot> allSpots = spotMapper.selectByCity(req.getCity()); // 按偏好标签加权打分，构建体验分 Map<Long, Double> scoreMap = buildScoreMap(allSpots, req.getTags()); // 邻接矩阵：交通耗时分钟数 long[][] travelMinutes = buildTravelMatrix(allSpots); List<List<ScenicSpot>> result = new ArrayList<>(); boolean[] visited = new boolean[allSpots.size()]; int days = req.getDays(); // 贪心阶段：逐天构造 for (int d = 0; d < days; d++) { List<ScenicSpot> dayPlan = new ArrayList<>(); int remainMinutes = DAILY_PLAY_MINUTES; double remainBudget = req.getDailyBudget(); while (remainMinutes > 0 && remainBudget > 0) { int bestIdx = findBestNext(dayPlan.isEmpty() ? getStartIndex(allSpots, req.getStartCity()) : dayPlan.get(dayPlan.size() - 1).getId(), allSpots, remainMinutes, remainBudget, visited, scoreMap, travelMinutes); if (bestIdx < 0) break; ScenicSpot spot = allSpots.get(bestIdx); dayPlan.add(spot); visited[bestIdx] = true; remainMinutes -= spot.getVisitMinutes() + travelMinutes[dayPlan.size()]; remainBudget -= spot.getTicketPrice(); } result.add(dayPlan); } // 回溯阶段：超预算则逐天换低票价景点 if (calcTotalBudget(result) > req.getBudgetMax()) { result = backtrackAdjust(result, allSpots, visited, req, scoreMap, travelMinutes); } return result; }

这个方法里最需要向答辩老师讲清楚的是findBestNext的评分逻辑。它的评分不是只看景点热度，而是score = tagWeight / (visitMinutes + travelTime)，等价于“单位时间内的体验密度”。这个公式本身就是贪心策略的解释：同样 2 小时，去一个 90 分且不堵车的近景点，远比去一个 95 分但要多绕 40 分钟车程的远景点划算。回溯阶段则对超出预算上限的线路，把当天“边际分数最低”的景点替换为同标签下价格更低的备选。

提示：贪心算法必然存在局部最优问题，答辩老师的追问大概率落在“你怎么证明你的方案接近全局最优”上。建议准备一组对比数据：同一份输入数据，你的算法耗时 2.3 秒，穷举法需要 4 分钟以上，且你的得分是穷举法的 88%——这个 88% 就是一张很好用的牌。准备一手实验数据写进设计文档的附录里，含时间/评分/可行性三列。

3.3 时间窗口与预算约束的落地参数

算法设计的最后一公里是把参数具体化，否则永远只能停留在伪代码。参考以下从真实项目中提炼出来的三个必须显式定义的参数：

参数名	建议值	类型	说明
`DAILY_PLAY_MINUTES`	540（9 小时）	常量	每天可游玩时间窗口，不含睡觉与早餐
`MAX_SPOTS_PER_DAY`	4	配置项	超过 4 个景点会导致体验极差，作为硬约束
`MIN_TRANSFER_MINUTES`	20	配置项	相邻两个景点之间最短切换时间，防止同城零距离错误

这三个参数中，MAX_SPOTS_PER_DAY是最容易被忽略的。很多毕设项目的代码只依赖“剩余时间”做判断，结果一天排了 7 个景点，时间上成立但逻辑上荒诞。加了硬约束之后，算法输出的线路一眼看上去就“像人做出来的”。

同时，预算计算不要只加门票。完整预算公式为：

单日预算 = 门票 + 餐饮（固定 80/人） + 住宿（按城市等级浮动） + 交通（按距离 × 单价)

scenic_spot表中要有ticket_price、visit_minutes、city_id、longitude、latitude五个字段，前四个参与预算与时间计算，经纬度参与交通矩阵的构造。交通矩阵构造的简化方案是用两点直线距离除以平均车速（市区 30km/h，高速 80km/h），能支撑起规划精度，又不必真的接高德或百度地图 API。

4. Spring Boot 实现规划接口的工程化细节：MyBatis 关联查询与缓存策略

4.1 推荐的项目分层与包结构

技术栈锁定为 springboot + mybatis（或 mybatis-plus）+ mysql。项目分层上，我习惯按功能横切而非按技术切，这样答辩时目录结构本身就能讲出逻辑：

com.example.tourplan ├── controller/ # 只做参数校验和路由 ├── service/ # 业务编排与规划算法 │ ├── RoutePlannerService.java │ └── LineQueryService.java ├── mapper/ # MyBatis Mapper接口 ├── model/ # 实体类（entity） ├── dto/ # 入参/出参对象 ├── vo/ # 前端展示对象 └── config/ # 跨域、拦截器、缓存配置

Controller 层的规范参考做法是：只接收 DTO、调 Service、返回统一响应体，不要在 Controller 里写任何计算逻辑。划重点：统一响应体Result<T>必须包含code、message、data三件套，其中code用数字枚举，不要用字符串"200"这种魔法值。这样前端拿到错误码可以直接 switch，而不是猜测。

4.2 解决 MyBatis 关联查询的 N+1 问题

line与line_detail，以及line_detail与scenic_spot之间存在两级关联。如果直接使用 MyBatis 的嵌套结果映射，很容易触发 N+1 查询：先查 10 条线路，再每条线路查一次明细，再每条明细查一次景点，共执行 1 + 10 + 10×3 = 41 次 SQL。表数据量小的时候显不出来，数据量一大，接口就毁了。

解决方案之一是使用 MyBatis 的collection嵌套查询，配合fetchType="lazy"与aggressiveLazyLoading=false。但更稳的实践是：写一个专用的查询 Mapper 方法，一次性 JOIN 出结果，再在 Java 内存中组装成嵌套结构。上面 Service 代码展示的就是这个思路。下面给出对应的 Mapper XML 片段：

<select id="selectLineDetailsMap" resultType="com.example.tourplan.model.LineDetail"> SELECT ld.*, s.name AS spot_name, s.ticket_price, s.visit_minutes FROM line_detail ld LEFT JOIN scenic_spot s ON ld.spot_id = s.id WHERE ld.line_id IN <foreach collection="lineIds" item="id" open="(" separator="," close=")"> #{id} </foreach> ORDER BY ld.day_seq, ld.spot_seq </select>

这里用了LEFT JOIN和IN集合查询，一次查出所有线路的明细和景点信息，之后在 Java 层用groupingBy分组，比 MyBatis 嵌套映射更可控。如果用了 mybatis-plus，则可以借助listByIds配合 LambdaQueryWrapper 完成同样的事，但注意后者仍会有 1 次主查询 + N 次附表查询的问题，需要留意。

4.3 热点线路的缓存策略：如何避免缓存穿透

线路规划系统的典型特征是热门线路的高频读。每次用户进入列表页，都会触发“主档 + 明细 + 景点”的完整组装，这个组装过程开销可观。参考 Spring Boot 的@Cacheable注解可以快速落地缓存而不引入额外中间件：

@Cacheable(value = "lineDetail", key = "#lineId") public LineVO getLineDetail(Long lineId) { Line line = lineMapper.selectById(lineId); List<LineDetail> details = lineDetailMapper.selectByLineId(lineId); // 组装详情 return assembleVO(line, details); }

@Cacheable背后的机制是 Spring AOP 代理：方法执行前先查缓存，命中则不进入方法体；未命中则执行方法并将返回值放入缓存。需要注意的问题是缓存穿透：如果传入一个不存在的lineId，方法每次都会查库，缓存也存不进去。解决方式是在lineMapper.selectById(lineId)返回 null 时主动缓存一个空对象，或者用布隆过滤器前置拦截。毕设项目里缓存空对象五分钟就够了。

缓存失效策略也不宜复杂，按“修改即失效”处理即可：后台管理员修改线路后，调用cacheManager.getCache("lineDetail").evict(lineId)主动清掉对应缓存。一句话原则：写操作很少，读操作很多，用“更新时删除缓存”远远好过“设置超时时间”，因为后者会带来缓存与数据库的不一致窗口。

5. 从毕设到可演示：管理端的关键交互与答辩演示脚本

管理端是很多毕设项目最薄弱的部分，数据库设计得不错，算法也写了，结果管理后台一打开只有五张表格，毫无演示价值。本节围绕“管理端 + 演示路径”补充三个关键点，让你在答辩或远程演示时，既能展示工程深度，又不露怯。

5.1 线路编辑功能：拖拽排序与实时预算预览

线路编辑页面不能只是表格填写。建议用现成的前端拖拽组件，比如 vue-draggable-plus 或 sortablejs，把line_detail的景点列表做成可拖拽排序的卡片列表。核心交互是：拖拽完成一个景点顺序调整后，立即向后端发起请求，重新计算“总耗时、总预算、每日景点数”，并把结果实时渲染在页面侧边栏。这个交互直接证明你的前端与后端是联动的，不是静态假页面。

后端对应提供以下接口：

接口	方法	作用
`/api/line/{id}/detail`	GET	获取单条线路的完整行程信息
`/api/line/{id}/detail/order`	PUT	接收调整后的`lineId + daySeq + spotList`，批量更新明细顺序
`/api/line/simulate`	POST	不落库，仅返回行程的时间/预算评估结果

simulate接口是加分项。它等于把规划算法单独暴露成了一个只读服务，答辩时可以直接演示“把景点 C 从第三天挪到第一天，预算变化多少”这种试算场景，比对着数据库截图有说服力太多。

5.2 答辩演示的三段式脚本

参考常见答辩流程，按以下三段演示，每段 2 分钟以内：

打开系统首页，展示“出发城市 + 天数 + 预算 + 偏好标签”四个筛选条件，选取“杭州 + 3 天 + 2000 元 + 自然风光”，点击规划，展示 1.5 秒内返回的三条备选线路；
点击其中一条线路，进入详情页，展示每日行程的可视化时间轴，上面有景点名、停留时间、交通方式和单日预算，并强调这些字段全部来自算法输出的结构化数据；
切到管理后台，直接修改该线路的第三个景点，保存后回到前台刷新，看到线路展示瞬间更新，同时缓存已失效——此处顺便说出“更新时删除缓存”的策略。

这套演示脚本的核心是用数字说话，每个环节都真实可验证，不会在提问环节发现页面访问报错。

5.3 留给自己的两个兜底安全设计

答辩和演示现场的网络环境通常不稳定，有两个兜底设计建议提前做好。第一个是数据初始化组件的开关：写一个DataInitializer实现ApplicationRunner，在其中判断景点表为空时自动插入系统演示所需的种子数据，用@Value("${init-data.enabled:true}")控制开关，万一演示现场连不上 MySQL，重启项目能自动造数。第二个是演示专用账号的固定密码：直接配置在application-demo.yml中，注意不要提交到公网仓库，彻底避免被裁判或同学登录后改动数据。