每到毕业设计选题季技术群里总有一群人在反复横跳做管理系统怕太水做商城感觉烂大街做算法类又担心撑不起前后端。如果你正在找一个既能覆盖Java后端、前端页面和数据库设计又不会把自己拖进地狱难度的方向SpringBootVueMySQL的旅游网站管理平台是值得认真考虑的一个选择。这个平台业务上围绕景点、旅游线路、团期和订单来转技术上把前后端分离开发、权限控制、文件上传、分页查询、事务和部署整条链路都串了起来无论应付毕设答辩还是作为一份作品写进简历都有东西可讲。这篇文章我不想写成“复制源码走一遍”的流水账而是想以一个实际带过这个题目的开发者视角把从选型到落地的关键决策、容易踩的坑、以及答辩时最容易被追问的细节都拆开聊一遍。1. 选型与定位这套技术组合的“正好够用”逻辑1.1 SpringBootMySQL把精力放在业务而不是配置上如果回到用传统SSH或者原生Spring MVC写项目的年代光是XML配置、数据源管理、事务配置就要耗掉大量时间。SpringBoot通过自动配置把这些变成了约定俗成的东西application.yml里写上数据库连接、端口和少量参数就能把项目跑起来。对毕设这种周期有限的场景这是最重要的时间节省。更重要的是SpringBoot在整个就业市场里的认知度非常高。答辩时无论老师问Spring的IOC、AOP还是问自动配置原理你都有现成的知识储备可以接住。如果你在这里选了一个特别小众的框架反而要花额外精力向老师解释“它是什么、为什么用它”解释成本一高答辩节奏就会被打乱。有人会问要不要直接上SpringCloud微服务我的建议是不要。微服务的核心是服务拆分、注册中心、配置中心、网关、降级限流这一堆东西而一个旅游管理平台的业务量级根本撑不起这些复杂度。硬拆出来的微服务在答辩时一旦被追问“服务拆分的边界是什么”“注册中心挂了怎么办”很容易把自己绕进去。选型不是越高级越好而是越匹配越好。1.2 Vue在前后端分离中的位置前端选Vue而不选其他框架核心原因在于生态完整、上手曲线温和。配合Element UI或Element Plus管理后台能在很短时间里搭出一套足够专业的界面表格、表单、弹窗、分页这些后台管理的高频组件都有现成方案。用户端的旅游展示页面也可以用组件化方式拆成导航栏、线路卡片、景点详情、订单步骤条等模块结构一目了然。如果学校课程还在教Vue2那就跟着学校版本走因为课设评分一般会参考课堂内容如果完全是自学选题直接上Vue3加组合式API。组合式API的setup语法让同一个功能的响应式数据、计算属性和方法集中在一块比Vue2的分散写法更容易读懂也更容易展示“我理解前端工程化”。1.3 为什么没有引入Redis、MQ这类中间件不是不能用而是分清主次。旅游平台的并发压力主要集中在下单和余位扣减这两个动作对毕业设计来说MySQL配合条件更新和事务完全能扛住。引入Redis做缓存、引入MQ做异步处理确实能让简历更好看但代价是多两套运维、多两套排错负担还要把“为什么必须用它们”想清楚。面试官最反感的一种情况是简历上写了Redis问缓存穿透怎么解决回答是“我复制了别人的配置”。如果时间不够宁可不加也不要让项目处于一种“依赖了很多中间件但讲不清非用不可”的状态。先把这个旅游平台做到逻辑闭环再去考虑加分项。选型定了以后接下来的关键问题就是平台的业务模块到底怎么拆才合理。2. 业务模块拆解用户端和管理端的边界划分2.1 核心实体关系景点、线路、团期、订单旅游平台最核心的实体是四张表景点、线路、团期、订单外加用户表。景点是基础资源一条旅游线路通常会包含多个景点一个景点也可能出现在多条线路里所以景点和线路是多对多关系一般需要一张线路-景点关联表来表达。线路本身是“商品模板”真正可售卖的是团期也就是某条线路在某一天出发还剩下多少名额。订单落在整个关系链的最末端由用户针对某个团期提交。这种从“资源”到“商品”到“库存”再到“交易”的分层模型很典型。很多初学者会犯的错是把出发日期、余位这些字段直接塞在线路表里。看起来省事可一旦线路包含多个出发计划整张表的数据就乱套了。把团期单独拆成一张表是这套设计里第一个值得在答辩时主动讲清楚的决策。2.2 用户端的操作闭环用户端面向普通游客功能可以概括为“逛、查、订、看”。逛是指浏览首页轮播图、景点列表和线路列表查是按名称搜索线路、查看线路详情和团期计划订是选择出发日期和出行人数填写联系人信息后提交订单看是在个人中心查看订单状态待支付订单可以取消或模拟支付。整个闭环不需要做得很复杂但必须完整。很多课设做到浏览就停了订单只是一个静态页面那答辩时会非常吃亏因为评委一定会追问“用户提交之后后台到底发生了什么”。哪怕支付只是模拟状态也要把“下单→扣余位→生成订单→后台可见→更新状态”这条链路跑通。2.3 管理端的权限与功能边界管理端做四块核心就够了内容管理负责景点、线路和轮播图的增删改查库存管理负责团期和余位的设置订单管理负责查看订单、确认订单、取消订单用户管理负责用户列表和账号状态。想进一步提升展示效果可以加一个统计面板显示订单总数、用户总数、待处理订单数这些数据直接查表count就能出来不需要额外依赖任何中间件。权限模型用两层就够普通用户只能访问用户端接口管理员可以访问管理端接口。不需要把权限设计成多角色的RBAC模型因为当前场景根本没有那么多角色和权限点。硬塞一个角色选择器进去反而会让自己陷入“设计了这个角色却不知道给什么权限”的尴尬。3. 数据库设计里最容易翻车的三个决策3.1 订单状态机的流转不要散落一堆if-else订单的status字段不要用int加注释去记更不要在每个接口里到处写if判断。推荐的做法是用一个枚举集中管理状态和流转规则。旅游平台的订单至少要包含以下状态待支付、已支付待出行、已完成、已取消。待支付只能流转到已支付或者已取消已支付只能流转到已完成已完成和已取消是终态不能再改。状态流转逻辑建议收口到枚举的nextStatus方法里Service层统一调用。这样在答辩时你可以很明确地说“状态是单向流转的每一种转换都是被枚举约束的”而不是“代码里几个if判断了一下”。如果考虑了退款可以把已支付待出行流转到已取消的同时做一次模拟退款但要注意这是简化方案真实业务还需要退款流水表。3.2 价格精度与余位并发控制价格字段必须用BigDecimal不要用double。double在表示小数时存在精度误差1块钱的0.1折价格算出来的结果可能是一长串奇怪的小数钱一旦出现精度问题就是硬伤。MySQL侧对应字段使用decimal(10,2)Java侧使用BigDecimal接收前端展示时再处理小数位。余位控制是另一个高频追问点。多人同时下单怎么避免超卖最稳妥的写法是条件更新把扣减动作约束在一条SQL里完成。UPDATE t_line_schedule SET booked_seats booked_seats 1 WHERE id #{scheduleId} AND booked_seats total_seats受影响行数为1说明扣减成功继续创建订单受影响行数为0说明余位已经满了抛出“该团期余位不足”的提示。这种写法比“先查余位判断后再更新”更安全因为查询和更新之间的时间窗口就是并发问题的温床。配合Transactional事务这条SQL就能作为答辩中“防超卖”的核心论据。3.3 时间、图片、字符集三个隐藏坑时间字段优先使用LocalDateTime不要再使用java.util.Date。MySQL侧存datetime接入层通过Jackson配置统一序列化成“yyyy-MM-dd HH:mm:ss”前端展示时才不会出现时间偏移8小时的问题。如果坚持用Date务必保证数据库连接的serverTimezone和运行环境的时区一致否则排查起来很头疼。我实际遇到过客户端显示时间比正常时间多了8小时翻到最后才发现是连接参数没有指定serverTimezone。图片字段存的是路径不是图片本身。上传的图片重命名后保存在服务器指定目录数据库只存相对路径或访问URL前端通过后端映射或Nginx直接访问。千万不要把图片转成Base64再塞进数据库那种做法会让表变得又大又慢后期导数据都是噩梦。字符集方面建库时就指定utf8mb4否则部署到Linux后中文变成问号的问题会反复出现。4. 后端编码的关键骨架登录认证、统一返回体、条件分页和下单事务4.1 JWT登录与传统Session方案的取舍旅游平台采用JWT做无状态认证是性价比很高的选择。用户登录成功后后端签发一个带过期时间的token前端保存起来后续请求放到Authorization请求头里后端用拦截器解析并确认身份。相比Session方案JWT不依赖服务端的内存和Session存储以后想把接口开放给小程序端同一套登录认证逻辑可以直接复用不需要改后端。实现时要注意三个细节。第一拦截器不仅要验证token是否有效还要做角色判断管理端接口必须校验当前用户是管理员第二公开接口比如首页、景点列表、登录注册要放进白名单否则用户没登录连网站首页都打不开第三处理跨域时要对OPTIONS预检请求放行这个后面会单独讲。签名算法用HS256就够了密钥放在配置文件里不要为了追求“高级”而引入复杂的密钥管理给自己增加没必要的工作量。4.2 统一返回体、全局异常与分页插件后端接口不要散装返回各种Map定义一个Result 容器包含code、message、data三个字段业务成功返回200和真实数据业务失败抛异常由全局异常处理器统一转换成错误信息。前端axios拦截器只需要处理这一种结构代码会清爽很多。业务异常建议单独封装一个BusinessException在Service层需要中断逻辑时直接throw由RestControllerAdvice捕获后返回给前端。分页查询用MyBatis-Plus的分页插件但有一个非常容易漏掉的配置必须在配置类里注册PaginationInnerInterceptor。很多新手导入了MyBatis-Plus却不注册分页插件分页查询返回的total永远是0Page对象里只有当前页数据前端分页组件就失去了总页数。多条件搜索建议用LambdaQueryWrapper配合StringUtils判断条件是否加入避免写一长串if-else。下面这段代码是线路列表的典型写法LambdaQueryWrapperTravelLine wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), TravelLine::getName, keyword) .ge(minPrice ! null, TravelLine::getPrice, minPrice) .le(maxPrice ! null, TravelLine::getPrice, maxPrice) .eq(StringUtils.isNotBlank(city), TravelLine::getDepartureCity, city) .orderByDesc(TravelLine::getCreateTime); PageTravelLine page lineService.page(new Page(pageNum, pageSize), wrapper);Controller只负责接收参数查询条件的组装和分页逻辑下沉到Service层结构清晰答辩时也更好解释。4.3 下单事务的执行顺序与订单快照下单接口是后端业务的核心逻辑顺序很关键。第一步根据前端传来的团期ID查出团期数据判断出发日期是否在当前日期之后第二步根据出行人数计算订单金额第三步执行带条件的余位更新校验受影响行数第四步插入订单记录订单里冗余保存线路名称、出发日期、单价、总价等信息整个过程加上Transactional任何一步异常都回滚余位扣减。订单快照这个点很多人忽略。如果订单表只存线路ID管理端后续修改了线路价格历史订单的展示也会跟着变化这显然不符合业务逻辑。订单必须保留下单那一刻的关键信息这是关系型数据库设计里很重要的冗余思想值得在答辩时主动讲。图片上传接口也用MultipartFile接收文件校验文件类型和大小上限重命名为UUID加后缀存到指定目录后返回访问路径数据库只保存这个访问路径。5. 前端Vue工程化的落地细节路由守卫、请求封装与列表页写法5.1 目录划分与路由规划前端项目按功能把目录分成用户端和管理端两块。src/views下面至少要有首页、景点、线路、订单、个人中心这些页面目录管理端则是admin/scenic、admin/line、admin/order、admin/user等。路由表全部静态声明管理端路由统一挂在AdminLayout下通过路由守卫统一拦截不需要做动态路由权限。只有管理员和普通用户两档角色动态路由的收益太小反而增加实现复杂度。页面组件建议按业务拆分导航栏组件、线路卡片组件、订单状态标签组件都单独放。这样用户端和管理端复用组件时只需要传不同的数据避免了在多个页面里复制粘贴大段模板代码。组件化的意义不单是让代码更短而是让某个功能有了唯一的修改入口。5.2 路由守卫与Axios请求拦截用户没有登录时可以浏览景点和线路但进入个人中心和下单页就必须登录。路由守卫在beforeEach里判断目标路由的meta.requiresAuth必要时检查本地存储里的token没有就跳转登录页。登录成功后把用户基本信息也写入本地存储页面顶部显示头像和昵称刷新后不丢失这个小优化能明显提升演示体验。axios封装是前端工程的必修课。创建一个axios实例并配置baseURL请求拦截器从本地存储取token放到Authorization头响应拦截器统一处理后端返回的Result结构如果code不是200使用组件库的Message或ElMessage提示后端返回的message如果遇到401则清理token并跳转登录页。这样每个页面里的接口调用都只关心正常的业务数据不用重复写错误弹窗。5.3 列表展示、服务端分页与状态标签线路列表和管理端订单列表面临同一个问题数据量一大不能一次查全。前端分页组件把当前页码和每页条数传给后端后端做服务端分页返回total和当前页记录。这个“为什么不在前端一次查全”的问题在答辩中出现的频率很高回答思路是服务端分页减少网络传输数据量、提升响应速度也避免前端渲染大量DOM导致卡顿同时分页本身是后端对大批量数据的通用控制手段。订单状态标签这种重复展示的逻辑建议封装成一个组件传入状态值渲染对应的颜色和文案。管理端多处使用的景点选择器、线路选择器也抽成组件接口字段变动时只改一处。页面表单要同时做前端校验和后端校验前端校验拦住大多数不符合规则的提交后端校验兜底保证接口安全这两层不能省。6. 联调、部署与答辩展示阶段的经验沉淀6.1 跨域问题的两种解决路径前后端分离项目必须要处理跨域。开发环境最简单的前端代理方案配置Vite或webpack的proxy把以/api开头的请求代理到本地Java服务端口开发时完全不用在后端操心跨域。生产环境用Nginx反向代理转发/api请求到Java服务Nginx本身就绕开了浏览器同源策略的限制后端甚至可以不配置跨域。如果坚持在后端配置CORS注意当需要携带凭证时不能使用allowedOrigins(*)要改用allowedOriginPatterns指定允许的来源模式否则浏览器会拦截响应。这个细节经常表现为前端控制台报CORS错误但后端日志显示接口已经执行了其实就是响应在浏览器侧被拦截了。6.2 从本地到服务器的部署操作清单部署可以拆成四步前端构建、后端打包、环境配置、服务托管。前端执行npm run build把dist目录放到Nginx的html目录并配置一条把/api路径代理到SpringBoot服务的规则后端用Maven打成可执行jar通过systemd注册一个服务设置开机自启和异常自动重启避免进程意外退出后还要手动拉起。配置文件用spring.profiles.active区分开发和生产环境生产配置里数据库地址、文件上传路径、JWT密钥都要单独设置不要把本地账号密码带到线上环境。Linux服务器上最容易忽略的是三个点。第一是时区系统默认的UTC会导致时间显示偏差启动脚本里要显式指定时区第二是字符集连接参数里需要指定UTF-8和服务端时区否则中文乱码问题会反复出现第三是静态资源目录权限Java进程必须对上传目录有写权限否则图片传不上去接口却一直报别的错误排查半天才发现是权限问题。6.3 答辩演示的流程和“话术”准备演示顺序建议这样安排先走用户端全流程从注册或登录开始浏览景点线路、搜索筛选、进入线路详情查看团期余位、选择日期和人数组装订单、提交后到个人中心看状态变化然后切到管理端找到刚才这笔订单做确认和状态更新再演示景点和线路的增改。这样评委看到的是一套完全打通的链路而不是两个孤立的界面。还要准备若干高频问题JWT和Session的区别是什么超卖问题是怎么解决的为什么订单表要冗余快照字段为什么分页必须做在后端图片为什么不存入数据库MySQL以后数据量变大了怎么办。每一个问题都可以从前面章节的决策理由里找到答案用自己的话整理一遍比背概念有用得多。6.4 收尾一点个人体会这几年带题目的体会是类似的项目拉开差距的地方不在功能多少而在细节深浅。你能把订单状态流转讲清楚把余位条件更新讲明白把订单快照字段的原因说透比堆十个半成品模块更有说服力。后续想扩展的话建议不要急着加秒杀或者推荐系统先从订单导出、线路收藏、多条件搜索优化这种能快速看到效果的小功能入手每加一个就让它真正跑通、讲得明白这个项目的价值会一点点积累起来。