Java家政服务平台毕设项目运行指南：Spring Boot与MySQL部署全攻略

简介：这是一套基于Java SpringBoot构建的家政服务平台毕业设计项目，面向计算机相关专业的本科生与进阶学习者，可作为毕业设计、课程设计或工程实训的完整参考。项目包含全套前端后台源码、数据库初始化SQL脚本以及配套论文，覆盖用户管理、服务预约、订单处理等典型业务模块，具备清晰的分层结构与可扩展性。压缩包共949个文件，大小约17.71MB，主要包含179个Java文件、164个JavaScript文件、61个Vue组件，以及HTML、CSS、XML配置和SQL脚本，并附有一键安装、运行与构建的批处理脚本，后端采用SpringBoot，前端结合Vue，技术栈贴近企业实际应用。目前已有87人学习下载，适合需要完整项目源码来对照实践、二次开发或撰写论文的人群。代码经过测试可直接运行，也方便在此基础上拓展功能，实现个性化需求。

1. 从“高分项目”到本地可跑：这套 Java 家政服务平台到底装了什么

一到毕设季，最容易在群里被转发的就是这种名字的压缩包：“高分项目-基于Java的家政服务平台的系统（包含全套源码 + 数据库sql + 论文）.rar”。我最初也以为又是标题党，直到帮两个学弟看过同名的项目结构，才确认这类包里确实是完整可运行的 Java 家政平台：Spring Boot 做后端、MySQL 存数据、管理端和用户端拆开，外加一份能直接改的论文初稿。对做毕业设计或 Java 课程设计的人来说，它的价值不是“代码能跑”，而是给你一条从数据库表设计到业务闭环的完整参照线——用户下单、家政人员接单、管理员审核派单、订单状态流转，这套流程覆盖了 Java Web 开发最常考的模块划分和权限思路。这篇笔记，我按自己拿到这类源码后“解压—跑通—改库—写论文—答辩”的顺序，把每一步命令、参数和坑都拆开讲。

2. 把 .rar 解开：先看清楚这里面是哪一代 Java 技术栈

2.1 解包之后先看三个文件，而不是急着点开 IDEA

拿到任何一个 .rar 的毕设源码包，我第一反应不是直接 import 到 IDEA，而是先解压，在资源管理器里看顶层结构。正常的家政服务平台包，顶层应该有三类东西：一个后端工程目录（常见名字是home-service、housekeeping-server之类）、一个sql或database文件夹、一个论文相关的 doc/pdf 文件。如果你的解压软件连中文文件名都乱码，那后面整个导入都会跟着翻车，所以建议直接用 7-Zip 解压 rar 文件，不要用 Windows 自带右键的“全部解压”——它对 GBK 编码的中文目录名兼容不好，解出来经常是乱码路径，到配置数据库连接时很容易出错。

解压完成后，先别碰前端页面和业务代码，打开后端工程的pom.xml，只看三件事：spring-boot-starter-parent的版本、有没有mybatis-plus依赖、打包用的是jar还是war。我见过的大多数家政平台源码都是 Spring Boot 2.x + MyBatis-Plus 组合，因为 MyBatis-Plus 能让毕设少写大量单表 CRUD，这也是它成为这类项目标配的原因。判断清楚这三点，你才知道自己要装哪个版本的 JDK——Spring Boot 2.7 用 Java 8 或 11 都没问题，但如果对方用的是 Spring Boot 3.x，那就必须 JDK 17 起步。

2.2 技术栈判断清单：给自己列一张表，省得启动时才报错

我习惯在解压后先建一个简单的判断清单，不需要多复杂，对着一张表打钩就行：

这一步很多人会跳过，觉得“反正都是 Java 代码，导进来先跑再改”。实际血泪经验是：跳过这步的人，大概率会在启动报错后回来补课，因为 MyBatis-Plus 版本和 Spring Boot 版本不匹配时，报错信息是“无法创建 bean”，根本不会告诉你是依赖版本冲突。与其黑匣子式排查，不如一开始就把版本对齐。确认完技术栈，下一步就是导入数据库脚本——这是后面所有验证的基础，必须先做。

3. 导入数据库 SQL：先装 MySQL 还是先跑源码，顺序别反了

3.1 创建数据库与导入 .sql 脚本的标准顺序

很多人拿到database.sql就直接在 Navicat 里双击运行，结果看到一堆Unknown database报错。原因很简单：脚本开头是CREATE DATABASE还好说，但很多毕设源码的 sql 文件里只写了USE xxx;和CREATE TABLE，不会帮你建库。所以第一件事是手动建库：

-- 建议在 MySQL 命令行或 Navicat 查询窗口执行 CREATE DATABASE IF NOT EXISTS home_service DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE home_service; -- 然后执行 sql 目录下的 .sql 文件 SOURCE /你的绝对路径/home_service.sql;

注意：如果你基础库的字符集选的是utf8，遇到手机号备注里有 emoji 或者特殊符号时，写入会报Incorrect string value。直接建库就用utf8mb4，这是这些年唯一不需要后悔的选择。

导入完成后别急着关，先数一下表数量。执行SHOW TABLES;看看是不是和论文里数据库设计章节的表清单一致。家政服务平台最少应该有这些表：用户表、家政人员表、服务项目表、订单表、评价表、管理员表。如果发现 sql 文件里还附带了sys_user这类 Spring Security 的表，说明这个系统用了权限框架，后面配置的时候要把用户名和密码对应上。

关于“先装 SQL Server 2025 还是先装 MySQL”这个热搜词，这里得说清楚：这个项目标题明确写了“数据库sql”，此类 Java 毕设项目里 99% 用的是 MySQL，不是 SQL Server。如果你手上只有 SQL Server 环境，就需要把CREATE TABLE里的字段类型手动改一轮，工程量和踩坑量都很大，不推荐。装 MySQL 8.0.33 以上版本时，注意用utf8mb4和caching_sha2_password默认认证插件，后面连不上时很可能是这个原因。

3.2 核对数据库账号密码：改 three 处配置才能跑通

sql 导入完成后，去后端工程里搜application.yml或application.properties，找到数据源配置。家政平台这类项目里最经典的一段配置是这样的：

spring: datasource: url: jdbc:mysql://localhost:3306/home_service?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

这里的 3306 是 MySQL 默认端口；useSSL=false是因为本地调试不需要加密连接；serverTimezone必须显式声明，不然 MySQL 8.x 驱动会按 JVM 默认时区去连，报The server time zone value 'Öйú±ê׼ʱ¼ä'这种乱码时区错误。密码那一栏建议立即改成你自己 MySQL 的 root 密码，不要沿用源码里写的123456或root，因为很多源码包是从别人电脑上导出的，密码可能对不上，启动时直接报Access denied。

改完配置文件，还需要确认工程里用的数据库连接池。大多数这类项目用的是 HikariCP，Spring Boot 2.x 默认自带，不需要额外依赖。HikariCP 的坑主要在连接超时：如果 MySQL 服务没启动，它会报Connection is not available, request timed out after 30000ms，而不会提示“连接被拒绝”，这是新手最容易误判的地方。遇到这类报错，先确认 MySQL 是否在运行，再回去检查账号密码，最后才是配置项问题。

4. 启动后端与两个前端：这套系统是单体工程还是前后端分离

4.1 从启动类反推前后端模式，决定你先跑哪个端口

家政服务平台这类毕设项目，最常见有两种工程形态。第一种是 Spring Boot 单体工程，页面用templates目录下的 Thymeleaf 或 Freemarker 渲染，后端启动后直接访问http://localhost:8080就能看到登录页，这种最简单，跑起来只需要一个进程。第二种是前后端分离：后端是一个 Spring Boot 工程，提供 JSON 接口；前端是一个独立的 Vue 工程，需要npm install和npm run serve另外启动一个 dev server。判断方法很简单：打开后端工程看结构，如果 src/main/resources 下只有application.yml而没有templates/static目录，那基本就是前后端分离。

我见过很多家政平台源码标着“管理系统”，其实做成了前后端分离，结果新手把后端跑起来了，访问 8080 看到一个 JSON 字符串“Hello World”，就以为项目坏了。后端启动成功的前兆是控制台出现Tomcat started on port(s): 8080，而页面能不能看取决于前端服务是否也在运行。Vue 工程一般默认跑在 8081 或者 5173 端口，具体看package.json里的 scripts 配置。如果前端工程同时存在vue.config.js里配置了代理，那说明它把/api前缀的请求转发到后端 8080，这是 Spring Boot 和 Vue 联调最常见的一种协作方式。

4.2 用 Maven 启动后端的完整命令和参数解释

如果你不想在 IDEA 里等它索引完整个依赖树，可以在命令行先把后端跑起来，这样能更快看到报错信息：

mvn clean package -DskipTests

这句命令里，clean是把之前编译的 target 目录清掉，避免旧 class 干扰；package是打包成 jar；-DskipTests是跳过测试用例——毕设源码里偶发有失败的测试代码，不跳过会让你卡在BUILD FAILURE。如果mvn命令本身报 “不是内部或外部命令”，那是环境变量没配好，你需要先配置MAVEN_HOME并加入 PATH，再回来执行。

打包完成后到 target 目录启动：

java -jar home-service-0.0.1-SNAPSHOT.jar --server.port=8080

--server.port=8080是运行时参数，优先级比application.yml里的server.port高。如果 8080 被占用报Port already in use，或者在 Windows 上提示BindException，可以改用--server.port=8081，不用动手改配置文件。启动日志里出现Started HomeServiceApplication in xx.xxx seconds才是真正成功，其他任何 log 出现APPLICATION FAILED TO START都说明还有配置没对齐。

启动成功后，用浏览器访问后端地址时，如果看到 404，不用慌。很多家政平台项目的登录页就在根路径http://localhost:8080/，如果根路径 404，尝试/login、/admin/login、/index.html这三个路径，具体看控制器里的@RequestMapping标注。这一步没什么玄学，就是根据路由一个路径一个路径试。

5. 常见问题与避坑指南：从环境报错到运行时翻车的五个排查记录

5.1 MyBatis-Plus 实体类与表字段映射不上，报column not found

现象：启动后端正常，但登录时后端日志抛 SQL 异常，提示Unknown column 'real_name' in 'field list'，而数据库表里明明有这一列。

原因：这是这类家政平台最常见的问题。源码里用了 MyBatis-Plus 的实体类，但实体里驼峰命名的字段和数据库下划线命名的字段没有开启自动映射。MyBatis-Plus 默认map-underscore-to-camel-case是开着，但如果你导入的 sql 是老项目导出的，字段命名是real_name，实体类是realName，两者对不上时会直接取字面量，导致 SQL 里出现一个不存在的列名。

解决：在application.yml里显式补上配置：

mybatis-plus: configuration: map-underscore-to-camel-case: true

补上重启，如果还报错，就去实体类里看@TableName注解是否写了正确的表名，以及@TableField是否把字段名指定清楚了。这一步排查完之后，大多数登录和列表接口都能恢复正常。

5.2 后端能启动，但前端登录提示“跨域请求被拒绝”

现象：Vue 前端自己跑在 8081，访问后端接口时浏览器控制台报No 'Access-Control-Allow-Origin' header is present，登录按钮点了没反应。

原因：前后端分离开发时，前端 dev server 的域名端口和后端不一致，浏览器默认会拦截跨域响应。这不是后端代码逻辑出错，是后端接口没有允许跨域来源。

解决：在后端工程里加一个跨域配置类，这是最通用的做法：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowCredentials(true) .maxAge(3600); } }

这段配置里allowedOriginPatterns("*")表示允许任意来源，适合本地调试；allowCredentials(true)表示允许携带 Cookie，但同时意味着不能再用*通配域名，所以要用allowedOriginPatterns而不是老的allowedOrigins。另外，前端如果用了 axios，记得withCredentials字段要一致，否则前端带了 Cookie，后端又不接受，一样会失败。

5.3 管理端进去是空白页，但浏览器控制台没有报错

现象：登录成功后跳转管理后台，页面一片空白，按 F12 看 Network 却发现静态资源 js/css 全部 404。

原因：多数情况下是把打包后的前端文件放到了后端静态资源目录下，但路径写错了。Spring Boot 默认从classpath:/static/读取静态资源，如果前端打包后的index.html引用了绝对路径/js/app.js，而后端资源根目录下没有这个/js目录，就会全站 404。

解决：把前端npm run build生成的dist目录内容拷贝到后端src/main/resources/static/下，重新打包启动。如果页面内容有更新，就重新拷贝再打包。这是个土办法，但它是单体部署和毕设答辩中最稳的一种方式，不需要引入 nginx，也不用处理端口转发。

注意：拷贝前记得删除static目录下旧的js/css子目录，否则旧文件会和新文件混在一起，浏览器缓存会加载到过期资源，页面上改了代码却不生效，最坑的是这种问题在答辩现场很难解释清楚。

5.4 MySQL 8 驱动连不上：Public Key Retrieval is not allowed

现象：启动后端时数据源初始化失败，报Public Key Retrieval is not allowed，但账号密码明明是对的。

原因：MySQL 8.0 默认的caching_sha2_password认证方式，在非 SSL 连接下需要先拿到服务器的公钥进行密码加密传输，客户端驱动默认不允许在线获取公钥。

解决：在 JDBC URL 后追加两个参数：

url: jdbc:mysql://localhost:3306/home_service?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai

allowPublicKeyRetrieval=true是本地开发环境允许的合理配置，生产环境不建议开放。如果加上这个参数还报Access denied for user 'root'@'localhost'，就去 MySQL 里确认一下 root 账号是不是只允许 localhost 登录，很多源码包里附带的是另一台机器的用户，不一定适配你的本机。

5.5 论文里的界面截图和实际运行效果长得不一样

现象：按论文写好的步骤登录系统，发现菜单名称、按钮位置和论文里的截图对不上，答辩时被老师质疑“不是同一个系统”。

原因：这是买源码、下载源码做毕设最普遍的现象——论文文字是围绕早期版本写的，但源码包后来被别人改过前端布局或功能模块，两者不同步。不是你没配好，是材料和代码版本没对齐。

解决：我的习惯是直接以实际运行的界面为准，反向调整论文截图。具体操作是：把系统跑通后，按论文原有章节，用自己的界面重新截图，替换掉论文里对应位置的图片。功能名对不上的地方，优先以实际功能为准改写论文里的描述，因为老师答辩时看的是现场演示，不会拿论文逐字逐句和代码比对。别为了论文好看去改界面，改界面的成本远高于改文字。

6. 进阶操作：把订单模块改成状态机驱动，顺手解决答辩追问

家政服务平台这类项目最容易在答辩时被追问的，不是 CRUD，而是订单状态流转。源码包里往往只是用一个status字段硬编码，比如 0 表示待接单、1 表示已接单、2 表示已完成，控制器里一堆if/else判断。这样做演示没问题，但老师一句“如果用户下单后取消了订单，而管理员同时把订单派给了家政人员，状态怎么处理”，你就会现场卡住。我一般会建议花两小时把订单状态改成枚举加状态机校验，这是成本最低、又能在答辩现场体现设计能力的改动。

先在工程里定义一个订单状态枚举：

public enum OrderStatus { PENDING(0, "待接单"), ACCEPTED(1, "已接单"), IN_PROGRESS(2, "服务中"), COMPLETED(3, "已完成"), CANCELLED(4, "已取消"); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code = code; this.desc = desc; } public boolean canTransitTo(OrderStatus target) { switch (this) { case PENDING: return target == ACCEPTED || target == CANCELLED; case ACCEPTED: return target == IN_PROGRESS || target == CANCELLED; case IN_PROGRESS: return target == COMPLETED; default: return false; } } }

这个枚举核心是canTransitTo方法：每个状态只允许合法跳转，用户在待接单时可以取消，但不能把已取消的订单改成进行中。改完枚举后，在订单 Service 的更新方法里做一次前置校验：

OrderStatus current = OrderStatus.of(order.getStatus()); if (!current.canTransitTo(target)) { throw new IllegalStateException("非法订单状态流转：" + current.getDesc()); } order.setStatus(target.getCode()); orderService.updateById(order);

这里的of方法可以从code反查枚举，避免在业务代码里散落魔法数字。答辩时你就可以说：订单模块采用状态机模式，所有状态跳转集中管理，非法流转会被拦截，而不是靠散落的 if 判断。这一句话，就能把项目从“增删改查”拉到“有状态设计意识”的层面。这个改进做完，不只是为了答辩——它也能避免真实运营中并发操作把订单搞到不可恢复的脏状态。我所有这类项目拿到手，第一件事都会把类似status这种裸字段收拢成枚举，这个习惯帮我少踩了很多次隐形翻车的坑。希望这篇笔记能让你少走一趟弯路，把精力省下来去打磨真正难的部分。

本文还有配套的精品资源，点击获取