每年毕业季都有不少人带着类似的标题来找我——JavaSpringBoot家政服务平台家政服务管理平台Web版。说实话这类题目在计算机毕设里属于标准意义上的稳妥选择业务场景清晰、用户角色明确、技术栈主流不卷算法不碰硬件认认真真做完答辩的时候也能讲出东西。这篇就把我当时做这个选题时的完整思路、编码路径和踩坑记录摊开写出来。内容不是教科书式的步骤堆砌更多是面向我拿到这个题目之后具体该按什么顺序做什么事的一份实战笔记。无论你是准备拿它当毕设还是纯粹想练手SpringBoot全家桶都可以参考。1. 为什么家政服务平台是一个性价比很高的毕设选题先聊选题。有人觉得家政服务太土不如电商、社交、短视频类来得有面子。但走过这个过程的人会明白毕设选题的价值从来不在于名字炫不炫而在于三个维度需求是否足够清晰、模块是否能撑起工作量、答辩时是否有东西可讲。家政平台在这三个维度上表现都相当好。家政服务的核心业务是用户发起预约平台派单给服务人员服务完成后结算评价。这个链路天然包含了最典型的业务角色——用户端C端、服务端B端也就是保洁阿姨、维修师傅、管理端Admin。三个角色之间必然涉及登录鉴权、权限区分、订单流转、状态变更、消息通知、服务评价这些全部映射到SpringBoot开发里最常考的知识点。你做完一个家政平台相当于把SSM/SpringBoot里用户体系业务订单后台管理统计报表四大件都过了一遍覆盖面比单纯做个博客或问卷系统扎实太多。另外家政平台有一个天然优势需求来源非常生活化。你不用去编造一个奇怪的业务场景面试官和答辩老师一看就懂这就降低了沟通成本。你在答辩时说用户下单预约保洁服务和说平台支持多维度SKU组合定价与促销活动前者的理解门槛显然更低。对一个本科生阶段的课程设计或毕业设计而言通俗场景完整实现是一种更稳妥的得分策略。而且家政平台的边界可以自由伸缩。基础版做到用户登录、选服务、提交预约、管理员分配、服务完成就足够毕业往深了做可以加支付模拟、地图选点、实时派单、消息推送、服务人员抢单、分区定价。这意味着你在一个题目下留足了扩展空间中期检查之后想给项目加量也不慌。2. 技术选型从SpringBoot版本到数据库每一样都得能说出理由技术栈是毕设答辩必被问到的问题因为这是最能看出一个学生是不是真做了的地方。我的推荐组合和理由如下2.1 核心框架SpringBoot 2.7.x MyBatis-PlusSpringBoot用2.7.x是我的实际建议。不是因为最新版不好而是两点现实原因第一大量现成的教程、博客、毕设源码都基于2.x版本遇到问题搜索引擎弹药充足第二3.x版本在Java 17环境下运行如果本机恰好是JDK 8直接跑不起来还得折腾环境。一个毕设项目稳定压倒折腾。持久层我推荐MyBatis-Plus而不是纯MyBatis。MP提供了BaseMapper的通用CRUD方法分页插件用起来也非常顺手能把重复劳动压缩到极低。这对工期紧张的学生来说是实实在在的解放。但注意这里有一条隐藏要求哪怕你用了MP也务必要会手写SQL。答辩时老师大概率会问MyBatis-Plus和MyBatis的区别你项目中哪些查询是手写SQL的你要能当场解释而不是只会说我用了现成的框架。2.2 前端方案Thymeleaf服务端渲染是一个被低估的选择家政平台这种管理型系统前端到底要不要用Vue需要考虑成本。用Vue Element UI做一个前端工程意味着技术栈变成前后端分离意味着你要处理跨域CORS、Token传递、Vue路由懒加载等一连串问题。对于以系统功能为考核核心的毕设来说这些属于额外风险。我自己最后选择了Thymeleaf模板引擎做服务端渲染SpringBoot原生集成页面直接写在resource/templates下数据用Model传参登录状态走Session逻辑清晰代码量小而且整站一眼看上去就是一个结构完整的单体Web应用。这不代表Thymeleaf没有局限性——局部刷新、异步交互不如前后端分离流畅。但应对后台管理系统的列表页、表单页、详情页完全足够。更重要的是把精力省出来留在后端业务和数据库设计上那才是拿分大头。2.3 数据库MySQL 5.7或8.0编码和时区是重点数据库本身没有悬念MySQL就对了。真正常被忽略的是两个细节一是建库时的默认字符集必须设置为utf8mb4而不是utf8否则用户头像昵称或者评价里出现emoji字符时插入会直接报错。二是连接串上的时区参数需要在application.yml里写入serverTimezoneAsia/Shanghai否则在部分MySQL驱动版本下会报时区错误或时间偏差8小时。2.4 额外推荐的组件清单光有SSM、模板引擎还不够下面这几项几乎是我给所有做SpringBoot毕设的人的标配实际用时也都派上了用场Lombok用Data注解替代手写getter/setter大幅度压缩实体类代码量。Hutool工具类库我主要用它生成订单号、处理日期字符串。Apache Commons Lang3写业务逻辑时会涉及ObjectUtils.isEmpty这类判断引入方便。Druid连接池自带监控页面答辩时打开展示一下连接池状态有一定效果。这些选型没有一个是猎奇或复杂的全部是行业存量项目里最常见的东西。用面试的话来说这叫技术选型贴合业务复杂度本身就是加分的点。3. 核心功能梳理三端角色下的模块边界与用例设计项目里我划分了三个角色端用户端、服务人员端、管理员端。很多做毕设的同学习惯把所有写在一个Controller里谁调都行——这是后期维护混乱的根源。正确的做法是从一开始就把访问边界划清楚用不同的Controller前缀和权限校验去约束操作。3.1 用户端Customer下单、支付、评价用户端核心流程包括注册/登录手机号密码JESSIONID管理Session浏览服务分类如日常保洁、深度保洁、家电清洗、月嫂等选择具体服务项选择服务时间填写地址提交预约订单创建后模拟支付这一步我使用了状态值流转没有对接真实支付组件服务完成后对订单进行评价打分这里有一个非常重要但新手容易漏掉的需求用户能看到的服务项必须是上架状态用户能预约的时间不能早于当前时间用户下单前需要校验余额或支付状态。这些不是想象出来的业务而是你打开任意一个真实家政App都能观察到的规则。设计用例时多从真实产品里倒推需求比凭空画用例图可靠得多。3.2 服务人员端Worker接单、执行、回单服务人员角色的核心是处理被分配到自己名下的订单登录后查看分配给我的订单列表查看订单详情包含服务地址、预约时间、用户备注开始服务状态从待服务变为服务中完成服务状态变为待评价或已完成在设计上值得注意的一点是服务人员不允许看到平台全量订单只能看到经过管理员指派、且指派给自己的那一批。这就要求SQL查询中必须有worker_id这个归属条件而不是做一个全部订单列表然后前端过滤。任何时候都不要把前端隐藏数据当成权限控制。3.3 管理员端Admin人员、服务项目、订单调度、统计管理端功能最多也是整个项目工作量最好展示的地方员工账号管理服务人员的增删改查、启用禁用服务分类和服务项目管理上架、下架、修改价格、维护服务简介订单管理查看所有订单、手动指派服务人员、处理订单异常、取消订单评价管理查看用户评价可隐藏违规评价数据统计整体订单量、各分类订单占比、营收金额合计、服务人员接单排行建议数据统计部分使用ECharts图表展示。这个是整个项目视觉上最能出效果的一部分同时在答辩演讲时能当话题延展——数据统计维度是怎么设计的如果数据量变大了该怎么优化都能顺势展开。4. 数据库设计九张核心表的职责划分与关键字段说明家政平台这种规模的项目数据库表控制在9张左右最合理。过多说明你设计过度过少又撑不起系统复杂度。我最终的表结构如下member用户表用户端id、手机号、密码BCrypt加密、昵称、头像、性别、注册时间、状态worker服务人员表id、姓名、手机号、密码、擅长服务分类、简介、评分冗余统计值、状态admin管理员表id、用户名、密码、角色等级、创建时间category服务分类表id、分类名称、排序值、图标、创建时间service服务项目表id、分类id、服务名称、封面图、单价、计量单位、服务时长、上架状态、简介orders订单表id、订单号、用户id、服务项目id、服务人员id可空待指派、服务时间、地址、联系人、联系电话、订单金额、状态、创建时间、支付时间、完成时间evaluation评价表id、订单id、评分、评价内容、评价图片、创建时间address用户地址表id、用户id、联系人、电话、详细地址、是否为默认地址operate_log操作日志表id、操作人、操作类型、操作内容、操作时间4.1 订单状态字段怎么设计整数状态枚举才是正确答案订单状态是家政系统里最核心的字段我强烈建议用tinyint整数存储而不是直接存中文字符串。例如0待支付1待指派2待服务3服务中4已完成5已取消6退款/异常。在Java代码里写一个OrderStatusEnum去映射这些数字和描述。这样做的好处有三个数据库层面状态检索效率高索引对数字友好前后端传递数据时不需要解析中文不会出现已完成和已完成 这种肉眼难辨的空格差异状态机的流转条件在Java枚举里可以写死避免业务层随意改状态。4.2 订单号的生成规则时间戳随机数就够用毕设不需要引入分布式ID方案但直接用MySQL自增id做订单号并不专业答辩可能会被问。我用的规则是yyyyMMddHHmmss 4位随机数。例如202405211430159281。这个格式可读性强能看出下单时间也足够支撑毕设演示场景。生成逻辑用Hutool里的DateUtil和RandomUtil拼接即可十几行代码解决。4.3 索引设计与冗余字段小项目也要有意识虽然数据量不大但设计表时建议还是把索引加上orders表的user_id、worker_id、status三个字段分别加普通索引orders表的主键使用bigint自增订单号字段加唯一索引——虽然随机数碰撞概率极低但唯一索引能从根本上杜绝重复也能作为一个亮点在答辩时说。另外worker表中的评价分数字段我采用了冗余存储每次用户提交评价时更新该worker累计评分和评价次数展示时直接取平均值即可不需要每次都去重算。这种空间换时间的思路在答辩时同样是可以讲的优化点。5. 核心痛点与编码实现登录鉴权、下单流程和状态机到了代码实现这一层我只挑三个最考验业务思维的环节展开登录鉴权的实现方式、下单预约的完整事务流程、订单状态机的流转控制。5.1 登录鉴权Session方案 拦截器校验权限Thymeleaf单体应用不需要引入Spring Security或JWT用Session配合HandlerInterceptor就能把权限控制做得很清晰。我写了两个拦截器LoginInterceptor检查当前Session中是否存在loginUser/loginWorker/loginAdmin不存在就重定向到对应用户端或后台的登录页。AdminInterceptor在LoginInterceptor的逻辑基础上再校验Session中的角色值是否等于管理员防止普通用户登录后直接访问admin路径下的管理接口。注册拦截器时要注意SpringBoot 2.x的写法实现WebMvcConfigurer接口重写addInterceptors方法设置excludePathPatterns排除登录页、静态资源/static/**、用户注册接口等。如果你在org.springframework.boot:spring-boot-starter-web里直接继承WebMvcConfigurerAdapter那是旧版写法现在编译会报错。5.2 下单预约的核心事务与校验顺序下单是整个系统里逻辑最复杂的操作涉及多张表的数据变化。我的下单方法事务实现顺序如下校验用户登录状态取出当前登录用户id。根据serviceId查询服务项目检查服务是否处于上架状态。校验提交的serviceTime不能早于当前时间精确到分钟。校验联系人、联系地址不为空。生成订单号构造Order实体状态设置为0待支付。插入订单记录返回订单id。用户点击模拟支付在支付方法中根据订单id将订单状态从0更新为1待指派同时更新支付时间。这里有一个值得专门说的问题下单和支付要不要放在同一个方法里我的选择是拆开因为现实业务中创建订单和支付本来就是两个动作。拆开之后订单数据能保留未支付的状态列表里可以展示待支付标签逻辑更干净。如果你把两个动作硬拼在一个方法出现支付失败、订单却创建成功的场景就非常难处理。在事务管理上下单方法标注Transactional(rollbackFor Exception.class)表示任何异常都回滚。很多同学只写Transactional不写rollbackFor这是不严谨的。默认情况下RuntimeException才触发回滚如果方法里出现受检异常而你没有声明回滚类型数据可能就半成功地写入库了。这一段我建议在答辩时主动说出来能看出你是真研究过。5.3 状态机的控制集中写一个执行状态变更的服务订单状态流转如果散在多个Service里到处写update语句后面改需求时会焦头烂额。我专门写了一个OrderStatusService方法签名类似public boolean changeOrderStatus(Long orderId, Integer fromStatus, Integer toStatus)所有涉及订单状态变化的地方都直接调用这个方法。底层SQL是UPDATE orders SET status #{toStatus}, update_time NOW() WHERE id #{orderId} AND status #{fromStatus}这里用上了条件更新的巧思如果订单当前状态不是预期的fromStatus更新影响行数为0方法返回false说明本次状态流转非法。这样从数据库层面就杜绝了用户反复提交、并发操作导致的状态错乱。举例来说用户支付订单fromStatus传0、toStatus传1管理员指派服务人员fromStatus传1、toStatus传2服务人员开始服务fromStatus传2、toStatus传3。整个链路清晰而且每一条流转都有审计可查。5.4 管理员指派服务人员时的分页和条件查询指派功能的后端核心是查询当前状态为待指派的订单列表并为每一笔订单选择可用的服务人员。这里我用MyBatis-Plus的分页插件配合自定义查询条件。SQL里需要JOIN三张表orders、service、worker。查询条件包括订单号模糊查询、下单时间范围查询、状态筛选。直接用LambdaQueryWrapper处理单表简单查询遇到多表查询就在Mapper里写Select注解的SQL语句。一个Mapper方法一个SQL结构保持简单明了。6. 真正的坑都在这里版本兼容、路径映射和前端联调讲完了主干实现再说项目落地过程中最容易让人卡壳的几个坑。很多同学代码逻辑写得很顺一运行就是404、500轮着报十有八九都是下面这些问题。6.1 SpringBoot版本过高导致的javax→jakarta包名问题这是在SpringBoot 3.x时代非常高频的报错。如果你用了Spring Boot 3.x会发现自己import javax.servlet.http.HttpServletRequest时编译不过去。原因是从Spring Boot 3.0开始Servlet规范从javax迁移到了jakarta。如果按照老教程写拦截器、Controller看到红色报错不要慌把javax改成jakarta即可。但我个人建议毕设还是用2.7.x避掉这层折腾。6.2 静态资源404Thymeleaf模板路径和静态资源路径的问题新手最常见的错误是application.yml里没配置spring.mvc.static-path-pattern或配置成了/static/**然后页面里的css、js全部加载不出来。默认情况下SpringBoot的静态资源是映射到/**的实际放在classpath:/static/目录下即可。如果你自定义了拦截器还要注意excludePathPatterns里有没有放行静态资源路径否则登录页面会拿不到bootstrap样式。6.3 使用MyBatis-Plus时时间字段自动填充很多人在插入订单时手动setCreateTime但更省事的做法是使用MP的自动填充功能。在实体类的createTime字段上标注TableField(fill FieldFill.INSERT)然后写一个MetaObjectHandler实现类在insertFill方法里统一设置创建时间。这里有一个坑一旦引入了MP的自动填充你在别处手写insert操作时有可能因为漏掉时间字段插入的数据时间字段为空。我最后所有订单写入操作都在同一个地方维护避免了这个问题的扩散。6.4 前端表单提交时的日期格式问题Thymeleaf页面里提交datetime-local类型的 浏览器传给后端的时间字符串会是2024-05-21T14:30这种带T的格式。如果后端直接用Date类型接收并配置了指定pattern就会报格式转换异常。我的解决办法是在实体类上增加DateTimeFormat(pattern yyyy-MM-ddTHH:mm)注解或者在Controller入参前用字符串接住再通过Hutool的DateUtil.parse转换为Date类型。推荐后者因为后端前后格式可控不被框架的全局配置牵连。6.5 时间显示相差8小时这个问题通常只出现在展示层。如果MySQL连接串没设置serverTimezone参数JDBC驱动可能是高版本默认使用服务器本地时区而服务器时区可能是UTC就会导致查询出的时间比实际早8小时。排查方法很简单在application.yml的数据库连接串后增加serverTimezoneAsia/Shanghai并且实体类中时间字段统一使用java.util.Date或LocalDateTime尽量避免混用。7. 部署测试与答辩准备让项目跑在别人的机器上也不慌项目写完不算完你需要在至少一台全新环境的机器上把它跑起来然后以答辩评委的身份去审视它。很多同学在自己电脑上开发时依赖了一堆本机专用配置换一台机器就起不来这类情况必须提前规避。7.1 打包部署用Maven打jar包而非在IDE里跑SpringBoot项目推荐打成可执行jar包部署这样在服务器上有Java环境就能运行。项目根目录执行mvn clean package -Dmaven.test.skiptrue打包完成后后台启动方式nohup java -jar target/housekeeping-platform-0.0.1-SNAPSHOT.jar --server.port8080 app.log 21 这里有一个常踩的坑如果你在application.yml中配置了文件上传路径或本地磁盘路径换机器后这些绝对路径可能不存在。我统一把这些路径配置放在application.yml里并通过ConfigurationProperties注入部署时只需修改配置文件不需要改代码。这也是一个可以在答辩时提及的工程化设计。7.2 测试用例的准备比数量更重要的是覆盖关键业务链路毕设演示最忌讳的是当场操作不顺。我的建议不是要你写几百个单元测试而是至少把手动冒烟用例列成一张表按顺序执行一遍确认没有问题。我的核心用例表至少包含用户注册→登录→浏览服务分类→查看服务详情→下单→支付管理员登录→添加服务人员→新增服务分类→新增服务项目→查看订单→指派服务人员服务人员登录→查看我的订单→开始服务→完成服务用户对已完成的订单提交评价→管理员后台查看评价非法访问用户直接访问admin路径被拦截跳转这几条链路完整走通后演示过程中基本不会翻车。如果有条件建议录屏存一份防止演示现场领导电脑连不上数据库。7.3 答辩时老师常问的几个问题提前准备答案结合我实际参加答辩和帮助别人答辩的经验老师对这个项目偏好问以下几个问题订单状态是怎么管理的如何在并发下防止状态错乱 答状态用整数枚举表示状态流转变更走专门的Service方法底层是带状态条件的UPDATE影响行数为0即非法流转。MyBatis-Plus和MyBatis的区别你手写了哪些SQL 答MP内置通用CRUD、分页插件、自动填充手写SQL集中在多表关联查询和统计类SQL并解释一两个具体场景。如何保证用户只能操作自己的订单 答所有订单查询方法初始化时都强制带上user_id条件用户id从Session中获取而非前端传参前端传参可被篡改是新手最易忽视的漏洞。如果数据量大了系统怎么优化 答从索引优化、分库分表思路、缓存Redis缓存服务项目和热门分类、读写分离引入主从这几个方向作答。不需要真的实现但要有思路。为什么要选这个题目创新点在哪 答回答的要点是业务链条完整、角色清晰、贴近真实的O2O业务形态以及你为了提升体验做的细节优化比如订单状态机、条件更新防止并发错乱、操作日志审计。创新点可以体现在方案设计的严谨性不必硬凹一个高深算法。8. 写在最后的心得回头再看这个项目家政服务平台的复杂度恰好落在一个本科生跳一跳能够到的位置上。它需要你认真设计数据库表结构需要你理解订单状态在真实业务中的流转也需要你面对前端页面和后端Controller互相配合的那些琐碎问题。做完这一整套你对SpringBoot的理解不会再停留在照着教程写个HelloController的层面。如果你正在准备这个题目我最后有一个建议一定不要只做能跑而是要为项目写一份结构清晰的README把启动步骤、默认账号、测试数据、核心流程说明放进去。这一份文档既是答辩的底气也是你代码之外的加分项。遇到问题也不要急着搜毕设源码往下抄自己把Bug调通一遍远比拿到一份完美源码更有收获。祝顺利。