每年毕业季都有不少同学拿着"家政服务系统"这类选题来找我看项目，说实话这个题目听起来简单——不就是个预约下单的网站吗？真正动手做的时候才发现，业务状态流转、后台权限、页面数据渲染这些环节一环扣一环，稍微没理清就到处报错。这次我把Y20030018这个基于Java + Spring Boot + MySQL + JSP + LayUI的家政服务系统完整设计思路梳理了一遍，从数据库设计到功能实现再到部署打包，重点讲清楚每个模块为什么这么设计，以及你自己复现时最容易卡住的几个点。

这个项目适合正在做毕设或课程设计的同学参考，也适合想快速上手Spring Boot传统Web开发的初学者。整套系统的核心价值在于：用最主流的Java后端技术，搭起一个包含用户端下单、后台管理、服务预约完整闭环的可用系统，技术栈经典不花哨，逻辑清晰可复现。下面直接进入正题。

1. 先搞清楚家政服务系统到底要做成什么样

1.1 业务闭环与角色划分

很多同学一上来就写代码，写了三天发现需求变来变去。家政服务系统本质上是一个"服务预约交易平台"，核心业务闭环是：用户浏览家政服务项目，选择需要的服务并下单，平台管理员接单后派单给家政人员，家政人员上门服务，用户确认完成后进行评价。

围绕这个闭环，系统至少要拆出三种角色。普通用户负责浏览和下单；家政人员负责接单和执行服务；系统管理员负责维护服务项目、管理订单、审核用户信息。如果你的设计里还有会员充值、优惠券、投诉处理这些扩展功能，那是加分项，但核心一定是上面这条链路。

1.2 核心模块清单与功能边界

一个能交差且经得起答辩追问的系统，功能模块最少要包含这些：

• 用户端：注册登录、服务项目浏览、服务详情查看、下单预约、个人订单查询、服务评价
• 家政端：待接订单列表、确认接单、查看我的服务记录
• 管理端：服务分类管理、服务项目管理、订单管理（审核/派单/完成）、用户管理

功能边界要划清楚，不然很容易做成"啥都想做但啥都做不全"。比如用户下单之后是否支持取消，取消后状态怎么变，管理员派单逻辑是手动派还是自动派，这些细节必须在设计阶段定下来。我见过太多项目做到最后订单状态机全是乱的，就是因为一开始没定好状态流转规则。

2. 技术栈选择：Spring Boot + MySQL + JSP + LayUI的组合逻辑

2.1 为什么这套组合适合课程设计和毕设

先说个现实问题：为什么不用前后端分离的Vue + Spring Boot？因为对于毕设场景，前后端分离意味着你要维护两套工程，要做接口文档、处理跨域，还得同时懂前端工程化和后端接口设计，工作量直接翻倍。而JSP + LayUI这套组合，页面和后端在同一个工程里，数据渲染用EL表达式、JSTL标签或者LayUI自带的数据表格组件就能搞定，学习曲线平缓得多。

Spring Boot的价值在于省掉了大量Spring MVC的XML配置，内嵌Tomcat让项目可以一键启动，这在演示答辩时特别重要。MySQL是数据库的标准答案——免费、资料多、可视化工具齐全。LayUI则解决了后台管理页面"丑"的问题，它的数据表格、表单、弹层组件都是封装好的，不需要你手写大量JavaScript。

这套组合还有一个隐藏优势：它足够经典。Spring Boot的自动配置原理、JSP的运行机制、MySQL的SQL编写，面试和答辩时老师问到的都是常见问题，网上资料一抓一大把，你不会被某个冷门框架卡住。

2.2 请求从页面到数据库的完整流转路径

理解整套系统的请求流转，是排查问题的基本功。一次普通的"用户点击下单"操作，后台实际发生的数据流向是这样的：

用户浏览器提交表单 → JSP页面发送HTTP请求到Controller层 → Controller接收参数并调用Service层 → Service层处理业务逻辑（比如校验库存、计算金额）→ 调用Mapper/DAO层执行SQL → MySQL返回结果 → 逐层返回至Controller → 将数据封装到ModelAndView或返回JSON → JSP页面渲染结果展示给用户

在这个链路里，最容易出问题的两个节点分别是Controller层的参数接收（前端字段名和后端实体属性对不上）和Service层的事务控制（多张表写入时部分成功部分失败）。写代码之前把这个流程画一遍，心里就有数了。

2.3 项目目录结构与命名约定

拿到源码第一件事不是跑起来，而是先看懂目录结构。我建议的包组织方式是这样的，也是实际操作中最顺手的：

com.housekeep ├── config // 拦截器、跨域等配置类 ├── controller // 控制层：用户端/管理端/家政端分开建子包 ├── service // 业务层接口 ├── service.impl // 业务层实现 ├── mapper // MyBatis映射接口（或用JPA Repository） ├── entity // 实体类，对应数据库表 ├── common // 通用工具类、统一返回结果封装 └── interceptor // 登录拦截器

实体类命名和数据库表名一一对应，Controller负责参数接收和视图跳转，Service里只写业务逻辑不写SQL，Mapper里只写SQL不写业务判断。很多同学喜欢把所有代码堆在Controller里，前期开发是快，但答辩时老师一旦让你加个功能，你就要在几百行的方法里定位，非常痛苦。

3. 数据库设计：五张核心业务表的结构与关系

3.1 用户表与角色设计要点

家政服务系统的用户表建议和角色合并设计，用role字段区分用户类型，比拆成三张用户表省事得多。字段至少要包含id、username、password、phone、real_name、role、avatar、create_time。密码绝对不能明文存储，用MD5加盐或BCrypt加密，这个点几乎是答辩必问。

角色字段用整数区分：0表示普通用户，1表示家政人员，2表示管理员。如果你做了后台账号的初始化脚本，记得在SQL文件里固定插入一个管理员账号，初始密码加密后写入，这样系统跑起来就能直接登录后台，演示时少说很多废话。

3.2 服务项目表与分类设计

服务项目是用户下单的标的物，建议拆成分类表和服务表两张。分类表很简单，就是id和name；服务表要包含id、category_id、name、cover、price、unit、description、status。为什么要拆分类？因为用户浏览时大概率会按"保洁""月嫂""维修"这些分类筛选，你如果只做一张表，每次改分类都要动服务表的结构，很不灵活。

service表里的status字段要预留，上下架状态用1和0标识。前端用户端只查status=1的服务，管理端能看全部。这个字段别看简单，没有它你就没法在后台临时下架某个服务，只能删数据，演示时如果误操作删了，还得重新造数据，很麻烦。

3.3 订单表的状态字段设计

订单表是整个系统里最重要的表，核心字段包括：id、order_no、user_id、service_id、staff_id（接单的家政人员）、service_time、address、amount、status、remark、create_time。order_no建议用时间戳+随机数生成，保证唯一，这是线下对账的凭证。

订单状态是整个系统的灵魂，建议用整数状态机：0待接单、1已接单、2服务中、3已完成、4已取消、5已退款。状态流转方向必须单向可控：待接单可以取消，已接单可以服务中，已完成之后才能评价。你可以在Service层写一个状态变更校验方法，每次更新前先查旧状态，再判断是否允许跳转到新状态。这比对数据库直接update要靠谱得多，也方便在答辩时解释"我是如何保证业务数据一致性的"。

另外建议加上address和service_time这两个字段，它们是家政服务区别于普通电商订单的核心字段——服务是有很强的时间属性和位置属性的，没有这两个字段，整个系统就退化成了卖虚拟商品的商城。

3.4 评价表的关联关系

评价表关联用户和订单，字段包括id、order_id、user_id、score、content、create_time。一个订单对应一条评价，所以order_id可以加唯一约束。评分建议用1到5的整数，统计平均分时直接AVG()聚合就行，不要设计得太复杂。

如果你想让系统看起来更完整，可以在服务表里冗余一个avg_score字段，每次有新的评价就重新计算该服务的平均分并更新。冗余字段会带来一致性问题，但在这个场景下收益远大于成本——用户端列表页直接显示评分，不需要关联查询评价表，性能好，代码也简单。

4. 核心功能实现：从登录拦截到订单流转

4.1 登录鉴权与Spring MVC拦截器配置

用户登录后把用户信息存进Session，拦截器负责拦截需要登录才能访问的URL。先定义一个HandlerInterceptor：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { // 未登录，重定向到登录页 response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

然后注册到WebMvc配置里。这里有个容易踩的坑：必须把登录接口、注册接口、静态资源路径排除掉，否则你连登录页都访问不了，直接死循环重定向。用addPathPatterns拦截所有请求，再用excludePathPatterns放行登录页和静态资源。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/css/**", "/js/**", "/layui/**"); } }

一个容易被忽略的点：拦截器里放行的静态资源路径一定要和你页面中实际引用的路径一致。LayUI的字体文件、JS、CSS经常引用的是相对路径，如果你把资源放在static/layui下但页面里写的是/layui/xxx，那拦截器没配置好就会一直在登录页打转。

4.2 下单流程与订单状态机的代码实现

下单接口是用户端最核心的接口，它的逻辑链条长，事务控制必须到位。一个完整的下单操作要同时做三件事：插入订单记录、扣减或校验服务状态、记录操作日志。这三步必须放在同一个事务里，否则订单创建成功但日志没写入，数据对不上。

@Transactional(rollbackFor = Exception.class) public boolean createOrder(Order order) { // 1. 校验服务是否存在且在售 ServiceItem item = serviceMapper.selectById(order.getServiceId()); if (item == null || item.getStatus() != 1) { throw new RuntimeException("服务不存在或已下架"); } // 2. 生成订单号 order.setOrderNo("HS" + System.currentTimeMillis() + String.format("%04d", new Random().nextInt(10000))); order.setStatus(0); // 待接单 order.setAmount(item.getPrice()); // 3. 插入订单 return orderMapper.insert(order) > 0; }

订单号生成这里不要用UUID，UUID一串36位乱码，用户看到根本不知道是什么；用时间戳加随机数的格式，既唯一又可读。事务注解里的rollbackFor必须写，因为Spring默认只回滚RuntimeException，你手动抛出的业务异常如果不加这个参数，事务不会生效。这是我见过最隐蔽的坑之一。

后台管理员的接单派单操作，本质就是更新订单status字段，同时把staff_id设置成选定的家政人员。这里建议用SQL语句做条件更新，在update语句里加上status条件的WHERE，天然避免了并发下单时的脏写。

UPDATE `order` SET status = 1, staff_id = #{staffId} WHERE id = #{orderId} AND status = 0

4.3 后台服务管理：LayUI数据表格的前后端交互

LayUI的数据表格组件table.render是后台管理的核心交互方式。它的数据格式有严格约定：返回的JSON必须包含code、msg、count、data四个字段，code固定为0，count是数据总量，data是当前页的数据列表。后端需要写一个带分页响应对应的Controller方法：

@RequestMapping("/admin/service/list") @ResponseBody public LayuiResult list(Integer page, Integer limit, String keyword) { List<ServiceItem> list = serviceMapper.selectByPage( (page - 1) * limit, limit, keyword); int count = serviceMapper.countByKeyword(keyword); return LayuiResult.ok(count, list); }

前端通过LayUI的table组件直接绑定URL和数据列：

table.render({ elem: '#serviceTable', url: '/admin/service/list', page: true, cols: [[ {field: 'id', title: 'ID', width: 80}, {field: 'name', title: '服务名称'}, {field: 'price', title: '价格'}, {field: 'status', title: '状态', templet: function(d){ return d.status == 1 ? '上架中' : '已下架'; }} ]] });

这里最容易出问题的就是分页参数。LayUI默认传入的page参数是当前页码，limit是每页条数，但你从数据库分页时用的是offset和size，必须手动做(page-1)*limit的换算。很多同学直接把page传进SQL当offset用，结果翻到第二页数据就错乱了。另外LayUI的搜索工具栏如果你想用，需要在table.render里加toolbar参数，并且监听toolbar事件，否则搜索框根本不渲染，这一块坑了不少人。

5. 环境搭建与项目部署：从源码到跑起来

5.1 必须注意的JDK、MySQL、Tomcat版本搭配

这个项目涉及Spring Boot + JSP + MySQL三个核心组件的版本搭配，简直就是版本地狱的重灾区。先说结论，经过多次验证的稳妥组合是：JDK 8 + Spring Boot 2.3.x + MySQL 5.7 + 内嵌Tomcat 9。这套组合兼容性最好，网上资料最多，遇到问题基本都能搜到答案。

如果你用了JDK 11以上或者Spring Boot 2.7以上的高版本，就要小心了。Spring Boot 3.0开始强制要求JDK 17，且它的JSP支持方式有变化，很多老教程直接失效。我建议凡是毕设，不要追求最新版本，用稳定组合比用新版框架省心得多。网上搜"springboot版本太高"这个热门词的同学，多半就是被版本坑过。

MySQL方面，安装时务必选5.7版本而不是8.0，8.0的默认认证插件是caching_sha2_password，老一点的JDBC驱动连不上，会报认证插件错误。如果你非要装MySQL 8.0，那就在连接串里加上allowPublicKeyRetrieval=true参数，同时把用户的认证插件改成mysql_native_password，这个操作网上教程很多，但不提前处理就会卡在第一步。

5.2 application.properties中反复出错的配置项

数据源配置是所有项目跑不起来的头号原因。一个能用的最小配置长这样：

server.port=8080 spring.datasource.url=jdbc:mysql://localhost:3306/housekeep?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false spring.datasource.username=root spring.datasource.password=123456 spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.mvc.view.prefix=/WEB-INF/jsp/ spring.mvc.view.suffix=.jsp

要重点解释三个参数：serverTimezone不写，高版本的mysql-connector-java会报时区错误；characterEncoding=utf8不写，页面和数据库之间传中文必乱码；useSSL=false是为了避免MySQL 8.0默认SSL握手导致的"SSL connection error"报错。这三个参数缺一个，项目就跑得不安稳。

JSP视图解析器配置也有讲究。prefix要指向/WEB-INF/jsp/这个路径，把JSP页面放在WEB-INF目录下有个额外好处：用户无法通过URL直接访问这些页面，安全性有保障。很多同学图省事把JSP放在webapp根目录，也能跑，但答辩时如果你说"我做了页面权限控制"，老师一访问WEB-INF外部的JSP文件直接能看到内容，场面就会很尴尬。

5.3 打包方式选择：为什么毕设建议打WAR包

Spring Boot默认打JAR包，但JSP对JAR包的支持并不友好。如果你用JAR包方式运行，JSP页面不会被打进包内，运行时访问页面会报404。所以用JSP做视图的项目，正确打包方式是WAR包。

在pom.xml里做三件事。第一，把packaging改成war：

<packaging>war</packaging>

第二，排除Spring Boot内嵌的Tomcat，不让它和外部Tomcat冲突：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency>

第三，重写SpringBootServletInitializer的configure方法，这是WAR包部署到外部Tomcat时能被正确加载的关键：

@SpringBootApplication public class HousekeepApplication extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { return builder.sources(HousekeepApplication.class); } public static void main(String[] args) { SpringApplication.run(HousekeepApplication.class, args); } }

打包命令用mvn clean package，生成的WAR文件丢到Tomcat的webapps目录下，启动Tomcat就能访问。如果你想用IDEA里内置的Tomcat调试，那就直接用Spring Boot的main方法启动，开发时两种方式灵活切换。

6. 复现项目时最容易踩的坑与排查思路

6.1 MySQL连接报错：时区与SSL的常见组合问题

复现这个项目时，启动阶段最常见的报错有两个。第一个是"Could not create connection to database server"，原因就是serverTimezone没配，或者配了但格式不对。第二个是"SSL connection error"，前面配置文件里加了useSSL=false就能解决。

还有一类Linux环境下特别容易出现的报错："ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'"。这不是项目代码的问题，而是MySQL服务没启动或者socket文件路径不对。排查思路是先在命令行里用mysql -uroot -p验证能不能进MySQL，如果能进但Spring Boot连不上，那就检查3306端口是否被防火墙拦截，用netstat -tlnp | grep 3306看看监听状态。记住一个原则：先命令行验证MySQL本身可用，再排查项目配置，不要一上来就怀疑代码。

6.2 JSP页面中文乱码的处理链路

JSP中文乱码是最磨人的问题，因为它在三个环节都可能出现。第一步，JSP文件头部的page指令必须设置UTF-8：

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

第二步，如果页面通过POST提交中文，要确保Tomcat的编码处理正常。Spring Boot的CharacterEncodingFilter默认开启，一般没问题；如果是外部Tomcat部署，可以在server.xml的Connector上加上URIEncoding="UTF-8"。第三步，数据库连接串里的characterEncoding=utf8保证数据落库时编码正确。这三层链路任何一层断掉都会乱码，排查时逐层检查即可。我遇到的真实情况是：页面显示正常，数据库里也是对的，唯独通过JSP转发的URL里有中文参数取出来是乱码，这就是典型的Tomcat URL编码问题。

6.3 LayUI表格不显示数据的三个排查方向

如果你用LayUI的table渲染一片空白，99%是这三种情况之一。第一种是返回JSON格式不对，LayUI要求code字段为0，很多人后端封装通用返回时code写的200，表格就静默失败，控制台还不报错。第二种是数据字段名不匹配，前端cols里定义的field要和后端实体属性名完全一致，特别是驼峰和下划线的问题，比如数据库是service_type，实体是serviceType，JSON里是serviceType，前端写的却是service_type。第三种是分页参数格式问题，前面提到过的page和offset换算错误。

排查这类问题建议打开浏览器开发者工具，看Network面板中请求的响应体到底是什么内容。如果响应里count和data都正常，那就是前端字段配置不对；如果响应本身是500错误或者返回了登录页的HTML，那就是拦截器配置把接口也拦了。按这个思路走，五分钟内就能定位。

6.4 网络搜索热词背后隐藏的扩展需求

在整理这个项目资料的过程中，我发现很多搜索热词其实反映了同学们的真实痛点。比如index 4.7 解决jsp中文乱码,nginx 支持jsp吗,springboot jar反编译成项目,这些其实都是开发链路中的常见困惑。Nginx本身不支持直接解析JSP，它只负责静态资源和反向代理，动态请求还是要转发给Tomcat处理。而"JAR包反编译"这个需求，通常是源码丢了想找回，用IDEA自带的反编译插件或JD-GUI工具可以把class文件还原成可读代码，但注释和资源结构会丢失，只适合应急参考。

另外一个高频词是"springboot banner生成器"，Banner是启动时的字符画，虽说不是功能需求，但花两分钟用在线工具生成一个带自己学校和题目的Banner，启动截图发到答辩演示文档里，细节观感会好很多。这就是所谓的"答辩加分项"——技术上不复杂，但体现了你对项目的认真程度。

回到这个家政服务系统本身，我个人实际操作中的最大体会是：这类传统Web项目，代码量和难度都不算高，但牵涉的技术环节非常多，从数据库建模到前端表格渲染，每个环节都有各自的规矩。你不需要把所有技术都学到精通，但一定要把数据流转链路理解透，知道一个问题发生时会出现在链路的哪一环，排查起来才能有的放矢。最后再分享一个实用技巧：先把数据库的SQL脚本单独整理好，在README里写清楚导入步骤和初始账号密码，你会发现无论是自己调试还是交给老师检查，都省下大量沟通成本。