每年到了毕业设计选题的季节总有一批计算机专业的同学在“做什么题目”这件事上反复纠结。管理系统太普通电商平台太烂大街纯算法又怕做不完。如果你也处在这个阶段我的建议很直接考虑一个基于Spring Boot加Vue的旅游网系统。这个名字听起来像一个普通的CRUD项目但它背后实际上覆盖了后端框架、前端工程化、数据库设计、权限控制、文件上传等多个重要技术点用来做毕业设计或者全栈练手性价比非常高。这个系统能做的事情也很清晰游客可以浏览旅游景点、查看线路详情、注册登录、收藏心仪路线、下单预订管理员可以在后台维护景点信息、管理订单、更新线路、上传图片甚至做简单的数据统计。一套经典的“前台门户后台管理”双端结构正好是当前企业在招全栈开发时最熟悉的形态。无论你是想顺利通过毕业答辩还是想在简历里多一个可直接演示的作品这个选题都值得认真对待。下面我会结合自己当初开发和指导同类项目的经验把这个“旅游网系统”从选题逻辑、技术拆解、数据库设计到核心代码和避坑技巧完整地讲一遍。内容不求高大上但求每一步都能落得了地。1. 项目选题与整体设计思路拆解1.1 旅游网系统的本质一个全栈项目如何串起整个知识体系很多人一听到旅游网系统第一反应是“这不就是增删改查吗”。这句话对但也不全对。纯粹的CRUD确实不难但旅游网这个业务场景天然带有多表关联、条件筛选、订单状态流转、文件资源管理这些真实业务特征比单纯的学生管理系统、图书管理系统更能体现一个开发者的建模能力和工程意识。从技术角度看一个完整的旅游网系统至少要拆成三个层面。最表层是用户看到的旅游门户包括首页轮播图、景点列表、目的地分类、线路详情、订单页面中间层是后台管理涉及登录鉴权、数据表格、图片上传、状态修改底层是一套关系型数据库设计至少要有用户表、景点表、线路表、订单表、收藏表如果做得细还会有分类表、评价表。这三个层面一旦串起来Spring Boot负责接口和业务逻辑Vue负责页面交互MySQL负责数据持久化你大学四年学到的东西基本都被调动起来了。这也是我推荐这个选题的核心原因它不偏门不冷门知识点分布均匀而且在答辩时非常好讲清楚。评委老师通常会问三个方向的问题业务设计上为什么这样拆表技术上如何解决跨域和权限控制代码里有没有什么亮点。这三个问题恰好都对应旅游网系统里绕不开的模块。1.2 选题价值旅游网到底能帮你证明什么能力毕业设计本质上是一个证明工具证明你具备独立完成一个软件项目的能力。那么旅游网系统能证明哪些能力第一全栈开发能力。你会写Controller、Service、Mapper也会写Vue组件和路由知道前端的请求怎么发到后端也知道后端的数据怎么响应给前端。第二数据库设计能力。旅游网涉及至少五张核心表它们之间存在外键关联比如用户下订单会引用线路表收藏表会关联用户和景点这种一对多、多对多的关系能够体现你对范式设计和索引运用的理解。第三工程协作思维。源码、数据库脚本、文档三件套本身就是毕业设计的标配你要学会把数据库导出成SQL文件把项目写成结构清晰的文档把部署过程整理成说明。这三点加在一起已经超过很多只写了一个静态页面或者单机控制台程序的毕业设计了。我见过一个同学做的题目也叫旅游网站但他只实现了用户登录和景点列表两个功能管理员后台完全没有订单表也是摆设。答辩时老师提问订单状态是怎么流转的他没法回答。这个教训其实可以避免选题的时候就要把系统模块想完整哪怕实现难度可以分阶段但在设计上不能缺胳膊少腿。2. 技术选型与核心模块拆解2.1 Spring Boot加Vue为什么是毕业设计里的安全牌在技术选型上Spring Boot加Vue的组合目前已经是毕业设计的主流配置。原因不难理解Spring Boot让后端开发变得非常轻量内置Tomcat不需要繁琐的XML配置通过一个启动类就能跑起来Vue则解决了前端DOM操作的杂乱问题组件化开发让页面结构清晰配合Element UI或者Element Plus能快速做出后台管理界面。更关键的是这两种技术栈的学习资料多遇到报错很容易搜到解决方案时间紧迫的毕业季容错率很高。有人会问为什么不用Spring Cloud或者微服务我的看法是毕业设计的第一目标是通过答辩第二目标是完整演示第三目标才是展示进阶能力。旅游网这个规模微服务反而会把复杂度拉高分布式事务、服务注册、链路追踪这些内容一旦写进项目里你要么讲不透要么因为环境问题演示不了。单体的Spring Boot项目完全可以支撑旅游网的并发需求把精力放在业务逻辑和代码质量上收益更大。后端分层上我建议严格做到Controller、Service、Mapper三层。Controller接收请求和参数校验Service处理业务规则Mapper负责数据库操作。避免在Controller里直接写业务逻辑或者把SQL堆在Service里这种代码当时感觉很爽后期改需求时就会很痛苦。前端则建议用Vue Router做路由管理Axios做HTTP请求封装Pinia或Vuex做状态持久化登录状态存到本地再结合路由守卫做页面访问控制。2.2 模块划分前台门户加后台管理如何铺开功能地图旅游网系统的功能划分基本可以归纳成一张表这也是我每次做需求分析时习惯用的方法。先把用户角色定义清楚再根据角色能做什么来拆分模块。角色功能模块核心操作游客旅游门户浏览景点、查看线路、搜索筛选、注册登录注册用户个人中心修改资料、收藏线路、下单预订、查看订单管理员后台管理维护景点信息、管理线路、审核订单、上传图片前台门户的重点是页面美观和信息展示效率。首页除了轮播图还要有热门景点、推荐线路、目的地分类导航列表页需要根据关键词、价格、目的地条件做筛选详情页要能展示多张图片、行程说明和预订按钮。这些页面看起来多但都在重复一套“列表详情”的模式写熟练后是可以复用的。后台管理的重点则是数据操作效率。用表格展示数据配合搜索框、分页和弹窗表单就可以完成对景点和线路的增删改查。订单管理需要用到状态标签例如待支付、已支付、已完成、已取消状态的切换要跟业务逻辑联动起来。再往上走还可以加一个统计面板用图表展示热门景点排名和每日订单量这一块可以作为答辩时的增量亮点因为很多人的毕业设计不做可视化。2.3 数据库设计几张表把旅游业务跑起来数据库是整个项目的地基地基不稳后面代码写得再好也会出问题。旅游网系统的核心表我建议设计成六张用户表、景点分类表、景点表、旅游线路表、订单表、收藏表。如果后续想增加评价功能再补一张评价表。这里先说说最关键的几个字段设计思路。用户表需要包含主键、用户名、密码、昵称、手机号、头像、角色、创建时间。密码一定要加密存放不要明文入库存至少用MD5加盐或者BCrypt。景点分类表很简单就是分类ID和分类名称两个核心字段。景点表要存储景点名称、所属分类、所在城市、景点简介、封面图片、详细内容和浏览量。旅游线路表是业务核心它要关联景点ID也要包含线路名称、行程天数、价格、出发城市、行程安排和发布状态。订单表要关联用户ID和线路ID包含订单编号、下单时间、出行日期、人数、总金额和订单状态。收藏表则通过用户ID和线路ID做联合唯一约束防止重复收藏。我在设计时特别强调一个问题图片资源到底存数据库还是存磁盘。很多同学喜欢把图片转成Base64塞进数据库这种做法在小项目里看起来方便但数据库很快会膨胀前端加载也会变慢。我推荐把图片文件存到服务器的某个目录下数据库里只存图片的访问路径例如/img/line/20230601xxxx.jpg。这样既保证了数据表轻量也方便以后扩展对象存储服务。3. 核心功能实现与实际编码要点3.1 登录注册与JWT权限控制登录注册是所有业务系统的入口旅游网也不能例外。在这个项目里我推荐用JWT来做身份认证而不是传统的Session。原因是前后端分离架构下后端接口不关心客户端是网页还是AppJWT把用户信息和过期时间保存在一串加密的Token里前端请求时在请求头带上Authorization字段后端通过拦截器统一校验即可。后端实现主要涉及三个类JWT工具类负责生成和解析Token拦截器负责拦截需要登录的接口WebMvcConfigurer负责注册拦截器并放行登录接口、首页接口和景点列表接口。生成Token时建议把用户ID和角色放进去这样后端在处理订单接口时可以直接从Token里拿到当前用户的ID不用前端每次额外传用户ID。这个设计不仅能减少参数传递也能防止用户越权访问他人的订单是一个很值得写进文档的亮点。前端要做的事情也不复杂。登录页面调用后端接口拿到Token后保存到localStorage新建一个Axios实例在请求拦截器里统一设置Authorization头。路由守卫里判断如果去个人中心或后台页面但没有Token就跳转到登录页。注销时移除本地Token并跳回首页。这些步骤是标准流程但很多新手会把Token存到Pinia里又忘了持久化一刷新页面就丢失登录状态这个小问题在答辩现场很容易暴露。3.2 景点与线路的展示、搜索和筛选旅游门户的浏览体验直接决定了系统的观感而这一块在技术上其实就是列表查询加上动态条件组合。后端写一个分页查询接口接收页码、每页大小、关键词、分类ID、城市、价格区间这些可选条件然后通过MyBatis Plus的LambdaQueryWrapper动态拼接查询条件。举个例子用户在前端搜索“三亚五日游”希望搜索结果里既有名称匹配的线路也包含目的地在三亚的线路。那么查询逻辑应该是在线路名称字段上做模糊匹配同时在城市字段上也做模糊匹配两个条件用OR连接。如果用户还选择了价格区间比如2000到4000那就在前一个条件基础上再用价格字段做AND条件。这种动态SQL的处理思路正是这类系统强调的逻辑。列表接口建议同时返回当前用户是否已收藏该线路的状态。做法是查线路列表时拿到线路ID集合再用当前用户ID去收藏表里查一遍得到已收藏的ID集合最后在返回结果里给每个线路标上一个isFavorite字段。很多教程会忽视这个细节但实际演示时用户点收藏按钮你会发现前后端联动全靠这个字段支撑。3.3 订单与收藏的业务逻辑细节订单是旅游网里最像真实业务的模块。用户从线路详情页选择出行日期和人数点击提交订单后端要做的操作包括查询线路价格、计算总金额、生成唯一订单编号、写入订单表并把线路的库存状态做对应修改。这里有一个容易被忽视的点也是答辩加分点下单接口要做好重复提交校验。比如前端按钮防抖只能防止用户连续点击后端最好加一个逻辑判断如果同一用户对同一条线路在短时间内已经存在一个待支付订单就返回提示而不是继续新建订单。收藏功能相对简单核心是收藏表的联合唯一约束。用户点击收藏时后端先检查记录是否已存在存在就删除不存在就插入本质上是一个反向操作。接口可以直接命名为toggleFavorite返回结果里带上当前是已收藏还是未收藏的状态。这个交互逻辑虽然一行状态判断就能完成但在前端体验上非常自然比“先取消收藏再重新收藏”的两段流程好得多。订单状态流转也要提前想清楚。比较稳妥的方案是给订单状态字段设置几个常量0表示待支付1表示已支付2表示已完成3表示已取消。用户只能对待支付订单发起取消管理员可以对已支付订单做确认操作。状态机提前画清楚代码写的时候就顺畅文档里也能画一张状态图这个内容答辩时能讲两分钟。3.4 后台管理的CRUD与图片上传后台管理界面用Vue加Element Plus实现是非常成熟的做法。表格组件绑定后端列表接口数据搜索区域绑定查询条件弹窗表单负责新增和编辑。这里的核心不是怎么写表格而是怎么保持代码整洁。我习惯把景点、线路、订单的管理页面都拆成独立的Vue文件公共的上传组件单独抽出去。每个页面只关注数据和表格列配置公共逻辑放到API模块里统一管理。图片上传是后台系统绕不开的功能。前端使用Element Plus的Upload组件设置action指向后端的/upload接口后端接收MultipartFile校验文件大小和扩展名生成随机文件名保存到本地指定目录并把访问路径返回给前端。需要注意开发环境里图片路径通常就是项目启动后访问的静态资源路径所以要在Spring Boot里配置静态资源映射把本地目录映射到/upload/这个虚拟路径。如果这个配置漏了前端会拿到一串图片地址但访问不到图片全部裂开演示时非常尴尬。4. 实操过程从零搭建一个可演示的旅游网4.1 开发环境准备与项目初始化开始动手前建议把环境统一好避免以后环境不一致导致的疑难问题。我常用的版本搭配是JDK 8或JDK 11Spring Boot 2.7.xMySQL 5.7或8.0Node.js 16以上Vue 3加ViteUI库用Element Plus。如果你习惯Vue 2也可以用Vue CLI加Element UI两种组合都能跑关键是别混着用。初始化后端时直接用Spring Initializr生成项目依赖勾选Spring Web、MySQL Driver、MyBatis Plus和Lombok。数据库连接配置写在application.yml里本地数据库先创建好例如travel_db字符集统一用utf8mb4时区设置为Asia/Shanghai。前期把连接串写好后面启动项目就不会频繁撞上时区报错。前端初始化建议用Vite执行npm create vite命令生成Vue项目然后安装vue-router、pinia和axios。这里有个经验安装依赖时要使用npm install而不是cnpm后者的依赖树在某些版本下会和Vite冲突导致项目启动异常。装完后第一步不是写页面而是把目录结构搭好views下面按模块分文件夹api下面按资源分文件router集中配置路由utils放Axios封装和公共函数。4.2 后端核心代码用户登录与线路查询示例后端代码我只挑两个关键的片段说明一个是登录接口一个是线路分页查询。完整源码结构其实遵循标准模板Controller层负责接收参数Service层处理逻辑Mapper层直接操作数据。登录接口的Service层大概是这样public String login(LoginDTO dto) { LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.eq(User::getUsername, dto.getUsername()); User user userMapper.selectOne(wrapper); if (user null || !passwordEncoder.matches(dto.getPassword(), user.getPassword())) { throw new BusinessException(用户名或密码错误); } return jwtUtil.generateToken(user.getId(), user.getRole()); }这个方法的思路很简单先按用户名查用户再比对密码比对成功就生成Token返回。密码用BCrypt加密所以比对时用passwordEncoder.matches方法。如果用户不存在或者密码不对直接抛自定义异常统一异常处理器会返回友好的错误提示而不是500错误页面。线路分页查询的Service层核心是动态条件拼接public PageResultLineVO pageLines(LineQuery query) { PageLine page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperLine wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(query.getKeyword())) { wrapper.and(w - w.like(Line::getName, query.getKeyword()) .or().like(Line::getCity, query.getKeyword())); } if (query.getCategoryId() ! null) { wrapper.eq(Line::getCategoryId, query.getCategoryId()); } wrapper.orderByDesc(Line::getCreateTime); lineMapper.selectPage(page, wrapper); return convertToPageResult(page); }代码量不大但已经把动态筛选和分页都涵盖了。你只要理解了这一段把同样的逻辑复制到景点管理、订单管理里后端大半功能就成型了。4.3 前端页面与接口对接从登录页到首页展示前端实现页面时我建议先做登录页和首页。登录页的逻辑是拿表单数据调后端登录接口成功后将Token存到localStorage再用router.push跳转到首页。这里有一个体验细节登录成功后最好刷新一下用户信息把用户名和角色存到Pinia里这样导航栏才能马上显示“欢迎XXX”而不是需要再手动刷新页面。首页展示则是调线路列表接口拿到数据后用卡片组件展示。如下图所示每张卡片包含线路封面、名称、天数、价格点击卡片跳转到详情页。Vue的模板语法就是这样接口返回什么页面就渲染什么。真正需要花时间的是把接口地址统一封装成函数不要在每个组件里直接写axios.get(http://localhost:8080/api/line/page)这种硬编码一旦后端端口变了全局到处都要改。Axios封装我也建议单独做。新建一个request.js创建实例后设置baseURL为/api请求拦截器统一加Authorization头响应拦截器把后端返回的code做统一判断。比如后端返回code为200表示成功code为401表示未登录这时前端就应该清理本地Token并跳转登录页。这种全局的响应处理能帮你省下大量重复的错误处理代码也为文档中“本项目实现了统一异常处理和登录拦截”这句话提供了真实支撑。4.4 数据初始化与前后端联调策略数据库脚本建议一次性写好包含建库、建表和基础数据。基础数据至少要有几个分类、十个景点和十条线路图片可以先使用网络占位图后期再替换成真实图片。我把这些初始化脚本保存成init.sql放进项目的数据库目录下文档里也写好说明。这样做的好处很明显无论换一台电脑还是在答辩现场重新部署只要执行一次SQL文件系统就能恢复到可演示的状态。联调时我的习惯是先把后端跑起来用Postman逐个测试接口确认返回格式符合预期再做前端页面。不要等所有页面写完了再一起联调那样排查问题会特别困难。前后端联调最常见的问题是跨域解决方法是在后端写一个跨域配置类允许本地前端的端口访问。如果前端端口是5173后端就放行这个来源。前端请求路径要注意接口地址不要带http://localhost:8080这个前缀直接写相对路径例如/api/line/page由Vite的代理配置转发到后端这样部署时不用修改前端代码只需要改代理配置或Nginx配置。5. 常见问题与避坑技巧实录5.1 跨域、拦截器与404问题跨域是我在指导项目时遇到最多的问题。前端请求后端莫名其妙报错浏览器控制台显示CORS错误基本就是后端没有配置跨域。解决办法有两个要么在后端写一个WebMvcConfigurer配置类全局放行要么在前端Vite配置里用proxy代理。我更推荐两者结合开发环境用代理部署后由Nginx做转发这样后端的跨域配置可以更严格安全性更高。拦截器导致的404比较隐蔽。如果你部署了拦截器但放行路径写错了前端明明请求的是存在的接口却总是返回404。这是因为请求被拦截器截住由于未通过校验直接返回前端看起来跟接口不存在一样。排查时先看后端日志有没有拦截器处理记录再逐字检查放行的路径规则。比如使用Ant通配符时要写/api/**而不是/api/*后者只能匹配一层路径。5.2 数据库连接、时区与中文乱码数据库问题也是高频故障点。启动后端报Communications link failure多半是MySQL没启动或者连接串里的端口写错。时区问题表现为时间字段差8小时解决方案是在jdbc连接串后面加上serverTimezoneAsia/Shanghai。中文乱码则通常是因为数据库字符集没有设置成utf8mb4或者建表时没有指定字符集。我的建议是建库时就执行CREATE DATABASE travel_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci后面基本不会再乱码。还有一个日常容易栽的坑MyBatis Plus打印的SQL日志里中文是正常的但前端查到的数据中文乱码。这种情况一般是前端项目文件的编码问题检查Vite配置中的charset或者确保编辑器文件保存为UTF-8。千万不要一条一条去改数据那是很笨的办法。5.3 前端打包与本地部署演示答辩前一天很多同学会发现开发环境跑得好好的项目打包之后白屏了。这通常涉及三个原因。第一Vite打包后的资源路径采用了绝对路径部署到非根路径时找不到JS和CSS文件需要在vite.config.js里设置base: ./。第二前端调用接口用的是开发环境代理打包后代理失效接口请求变成404解决办法是在生产环境配置里把接口地址改为后端的完整地址或者用Nginx统一转发。第三history路由模式在没有做服务器配置时刷新页面会404解决办法是改用hash模式或者在后端加一个路径转发规则。对于大多数毕业设计场景我推荐一个稳妥的演示方案后端打包成JAR包运行前端打包成静态文件再通过Nginx把前端和后端集成在一起。如果现场没有Nginx也可以直接用Spring Boot的静态资源机制把前端打包后的dist目录放进resources/static下这样整个系统就可以通过后端一个端口访问了。结束时给评委演示这个完整的部署链路本身就是加分项。项目扩展与我的几点建议最后再聊点题外话。旅游网系统做完之后如果你想让它从毕业设计变成简历作品我建议从三个方向做扩展。一是增加Redis缓存热点线路数据尤其适合在演示时说明“为什么排行榜接口更快”这样的问题。二是引入定时任务例如自动取消超时未支付订单这个逻辑虽然简单但用到Scheduled注解代码量不大又很有业务价值。三是增加一个数据可视化看板用ECharts展示订单趋势和热门景点排行会让整个项目立刻显得不一样。我个人的体会是毕业设计最怕的不是题目难而是你只做了一个“看起来能用但讲不出道理”的半成品。旅游网系统这个题目好就好在它的每个模块都能讲出实际业务逻辑每个技术点都能找到现实场景去对应。你在写代码时不妨每完成一个功能就停下来想三个问题这个功能解决什么问题为什么这么设计如果数据量变大还能不能撑住。带着这三个问题去做你的代码、文档和答辩都会顺畅很多。
