做计算机毕业设计十个里八个人做的是“某某管理系统”剩下两个在做“基于SpringBoot的某某平台”。但今天要聊的这个题目不太一样它不是卖给学校、超市、宠物店的通用增删改查而是把“婚礼上找伴娘伴郎”这件事做成了一个撮合平台。核心关键词就两个——SpringBoot和Vue.js架构上用的是前后端分离。说实话这类题目在毕设圈里不算最热门的但正好戳中了一个很真实的场景新人办婚礼伴娘伴郎凑不齐或者不想麻烦朋友需要一个地方能找到合适的、可以付费邀请的伴娘或伴郎。这个项目适合谁参考如果你是正在选毕设题目的计算机专业学生想做点“听起来有业务场景、做起来又有技术含量”的东西这个题目非常合适。它既有常规系统必备的用户管理、登录注册、数据维护又有比“管理系统”高一个维度的撮合逻辑和订单状态流转能体现出你对业务流程的理解。而且SpringBoot负责后端接口、Vue.js负责页面交互前后端分离的架构正好是目前企业开发的标配答辩的时候也容易讲出东西来。我下面把这套系统从选题思路、数据库设计、后端实现、前端页面到排坑经验全部拆开写一遍内容包括可直接复用的表结构、接口设计思路和代码片段也把毕设里最容易翻车的“版本坑”“跨域坑”“打包坑”一并讲清楚。照着这个思路做整套系统不仅能跑通还能让你答辩时被问到细节也不慌。1. 项目整体设计与技术选型解读1.1 业务定位与核心需求婚庆伴娘服务系统听名字像是中介平台但本质上是做“信息撮合”。新人甲方有伴娘伴郎需求比如婚礼需要4个伴娘2个伴郎而另一些人乙方愿意以兼职形式担任伴娘伴郎系统要把这两拨人连接起来。这和常见的二手交易平台有点像但区别在于交易对象不是商品而是“人 服务”需求不是标准化的每个婚礼的时间、地区、换装要求、是否上台玩游戏都不一样撮合成功之后还需要订单确认和评价形成服务闭环所以从毕业设计的功能规划来看刷掉只会增删改查的思路核心功能应该围绕“需求发布—搜索匹配—邀约沟通—订单确认—服务评价”这个链路来做。单纯做一个“伴娘信息展示网站”是没意思的也很难通过答辩。根据这个业务定位我把系统拆成了这几块模块核心功能说明用户模块注册登录、个人信息维护、身份选择区分新人用户和伴娘伴郎用户需求发布模块新人发布婚礼需求城市、日期、人数、预算撮合平台的“货源”服务展示模块伴娘伴郎展示个人资料、经验、档期撮合平台的“供给”撮合搜索模块按城市、日期、人数条件筛选智能推荐核心亮点要做出筛选逻辑订单模块新人发起邀请、伴娘伴郎接单、状态流转体现业务闭环评价模块婚礼结束后互评打分提升平台可信度后台管理用户审核、订单管理、数据统计用于答辩展示管理端这套功能划分下来工作量适中开发难度也正好是一般毕设的水平但业务逻辑比普通管理系统有得聊。1.2 为什么选 SpringBoot 加 Vue.js 这套组合选技术栈这件事在毕设里经常被当成“形式主义”但其实它是答辩老师第一个会问的问题。你要是说“因为大家都用”——那就尴尬了。得能讲出道理来。选SpringBoot当后端理由很直接开发效率高、生态成熟、面试认可度高。SpringBoot把Spring那一堆复杂的配置自动化掉了内嵌Tomcat打个jar包就能跑配合MyBatis-Plus做数据访问写起接口来非常快。对毕设来说你不需要花三个月去研究框架配置能把精力放在业务实现上这是最大的优势。选Vue.js当前端理由是页面交互友好、组件化开发清晰。婚庆这个题材本身有展示需求伴娘伴郎的个人页面、婚礼场景图、服务介绍都需要做得好看。Vue的组件化写法把搜索页、详情页、订单页面独立拆开每块内容互不干扰开发和调试都省心。再用前后端分离架构把它们拼起来后端只提供Json接口前端负责渲染和交互。这么做有两个现实好处。第一是分工清晰后端不用管页面长什么样前端也不关心Sql怎么写第二是部署灵活前端打包成静态文件扔到Nginx里后端打成jar包独立运行将来要扩展小程序端或者App端后端接口可以原样复用。顺带说一句我还见过有人用SpringBoot配合Thymeleaf模板引擎直接渲染页面的做法确实省事但那套路子拿到面试官面前基本没什么可聊的。前后端分离这一手既贴近企业现状又方便你在毕业设计说明书里多写几十页架构设计内容属于性价比很高的选择。1.3 角色划分与业务闭环流程系统的角色权限设计直接决定了数据库怎么建、接口怎么分。我建议至少分三个角色管理员、新人用户、伴娘伴郎用户。管理员维护平台内容审核伴娘伴郎资质查看所有订单和数据统计新人用户发布婚礼需求浏览伴娘伴郎列表发起邀约确认订单并评价伴娘伴郎用户维护个人资料和服务档期浏览需求列表接受或拒绝邀约完成订单后互相评价这里有一个经典设计点用户表本身不做死“我是买家”还是“我是卖家”而是通过角色字段或独立表来区分。更合理的方式是用一个user表存账号密码和角色标识再用user_info表存各自的详细信息。这样新人也可以有自己的基本资料伴娘伴郎也可以看别人的婚礼需求角色切换灵活以后扩展业务也方便。核心业务闭环流程是这样的新人登录后发布婚礼需求系统根据城市、婚期、预算等条件推荐合适的伴娘伴郎新人浏览并查看对方档期后发起邀约对方收到邀约后可以选择接受或拒绝接受后生成订单标注服务日期和服务内容婚礼结束双方互评。管理员在后台监控整个流程有问题可以人工介入。这套闭环走通之后不管是写代码、画流程图还是写论文你手里都有非常清晰的主线答辩演示也从“点几个页面给老师看”变成“完整讲一个业务怎么流转”观感完全不一样。2. 数据库与后端架构拆解2.1 数据库表设计从用户到撮合到评价数据库设计这部分是答辩时老师必看的东西。表建得好不好说明你脑子里有没有业务流程。我这套系统的核心表可以拆成下面几张。第一张是用户表sys_user字段包括id、username、password、phone、role_type、status、create_time。密码建议存加密后的密文用Spring Security自带的BCrypt或者MD5加盐都行。status用来做账号禁用后台管理要用到。第二张是用户资料表user_profile关联user_id根据角色存储不同信息。很多人会把所有字段塞进用户表里那样一张表十几个字段代码写起来很变扭。拆成独立profile表之后新人用户有婚礼预算偏好伴娘伴郎用户有身高、经验、档期、服务城市这些信息各存各的互不干扰。第三张是需求表demand字段包括id、user_id、city、wedding_date、need_role、need_count、budget、description、status。这是新人发布的“需求单”撮合平台上的乙方就是靠这张表发现机会的。第四张是邀约/订单表reservation字段包括id、demand_id、provider_id、status、service_date、amount、remark。status建议用枚举数字0待接受、1已接受、2已完成、3已拒绝、4已取消。这是撮合平台的核心表整个业务状态流转都在这里体现。第五张是评价表review关联订单id和用户id存评分和评论内容。做完这一步系统就形成了“找—约—买—评”的闭环。如果要加一点难度可以加一张收藏表favorite新人可以收藏自己看上的伴娘伴郎。别小看这个功能它能很自然地在答辩时引出“关联查询”“列表分页”这些知识点。2.2 后端工程分层与代码组织SpringBoot后端工程我建议按经典的四层结构来组织controller、service、mapper、common。controller接收请求做参数校验调用service返回统一结果service写业务逻辑比如撮合匹配、订单状态流转、评价校验mapper用MyBatis-Plus写数据库操作大部分情况都不用自己写Sqlcommon放统一返回体、异常处理、工具类、JWT工具类统一返回体是很多新手容易忽略的点。我强烈建议定义一个Result类包含code、message、data三个字段。所有接口都返回这个包装体配合全局异常处理前端拿到数据后用code判断是否成功不需要每写一个接口就去处理一堆异常分支。这个设计在答辩时也能作为“工程化意识”的加分项。以撮合搜索为例service层核心逻辑是根据前端传过来的城市、婚期、角色、预算区间这些条件拼查询参数分页查伴娘伴郎用户再对结果做简单排序。用MyBatis-Plus的LambdaQueryWrapper就能实现不需要写复杂的Sql。public PageResultUserProfileVO searchProvider(SearchQuery query) { PageUser page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperUserProfile wrapper new LambdaQueryWrapper(); // 城市匹配 if (StringUtils.hasText(query.getCity())) { wrapper.eq(UserProfile::getCity, query.getCity()); } // 角色匹配 if (StringUtils.hasText(query.getRoleType())) { wrapper.eq(UserProfile::getRoleType, query.getRoleType()); } // 预算区间匹配 if (query.getMaxBudget() ! null) { wrapper.le(UserProfile::getFee, query.getMaxBudget()); } wrapper.eq(User::getStatus, 1); PageUserProfile result userProfileMapper.selectPage(page, wrapper); return assemblePageResult(result); }这段代码虽然看着简单但它体现了一个关键设计思想前端传查询条件后端动态组装查询条件数据库层做分页。相比直接写死一条Sql这种方式可维护性强得多加筛选条件就是多一行代码的事。2.3 登录鉴权与接口安全设计前后端分离下最常见的登录方案是JWTJSON Web Token。原理很简单用户登录成功后后端发一个加密的token给前端前端每次请求都把token放在请求头里带上后端用拦截器校验token是否有效并解析出用户信息。相比传统Session方案JWT的好处是后端不需要保存登录状态天然适合分布式部署和前后端分离。毕设项目用JWT技术含量够而且面试时也是一个高频考点。实现上三步走第一步登录接口校验账号密码成功后生成JWT返回前端第二步写一个拦截器或过滤器拦截需要登录的接口解析请求头里的token非法就返回401第三步用ThreadLocal保存当前用户信息方便service层直接用而不用每次在方法参数里传userIdJWT本身不难难的是要在写接口之前就把它搭好。如果先写了十几个接口再回头加鉴权你会想骂人。所以项目第一天就把登录注册和一个受保护的“获取当前用户信息”接口跑通后面所有功能在这个基础上加速度会快很多。除了JWT接口安全还有一件事密码不存明文。用MD5加盐或者BCrypt都行BCrypt更规范一点。这个细节答辩老师如果问你“密码安全怎么做的”你就有的聊了。2.4 撮合搜索核心功能实现思路撮合是这个系统区别于普通管理系统的核心所以搜索接口不能上来就是一通死查。我当时的做法是维护一个可扩展的匹配规则顺序先过滤条件再打分排序。过滤条件包括城市、日期是否空闲、角色类型、预算范围。这些是硬性条件不满足就过滤掉。打分排序是加分项比如在平台服务次数越多、评分越高、资料完整度越高的伴娘伴郎排得越靠前。用简单加权打分就能实现public Integer calculateScore(UserProfile p) { int score 60; if (p.getServiceCount() ! null) score p.getServiceCount() * 2; if (p.getAvgRating() ! null) score p.getAvgRating() * 5; if (p.getRealNameVerified() ! null p.getRealNameVerified()) score 10; return score; }这样实现的优势是你可以在答辩的时候说“我的撮合不是纯过滤而是带智能推荐的”。哪怕权重算法很简单但你已经有了“算法意识”这是毕设评分里很容易拉开差距的地方。排序完了之后还要处理一个常见的坑分页与排序的顺序。MyBatis-Plus的分页插件一定要正确配置PaginationInnerInterceptor否则分页查出来的total永远是0。这个问题我在下面排坑章节会详细说。3. Vue.js 前端实现与联调实录3.1 前端工程初始化和代码组织前端我用的是Vue 3 Vite Element Plus。Vite比Vue CLI启动快很多而且Vue 3的组合式API写起来更简洁。毕设项目如果选最新技术栈在答辩时也是一个加分项但前提是你真的能讲清楚Vue 3和Vue 2的差别到底在哪。工程初始化命令很简单npm create vitelatest wedding-frontend -- --template vue cd wedding-frontend npm install npm install axios element-plus vue-router pinia目录结构建议这样组织src/api按模块封装接口请求比如user.js、demand.js、reservation.jssrc/router路由配置文件src/storePinia状态管理存用户token和用户信息src/views页面级组件比如首页、搜索列表、详情页、订单页src/components可复用的公共组件这种结构对应了后端的分层思想。接口请求集中放在api目录页面里不直接写axios调用而是import封装好的函数。以后后端接口路径变了只需要改一个文件不用满项目去替换。3.2 核心页面与路由设计路由设计要跟着业务走。我梳理了一套比较顺的页面结构/home平台首页展示推荐伴娘伴郎和最新需求/search搜索列表页带筛选项/detail/:id伴娘伴郎或个人详情页/demand/publish发布婚礼需求/demand/list我发布的需求/reservation/list邀约订单列表/profile个人资料维护/login、/register登录注册/admin/*后台管理页面加路由守卫是必须的不然没登录就能进订单页面后端接口即使有鉴权前端体验也烂。我通常用路由守卫配合Pinia里存的token判断是否放行。router.beforeEach((to, from, next) { const store useUserStore(); if (to.meta.requiresAuth !store.token) { next(/login); return; } next(); });路由设计还有一个注意点如果要用history模式部署之后刷新页面会404。Nginx里需要配置try_files指向index.html。用hash模式就不会有这个坑但地址栏会多个#号。毕设演示我一般建议用hash模式省事不至于出意外。3.3 前后端联调Token、跨域与接口规范联调是毕业设计开发里最磨人的环节你一个人写前后端也一样会踩坑。最常见的三个问题请求头没带token、跨域被拦、参数对不上。axios请求封装的正确做法是创建一个实例统一配置baseURL和超时时间用请求拦截器自动加上tokenconst request axios.create({ baseURL: /api, timeout: 10000 }); request.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; });响应拦截器里统一处理错误码比如401跳回登录页500弹出错误提示。前端每个页面只管写业务代码不重复处理错误逻辑。后端跨域的解决方式最简单的是加一个CorsConfig配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(Registry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:5173) .allowedMethods(*) .allowedHeaders(*) .allowCredentials(true); } }再啰嗦一句Vite里的代理配置也很重要。开发时前端跑在5173端口后端跑在8080端口光有后端CORS还不够前端最好配置代理把/api开头的请求转发到后端这样前端代码里写的baseURL就是相对路径部署时也不用临时改一堆接口地址。4. 实操排坑与答辩准备全记录4.1 SpringBoot 版本太高导致的经典入坑现在新开的项目一上来就用SpringBoot 3.x很多人觉得版本越新越好。但在毕设这个场景下版本太高很容易变成坑。SpringBoot 3.x要求JDK 17起步而且包名从javax改成了jakarta。网上一堆教程和前辈留下的代码都是基于SpringBoot 2.x写的你抄过来发现import javax.servlet报错就是因为基础版本不对。如果自己能从坑里爬出来SpringBoot 3.x没问题。但如果你大量参考学长学姐的项目代码和网上教程我劝你用SpringBoot 2.7.x JDK 8或JDK 11更稳妥。等代码全部跑通了想换成3.x那是后面的事不要在毕设最紧张的阶段给自己增加不确定性。同理前端也别一上来就去追最新版依赖Element Plus的稳定版本就够用。4.2 分页查询的total永远是0这个问题80%出在MyBatis-Plus的分页插件没配置。MyBatis-Plus的分页查询靠拦截器实现如果你只写了selectPage而不加分页插件selectPage会直接查出全部数据然后内存分页total永远返回0。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }很多教程里只在启动类里加MapperScan没加这个配置类。抄代码的时候一定要连这个一起抄不然后端接口能查出数据但分页信息全不对前端列表翻页就全乱套。4.3 图片上传与访问的路径问题伴娘伴郎平台肯定要传照片传照片就绕不开文件上传。后端接收MultipartFile后保存到本地磁盘再把访问路径返回给前端。这里有两个坑。第一个坑是跨域访问不到图片。上传的图片如果存在D:/upload/photo.jpg前端页面访问http://localhost:8080/upload/photo.jpg是拿不到的因为你没有做静态资源映射。需要加一个WebMvcConfigurer把本地目录映射成URL路径Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:D:/upload/); }第二个坑是打包部署后路径写死。上传路径写本地绝对路径没问题但如果你用阿里云OSS做云存储代码里就要把存储逻辑抽出来做成接口本地实现和OSS实现分开。这一块属于加分项有精力可以搞没精力先把本地存储的路径打通就够答辩了。4.4 部署打包实操要点毕设到后期经常要部署到服务器上演示有两个方案能搞定。方案一前端打包成静态文件丢到SpringBoot的src/main/resources/static目录下然后整个后端打成一个jar包一个命令直接启动。这个方案最简单但严格来说不完全是前后端分离的部署形态。方案二前端用npm run build生成dist目录扔到Nginx的html目录下后端打成jar包独立运行。请求流程是浏览器访问Nginx的80端口拿前端页面前端通过配置把/api请求反向代理到后端的8080端口。这才真正体现前后端分离。Nginx的关键配置如下server { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/; } }注意proxy_pass后面的斜杠带斜杠和不带斜杠转发行为完全不同。这个细节够你排查两个小时。部署的时候别急先本地打包验证再上服务器一步步来。4.5 答辩演示预案与常见问题答辩演示这次操作代码写得好不如演示顺。我建议按这个顺序走登录进系统发布一个婚礼需求搜索看到推荐结果对某个伴娘发起邀约切换到对方账号接受邀约生成订单最后完成订单给评价。这一套流程走下来整个系统的核心功能就全部展示到了。演示前务必准备三件事一是把数据库恢复成初始数据别让老师看到一堆测试垃圾数据二是提前试一遍流程确认每一步渲染正常三是准备一个小本子记录关键表的字段和关键接口路径防止老师临时问细节答不上来。答辩老师常见的提问方向有这么几类为什么选前后端分离——答清职责与部署分离用户密码怎么加密的——BCrypt加盐哈希接口怎么控制权限——JWT令牌拦截器校验数据库表之间关系怎么设计——外键逻辑、一对多/多对一如果并发量大了怎么办——Redis缓存、限流、MySQL索引优化这些问题说实话都不难但需要你平时写代码的时候留个心眼不要光顾着抄代码跑通功能。理解每一层设计的意图答辩就不慌张。做这个项目过程中我个人体会比较深的一点是毕设没必要追求技术多炫但一定要把“业务闭环”讲通畅。很多人的系统单看页面多得数不清但点来点去都是零散功能没有一条能让用户走通的完整业务链。而婚庆伴娘服务系统这个题目天然自带撮合、订单、评价这套闭环只要你顺着这个主线把代码写扎实答辩效果绝不会差。最后再多提醒一句如果你的时间还算充裕建议把搜索模块的排序算法再做精致一点或者加个小程序端和服务消息通知哪怕不做完整只做出雏形写论文和答辩的时候素材都能多出一大截。