每年毕设季和课程设计选题的时候旅游管理网站都是Java方向出现频率最高的几个题目之一。这个项目看着普通但它把SpringBoot后端、Vue前端、MySQL数据库、前后端分离、登录鉴权、文件上传、订单状态流转这些实际开发里天天见的东西全部串起来了。所以不管你是为了应付课程设计、毕业设计还是想拿一个能写进简历的练手项目这个选题的性价比都非常高。这篇文章我会结合自己完整做一套旅游管理网站含文档PPT源码的实践过程把技术选型、数据库设计、后端实现、前端联调、答辩准备这些环节逐个展开。重点说清楚每一步为什么这么做以及实际开发里那些文档和教程不会告诉你的坑。1. 为什么旅游管理网站和技术选型绕不开SpringBootVue1.1 这个项目到底在练什么能力很多人觉得旅游管理网站就是简单的增删改查难度不大。这个判断只说对了一半。旅游管理网站的业务复杂度恰好卡在一个很微妙的位置它比纯粹的单表CRUD有深度但又不像电商系统那样需要处理秒杀、库存、支付回调等一堆高并发场景。这种比上不足、比下有余的特点决定了它是一个非常适合练手和展示的项目。实际开发中你会接触到几类核心问题。第一类是前后端数据交互前端通过HTTP请求调用后端接口后端返回JSON数据整个流程涉及请求参数校验、统一返回格式、异常处理。第二类是登录鉴权不同角色普通用户和管理员访问不同权限的资源需要一个可靠的Token机制来维持登录状态。第三类是业务状态流转一张订单从创建、支付、出行到完成中间的状态变化有自己的规则不能随意跳转。第四类是文件上传与静态资源访问线路图片和景点图片需要上传并回显。这些问题都是真正工作中会遇到的而且它们都藏在旅游管理网站这个看似简单的业务里。做完这个项目你基本就能理解一个典型的Web应用是怎么从零跑起来的。1.2 技术栈全景与版本选择主流的旅游管理网站项目前后端技术栈高度一致后端用SpringBoot前端用Vue数据库用MySQL。具体到我个人推荐的一套配置如下层面技术选型说明后端框架SpringBoot 2.7.x生态最成熟网上资料多踩坑容易搜到答案ORM框架MyBatis-Plus单表CRUD基本不用写SQL分页也方便数据库MySQL 5.7 / 8.0免费、稳定、课程设计的主流选择登录鉴权JWT无状态、前后端分离场景下的标准方案工具库Hutool日期、文件、字符串处理都能省不少代码前端框架Vue2 / Vue3取决于开发经验Vue2 ElementUI更稳Vue3 ElementPlus更新HTTP请求Axios统一封装请求拦截器、响应拦截器组件库Element UI / Element Plus后台管理界面直接用现成组件拼装版本上我建议优先选择SpringBoot 2.7.x而不是3.x原因很实际很多旧教程、依赖包和答辩现场的老师还停留在2.x的理解上3.x木解决了JDK版本和依赖兼容问题但对课程设计来说没有必须升级的价值。我自己做的时候用2.7.18配合JDK8整个过程几乎没遇到过环境层面的问题。前端的版本选择看个人基础。用Vue2 Element UI的优势是教程多、坑都被人踩平了用Vue3 Element Plus的优势是贴近现在企业的实际用工需求。如果你是要找工作建议用Vue3的语法写但选择Element Plus组件库的稳定版本。我一般在项目落地时用Vue2兼顾稳定和效率但代码注释里会把Vue3的对应写法标注出来这样面试时被问到也不会露怯。1.3 前后端分离与单体架构的边界SpringBootVue这种组合是典型的前后端分离架构。简单说后端只负责提供API接口和数据处理前端只负责页面渲染和用户交互两者通过JSON格式的数据交互前端可以通过npm run dev启动本地开发服务也可以通过npm run build打包成静态文件部署到Nginx。这种架构的第一个好处是开发互不阻塞——前端写页面不需要等后端写完接口只要约定好接口文档前后端就可以并行开发。第二个好处是职责清晰——后端专注于业务逻辑前端专注于交互体验。第三个好处是面试时有话讲——前后端分离本身就是一个可以展开聊很久的架构话题包括跨域问题、Token认证、部署方案。当然这里也要说句实在话对于课程设计这种体量的项目前后端分离确实会比服务端渲染的JSP方案多花一些时间尤其是跨域配置和Token维护这两个环节。但正因为多花了这些时间你能学到的知识面和简历上能写的东西也完全不一样。我的建议是别图省事用老旧的JSP方案既然选了SpringBoot线性技术栈就走完整的前后端分离流程。2. 数据库设计是旅游管理网站的地基2.1 核心业务表到底要建几张数据库设计是很多新手最容易糊弄过去的地方但偏偏答辩时老师最喜欢问。旅游管理网站的核心业务不复杂我建议至少包含以下几张表表名作用关键字段user用户表用户名、密码、昵称、头像、电话、角色scenic景点表景点名称、简介、详细描述、图片、所属城市travel_line旅游线路表线路名称、出发地、目的地、天数、价格、图片、简介、详细行程order订单表订单编号、用户ID、线路ID、出发日期、人数、总价、状态、下单时间comment评论表对应线路或景点、用户ID、评分、内容、评论时间favorite收藏表用户ID、线路ID、收藏时间我见过不少同学把景点和旅游线路混在一张表里结果后面前台展示和后台管理都变得很别扭。实际上这两个概念是分开的景点是一个具体的游览地点比如故宫旅游线路是一套完整的行程安排比如北京故宫八达岭长城三日游它内部会关联多个景点。具体到课程设计的体量若不涉及多线路关联多景点的复杂映射不做中间关联表问题也不大因为业务上通常是线路自己去描述行程内容。2.2 订单表设计的常见坑订单表是整个项目里业务逻辑最复杂的一张表也是最能体现你设计水平的地方。这里有两个我认为最关键的细节。第一个是订单编号不要用自增ID。订单编号需要用LocalDateTime加随机数生成一个唯一字符串类似20250512101234567890。原因是自增ID很容易暴露订单量也不利于后续扩展。第二个是金额字段不要用double、float一律用BigDecimal。这个坑我踩过一次之后记忆深刻浮点数在计算总价和退款金额时会有精度丢失的问题课程设计麻雀虽小五脏俱全老老实实上BigDecimal最安全。还有一个容易被忽视的设计是订单状态字段。我建议用int类型通过常量类统一管理状态值。比如0代表待支付、1代表已支付、2代表已出行、3代表已完成、4代表已取消。状态之间的流转有明确的限制已取消的订单不能变成已支付已支付的订单不能直接变成已完成。这些规则在Controller里要通过条件判断实现答辩时老师非常喜欢顺着这个点往下问。2.3 建表的细节与字段取舍数据库设计阶段的细节会直接决定你能不能少写几百行烂代码。我总结几个操作性很强的建议所有时间字段业务上需要精确到秒的用datetime只需要日期的用date。Java端用LocalDateTime或LocalDate对应避免使用java.util.Date那种老掉牙的写法。所有文本内容较长的字段比如线路详情和行程安排用text类型别用varchar(255)硬撑不然用户多输入几个字就直接报错。用户名、线路名称这些需要展示的文本字段注意设置合理的长度同时业务逻辑里做参数校验前后端双重校验。外键建议只在逻辑上保留关联关系物理上不建立外键约束。原因很简单课程设计的数据量不会产生不一致问题但物理外键会在后续做删除操作时带来一堆麻烦。每张表都加上create_time和update_time两个字段。MyBatis-Plus支持自动填充几乎不费事但有了这两个字段出问题时排查数据版本非常方便。3. 后端实现从分层架构到登录鉴权和核心接口3.1 Controller-Service-Mapper三层到底怎么拆SpringBoot后端代码的组织方式大部分人都会采用经典的Controller-Service-Mapper三层结构再加上entity实体包、common通用包和config配置包。我实际开发时的分包结构大致如下com.example.travel ├── controller // 接收前端请求返回结果 ├── service // 业务逻辑处理 │ └── impl // Service接口的实现类 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── common // 统一返回结果、异常处理、常量类 ├── config // 跨域配置、拦截器配置、文件上传配置 ├── utils // JWT工具类、文件工具类 └── TravelApplication.javaController层只负责参数接收和结果返回不写任何业务逻辑Service层才是真正干活的地方处理业务规则和事务Mapper层通过MyBatis-Plus提供的BaseMapper接口大部分单表操作都继承自这个接口不需要自己写SQL。举一个具体的例子用户在前台提交订单时Controller里的代码只有几行接收JSON参数、调用Service层、返回统一结果。真正复杂的业务逻辑——比如检查库存其实这里应该说是确认线路是否可预订、计算总价、生成订单编号、设置状态——都放在Service层里。这样做的好处是代码逻辑一眼能看明白答辩时候也能讲清楚你的设计思路。3.2 JWT登录鉴权的完整实现思路登录鉴权是前后端分离架构里最绕不开的一个环节。传统的Session方案在跨域场景下需要额外处理Cookie的传递问题而JWT方案无状态后端不需要保存登录态用户登录成功后拿到一个Token之后的每次请求在请求头里带上这个Token后端通过拦截器验证Token是否合法。实现步骤大致分四步登录接口校验用户名密码成功后生成JWT返回前端。前端拿到Token存到localStorage或sessionStorage中Axios每次请求自动在请求头加上Authorization: Bearer token。后端写一个HandlerInterceptor拦截器拦截除登录、注册等白名单之外的请求。拦截器中解析Token解析成功就把用户信息放进Request域失败则直接返回401状态码让前端跳转登录页。核心代码里比较关键的是JWT工具类以jjwt库为例生成Token的代码大致长这样public String createToken(Integer userId, String username) { // 设置过期时间为24小时 long expireTime 24 * 60 * 60 * 1000L; return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expireTime)) .signWith(SecretKeySpecUtil.getKey()) .compact(); }解析Token的代码则用Jwts.parserBuilder()读取签名成功则返回Claims对象失败则抛出ExpiredJwtException或SignatureException。这里要特别提醒一个新手容易忽略的点Token过期时间是24小时还是7天要根据实际使用场景决定。课程设计项目通常没有其他设备端踢人下线的需求设置24小时比较合适。但如果演示时间跨度长可以适当延长到7天。另外signWith方法在高版本jjwt中必须传入Key对象直接传入字符串会报错这一点如果你用的是较新版本的jjwt需要额外注意。3.3 统一返回结果和全局异常处理的写法这是个看起来不起眼但能迅速提升你代码质量的操作。我在项目里统一封装了一个Result类所有接口都返回同样的格式{ code: 200, message: 操作成功, data: {...} }code字段用200表示成功用400表示参数错误用401表示未登录用500表示服务器异常。前端拿到这个结构后先判断code是否为200是则处理data否则弹出message提示用户。这样做前后端联调时的沟通成本会低很多。配合失败情况还需要一个全局异常处理器。用RestControllerAdvice配合ExceptionHandler把所有异常统一拦截处理避免堆栈信息直接暴露给前端。我自己在项目中至少处理了三类异常业务异常、参数校验异常和兜底的Exception。这三个异常处理器写完之后Controller的代码终于变得非常干净——不需要每个接口都写try-catch了。3.4 文件上传与图片回显的配置陷阱旅游管理网站的前台页面和后台管理都要展示图片所以文件上传功能几乎是必修课。我的做法是后台管理系统上传图片到本地的upload目录然后把访问路径保存到数据库前端页面通过后端配置的虚拟路径映射来访问图片文件。后端配置虚拟路径映射的代码是通过WebMvcConfigurer的重写方法实现的Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadDir /); }这里有一个非常经典的问题addResourceLocations里的路径末尾必须带/否则映射失败。这个坑看文档时很容易忽略但实际配置时踩到的人非常多。另一种常见做法是把图片上传到Nginx的静态目录或者使用云存储服务原理上都是一样的核心就是给前端提供一个可以直接访问图片的URL。4. 前端Vue实现页面搭建、路由守卫与联调细节4.1 前端工程结构和请求封装Vue前端项目我建议按下面这种方式组织src ├── api // 每个模块的接口调用文件 ├── assets // 静态资源 ├── components // 公共组件 ├── router // 路由配置 ├── store // 状态管理或本地存储封装 ├── views // 页面组件 ├── utils // 请求封装、工具函数 ├── App.vue └── main.js其中utils/request.js是整个前端和所有对后端交互的出口使用Axios做了统一封装。核心逻辑如下请求拦截器从localStorage中取出Token有则添加到请求头中。响应拦截器判断HTTP状态码和业务状态码。业务状态码401说明Token失效清空本地存储并跳转登录页。使用ElMessage统一弹出错误提示页面组件中就不需要每个接口都重复写错误处理。这个封装写好之后每个页面调用接口只需要像这样// 获取线路列表 getTravelLineList(params).then(res { this.tableData res.rows; });当然这里有个需要注意的点Axios的then回调里拿到的已经是res.data.data还是整个响应对象取决于你响应拦截器里做了什么处理。我自己的习惯是响应拦截器里直接return response.data这样业务页面的代码更简洁但这个约定必须在团队内部统一否则前后端联调时会混乱。4.2 路由设计与权限控制前台部分需要页面首页、景点列表、线路列表、线路详情、登录注册、个人中心、我的订单、订单结算。后台管理需要的页面后台首页、线路管理、景点管理、订单管理、用户管理、评论管理。两者最好用不同的路由模块区分开比如前台访问路径不带前缀后台全部加/admin前缀。后台页面的权限控制通过Vue Router的路由守卫实现。在路由跳转之前先判断用户角色如果角色不是管理员直接跳回前台首页。代码写法如下router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path.startsWith(/admin) !token) { next(/login); return; } next(); });这个守卫逻辑虽然简单但它是面试时能说得清楚的完整权限方案基础。如果你还想加新功能可以进一步做动态路由和按钮级权限但课程设计做到路由级控制已经足够了。4.3 核心页面的实现逻辑以旅游线路详情页为例这个页面的核心交互是把选好的线路加入订单也就是立即预订。页面加载时调用后端接口获取线路详情展示线路图片、介绍、天数、价格。用户选择出发日期和出行人数后前端实时计算总价格点击预订后跳转确认订单页。确认订单页要注意的是价格应该以后端重新计算为准不能直接信任前端传过来的总价。前端页面适合做展示凡是涉及金额的地方都应该由后端根据线路单价和人数重新计算防止用户通过修改请求参数来篡改价格。这也是答辩时老师喜欢问的一个安全点。后台管理页面则主要用Element UI的表格组件。新增、编辑操作通过Dialog弹窗表单完成删除操作需要ElMessageBox.confirm做二次确认分页数据通过后端返回的总条数和当前页计算得出。这里配合后端使用的分页框架我在项目中用的是MyBatis-Plus的分页插件只需要在配置类里注册一个PaginationInnerInterceptor然后传入Page对象即可完成分页查询。5. 项目文档、PPT与源码交付的完整姿势5.1 文档部分应该覆盖哪些章节很多同学项目代码写完了但文档和PPT做得稀烂导致答辩分数直接腰斩。其实课程设计和毕业论文的文档结构有一个非常通用的模板旅游管理网站可以按照下面的章节来组织绪论项目背景、研究意义、国内外现状。这里不要空谈技术发展要结合旅游行业的信息化需求来说比如传统旅行社门店经营效率低、线上预订需求增长等。需求分析用文字配合用例图说明管理员和普通用户分别能做什么每个功能模块列出具体的功能点清单。系统设计系统整体架构图、业务流程设计、数据库ER图和数据表字段说明。系统实现按照模块逐个展示页面截图并结合关键技术代码做解释。系统测试测试环境、测试用例、测试结果。这个地方要写真实操作过的用例比如正常登录、错误密码、未登录访问后台、提交空表单等。文档有个容易被忽视的点截图一定要用你自己系统里真实运行的效果不要从别的文章里复制。答辩现场老师会直接打开系统验证你文档里写了什么功能系统里必须能找到对应的入口和结果。5.2 PPT的制作逻辑PPT不需要页数吓人但逻辑要连贯。我个人建议控制在15到20页左右每页解决一个问题。核心页面安排如下第1页项目名称、技术栈、你的姓名学号。第2-4页项目背景、研究意义、核心功能点。第5-6页技术选型重点写为什么选SpringBoot和Vue。第7-8页系统功能模块图用一张结构图展示前后台的所有功能。第9-10页数据库设计挑几张核心表展示字段和关系。第11-14页核心功能截图配合少量文字说明。第15-18页总结与展望以及你个人在本项目中负责的部分。PPT最重要的是少贴大段文字、多放运行截图。每个页面讲解时间大概在20到30秒全场控制在7分钟以内最稳妥。演示操作系统时提前准备好测试账号现场输入账号密码这种操作很容易浪费时间。5.3 答辩现场的高频追问清单答辩老师不一定仔细看过你的代码但他们很会根据项目名和技术栈问一些高频问题。以旅游管理网站配合SpringBootVue技术栈为例以下问题几乎必被问到为什么选择这个课题你的系统相比传统人工管理优势在哪数据库表结构为什么这么设计订单表和线路表之间是什么关系登录状态是怎么保持的JWT和Session的区别是什么如果用户量增大系统哪些地方会成为瓶颈前端路由守卫是怎么实现权限控制的如果不登录直接访问后台URL会发生什么订单的状态是怎么流转的哪些状态之间可以互相转换你用的分页插件原理大概是什么这些问题不需要面面俱到但至少要做到能听懂问题并且说出合理的思路。我自己当年就在如果用户量增大这个问题上吃了亏只会回答加缓存、加负载均衡但具体哪个模块最容易出问题、加什么缓存、负载均衡怎么部署完全答不上来。后来我把什么场景会导致性能下降、对应解决方案是什么在前后台各挑了一个核心模块讲清楚再遇到类似问题就自然多了。5.4 源码整理的最佳实践源码本身写得好不好是一回事看上去整不整齐是另一回事。答辩和面试时对方不一定有时间一行行读代码但一定会看你的项目结构是否规范。有几个细节特别能加分后端代码包名规范Controller、Service、Mapper分层明确实体类置于entity包不要把所有类都丢在一个包下面。代码中关键业务逻辑注释完整特别是登录鉴权、订单状态流转、文件上传、分页查询这几个核心功能点。前端代码建好api目录每个页面的接口调用集中放置不要在各个页面组件里散落原始的Axios调用。README.md文件写好项目介绍、环境要求、快速启动步骤、测试账号信息。这一步虽然不涉及业务代码但对于面试官或者导师快速上手你的项目来说非常关键也是体现工程素养的直接方式。项目压缩包按照源码、数据库脚本、文档、PPT、演示视频分目录放置不要全部堆在根目录下。数据库脚本尤其要注意导出的脚本要在另一台干净的电脑上能直接执行。很多同学的SQL脚本依赖于本地数据库的字符集或者少导了数据换了个环境就跑不起来。建议使用Navicat或MySQL自带的导出工具把CREATE DATABASE语句和USE语句都包含进去让别人拿到脚本后从零建库也能正常启动系统。6. 站在做完整个项目之后的视角复盘做旅游管理网站这个项目整体流程走下来其实并不复杂。最核心的工作量集中在两块一是数据库设计阶段表结构设计得合理后端业务逻辑能省很多事二是前后端联调阶段统一了接口格式和Token传递机制联调过程中的问题不会太多。剩下的大部分时间其实都花在测试流程、优化细节和准备文档材料上。我个人的建议是如果你时间有限优先保证核心链路是完整的用户能注册登录管理员能发布线路用户能下单。分页查询、评论、收藏、图片上传这些功能作为加分项可以在核心链路跑通后逐步补齐。不要一开始就想着把所有功能全部做完项目开发是一个不断迭代的过程核心功能能够稳定跑起来比功能列表写得好但实际上线一堆bug要重要得多。最后分享一个我做测试时会用的小技巧把游客、普通用户、管理员三个角色的账号在文档里单独列出来每测试一个功能前先明确当前登录的角色。很多前后端分离项目在联调阶段出现权限问题原因就是测试时用错了账号导致看到的数据范围不对误以为代码有bug。其实系统中的数据本身就有权限隔离逻辑游客看不到个人中心普通用户不能进后台管理管理员不能在前台下单——这些规则必须在测试前就心中有数。把角色账号准备清楚无论是在自己测试还是后来换了一台电脑重新演示都能帮你省下大量排查问题的时间。
SpringBoot+Vue旅游管理网站项目实战：前后端分离、JWT鉴权与数据库设计全解析
每年毕设季和课程设计选题的时候旅游管理网站都是Java方向出现频率最高的几个题目之一。这个项目看着普通但它把SpringBoot后端、Vue前端、MySQL数据库、前后端分离、登录鉴权、文件上传、订单状态流转这些实际开发里天天见的东西全部串起来了。所以不管你是为了应付课程设计、毕业设计还是想拿一个能写进简历的练手项目这个选题的性价比都非常高。这篇文章我会结合自己完整做一套旅游管理网站含文档PPT源码的实践过程把技术选型、数据库设计、后端实现、前端联调、答辩准备这些环节逐个展开。重点说清楚每一步为什么这么做以及实际开发里那些文档和教程不会告诉你的坑。1. 为什么旅游管理网站和技术选型绕不开SpringBootVue1.1 这个项目到底在练什么能力很多人觉得旅游管理网站就是简单的增删改查难度不大。这个判断只说对了一半。旅游管理网站的业务复杂度恰好卡在一个很微妙的位置它比纯粹的单表CRUD有深度但又不像电商系统那样需要处理秒杀、库存、支付回调等一堆高并发场景。这种比上不足、比下有余的特点决定了它是一个非常适合练手和展示的项目。实际开发中你会接触到几类核心问题。第一类是前后端数据交互前端通过HTTP请求调用后端接口后端返回JSON数据整个流程涉及请求参数校验、统一返回格式、异常处理。第二类是登录鉴权不同角色普通用户和管理员访问不同权限的资源需要一个可靠的Token机制来维持登录状态。第三类是业务状态流转一张订单从创建、支付、出行到完成中间的状态变化有自己的规则不能随意跳转。第四类是文件上传与静态资源访问线路图片和景点图片需要上传并回显。这些问题都是真正工作中会遇到的而且它们都藏在旅游管理网站这个看似简单的业务里。做完这个项目你基本就能理解一个典型的Web应用是怎么从零跑起来的。1.2 技术栈全景与版本选择主流的旅游管理网站项目前后端技术栈高度一致后端用SpringBoot前端用Vue数据库用MySQL。具体到我个人推荐的一套配置如下层面技术选型说明后端框架SpringBoot 2.7.x生态最成熟网上资料多踩坑容易搜到答案ORM框架MyBatis-Plus单表CRUD基本不用写SQL分页也方便数据库MySQL 5.7 / 8.0免费、稳定、课程设计的主流选择登录鉴权JWT无状态、前后端分离场景下的标准方案工具库Hutool日期、文件、字符串处理都能省不少代码前端框架Vue2 / Vue3取决于开发经验Vue2 ElementUI更稳Vue3 ElementPlus更新HTTP请求Axios统一封装请求拦截器、响应拦截器组件库Element UI / Element Plus后台管理界面直接用现成组件拼装版本上我建议优先选择SpringBoot 2.7.x而不是3.x原因很实际很多旧教程、依赖包和答辩现场的老师还停留在2.x的理解上3.x木解决了JDK版本和依赖兼容问题但对课程设计来说没有必须升级的价值。我自己做的时候用2.7.18配合JDK8整个过程几乎没遇到过环境层面的问题。前端的版本选择看个人基础。用Vue2 Element UI的优势是教程多、坑都被人踩平了用Vue3 Element Plus的优势是贴近现在企业的实际用工需求。如果你是要找工作建议用Vue3的语法写但选择Element Plus组件库的稳定版本。我一般在项目落地时用Vue2兼顾稳定和效率但代码注释里会把Vue3的对应写法标注出来这样面试时被问到也不会露怯。1.3 前后端分离与单体架构的边界SpringBootVue这种组合是典型的前后端分离架构。简单说后端只负责提供API接口和数据处理前端只负责页面渲染和用户交互两者通过JSON格式的数据交互前端可以通过npm run dev启动本地开发服务也可以通过npm run build打包成静态文件部署到Nginx。这种架构的第一个好处是开发互不阻塞——前端写页面不需要等后端写完接口只要约定好接口文档前后端就可以并行开发。第二个好处是职责清晰——后端专注于业务逻辑前端专注于交互体验。第三个好处是面试时有话讲——前后端分离本身就是一个可以展开聊很久的架构话题包括跨域问题、Token认证、部署方案。当然这里也要说句实在话对于课程设计这种体量的项目前后端分离确实会比服务端渲染的JSP方案多花一些时间尤其是跨域配置和Token维护这两个环节。但正因为多花了这些时间你能学到的知识面和简历上能写的东西也完全不一样。我的建议是别图省事用老旧的JSP方案既然选了SpringBoot线性技术栈就走完整的前后端分离流程。2. 数据库设计是旅游管理网站的地基2.1 核心业务表到底要建几张数据库设计是很多新手最容易糊弄过去的地方但偏偏答辩时老师最喜欢问。旅游管理网站的核心业务不复杂我建议至少包含以下几张表表名作用关键字段user用户表用户名、密码、昵称、头像、电话、角色scenic景点表景点名称、简介、详细描述、图片、所属城市travel_line旅游线路表线路名称、出发地、目的地、天数、价格、图片、简介、详细行程order订单表订单编号、用户ID、线路ID、出发日期、人数、总价、状态、下单时间comment评论表对应线路或景点、用户ID、评分、内容、评论时间favorite收藏表用户ID、线路ID、收藏时间我见过不少同学把景点和旅游线路混在一张表里结果后面前台展示和后台管理都变得很别扭。实际上这两个概念是分开的景点是一个具体的游览地点比如故宫旅游线路是一套完整的行程安排比如北京故宫八达岭长城三日游它内部会关联多个景点。具体到课程设计的体量若不涉及多线路关联多景点的复杂映射不做中间关联表问题也不大因为业务上通常是线路自己去描述行程内容。2.2 订单表设计的常见坑订单表是整个项目里业务逻辑最复杂的一张表也是最能体现你设计水平的地方。这里有两个我认为最关键的细节。第一个是订单编号不要用自增ID。订单编号需要用LocalDateTime加随机数生成一个唯一字符串类似20250512101234567890。原因是自增ID很容易暴露订单量也不利于后续扩展。第二个是金额字段不要用double、float一律用BigDecimal。这个坑我踩过一次之后记忆深刻浮点数在计算总价和退款金额时会有精度丢失的问题课程设计麻雀虽小五脏俱全老老实实上BigDecimal最安全。还有一个容易被忽视的设计是订单状态字段。我建议用int类型通过常量类统一管理状态值。比如0代表待支付、1代表已支付、2代表已出行、3代表已完成、4代表已取消。状态之间的流转有明确的限制已取消的订单不能变成已支付已支付的订单不能直接变成已完成。这些规则在Controller里要通过条件判断实现答辩时老师非常喜欢顺着这个点往下问。2.3 建表的细节与字段取舍数据库设计阶段的细节会直接决定你能不能少写几百行烂代码。我总结几个操作性很强的建议所有时间字段业务上需要精确到秒的用datetime只需要日期的用date。Java端用LocalDateTime或LocalDate对应避免使用java.util.Date那种老掉牙的写法。所有文本内容较长的字段比如线路详情和行程安排用text类型别用varchar(255)硬撑不然用户多输入几个字就直接报错。用户名、线路名称这些需要展示的文本字段注意设置合理的长度同时业务逻辑里做参数校验前后端双重校验。外键建议只在逻辑上保留关联关系物理上不建立外键约束。原因很简单课程设计的数据量不会产生不一致问题但物理外键会在后续做删除操作时带来一堆麻烦。每张表都加上create_time和update_time两个字段。MyBatis-Plus支持自动填充几乎不费事但有了这两个字段出问题时排查数据版本非常方便。3. 后端实现从分层架构到登录鉴权和核心接口3.1 Controller-Service-Mapper三层到底怎么拆SpringBoot后端代码的组织方式大部分人都会采用经典的Controller-Service-Mapper三层结构再加上entity实体包、common通用包和config配置包。我实际开发时的分包结构大致如下com.example.travel ├── controller // 接收前端请求返回结果 ├── service // 业务逻辑处理 │ └── impl // Service接口的实现类 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── common // 统一返回结果、异常处理、常量类 ├── config // 跨域配置、拦截器配置、文件上传配置 ├── utils // JWT工具类、文件工具类 └── TravelApplication.javaController层只负责参数接收和结果返回不写任何业务逻辑Service层才是真正干活的地方处理业务规则和事务Mapper层通过MyBatis-Plus提供的BaseMapper接口大部分单表操作都继承自这个接口不需要自己写SQL。举一个具体的例子用户在前台提交订单时Controller里的代码只有几行接收JSON参数、调用Service层、返回统一结果。真正复杂的业务逻辑——比如检查库存其实这里应该说是确认线路是否可预订、计算总价、生成订单编号、设置状态——都放在Service层里。这样做的好处是代码逻辑一眼能看明白答辩时候也能讲清楚你的设计思路。3.2 JWT登录鉴权的完整实现思路登录鉴权是前后端分离架构里最绕不开的一个环节。传统的Session方案在跨域场景下需要额外处理Cookie的传递问题而JWT方案无状态后端不需要保存登录态用户登录成功后拿到一个Token之后的每次请求在请求头里带上这个Token后端通过拦截器验证Token是否合法。实现步骤大致分四步登录接口校验用户名密码成功后生成JWT返回前端。前端拿到Token存到localStorage或sessionStorage中Axios每次请求自动在请求头加上Authorization: Bearer token。后端写一个HandlerInterceptor拦截器拦截除登录、注册等白名单之外的请求。拦截器中解析Token解析成功就把用户信息放进Request域失败则直接返回401状态码让前端跳转登录页。核心代码里比较关键的是JWT工具类以jjwt库为例生成Token的代码大致长这样public String createToken(Integer userId, String username) { // 设置过期时间为24小时 long expireTime 24 * 60 * 60 * 1000L; return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expireTime)) .signWith(SecretKeySpecUtil.getKey()) .compact(); }解析Token的代码则用Jwts.parserBuilder()读取签名成功则返回Claims对象失败则抛出ExpiredJwtException或SignatureException。这里要特别提醒一个新手容易忽略的点Token过期时间是24小时还是7天要根据实际使用场景决定。课程设计项目通常没有其他设备端踢人下线的需求设置24小时比较合适。但如果演示时间跨度长可以适当延长到7天。另外signWith方法在高版本jjwt中必须传入Key对象直接传入字符串会报错这一点如果你用的是较新版本的jjwt需要额外注意。3.3 统一返回结果和全局异常处理的写法这是个看起来不起眼但能迅速提升你代码质量的操作。我在项目里统一封装了一个Result类所有接口都返回同样的格式{ code: 200, message: 操作成功, data: {...} }code字段用200表示成功用400表示参数错误用401表示未登录用500表示服务器异常。前端拿到这个结构后先判断code是否为200是则处理data否则弹出message提示用户。这样做前后端联调时的沟通成本会低很多。配合失败情况还需要一个全局异常处理器。用RestControllerAdvice配合ExceptionHandler把所有异常统一拦截处理避免堆栈信息直接暴露给前端。我自己在项目中至少处理了三类异常业务异常、参数校验异常和兜底的Exception。这三个异常处理器写完之后Controller的代码终于变得非常干净——不需要每个接口都写try-catch了。3.4 文件上传与图片回显的配置陷阱旅游管理网站的前台页面和后台管理都要展示图片所以文件上传功能几乎是必修课。我的做法是后台管理系统上传图片到本地的upload目录然后把访问路径保存到数据库前端页面通过后端配置的虚拟路径映射来访问图片文件。后端配置虚拟路径映射的代码是通过WebMvcConfigurer的重写方法实现的Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadDir /); }这里有一个非常经典的问题addResourceLocations里的路径末尾必须带/否则映射失败。这个坑看文档时很容易忽略但实际配置时踩到的人非常多。另一种常见做法是把图片上传到Nginx的静态目录或者使用云存储服务原理上都是一样的核心就是给前端提供一个可以直接访问图片的URL。4. 前端Vue实现页面搭建、路由守卫与联调细节4.1 前端工程结构和请求封装Vue前端项目我建议按下面这种方式组织src ├── api // 每个模块的接口调用文件 ├── assets // 静态资源 ├── components // 公共组件 ├── router // 路由配置 ├── store // 状态管理或本地存储封装 ├── views // 页面组件 ├── utils // 请求封装、工具函数 ├── App.vue └── main.js其中utils/request.js是整个前端和所有对后端交互的出口使用Axios做了统一封装。核心逻辑如下请求拦截器从localStorage中取出Token有则添加到请求头中。响应拦截器判断HTTP状态码和业务状态码。业务状态码401说明Token失效清空本地存储并跳转登录页。使用ElMessage统一弹出错误提示页面组件中就不需要每个接口都重复写错误处理。这个封装写好之后每个页面调用接口只需要像这样// 获取线路列表 getTravelLineList(params).then(res { this.tableData res.rows; });当然这里有个需要注意的点Axios的then回调里拿到的已经是res.data.data还是整个响应对象取决于你响应拦截器里做了什么处理。我自己的习惯是响应拦截器里直接return response.data这样业务页面的代码更简洁但这个约定必须在团队内部统一否则前后端联调时会混乱。4.2 路由设计与权限控制前台部分需要页面首页、景点列表、线路列表、线路详情、登录注册、个人中心、我的订单、订单结算。后台管理需要的页面后台首页、线路管理、景点管理、订单管理、用户管理、评论管理。两者最好用不同的路由模块区分开比如前台访问路径不带前缀后台全部加/admin前缀。后台页面的权限控制通过Vue Router的路由守卫实现。在路由跳转之前先判断用户角色如果角色不是管理员直接跳回前台首页。代码写法如下router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path.startsWith(/admin) !token) { next(/login); return; } next(); });这个守卫逻辑虽然简单但它是面试时能说得清楚的完整权限方案基础。如果你还想加新功能可以进一步做动态路由和按钮级权限但课程设计做到路由级控制已经足够了。4.3 核心页面的实现逻辑以旅游线路详情页为例这个页面的核心交互是把选好的线路加入订单也就是立即预订。页面加载时调用后端接口获取线路详情展示线路图片、介绍、天数、价格。用户选择出发日期和出行人数后前端实时计算总价格点击预订后跳转确认订单页。确认订单页要注意的是价格应该以后端重新计算为准不能直接信任前端传过来的总价。前端页面适合做展示凡是涉及金额的地方都应该由后端根据线路单价和人数重新计算防止用户通过修改请求参数来篡改价格。这也是答辩时老师喜欢问的一个安全点。后台管理页面则主要用Element UI的表格组件。新增、编辑操作通过Dialog弹窗表单完成删除操作需要ElMessageBox.confirm做二次确认分页数据通过后端返回的总条数和当前页计算得出。这里配合后端使用的分页框架我在项目中用的是MyBatis-Plus的分页插件只需要在配置类里注册一个PaginationInnerInterceptor然后传入Page对象即可完成分页查询。5. 项目文档、PPT与源码交付的完整姿势5.1 文档部分应该覆盖哪些章节很多同学项目代码写完了但文档和PPT做得稀烂导致答辩分数直接腰斩。其实课程设计和毕业论文的文档结构有一个非常通用的模板旅游管理网站可以按照下面的章节来组织绪论项目背景、研究意义、国内外现状。这里不要空谈技术发展要结合旅游行业的信息化需求来说比如传统旅行社门店经营效率低、线上预订需求增长等。需求分析用文字配合用例图说明管理员和普通用户分别能做什么每个功能模块列出具体的功能点清单。系统设计系统整体架构图、业务流程设计、数据库ER图和数据表字段说明。系统实现按照模块逐个展示页面截图并结合关键技术代码做解释。系统测试测试环境、测试用例、测试结果。这个地方要写真实操作过的用例比如正常登录、错误密码、未登录访问后台、提交空表单等。文档有个容易被忽视的点截图一定要用你自己系统里真实运行的效果不要从别的文章里复制。答辩现场老师会直接打开系统验证你文档里写了什么功能系统里必须能找到对应的入口和结果。5.2 PPT的制作逻辑PPT不需要页数吓人但逻辑要连贯。我个人建议控制在15到20页左右每页解决一个问题。核心页面安排如下第1页项目名称、技术栈、你的姓名学号。第2-4页项目背景、研究意义、核心功能点。第5-6页技术选型重点写为什么选SpringBoot和Vue。第7-8页系统功能模块图用一张结构图展示前后台的所有功能。第9-10页数据库设计挑几张核心表展示字段和关系。第11-14页核心功能截图配合少量文字说明。第15-18页总结与展望以及你个人在本项目中负责的部分。PPT最重要的是少贴大段文字、多放运行截图。每个页面讲解时间大概在20到30秒全场控制在7分钟以内最稳妥。演示操作系统时提前准备好测试账号现场输入账号密码这种操作很容易浪费时间。5.3 答辩现场的高频追问清单答辩老师不一定仔细看过你的代码但他们很会根据项目名和技术栈问一些高频问题。以旅游管理网站配合SpringBootVue技术栈为例以下问题几乎必被问到为什么选择这个课题你的系统相比传统人工管理优势在哪数据库表结构为什么这么设计订单表和线路表之间是什么关系登录状态是怎么保持的JWT和Session的区别是什么如果用户量增大系统哪些地方会成为瓶颈前端路由守卫是怎么实现权限控制的如果不登录直接访问后台URL会发生什么订单的状态是怎么流转的哪些状态之间可以互相转换你用的分页插件原理大概是什么这些问题不需要面面俱到但至少要做到能听懂问题并且说出合理的思路。我自己当年就在如果用户量增大这个问题上吃了亏只会回答加缓存、加负载均衡但具体哪个模块最容易出问题、加什么缓存、负载均衡怎么部署完全答不上来。后来我把什么场景会导致性能下降、对应解决方案是什么在前后台各挑了一个核心模块讲清楚再遇到类似问题就自然多了。5.4 源码整理的最佳实践源码本身写得好不好是一回事看上去整不整齐是另一回事。答辩和面试时对方不一定有时间一行行读代码但一定会看你的项目结构是否规范。有几个细节特别能加分后端代码包名规范Controller、Service、Mapper分层明确实体类置于entity包不要把所有类都丢在一个包下面。代码中关键业务逻辑注释完整特别是登录鉴权、订单状态流转、文件上传、分页查询这几个核心功能点。前端代码建好api目录每个页面的接口调用集中放置不要在各个页面组件里散落原始的Axios调用。README.md文件写好项目介绍、环境要求、快速启动步骤、测试账号信息。这一步虽然不涉及业务代码但对于面试官或者导师快速上手你的项目来说非常关键也是体现工程素养的直接方式。项目压缩包按照源码、数据库脚本、文档、PPT、演示视频分目录放置不要全部堆在根目录下。数据库脚本尤其要注意导出的脚本要在另一台干净的电脑上能直接执行。很多同学的SQL脚本依赖于本地数据库的字符集或者少导了数据换了个环境就跑不起来。建议使用Navicat或MySQL自带的导出工具把CREATE DATABASE语句和USE语句都包含进去让别人拿到脚本后从零建库也能正常启动系统。6. 站在做完整个项目之后的视角复盘做旅游管理网站这个项目整体流程走下来其实并不复杂。最核心的工作量集中在两块一是数据库设计阶段表结构设计得合理后端业务逻辑能省很多事二是前后端联调阶段统一了接口格式和Token传递机制联调过程中的问题不会太多。剩下的大部分时间其实都花在测试流程、优化细节和准备文档材料上。我个人的建议是如果你时间有限优先保证核心链路是完整的用户能注册登录管理员能发布线路用户能下单。分页查询、评论、收藏、图片上传这些功能作为加分项可以在核心链路跑通后逐步补齐。不要一开始就想着把所有功能全部做完项目开发是一个不断迭代的过程核心功能能够稳定跑起来比功能列表写得好但实际上线一堆bug要重要得多。最后分享一个我做测试时会用的小技巧把游客、普通用户、管理员三个角色的账号在文档里单独列出来每测试一个功能前先明确当前登录的角色。很多前后端分离项目在联调阶段出现权限问题原因就是测试时用错了账号导致看到的数据范围不对误以为代码有bug。其实系统中的数据本身就有权限隔离逻辑游客看不到个人中心普通用户不能进后台管理管理员不能在前台下单——这些规则必须在测试前就心中有数。把角色账号准备清楚无论是在自己测试还是后来换了一台电脑重新演示都能帮你省下大量排查问题的时间。
