1. 项目概述这是一个什么样的系统先把这个项目的定位说清楚。市面上提到婚庆服务大部分人的第一反应是婚纱摄影、婚宴酒店、司仪跟妆但伴娘伴郎这一环长期处于非常尴尬的位置——新人需要找靠谱的伴娘伴郎但渠道极其有限只能靠亲戚朋友硬凑而很多有经验、有时间、愿意接单的伴娘伴郎又没有一个能被新人看到的地方。这个毕业设计要解决的正是这个信息撮合问题。从技术形态上看这是一个典型的前后端分离架构项目后端用SpringBoot提供RESTful API前端用Vue.js构建单页应用两者通过JSON数据交互。用一句大白话总结后端只管数据和业务逻辑前端只管页面渲染和用户交互互不掺和。这种架构的好处后面我会详细讲但先记住一点——它能让你以几乎为零的成本把同一个后端同时服务Web端、小程序端、App端这在求职面试时是非常加分的项目亮点。从业务形态上看系统核心围绕三类用户展开普通访客可以浏览伴娘伴郎信息注册后的用户分两种身份——服务人员可以发布自己的接单信息客户可以发布需求、预约心仪人选。平台从中做撮合、管订单、收评价形成一个完整闭环。适合谁参考如果你是计算机相关专业的应届生正在为毕业设计选题发愁或者你想在简历里加一个真实业务场景 主流技术栈的项目这个题目都是非常理想的选择。它不是那种教科书式的CRUD管理系统而是带着真实商业模式的服务撮合平台业务逻辑有一定的复杂度用来展现你的设计能力正好合适。2. 技术选型为什么偏偏是SpringBoot Vue.js2.1 SpringBoot 3.x版本选择的血泪教训先聊聊后端。搜索结果里有一个热搜词特别扎眼springboot版本太高。这不是段子是无数应届生踩过的坑。如果你打算做这个课题我的建议是如果不是为了秀新技术老老实实用Spring Boot 2.7.x。原因很现实。很多网上的教程、毕设参考代码、甚至是你在CSDN找到的现成代码片段都是基于Spring Boot 2.x写的。Spring Boot 3.0开始强制要求JDK 17并且把大量旧版本的API标记为废弃或直接移除比如javax.*命名空间变成了jakarta.*。你想象一下这个场景你在网上抄了一段很完美的工具类代码粘进项目里结果报错无法解析javax.servlet.http.HttpServlet——这种错误对新手来说是致命的因为你根本不知道问题出在哪个环节。我个人的建议组合是JDK 8 Spring Boot 2.7.18。这个版本是Spring Boot 2.x系列的最后一个维护版本稳定、资料多、坑少对毕业设计来说完全够用。如果你胆子大想用JDK 17 Spring Boot 3.x也可以但你要做好遇到问题百度不到答案的心理准备。2.2 Vue 2还是Vue 3这是个问题前端框架的选择同样让人纠结。Vue 3已经是绝对的主流了但这里我要说句得罪人的话如果你之前只学过Vue 2毕业设计的时间又紧Vue 2.7也是一个可以接受的选择。为什么因为Vue 2的生命周期、组件通信、路由配置教程多到你根本看不完而Vue 3的组合式API虽然在工程上更优雅但很多新手刚接触会觉得怎么和我学的不一样。不过这里也有个折中方案Vue 3的写法其实可以在绝大多数场景下沿用Vue 2的选项式APIOptions API也就是说你只需要安装Vue 3的环境代码照样按老写法来照样能跑。我自己更倾向推荐Vue 3 Element Plus的组合。原因有两个一是Element Plus是Element UI的升级版组件风格清爽做后台管理界面非常合适二是答辩时面试官问你为什么用Vue 3你可以说出响应式系统基于Proxy实现、更好的TypeScript支持、组合式API提升了代码复用性——这些话往那一放显得你有跟进前端技术演进的能力。2.3 前后端分离到底好在哪说到前后端分离很多同学只是知道这个词但说不清楚它解决了什么问题。我打个比方传统开发模式比如用Thymeleaf服务端渲染就像一家餐厅从买菜、切菜、炒菜到上菜全在后厨完成顾客只能吃到最终成品。前后端分离则像中央厨房和门店分离——中央厨房后端统一做好半成品并通过接口配送门店前端负责按顾客喜好组装摆盘。这套模式有几个实打实的好处第一团队协作效率高。前端工程师不用关心SQL怎么写后端工程师不用纠结按钮颜色用什么色值各干各的最后以接口文档为依据联调。第二扩展灵活。你的后端接口设计得足够规范以后如果学校要求你又做一个微信小程序版本你可以直接复用同一套API只需要写一个新的前端界面。第三职责清晰更容易排查问题。接口返回的数据不对那就查后端页面按钮点了没反应那就查前端不用在混杂的模板代码里大海捞针。3. 需求分析把拍脑袋的需求变成功能模块3.1 用户角色与核心痛点做毕业设计最容易犯的错就是一上来就建表写代码。正确的姿势是先花一天时间把用户故事画清楚。我帮你们把需求理了一遍普通游客可以浏览服务列表、看服务详情和评价想使用完整功能需要注册登录。服务人员伴娘/伴郎这是系统的供给方。他们的痛点是我有时间有经验怎么让新人发现我。所以系统要给他们提供一个完善的主页展示功能包括个人资料、服务风格、档期状态、历史评价。客户新人这是需求方。他们的痛点是怎么快速找到档期合适、风格匹配、靠谱可信的人。系统要提供多维度的检索筛选、档期核对、以及基于评价的参考信息。平台管理员负责审核服务人员上传的资料、管理用户状态、处理举报投诉、统计平台数据。3.2 四大核心业务模块基于上面的角色和痛点系统可以划分为四个核心业务模块。第一是用户模块。包含注册、登录、个人信息维护。注意设计两个细节一是用户注册后默认是客户身份需要申请才能切换为服务人员二是登录状态用JWT管理无状态、跨域方便。第二是服务管理模块。服务人员发布服务信息包括但不限于服务类型伴娘/伴郎/领掌、档期日期、所在城市、服务报价、个人介绍、照片。这里有一个比较关键的状态设计——服务信息需要经过管理员审核才能上架避免垃圾信息和虚假报价。第三是订单撮合模块。这是整个系统的业务核心。客户浏览服务列表后选定心仪的伴娘发起预约请求订单状态为待确认伴娘在自己后台查看请求确认档期无误后接受订单状态变为已确认服务完成后客户确认完成状态变为已完成。整个状态流转必须覆盖所有异常分支客户取消、伴娘拒绝超时未处理等。第四是评价反馈模块。订单完成后客户可以对服务人员进行评分和文字评价评价内容将实时展示在服务人员主页。这个模块虽然技术实现简单就是一个关联表的增删改查但它是整个系统的信任基石业务价值最高。3.3 非功能性需求除了功能还有几个看不见但同样重要的需求性能方面伴娘服务列表页的加载速度直接影响用户体验。数据库查询务必加上分页照片信息最好走OSS或用相对路径静态资源映射避免把图片存成Base64字符串塞进数据库——那会让单页查询慢到怀疑人生。安全方面密码必须用BCrypt加密存储不能用MD5。接口需要做登录拦截服务人员只能操作自己发布的记录普通用户不能调用管理员接口。界面方面婚庆主题的视觉风格整体要偏温暖柔和主色调建议用玫瑰金或者香槟色搭配白色让人一看就觉得是婚庆平台。这是加分项尽量不要用默认的蓝白色后台模板直接交差。4. 数据库设计六张核心表的来龙去脉4.1 设计原则数据库设计是整个项目的地基。地基打歪了后面写代码会处处别扭。我的建议是先画出简易的ER图理清实体和关系再动手建表最后用SQL脚本把表结构固化下来。核心实体有六个用户表user、服务信息表service_info、订单表order_info、评价表comment、收藏表favorite、管理员相关的表可以并入用户表用角色字段区分。4.2 用户表与角色设计用户表是所有表的核心我给出一个通用设计思路userid、username、password、phone、roleUSER/ADMIN、status这里有两个容易踩坑的点。一是角色和身份的分离我建议用role字段区分登录用户的系统权限普通用户 vs 管理员另加一个user_type字段区分用户的服务者/客户身份或者用is_server布尔字段比如一个用户登录系统是普通用户同时他也可以是服务提供者这并不冲突。二是status字段推荐用0正常、1封禁不要用-1因为-1通常留给已删除含义混着用后面写业务逻辑容易晕。4.3 服务信息表与档期设计服务信息表是业务的核心表字段大致如下user_id关联用户表service_type服务类型伴娘、伴郎、领掌city所在城市price服务价格这里定义为每次服务费用description个人介绍photos服务照片URLstatus审核状态0待审核1已上架2已下架3审核驳回view_count浏览热度这里我想强调一个容易被忽略的设计档期schedule字段。很多人会把档期设计成文本字符串比如2024年5月有空这是大忌。因为文本无法参与查询无法判断2024-05-20是否已被占用。正确做法是单独建一张档期表按天存储scheduleid、user_id、service_id、available_date、status0空闲 1已锁定这样客户在预约时系统就能先过滤掉目标日期不可用的服务人员从源头避免订单冲突。这个细节在你的论文里和答辩中都非常值得展开讲因为它体现的是业务深度。4.4 订单表与评价表订单表的关键是状态流转日志。建议建表时顺便加一张order_log表记录每次状态变更的操作人、时间、变更前后状态。这是很多初级工程师不会设计的点但它价值极高——遇到纠纷时可以还原整个流程评优答辩时也是很好的亮点。评价表相对简单关键字段order_id关联订单、service_user_id被评人、rating1-5星、content文字评价、create_time。一个常见约束是一个订单只能评价一次可以在订单表上加一个comment_status字段或者在评价表给order_id建唯一索引两种方案都行。5. 前后端分离实操从初始化到核心功能落地5.1 后端项目初始化搭建后端项目时我推荐两种方式一是Spring Initializrstart.spring.io在线生成。这种方式的好处是依赖版本由官方帮你匹配好。选择项目参数时注意Java选8如果你用Spring Boot 2.x依赖勾选Spring Web、MyBatis或Spring Data JPA、MySQL Driver、Lombok。二是直接用IDEA内置的Spring Initializr。和在线版一样只是集成在了IDE里面少一步下载解压的流程。项目结构我建议这样划分com.example.wedding ├── controller ├── service ├── mapper ├── entity ├── common统一返回结果、异常处理、JWT工具类 └── config跨域配置、拦截器配置这个包结构很常规不要尝试在毕业设计里引入DDD分层或者微服务拆分那是给自己找麻烦。5.2 跨域配置前后端联调的第一道坎前后端分离项目几乎必然遇到跨域问题。原理不多说了你只需要知道浏览器会有同源策略协议、域名、端口任意一项不同都会触发限制前端页面在localhost:8080后端接口在localhost:9090端口不同就是跨域。解决方式有两种。一种是前端用Vite/Webpack配置代理把/api请求转发到后端这种方式只在开发环境有效。另一种是后端配置全局CORS让后端主动放行跨域请求。我推荐两者配合开发环境用Vite代理生产环境部署时用Nginx统一转发。但是如果你图省事只在后端加一个WebMvcConfigurer重写addCorsMappings方法也完全应付得了毕业设计的场景。这里给一份可以抄作业的后端CORS配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意两点一是allowCredentials(true)表示允许携带Cookie凭证但如果你用JWT存在请求头里其实可以不设这个避免和allowedOrigins(*)冲突二是不要图省事直接把allowedOrigins设为*同时又开allowCredentials部分浏览器版本会直接给你报错。5.3 统一返回格式与异常处理前后端分离后接口的返回格式必须统一否则前端没法写统一的响应处理逻辑。我建议定义一个Result类Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ... } public static T ResultT error(String message) { ... } }约定code200成功code500系统异常code401未登录或登录过期code403无权限。有了这个统一格式前端axios拦截器只需要判断code不等于200就弹错误提示逻辑非常清爽。异常处理上用RestControllerAdvice做全局异常拦截。重点是把业务异常比如该日期已被预约和系统异常区分开。业务异常用自定义枚举或自定义异常类抛出全局处理器捕获后返回对应code系统异常统一返回服务器开小差了不要把SQL报错堆栈直接返回给前端——那既是安全隐患也很掉价。5.4 前端核心页面落地前端项目的创建推荐用npm create vitelatest模板选择Vue 3。依赖安装除了vue-router和pinia或Vuex外还有axios和element-plus。核心页面至少需要这几个首页服务人员推荐列表 搜索栏按城市、服务类型、价格区间筛选服务详情页个人展示、服务介绍、档期日历、评价列表、预约按钮个人中心我的预约客户视角、我收到的预约服务人员视角、我的服务管理后台管理页用户管理、服务审核、订单管理、数据统计这里给一段前端调用后端接口的示例搜索服务列表// api/service.js import request from /utils/request export function getServiceList(params) { return request({ url: /api/service/list, method: get, params }) }axios实例里配置baseURL为/api开发模式下利用Vite的代理把请求转发给后端后端接口路径全部以/api开头这也方便将来部署时用Nginx做路径转发。接口路径统一带/api前缀这个习惯很多人初学时不注意后面部署上线时就会到处踩坑。至于登录状态的前端控制推荐的做法是请求拦截器里从localStorage取JWT token放到Authorization请求头里响应拦截器里遇到401就清除本地登录信息并跳转登录页。这样一个全局的登录防护就搭好了不需要在每一页都写判断逻辑。6. 关键业务逻辑订单状态机与防重并发6.1 订单状态机的设计订单模块是整个系统里最容易写乱的部分因为它的状态字段不止一个。我建议用一张图把状态流转理清楚这里用文字描述等待确认0 - 已确认1 - 已完成2 - 已评价3等待确认0 - 已取消4 客户取消等待确认0 - 超时未接5 服务人员超过48小时未处理已确认1 - 进行中6 服务当天标记为已开始服务进行中6 - 已完成2我在代码里通过一个OrderStatusEnum来统一管理public enum OrderStatusEnum { WAITING_CONFIRM(0, 待确认), CONFIRMED(1, 已确认), FINISHED(2, 已完成), COMMENTED(3, 已评价), CANCELLED(4, 已取消), TIMEOUT(5, 超时未接), SERVING(6, 服务中); private final Integer code; private final String desc; // 构造器和getter }业务方法里只允许合法状态迁移比如客户取消这个方法只能从待确认状态操作否则直接抛业务异常。这个设计在答辩时被问到如何避免订单状态越界变更你就把你的枚举状态机和判空逻辑展示出来解答得明明白白。6.2 档期锁定的并发处理这是系统里唯一值得谈并发的点。场景是这样的两个客户同时看到同一个伴娘同一日期无档期冲突同时提交预约请求如果代码处理不当会出现超卖一个伴娘同一天接了两单。解决方法有几种按推荐程度排序方案一在schedule表对(service_id, available_date)建唯一索引预约成功后将该日期记录更新为已锁定。一旦两条并发请求同时到达数据库层面第二条请求会因为唯一索引冲突而报错再把这个异常捕获并转换为该日期已被预约。方案二使用乐观锁。在service_info表加一个version字段更新档期时带上WHERE version ?如果更新影响行数为0则说明已有其他事务先一步修改返回预约失败。方案一的成本最低对毕业设计来说已经完全足够。但如果你在论文里写上通过唯一索引保证了并发场景下的档期不超卖这就是一个很有质量的亮点几乎所有答辩老师都会认可。6.3 JWT登录与权限控制JWTJSON Web Token的本质是服务器端不保存用户的登录状态而是把用户信息过期时间打包签名后发给前端前端保存这个token后续每次请求都带上服务器验证签名即可。实现步骤不复杂登录成功后后端把用户id、用户名、角色塞到token里用jjwt库生成签名拦截器在每次请求时解析请求头里的token验证签名和过期时间然后将用户信息放入ThreadLocal后续controller层直接获取当前登录用户非常方便。权限控制上用拦截器实现AuthInterceptor拦截/api/**路径校验白名单之外的请求继承HandlerInterceptorAdapter重写preHandle方法如果token非法则返回Result.error并附带code401。像服务人员操作自己的服务记录这样的资源级权限则要在service层做一层判断比如更新服务信息前先从数据库查出这条记录的user_id与当前登录用户对比不一致就抛403异常。7. 部署上线别让你的项目只活在本地环境7.1 后端打包SpringBoot后端打包很简单mvn clean package -DskipTests如果你用的打包方式是jar最终会生成一个可执行JAR包用java -jar就能跑起来。但这有个小坑项目里如果引用了本地文件比如上传的图片存在某个磁盘路径部署到服务器后路径会变化所以文件存储路径建议配置在application.yml里通过Value注入使用。7.2 前端部署前端构建npm run build会生成一个dist目录里面是纯静态文件。部署时用Nginx托管这个目录并把/api路径反向代理到后端的9090端口配置大概长这样server { listen 80; server_name yourdomain.com; root /var/www/wedding/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:9090/api/; } }这里有个非常关键的细节前端路由用的是history模式的话Nginx必须配置try_files回退到index.html否则刷新二级页面时会出现404。配置如下location / { try_files $uri $uri/ /index.html; }这个坑我亲眼见到无数人踩过——本地开发好好的部署上线一点刷新就白屏就是这个原因。7.3 宝塔面板实操如果你对Linux不熟我强烈推荐用宝塔面板来做部署它把Nginx、MySQL、Java环境的安装全部图形化了点按钮就能装好。部署流程大致是上传JAR包到服务器 - 用Supervisor或宝塔的进程守护管理后端进程 - 上传前端dist目录到站点根目录 - 配置Nginx - 搞定收工。顺带提一句springboot 阿里云构建地址那个热搜词。很多同学部署时在阿里云服务器上遇到镜像源问题解决方案是修改Maven的settings.xml配置阿里云镜像仓库。这个步骤属于经验类问题等你真踩到了再看配置文档即可。8. 避坑指南毕业设计阶段最容易犯的10个错误写到这儿我觉得有必要把带过学生常犯的错误集中列出来这些错误几乎每年都在重复值得做成一个自查清单第一项目里任意两个实体之间出现属性内嵌外键但没建关联索引导致关联查询慢到爆炸。比如订单表查service_id时一定要对service_id字段建索引。第二密码明文存储。答辩时被老师打开数据库看到password字段里的明文密码瞬间好感清零。用BCryptPasswordEncoder解决这个问题。第三日期处理混乱。数据库用datetimeJava用LocalDateTime前端展示不格式化结果页面上显示2024-05-20T12:35:00.00000:00这种鬼样子。统一时区、统一格式化工具类。第四上传的文件直接存数据库。头像、服务图片一律存URL文件存本地目录或OSS不要把Base64字符串存成TEXT字段。第五前端没做路由守卫游客可以直接访问管理后台页面。虽然后端有权限校验但前端也得做一遍体验和安全性都更好。第六异常处理用e.printStackTrace()就打发了。要让接口在异常时返回统一格式的JSON而不是返回一段完整的堆栈信息给前端。第七分页查询用SELECT *然后Java代码里截取。数据量小的时候确实看不出问题但一旦数据量上来了数据库IO和内存占用会很尴尬。用MyBatis的PageHelper插件或手动LIMIT分页。第八订单金额用float或double计算。涉及金额计算一定要用BigDecimal这个属于基本功但每年都有人犯。第九不做事务管理。比如创建预约时同时更新档期状态两步操作中间一旦报错库里就会出现订单已创建但档期还是空闲的数据孤儿。在方法上加Transactional注解。第十不写接口文档。毕业设计的代码量并不大少写一次Swagger注解确实省事但对有整理能力的同学我还是建议花半天时间配上springdoc-openapi答辩的时候直接在线演示API文档视觉冲击力很强。9. 答辩要点与项目亮点提炼做毕业设计不只是把系统做出来答辩时的表达同样关键。我总结几个让答辩老师点头的要点技术层面讲清楚三个为什么。为什么用前后端分离因为解耦、可扩展、便于多端复用。为什么用JWT而不用Session因为无状态适合前后端分离和横向扩展。为什么用MyBatis而不用Spring Data JPA因为作为毕业设计MyBatis的SQL可控性更强排查问题更直观。这三个问题的回答思路你提前准备好比背一百行代码讲解都有用。业务层面讲清楚撮合的商业逻辑平台通过审核保障供给质量通过评价机制建立信任通过档期锁定避免交易冲突。尤其是档期唯一索引防超卖这个设计把技术问题和业务问题结合起来了是很好的答辩亮点。最后一定要准备一个如果让我重做一次我会怎么改进的答案。比如现在照片存在本地服务器考虑迁移到对象存储现在评价系统缺少追评和回复功能以后可以做成类似电商平台的评价体系现在推荐列表是时间排序以后可以考虑基于浏览行为的个性化推荐。这种收尾不是说空话而是让老师看到你理解了系统的边界和演化方向比我觉得已经完美了高明得多。我个人带学生做这类项目的体会是毕设项目的难点从来不在技术上而在能否完整讲出一个业务故事。SpringBoot和Vue.js都只是实现工具真正让答辩过程顺畅的是你对自己系统的每个设计决策都有合理的解释。把这篇文章里涉及的设计取舍、防坑经验、业务逻辑都理清楚了你的毕业设计就成功了一大半。