先说个题外话。每年到这个时间点都会有一大批学弟学妹在群里问“SpringBoot Vue 的家政系统怎么做”“毕设系统跑不起来怎么办”“数据库导入报错怎么办”。家政服务管理系统确实是个经典题目业务线清晰、角色分明、技术栈也主流用来做课程设计或者毕业设计都非常合适。这篇就基于我实际整理和调试这套系统的经验把设计思路、数据库结构、前后端实现、排错心得、文档和答辩准备一次性聊透。你拿到源码之后照着这篇去改、去跑、去讲比你自己闷头摸索省力很多。1. 项目概述与设计思路拆解1.1 这个系统到底在做什么需求拆解与角色分析家政服务管理系统本质上解决的是一个撮合交易问题有家政需求的用户、提供服务的家政人员、以及负责运营管理的平台方三方需要在同一个系统里完成信息匹配、服务下单、过程跟踪和服务评价。听起来简单但真正落到功能设计上角色权限、业务流程、状态流转都比预想的要复杂得多。这套系统的用户角色分成三类。普通用户也就是雇主核心诉求是注册登录、浏览家政服务项目、按类别或关键词搜索、下单预约、查看订单进度、完成后评价。家政人员核心诉求是注册入驻、查看平台分配或自己抢单的订单、接单/拒单、更新服务状态、查看收入记录。管理员的核心诉求则更多一些审核家政人员入驻资质、管理服务类别与服务项目、处理投诉与退款、查看订单流水、做简单的数据统计。三者的诉求叠加在一起就构成了系统的主干功能模块。我在做技术选型和模块划分时得到的核心结论是不要一上来就堆功能先把三个角色各自的“必须项”圈出来再讨论扩展项。比如用户端必须有订单列表和评价入口家政端必须有状态更新按钮管理端必须有审核开关。这些是骨架其他都是肉。1.2 技术选型为什么是SpringBoot Vue选型逻辑与优势分析做毕设或课程设计技术栈的“主流性”有时候比“先进性”更重要。SpringBoot Vue 这套组合在目前的Java Web开发里属于绝对主流网上资料多、招聘市场上认可度高更重要的是踩坑的人多意味着前人留下的解决方案也多你卡住一小时搜得到答案的概率非常大。后端选 SpringBoot 是因为它把配置简化到了极致。传统 SSM 项目要写一堆 XML 配置文件而 SpringBoot 通过自动配置和 starter 机制一个注解就能把项目跑起来。它对初学者的友好程度在于你不需要理解太多底层原理先把项目跑通再逐步深入。配合 MyBatis-Plus连单表 CRUD 的 SQL 都帮你省了BaseMapper 里已经封装好了增删改查方法。前端选 Vue 的理由也很直白组件化开发思路清晰模板语法接近原生 HTML配合 Element PlusUI 组件库和 AxiosHTTP 请求库几天时间就能搭出一个能看的管理后台。而且 Vue 的双向数据绑定让表单类页面写起来非常舒服数据一变页面自动更新对不擅长手动操作 DOM 的同学友好得多。1.3 系统整体架构与目录结构设计实际项目采用的是经典的前后端分离架构。前端单独跑一个 Vue 工程后端单独跑一个 SpringBoot 工程两者通过 RESTful API 通信。这种架构的好处是职责单一、便于分工也更贴近企业真实开发模式。后端目录结构按“controller / service / mapper / entity”四层划分。Controller 只负责接收参数和返回结果不写业务逻辑Service 层存放核心事务处理逻辑Mapper 负责数据库交互Entity 映射数据库表结构。这种分层初期会让人觉得代码“绕了一圈”但后期维护和答辩讲架构时优势就体现出来了——面试官和老师问到“为什么这么分层”你能给出清晰且规范的回答。前端目录结构则是典型的 Vue 工程布局views 放页面组件router 放路由配置store 放全局共享数据登录状态、用户信息utils 封装请求工具类和 token 处理逻辑api 目录按模块拆分接口调用。把 api 和页面分开这个习惯我从第一次写项目就养成了好处是我们的页面组件干干净净改接口只动 api 文件排查问题也非常高效。2. 核心功能模块与数据库设计详解2.1 六大功能模块的职责划分这套系统的功能模块我拆成六个用户管理、家政人员管理、服务类别管理、订单管理、评价管理、公告管理。用户管理负责普通用户的注册、登录、个人信息维护。家政人员管理比较特殊因为家政人员不像普通用户可以自由注册后立刻使用需要管理员审核通过后才能接单所以这个模块包含入驻申请和审核状态管理。服务类别管理是一个典型的树状分类结构比如“保洁清洗”下面有“日常保洁”“深度保洁”“开荒保洁”一级分类和二级服务项目之间构成一对多关系。订单管理是整个系统的核心涉及下单、支付、派单、接单、服务完成、确认验收等多个环节。评价管理比较简单订单完成后用户可以对家政人员的服务打星评级和写文字评价后台展示在服务详情页。公告管理则是管理员发布系统通知前端在首页轮播展示。2.2 数据库表设计核心表结构与字段逻辑数据库表设计是我在整套系统里花时间最多、也认为最有必要讲清楚的部分。核心数据表有7张用户表t_user、家政人员表t_worker、服务类别表t_category、服务项目表t_service、订单表t_order、评价表t_comment、公告表t_notice。用户表字段包括主键id、用户名、密码BCrypt加密后存储、姓名、手机号、头像url、注册时间。家政人员表在基础信息之外额外增加身份证号、服务区域、入驻申请时间、审核状态、审核意见、星级评分。这里有个细节审核状态用整型枚举0待审核、1通过、2拒绝比字符串更节省空间程序判断也比字符串比较方便。服务项目表要关联类别表通过 category_id 外键确定归属。订单表是最复杂的一张表订单编号用字符串类型类似“JD20250612001”这种带时间戳的格式下单用户id、家政人员id、服务项目id、预约时间、服务地址、订单金额、订单状态、下单时间、完成时间都要有。关于主键类型我个人建议用bigint自增或用雪花ID。自增主键对 MySQL 和 MyBatis-Plus 的 Insert 回填支持最友好生成的主键有序、索引效率高。有的同学习惯用UUID字符串虽然全局唯一但随机字符串作为主键会导致 B 树索引频繁页分裂数据量大了以后插入性能明显下降完全没必要在课程设计里选它。2.3 订单状态机与关键业务逻辑设计订单状态是这个系统的灵魂。如果不在设计阶段把状态流转想清楚写代码时极容易陷入“改一处漏三处”的局面。我最后敲定的状态机如下待支付0用户提交订单后生成此时订单还未真正生效已支付待派单1支付成功等待管理员或系统派单已派单待接单2系统分配家政人员等待对方确认服务中3家政人员接单并开始上门服务已完成4家政人员标记“服务完成”用户确认后可评价已取消5用户支付前取消或平台介入取消已退款6订单取消后完成退款流程。每个状态的流转都要有对应的操作入口和权限校验。比如“用户不能强制把订单从已完成回退到服务中”这种状态回退如果不过滤会让数据变得一团糟。我的实现方式是在 Service 层写一个transition方法显式校验“当前状态→目标状态”是否允许不合法直接抛业务异常。一个经验把状态字段做索引。订单表数据量大以后按状态统计是最高频的查询条件加上索引能显著提升统计速度。建表语句里idx_order_status这种小细节写在课程设计文档里是加分项。3. 实操过程从环境搭建到前后端联调3.1 本地环境准备与项目导入先检查环境JDK 1.8或更高版本、Maven 3.6、Node.js 14推荐 16 或 18、MySQL 5.7或8.0。这里有个大坑SpringBoot 2.x 和 3.x 的兼容性差异很大。这套系统基于 SpringBoot 2.7.x如果你的环境变量里 JDK 版本是 17跑 3.x 没问题但跑 2.7.x 反而可能要调整如果 JDK 是 1.8就只能用 2.7.x千万先确认版本再上手不然一启动就是各种莫名其妙的报错。导入后端项目用 IDEAFile → New → Project from Existing Sources选择项目根目录下的pom.xmlMaven 会自动下载依赖。这一步考验网速也考验耐心阿里云镜像能救你在settings.xml里配置好镜像源依赖下载速度快一倍不止。前端工程是标准 Vue CLI 或 Vite 创建的项目结构用 WebStorm 或 VS Code 打开然后在终端执行npm install。Node 版本太老12及以下或太新19都可能因依赖兼容性装不上或启动报错我的建议是固定用 Node 16Electron 生态和 Vue CLI 都比较稳妥。3.2 数据库初始化与后端配置详解数据库文件在项目sql目录下后缀是.sql。用 Navicat 或命令行执行source xxx.sql即可导入。导入后先别急着启动后端打开application.yml检查三处配置数据源地址jdbc:mysql://localhost:3306/xxx、数据库用户名密码、MyBatis-Plus 的日志输出配置。如果说这些是可选项那有一项是必查项数据库连接 URL 里的serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue。MySQL 8.0 默认时区是 UTC不设置serverTimezone后端执行 SQL 插入时间字段时会出现“相差八小时”的诡异问题。allowPublicKeyRetrievaltrue是 MySQL 8.0 连接时经常出现的公钥检索报错的解药。启动后端之前还要建议检查一下端口占用。SpringBoot 默认 8080如果你电脑上已经跑着其他服务占了 8080直接改application.yml里的server.port即可。前端联调时记住这个端口反向代理和 Axios 里都要指向它。3.3 前端项目初始化与联调配置前端跑起来的第一步是安装依赖然后启动开发服务器npm run serveVite 项目则是npm run dev。默认端口通常 8080和后端冲突所以 Vue CLI 项目一般配置了vue.config.js里面会指定port: 8081。跨域问题在前后端分离项目里几乎必然出现。因为浏览器安全策略前端localhost:8081去请求后端localhost:8080会被拦截。解决方案有几种后端加 CORS 全局配置类加CrossOrigin注解或者前端配代理。前端 Vue CLI 的代理配置非常省事在vue.config.js里加一段devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }意思是前端发的/api开头的请求全部转发到后端 8080 端口浏览器看到的还是同源地址跨域问题自然消失。这样做的好处还有一层就是线上部署时你只需要改代理目标地址前端代码不用动。3.4 核心接口与前后端交互的实现流程后端核心接口设计遵循统一返回格式。我在项目里封装了一个Result类包含code、message、data三个字段。code200表示成功其他一般是业务异常码。这个习惯非常重要前端 Axios 拦截器里统一判断 code而不是直接拿 HTTP 状态码做业务判断。HTTP 状态码只有几百个定义业务状态码是你自己可以随意扩展的两者混为一谈会写出很脆弱的代码。登录模块我采用 JWTJSON Web Token方案。用户登录成功后后端用密钥生成一个包含用户id和角色信息的 token返回给前端前端把 token 存到 localStorage每次请求在 Axios 拦截器里加上Authorization: token后端用一个拦截器解析 token解析失败或过期就返回 401。相比传统的 Session 方案JWT 的好处是天然适合前后端分离——不需要依赖服务器端会话存储扩展服务时不需要session同步。订单提交流程是一个典型的事务场景。用户提交订单后端要做校验用户状态、校验服务项目是否可下单、计算订单金额、生成订单编号、扣减库存如果某些服务有人次限制、返回前端待支付订单信息。任何一个环节失败整个事务要回滚否则会出现“订单没生成但库存扣了”或者相反的错误。在 SpringBoot 里给 Service 方法加Transactional注解就能搞定。4. 常见问题与调试技巧实录4.1 最高频的启动报错与排查方法这套系统我在不同电脑上跑过几十次总结出三个最高频的启动报错基本覆盖九成问题。第一个Port 8080 was already in use。遇到这个问题很多人直接改端口但改了之后前端代理和后端端口不一致又出问题。我的建议是先把占用端口的进程找出来干 掉用netstat -ano | findstr 8080看 PID 再决定处理方式或者索性统一把前后端端口都改掉。第二个查询数据库报Unknown database xxx或Access denied for user root这类百分之百是application.yml里的数据库名或密码和本地实际不一致。解决办法是打开数据库客户端核对库名和账号。注意.sql文件里的建表语句可能是CREATE DATABASE IF NOT EXISTS home_service DEFAULT CHARACTER SET utf8mb4但在 MySQL 8.0 里默认字符集已经是 utf8mb4如果导入时你是手动建库一定要选 utf8mb4不能选 utf8否则存中文没问题存特殊表情符时候就会报错。第三个Maven 依赖下载失败Cannot resolve symbol SpringBootApplication。这个不是代码问题是依赖没拉下来。依次尝试IDEA 里 Maven 面板点刷新、mvn clean install、删掉本地仓库com和org目录下相关文件夹重新下载。如果都失败检查settings.xml是否配置了错误的镜像地址。4.2 前后端联调阶段最容易翻车的几个地方前端跑起来后页面白屏打开控制台就一句话Failed to load resource: the server responded with a status of 404。这通常不是后端没启动而是你请求的路径和后端 Controller 里的映射对不上。比如后端是RequestMapping(/api/user)前端请求是user/list少了/api前缀404 是必然的。排查方法是打开浏览器的 Network 面板看请求 URL再对照后端代码里的RequestMapping/GetMapping值一目了然。登录成功后页面没有跳转或者刷新后登录状态丢失多数是 token 存取问题。一个原则token 存 localStorage用户信息存 sessionStorage 或 PiniaVuex。刷新后从 localStorage 取 token 判定登录态然后重新拉取用户信息。很多同学把用户信息也放 localStorage刷新后页面显示的用户名还是旧的逻辑就错了。还有一个经常被忽略的问题时间字段显示格式不对。MySQL 里的datetime类型前端拿到后显示成一串带 T 的 ISO 字符串比如2025-06-12T10:30:00.00000:00不好看也不符合中文用户习惯。处理办法是在后端实体类的日期字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解或在前端封装一个时间格式化方法两者效果一致但后端统一处理更省事。4.3 课程设计文档、答辩与二次扩展的建议源码能跑只是第一步课程设计的分数很大程度上取决于文档和答辩表现。文档撰写要抓住重点需求分析里不要只写“系统需要用户管理”而要写出具体的功能点和操作路径数据库设计里除了表结构图要写字段注释和表关系说明为什么这样设计测试部分要写功能测试和结果用表格列清楚用例名称、操作步骤、预期结果、实际结果即可。答辩环节最高频的问题就三个为什么选 SpringBootJWT 和 Session 有什么区别订单状态是怎么流转的这三个问题都在这篇博客里有对应内容把这三个问题融会贯通讲明白答辩环节基本稳了。想做二次扩展的同学方向有很多引入 Redis 做验证码存储和会话管理、集成支付宝沙箱做真实支付回调、用 WebSocket 让用户实时看到订单状态变化、引入 ElasticSearch 做服务项目的全文搜索。最简单的扩展是加个数据统计模块后端用一条SELECT count(*) ... GROUP BY就能查出各订单状态下单量前端用 ECharts 画个饼图视觉效果和文档素材立刻提升一档。4.4 部署上线从本地到云服务器的步骤参考有些学校的课程设计要做演示答辩评委可能要求系统在服务器上能访问而不只是本地跑。这个过程我也踩过不少坑。后端打包用 Maven 的mvn clean package生成一个可执行的jar包然后上传到云服务器执行java -jar xxx.jar。但这里有个关键点打包时默认用的配置还是application.yml里面指向的是本地数据库部署到服务器一定要修改数据库地址和账号密码。更规范的做法是为部署准备单独的配置项比如使用application-prod.yml并通过--spring.profiles.activeprod指定使用生产环境配置。这一步虽小却能避免“代码在本地正常、上服务器跑不起来”的经典翻车。前端部署要先构建npm run build产物在dist目录。把这个目录用 Nginx 托管Nginx 会监听 80 端口并把静态资源返回给浏览器。但前端请求/api时还要在 Nginx 配置里加一个反向代理规则把/api转发到后端服务的 8080 端口对应配置就是location /api { proxy_pass http://localhost:8080; }。如果没有这句你部署后的页面点任何按钮都会在接口处失败。数据库方面把本地导出的 SQL 在服务器执行一次再把配置改为服务器地址即可。这套“本地开发 服务器部署”的完整链路在写进课程设计报告的“系统部署与测试”章节时本身就是非常充实的一页材料。另外再分享一个我自己的小习惯在改动涉及订单状态的地方可以把关键节点的日志打出来比如“用户下单成功订单号xxx金额xxx状态待支付”排错时看一眼日志就能定位到环节。很多同学不喜欢看日志遇到问题就从第一行代码翻到最后一行效率很低。系统的报错信息会明确告诉你是数据库还是接口还是前端——多花十分钟看懂报错比漫无目的地改代码有用得多。这套家政服务管理系统只要把它跑通、读明白、能讲清楚课程设计这一关就稳稳拿下了。