SpringBoot+Vue智能旅游行程规划系统实战：从CRUD到智能算法

1. 从标题拆解出真正的需求不是做CRUD而是做规划打开需求文档或者任务书写着基于SpringBootVue的智能旅游行程规划系统很多人第一反应是这不就是一个景点管理订单管理的CRUD吗前端Vue写几个页面后端SpringBoot搭几个接口数据库建几张表跑通了交差。我接过这个项目时也被这个表面印象误导过真正动手才发现这类系统的难点根本不在管理系统那四个字而在智能规划。游客不是来帮你维护景点数据的他要的是输入一个城市、几天时间、几个偏好系统能自动帮他排出一条合理的游玩路线。CRUD只是底座行程推荐算法才是系统的灵魂。如果你只做了景点和酒店的管理而不去做路线生成、时间冲突处理、偏好加权排序这个项目顶多算半个。搞懂这点后我把整体拆成了三层数据层景点库、酒店库、城市库、行程主表、行程明细表业务层行程自动生成、冲突检测、偏好打分、交通耗时估算交互层Vue页面展示地图路线、时间轴卡片、手动调整接口。这套分层不只是为了代码好看它保证了算法模块可以单独替换、单独测试。比如我后来把贪心算法升级成带评分函数的多方案择优只改了一个Service类的几个方法前端完全没有动。标题里还有个容易被忽略的关键词——部署文档。说实话这类系统真正的完成度不是看你代码跑得多欢而是交付之后能不能在另一台机器上从零拉起来。后面我会用专门一章讲部署里的那些坑这往往是毕业设计和企业项目之间差距最大的地方。这篇文章会把这套系统的完整实现路径讲清楚覆盖数据库设计、算法实现、前后端联调、部署上线、测试数据构造尽量跳过教科书里那些废话只讲你动手时真正用得上的东西。2. 数据库设计五张核心表缺一张后面都难受系统涉及的实体其实不多用户、景点、酒店、城市、行程。但行程这块的建模有讲究很多人在这里栽跟头。我最终落地的表结构是这样的照着业务倒推出来的表名作用关键字段user用户表id, nickname, travel_preference偏好JSONcity城市表id, name, lat, lng用于距离计算attraction景点表id, city_id, name, lat, lng, business_hours, visit_duration, score, tags, costhotel酒店表id, city_id, name, lat, lng, price, scoretrip行程主表id, user_id, city_id, start_date, day_counttrip_item行程明细表id, trip_id, day_index, sort_no, item_type(attraction/hotel/rest), item_id, start_time, end_time2.1 行程主表和明细表为什么要拆开一开始我图省事把整个行程JSON直接塞到trip表里的一个plan字段里查询前端一次拿到全部数据确实快。但很快就遇到问题用户要手动调整某一天的路线顺序前端得把整个plan传回来后端要解析重写整个JSON前端要自己维护一堆数组索引双向绑定搞得一团糟。后来老老实实拆成主表和明细表。主表存用户、目的地、总天数这些一次性的信息明细表把每一天、每个时间段的安排变成一行。这样前端要调整顺序只需要改trip_item里的sort_no后端写一个update接口专门处理排序逻辑清晰得多也方便循环展示、按天筛选。拆开之后还有个额外好处统计系统里每天的平均景点数、热门时段直接SQL聚合trip_item就行不用解析JSON。这算是数据建模阶段的一个正确妥协。2.2 attraction表设计里的两个关键考量景点表是系统的数据粮仓有两个字段最容易忽略一个是business_hours。很多景点不是全天开放的有的上午8点半开门、下午5点关闭有的午休闭园。同一个城市的景点开放时间差异很大做行程规划时必须作为硬约束。我存字符串08:30-17:00后端解析的时候转成时间区间去碰撞。另一个是visit_duration_hours表示游玩这个景点大概需要多久。这个值不建议搞得太细比如不要写成2.3小时这种伪精度。按景点类型给默认值就好博物馆2小时、主题公园4小时、自然风景区3小时。它是行程安排的核心标尺去重复计算交通时间的误差远远大于这个数值本身的误差。经纬度字段也必须有。城市内景点之间的大致交通时间用经纬度直线距离乘一个系数来估算比查第三方地图API稳定得多而且不依赖外网离线也能演示。2.3 用户偏好字段JSON还是关联表用户偏好喜欢自然风光还是人文古迹、喜欢拍照打卡还是深度游有两种存法一种是单独建一张user_pref表一种是在user表里加一个varchar字段存JSON。我选了后者。原因很直接偏好会被算法模块高频读取、低频修改JSON存序列化字符串访问一次就拿到了不用每趟都JOIN一次。而且偏好的维度可能随着系统迭代增加JSON结构天然支持扩展。SQL里就用JSON_CONTAINS做简单过滤性能对这个体量的系统毫无压力。对应Java实体类里的偏好字段我建议用一个Map类型接收JSON转换的事情交给Jackson。这样不管将来加亲子游还是美食游标签代码都不用跟着改结构。3. 智能规划核心贪心算法加评分函数而不是随便推荐几个景点接下来是这个系统真正值钱的部分——自动行程生成。这个模块直接决定了用户在页面上能不能看到一条像人排出来的路线很多号称智能的系统实际上只是按评分排序扔出几个景点完全不考虑地理位置和时间顺序用户拿到手里就是一堆地图上散落的点。我的方案分两步先按天生成候选景点集合再用贪心加评分函数排布每天的具体时间线。3.1 整体算法流程处理逻辑是逐天进行的伪代码如下输入城市C出行天数D偏好标签P酒店坐标H 输出每天的行程时间线 items for day in 1..D: 计算当天剩余可用时间段去掉睡觉时间 从候选池中挑选满足未游玩过且当天不在冲突行程中的景区 所在地理位置从酒店出发按可达性 偏好得分 排序 依次把景点插入当日时间线遇到营业时间冲突就跳过 当天景点达到数量上限或时间用尽则结束当天安排 为当天安排午餐/晚餐的时间窗这里有个容易忽略的点用户从酒店出发而不是从全城中心出发。所以每天的行程实际上是酒店—景点—景点—返回酒店的闭环每个景点的入场时间受前一个景点的游玩时长和通勤时间双重约束。把交通耗时也纳入排序逻辑是这套方案和简单按评分排序的本质区别。具体做法景点A到景点B的交通时间用经纬度欧氏距离乘以城市系数。在一个中等城市直线1公里按实际行驶2到3分钟估算系数取2.5比较稳。3.2 评分函数的设计贪心算法里的每个景点不能只按景点的全局评分排序必须复合计算一个当日适合度score attraction.score * 0.5 preference_match_score * 0.3 (1 - distance_factor) * 0.2preference_match_score 计算方式景点标签和用户偏好标签的交集比例。比如用户偏好自然,徒步景点tags含有自然,摄影交集1个并集3个得分就是1/3归一化到[0,1]。distance_factor 是当前坐标到该景点的交通耗时占当天总可用时间的比例。含义很简单如果一个景点评分再高但过去要花两个小时当天的性价比就下降了。这个0.2的权重就是用来惩罚偏远景点的。用上面三个维度算出来的分数再做排序得到的是合理的候选序列而不是一串网红景点大拼盘。3.3 营业时间和游玩时长的碰撞处理拿到候选序列后就要把景点一个个放进时间线。这一步必须校验两个时间约束营业时间约束景点开门前的时段不能排入关门前的最后入场时间不能晚于关门前1小时游玩时长约束景点游玩需要的时间不能超出当天剩余可玩时间。这两个约束有一个经典的坑不能只校验开始时间在营业时间内。比如一个景点营业时间9:00-17:00游玩时长3小时如果你安排在16:00入场虽然16点在营业时间内但游玩会持续到19点超时了。正确逻辑是游玩结束时间必须不晚于闭园时间。我当时用一个DayPlanner类专门管理当天的时间轴核心方法长这样你们可以参考public boolean tryInsert(Attraction attraction, LocalTime visitStart) { LocalTime visitEnd visitStart.plusHours(attraction.getVisitDuration()); if (visitEnd.isAfter(attraction.getClosingTime())) { return false; // 游玩会超过闭园时间 } if (visitStart.isBefore(attraction.getOpeningTime())) { return false; // 还没开门 } // 检查当天已有行程的区间冲突 for (TimeSlot slot : occupiedSlots) { if (visitStart.isBefore(slot.getEnd()) visitEnd.isAfter(slot.getStart())) { return false; } } occupiedSlots.add(new TimeSlot(visitStart, visitEnd)); return true; }3.4 一天安排的份量和节奏很多人做这个模块时往一天里塞尽量多景点结果用户走断腿。我做了两个参数限制每天景点数上限配置成3到4个按城市和景区类型浮动每天总游玩时间控制在8小时以内就餐时间窗固定插在中午12点到13点、晚上18点到19点。这两个限制是产品层面的设计不是算法必须。从真实旅游角度看一天排5个景点基本都是赶场子排3个反而更像一个正常人的旅游节奏。系统生成的行程如果比旅行社的行程还疯狂用户一眼就看出不真实。给每天的行程追加一段游览动线说明也很有用例如根据每天的景点组合自动生成上午优先安排距离较远的自然景区下午就近安排文化场馆这类文字这让规划感直接拉满。3.5 多方案择优而不是只给一条路线只算一条路线用户不满意就得自己手动调体验一般。我后来又加了多方案机制用上面这个流程跑三到五遍每遍在候选池里微调优先级的偏移值生成多条可行路线按照总游玩权重总通勤时间偏好覆盖度做一个综合排序让用户在页面上切换方案对比。具体做法是第二遍把评分公式里的三个权重随机浮动10%第三遍把起始酒店到首个景点的距离权重提高。这样产生的不只是同一个算法的重复结果而是三种不同侧重的方案。实测下来用户对方案B的认可度明显高于只给单一结果。这个多方案评估不只靠感觉我抽了一批用户测试给每个方案从路线通勤总时长、覆盖偏好标签数量、当日景点游玩总时长三个维度打分最后综合分最高的方案作为默认。给用户三个备选他心理上也会觉得系统更智能。4. 前端Vue页面地图展示、时间轴拖拽和方案切换前端这部分的骨架其实不复杂——首页搜索目的地、行程列表页、规划详情页。真正的体验核心在规划详情页。4.1 地图选型与路线绘制展示路线地图是刚需。我这里用的是Leaflet加OpenStreetMap没去接需要申请key的商业地图SDK。原因很简单第一不用申请各种key省去配置分发麻烦第二Leaflet的marker和polyline组件足以画出路线的全部要素第三整套纯前端依赖后期打包部署没有平台限制。画路线的基本步骤// 伪代码示意核心数据流 const items getTripItems(tripId); // [{name, lat, lng, type, ...}] const polylinePoints items .filter(item item.type attraction) .map(item [item.lat, item.lng]); L.polyline(polylinePoints, {color: #2e7d32}).addTo(map); items.forEach(item { L.marker([item.lat, item.lng]) .addTo(map) .bindPopup(${item.name}br/${item.startTime} - ${item.endTime}); });要注意的一个核心问题是前端拿到的坐标类型必须和后端数据库、算法模块完全一致。我调接口时遇到过数据库里存的经纬度是字符串前后端解析到地图上就变成Null的情况非常基础但很致命。后来统一约定为Double类型、后端JSON序列化不转字符串才彻底解决。4.2 时间轴拖拽的交互逻辑单纯展示路线只能算看交互上还需要改。我在左侧做了一个时间轴面板按天分组展示当天每个景点的卡片卡片上标明进入和离开时间。Windows上用的懒人做法用vue-draggable实现卡片拖拽排序拖拽完成后把新的顺序数组发给后端后端重新计算每个景点的时间。这块设计有一个实现的讲究拖拽调整的只是景点顺序不是每个景点的开始时间。用户拖完前端只传sort sequence后端重新跑一趟时间编排把新的start_time/end_time算出来返回前端再刷新。如果前端自己去改时间会面临时区、格式、营业时间三重麻烦不如交给后端统一处理。4.3 三种方案切换的体验优化方案切换的UI我用了三个竖排的tab卡点击任意一个左侧时间轴内容、右侧地图路线同步更新。所有数据从后端一次性取出三个方案的全部trip_item前端做tab切换的纯视图渲染不再重复请求接口体验上做到了几乎零等待。这个优化主要是出于接口压力的考虑——规划详情页是用户停留时间最长的页面每次切换都请求一次后端加载转圈会打断思路。一次性返回全部方案数据换来的是前端切换即时生效代价仅仅是首次加载稍慢几十毫秒完全值得。4.4 页面结构分层整个规划详情页的结构我虽然只用了一个Vue页面但组件拆得很细TripCalendarTab负责方案tab切换TimelinePanel时间轴卡片列表支持拖拽MapPanel地图展示DayTabs按天切换的标签栏。组件拆分的核心动力不是代码洁癖而是让每个小组件都能独立做状态控制——拖拽的组件和地图组件互不干扰改一套逻辑不影响另一套。后期如果要做移动端适配这些组件都可以直接复用。5. 部署才是交付的最后一公里配置文件、跨域和打包细节代码写完、本地跑起来只能算完成一半。这类项目交付时通常会带部署文档把自己机器的环境变量、数据库引导、前端打包配置全部记录下来。但我在真实部署时发现最容易翻车的恰恰是最不起眼的几个细节。5.1 环境变量统一管理不要写死在application.yml我见过不少项目把数据库地址和密码直接写在application.yml里自己机器上能跑换一台机器就容易踩坑。部署时的正确做法是用SpringBoot的application.yml做配置模板关键项使用环境变量占位spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: ${DB_USER} password: ${DB_PASSWORD}部署机器上设置好系统环境变量或在启动脚本里引入.env文件这样源码分发出去也不泄露敏感信息。同时要记得修改MySQL的时区参数serverTimezoneAsia/Shanghai这可以在源头避免大部分时间差、日期显示不对的问题。5.2 跨域问题的两个层面前端开发时localhost:8080的页面要请求localhost:9090的后端接口跨域问题会立刻暴露。开发环境里我在Vue的vite.config.js里配置了代理server: { port: 8080, proxy: { /api: { target: http://localhost:9090, changeOrigin: true } } }但生产环境我选择的是Nginx反向代理一个server块里同时代理前端静态资源和后端/api路径。这里有个经验不要在生产环境依赖SpringBoot的CORS配置解决问题而是用Nginx统一处理跨域。Nginx配置如下location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; # 这是前端history路由的关键 } location /api { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }try_files $uri $uri/ /index.html这行特别提醒一下。Vue用history模式路由时刷新页面会404必须靠这一行把路由请求重写回index.html。少了它部署文档写得再完整前端实际一刷就露馅。5.3 前端构建的坑base路径Vue前端构建时如果在nginx的子路径下部署比如 https://你的域名/demo/travel/需要在vue.config.js里配置publicPathmodule.exports { publicPath: process.env.NODE_ENV production ? /demo/travel/ : / }我之前部署时没注意直接在根路径部署一切正常换到子路径后CSS和JS全部404看控制台才发现是base路径不对。这个信息一定要写进部署文档因为不同用户拿到部署包后放的路径可能是完全不同的。5.4 部署清单速查后端构建mvn clean package -DskipTests生成jar包前端构建npm run build生成dist目录数据库初始化执行提供的schema.sql和data.sql注意导入顺序后端启动nohup java -jar travel.jar --spring.profiles.activeprod app.log 21 前端部署dist目录内容拷到nginx的web目录验证访问前端地址随便搜索一个城市生成行程确认地图marker能正常显示。6. 测试数据构造造出一座滨江市让行程规划真正跑通讲完部署还得讲一个隐藏的重要环节——测试数据的构造。一个空数据库是跑不出任何行程的你要设计一组尽可能贴近真实场景的景点、酒店数据算法才能真正展现效果。我构造了一个虚构的滨江市包含12个景点覆盖自然、文化、乐园、美食四类标签4家酒店分布在城市的四个方位每个景点都有合理的经纬度、营业时间、游玩时长、评分、票价。比如其中几个设计景点标签营业时间游玩时长评分云岭山风景区自然,徒步08:00-17:3044.8滨江博物馆文化,历史09:00-17:0024.6欢乐谷主题乐园乐园,亲子10:00-21:0054.9老城美食街美食,人文11:00-22:0024.5构造数据时要注意数据的分布合理性——不能把4个5A级景点堆在一个角落否则算法无论怎么排都是绕圈走也不能让所有景点营业时间统一否则算法的开放时间约束就形同虚设。数据合理算法才能表现出所谓的智能。这一点也值得写进项目说明文档方便他人理解算法的效果边界。6.1 规划结果验证用滨江三日游测试时我预设用户偏好自然文化入住城西的湖景酒店。系统的生成结果如下Day 1云岭山风景区上午偏远优先→ 山脚茶室午餐→ 滨江博物馆下午→ 老城美食街晚餐Day 2欢乐谷主题乐园全天→ 晚间城市阳台看夜景Day 3植物园上午→ 文创街区下午购物从路线可以看到算法的几个有效行为把路程较远的云岭山排在了第一天上午因为从酒店出发距离远但顺路向景区群推进第二天全天安排的是游玩时长5小时的主题乐园没有插入其他景点因为时间冲突检测会自动拒绝插入第三天安排的距离近、节奏缓的行程考虑到用户已经是游玩尾声比较符合真实旅游的身体规律。这套数据还有一个好处demo演示时讲出来有条理。给老师或者面试官展示时直接说你看我选自然文化偏好系统把偏远的山放在第一天把游乐园独立安排一天这是合理规划比说我的算法用了贪心评分要直观得多。6.2 测试用例留痕我还把验证过程中的几个典型场景固化成测试用例用例1偏好自然时自然类景点在方案中的占比不低于70%用例2偏好亲子时含主题乐园的行程方案排第一用例3某景点当天不可插入时关门早系统不会强行排入并导致超时用例4用户拖拽把景点A从Day1挪到Day2后后端重新计算的时间不重叠。这些用例既是我调算法的参考标尺也写进了项目报告变成系统验收时的核心证据。这一步千万别省测试数据构造得越认真项目答辩或者验收时你可讲述的东西就越多。7. 最后再聊两句开发体会这个系统做完我自己最大的一个感受是一个所谓的毕业设计系统和能跑通的demo之间的差距主要不是代码量而是对场景的理解深度。CRUD只要细心谁都能写但只有你会去考虑游客一天不能排5个景点酒店到景点的通勤时间必须计入排序营业时间约束的判定要用游玩结束时间而不是入场时间这些东西系统才会从有功能变成有灵魂。另外如果你也打算用这个题目建议在动手前先把数据构造和验证用例想清楚不要等系统做完了才去找数据。数据质量直接决定了算法好不好看、演示顺不顺。我最后一版就是先造好了滨江市的数据集再回头微调算法的权重前后只花了一个晚上效果却比之前到处拼凑数据跑出来的结果强很多。希望这篇东西能帮到正在做类似项目的朋友尤其是那些拿到智能XX系统题目但不知道怎么让系统真正智能起来的同学。系统源码部分不方便直接贴但所有核心算法的思路、接口设计的取舍、部署的细节上面都写清楚了按这个框架搭出来的系统比很多模板化的成品要扎实不少。