家政平台毕业设计怎么做？从订单状态机到答辩全流程

每年三四月份，找我帮看毕设选题的同学就多起来了。说实话，这两年我至少看到几十份“家政服务平台”的选题报告——SpringBoot、Vue、MySQL 三个关键词整整齐齐排在技术方案那一栏。很多同学会犹豫：这个题是不是太普通了？做完能学到东西吗？答辩会不会被问住？

我的回答通常是：把家政平台当一个普通的管理系统去做，确实撑不起一场合格的毕业答辩；但如果你把下单、派单、服务、评价这一整条业务链路完整做出来，再配一份把设计依据讲清楚的论文，这个项目的含金量比很多花哨的选题都高。它不炫技，但每一层都有东西可问、可讲、可验证。这篇内容我就按自己复盘过多次的路线，聊聊这个项目从技术选型、数据库设计、前后端实现到部署论文一整套到底该怎么做。

1. 家政平台选题的含金量：为什么代码量不大却适合做毕设

1.1 业务闭环怎么定义才算完整

家政平台和最常见的“XX信息管理系统”最大的区别在于：它有状态、有交易、有角色区分。一个能被评委认可的家政平台，不是只有增删改查，而是要能把业务跑通。比如用户注册后能浏览服务项目，选择保洁或月嫂服务并指定上门时间，下单之后管理员在后台能派单给具体家政人员，服务完成后用户还能对这个服务人员评价打分。这一条业务线走完，“服务闭环”就有了。

要注意，业务闭环不是功能越多越好。我看过很多同学的项目，功能列表写得满满当当，结果答辩 PPT 里每个模块都是浅尝辄止，真正的细节一问就慌。功能边界要合理：用户端、管理员端各一套，家政人员如果不想单独做一套登录页面，可以在后台用“服务人员表”加“派单操作”来代替，把逻辑讲清楚就行。

从开发量来看，这样的业务闭环涉及实体多（用户、服务项目、家政人员、订单、评价），关联关系不复杂但足够训练建模能力，代码量也在一个学期的可控范围内。最关键是，这个业务的“状态”非常清晰：订单从待支付到已完成要经历多步，每一步谁有权限改、修改时需要哪些字段，都可以写成文档，论文的好多章节也就有东西可写了。

1.2 三件套的分工与技术选型理由

先说 SpringBoot。很多人对它的理解停留在“简化了 SSM 配置”，但答辩角度你要能说清楚：它利用自动配置减少了手动装配，内嵌 Tomcat 让项目能打成可执行 jar 直接运行，同时忠实地保留了 Spring 的 IoC 和 AOP 能力。我用 SpringBoot 搭后端，最大的体感是省去了大量 XML 配置，bean 的注册和依赖注入更直观了，很适合把重心放在业务逻辑上。

再说 Vue。前后端分离已经是目前企业开发的常态，Vue 的组件化开发让前端代码能拆成一个个可复用的页面组件，数据双向绑定又让表单交互、订单状态展示这类高频操作写起来非常顺手。写毕设时我建议直接用 Vue3 的组合式 API，它会比 Vue2 的选项式 API 更容易把逻辑组织清楚，特别是登录状态、订单列表这种跨页面共享的数据，用 Pinia 管理比到处传 props 省心得多。

MySQL 则是到现在依然最主流的开源关系型数据库。订单、用户、金额这些需要事务保证的数据，用 MySQL 天然合适：InnoDB 引擎支持事务和外键，订单扣款、状态变更操作出错能回滚，不会留下脏数据。相比在毕设里硬上 MongoDB 或者 Redis 存主数据，MySQL 是稳妥且能讲明白的选择。三者的分工梳理一下就是：

实际上我现在做真实的小型业务系统，这套组合仍然是默认起点——它足够健壮，也不至于杀鸡用牛刀。技术栈本身没什么好纠结的，真正拉开差距的是后面系统设计这一步。

2. 系统设计的先后顺序：先把订单状态机想清楚

2.1 功能模块划分：用户端、管理端与人员表的处理方式

做设计之前，先画角色。我的建议是平台按三类人考虑：普通用户（下单方）、管理员（运营方）、家政人员（服务方）。家政人员如果不在系统里登录操作，那就在后台派单时通过“家政人员表”进行关联，数据模型上必须有这个实体，否则订单归属说不清楚。

接下来是权限设计。用户只能操作自己的订单，管理员能看所有订单并派单，这是最基础的数据隔离。功能列表我推荐以下这些，覆盖业务闭环且不虚浮：

• 用户端：注册登录、服务项目浏览、按分类筛选、下单选时间、模拟支付、订单列表与详情、取消订单、服务完成后评价。
• 管理端：登录、服务项目管理（增删改查）、家政人员管理、订单管理（查看详情、分配人员、更新服务状态）、评价管理（可见、可删除）、基础数据统计（订单量、营业额）。

注意：在线支付这种功能，写起论文来容易把自己绕进去。没有实际第三方支付接口的情况下，建议用“模拟支付”表述——生成一笔支付流水，更新订单状态为已支付即可。这既符合业务逻辑，又不需要资质说明，答辩时也更诚实。

2.2 核心表结构与订单状态流转规则

表结构是整个系统设计的核心，我做完这个项目最大的体会是：表设计得不好，后面代码再怎么补救都别扭。核心表至少包括：用户表 user、家政人员表 worker、服务项目表 service_item、订单表 order、评价表 comment、管理员表 admin，可选的有公告表、支付流水表。

订单表是重中之重，字段建议这样设计：订单编号 order_no、下单用户 id、服务项目 id、家政人员 id、预约上门时间 appointment_time、订单状态 status、金额 amount、备注、创建时间、更新时间、支付时间。订单编号一定要独立生成，不要用自增 id 充数，方便在支付流水、日志、对账时定位。

状态字段推荐用 tinyint 存数字，每个数字含义在注释和枚举类里写清楚。数字相比字符串占用空间小、查询快，配合枚举类能避免魔法值散落代码各处。我常用的状态定义是：

关键是要在数据库设计文档里把状态流转图画清楚：待支付只能流转到已取消或待派单，已完成的订单不能再取消，这些约束写清楚，答辩时就是加分项。

外键和索引不要乱加。订单表的用户 id、服务项目 id、家政人员 id 建立普通索引即可，用户 id 和状态经常联合查询，也可以建联合索引。性别、备注这类字段不要建索引，否则是浪费空间、拖慢写入。我早期图省事把每个外键都设置为物理外键，结果删除项目时经常报错。项目开发期用逻辑外键，只在代码和文档里维护关系，反而省心不少。

3. 后端骨架搭建：登录鉴权、下单事务与接口约定的取舍

3.1 分层结构与 JWT 登录鉴权的落地方式

后端项目结构直接用标准分层：controller（接收请求）、service（业务逻辑）、mapper（数据库操作）、entity（实体）、config（配置）、common（统一返回、异常、工具类）。很多网上源码喜欢把所有代码挤在 controller 里，能用，但后期改一个字段要改三个地方，而且论文里的“系统设计”没法写，所以我不建议学习阶段这样省事。

登录鉴权是每个后端都要过的关。这里我建议用 JWT 而不是 Session。Session 依赖服务端存储，前后端分离部署后要处理跨域 Cookie、集群 Session 同步一堆问题，而 JWT 把用户身份信息放在令牌里，登录后后端把生成的 token 返回给前端，前端后续请求在请求头带Authorization: Bearer token，后端通过拦截器验签解析出用户信息即可。

在 SpringBoot 里做这个链路并不复杂：写一个 JwtUtil 工具类负责生成和解析 token，配置一个拦截器 HandlerInterceptor，在 preHandle 中放行登录和注册接口，其余接口都验 token。拿到 token 后把用户 id 放进 ThreadLocal，service 层随时能取到当前登录用户，写“我的订单”接口时就不用再靠前端传用户 id 了。这样避免了一个容易被评委挑刺的漏洞：篡改用户 id 越权查看他人订单。

密码存储至少用 BCryptPasswordEncoder 做哈希，别用 MD5。MD5 已经被彩虹表打穿，答辩时问到加密方案是减分项。Entity 里不返回密码字段，统一返回体 Result 封装状态码、消息、数据，全局异常用 @RestControllerAdvice 兜住，这些虽然基础，但会让代码观感一下子很“工程化”。

3.2 下单接口的校验与事务边界

下单接口是核心业务，校验逻辑不能少。用户下单时后端要做几步检查：服务项目是否上架、预约时间是否在合理范围（比如不能是过去时间）、该时段该家政人员是否已排单，以及用户是否有未完成订单（防止重复下单）。这些校验都通过后，再开启事务创建订单，状态置为待支付。

我自己的实现里，防重复下单用的是数据库层面加约束：用户 id、订单状态、预约时间组合一个场景判断，先查有没有“待支付”或“待服务”的订单，有就直接拒绝，提示用户先处理已有订单。那段时间我还真遇到过一个场景，用户连续点了两次“立即预约”生成两笔订单，就是没做好这个幂等判断，后来在前端也加了按钮防重复点击，后端也加了校验，双保险才算稳。

订单状态流转不要散落在 service 里到处改 status，建议封装成 OrderService 内部的 stateChange 方法，并维护一张状态流转允许表（用 Map 或 switch 都行），不允许的流转直接抛业务异常。比如待支付点击取消就进入已取消，已完成不能再次改成待支付。这样做最大的好处是：业务规则集中在一处，论文里能写清楚，答辩问到“如果服务中途用户取消怎么办”也有明确回答。

涉及金额或状态变更的接口，方法上加@Transactional，保证异常时整体回滚。尤其是支付模拟和订单状态更新，两步操作必须在一个事务里：先插入支付流水，再更新订单状态，任何一步失败都不能留下“钱付了但订单还是待支付”的不一致状态。

3.3 接口规范与全局异常的统一处理

前后端分离的项目里，接口约定直接决定联调效率。我建议后端所有接口都用 RESTful 风格：资源用名词复数，动作靠 HTTP 方法表达。GET /api/order/{id}查单笔订单，POST /api/order下单，PUT /api/order/{id}/status更新状态，DELETE /api/order/{id}取消。统一前缀 /api，方便 Nginx 转发和前端 axios 的 baseURL 配置。

返回结构统一，比如：code（0 成功，非 0 失败）、message、data 三个字段。前端 axios 响应拦截器里遇到 code 非 0 直接弹提示，遇到 401 跳登录页。分页统一用 PageResult 封装，查询接口参数用 PageQuery 对象接收页码和大小。这样一套约束下来，写页面交互逻辑的人不用猜后端字段，后端不用迁就前端的临时需求，接口联调基本一两天就能过。

异常处理上，我习惯在 service 抛业务异常（比如“该时段已被预约”“订单状态不允许该操作”），全局异常处理器统一捕获后返回错误信息，而不是让 Spring 默认的异常页直接输出一大串堆栈。代码里尽量别用否定条件，多用卫语句提前返回，这个习惯也会让代码走查时舒服很多。

4. 前端页面落地：路由守卫、axios拦截器与订单交互

4.1 Vue 环境搭建与依赖版本匹配

前端环境这里坑不少。如果你直接按教程装了最新版 Node 和最新版 Vue CLI，然后又下载了一个网上开源的 SpringBoot 后端，大概率会栽在依赖冲突上。我的建议是：Node 版本选 LTS 稳定版（18 或 20），Vue CLI 或 Vite 都行，新项目推荐 Vite；如果已有的源码是 Vue2 项目，就不要强行升级 Vue3，反之也一样，前后端联调时版本一致性远比“用最新”重要。

框架之外还要装几样标配依赖：vue-router 管理路由、axios 发 HTTP 请求、Pinia（Vue3）或 Vuex（Vue2）管状态。如果你用的网络环境装 npm 依赖慢，把 registry 切换成国内镜像源，能节省一大半时间。这些内容看似琐碎，但每年都有不少人在“npm install 依赖”这一步卡住两三天，绝大部分是版本不匹配或镜像源没配好。

4.2 路由守卫、axios 拦截器和核心页面实现

路由守卫是前端安全的第一道门。未登录用户直接访问“我的订单”页面时不让他进入，router.beforeEach里检查本地存储的 token，没有就重定向到登录页。登录成功后把用户信息存进 Pinia，后续页面里的头像、昵称、订单数量都从这里读取，不需要频繁请求后端。

axios 拦截器的写法也基本固定：请求拦截器从 localStorage 取 token 加到请求头，响应拦截器统一处理业务返回——code 为 0 数据正常返回，401 说明 token 过期或无效，清掉本地状态跳回登录页，其他错误码弹错误提示。这样每个页面都不会被重复的错误处理代码污染。

核心页面我建议重点写这几块：

• 首页：服务项目卡片列表 + 分类筛选，点击“立即预约”进入下单页。
• 下单页：展示服务详情、价格、预约日期和时间段的选择器，提交前再次确认。
• 订单列表/详情页：按状态 tab 切换（待支付、待服务、待评价等），状态不同，操作按钮不同——待支付能取消，服务中能联系客服（可以做成弹窗提示），待评价能跳评价弹窗。
• 管理后台：表格展示订单，支持按状态筛选、派单弹窗（选择家政人员）、服务项目 CRUD 页面。

这里想特别说下单页的时间选择。家政平台和普通电商不同，服务时间是核心字段。我的做法是前端按后端返回的可约时段渲染时间段按钮，用户选了某天某时段，后端再校验一次是否冲突。前端只做展示，把真实验证交给后端，这样即使有人绕过前端直接调接口也拦得住。

5. 本地联调到部署运行：环境版本匹配与踩坑记录

5.1 本地环境安装顺序与版本对照

部署环节是毕设里最容易被低估的。我先给一份本地环境清单和版本建议：JDK 要用对应 SpringBoot 版本的，如果项目基于 SpringBoot2.x 就用 JDK8 或 11，如果 SpringBoot3.x 则 JDK17 起步，版本不匹配最常见的报错就是UnsupportedClassVersionError或启动直接失败。MySQL 装 5.7 或 8.0 均可，但 8.0 的加密方式、驱动类名、连接 URL 时区参数都和 5.7 不同，网上查资料时先看清楚自己版本。Maven 装了之后建议在 settings.xml 里配阿里云镜像，否则依赖下载能等到怀疑人生。

安装顺序上我习惯先把数据库建好（建库时统一 utf8mb4 字符集），再启动后端，最后再搞前端。为什么？因为后端启动依赖数据库连接，如果数据库没准备好，后端报了数据库连接失败，你还要回头排查环境，不如先把底层的依赖排掉。前端是最后接进来的，devServer 代理配好后直接 npm run dev 就能和本地后端联调。

5.2 前后端联调、打包与部署方案

本地联调最常遇到的是跨域问题。Vue 开发服务器的默认端口是 5173 或 8080，后端接口是 8080，端口不同浏览器会拦截请求。解决办法有两种：一是在 Vite 或 Vue CLI 的 devServer 里配置 proxy 代理，把 /api 开头的请求转发到后端地址；二是在后端写 CORS 配置类。我更推荐开发期用代理，因为生产部署时一般是 Nginx 反向代理，开发期用代理更贴近生产环境的行为。

演示部署推荐两种方式。第一种最省事：后端打成 jar 包，java -jar 运行在 8080，前端 npm run build 构建出的 dist 目录直接扔给 Nginx 托管，Nginx 再把 /api 请求反代到后端 8080 端口。第二种是纯本地演示：后端 jar 启动、前端 npm run dev 起开发服务器，适合答辩现场没网络的情况。注意：后端 application.yml 里的数据库连接、端口等要改成实际环境的值，打包前检查一遍，别让低级错误毁掉演示。

5.3 高频部署错误清单与解决方式

我拿到过不少网上开源的毕设源码，几乎每次部署都要踩一遍雷，这里列几个高频问题：

• MySQL 8.0 连接报错：驱动要写com.mysql.cj.jdbc.Driver，URL 里加serverTimezone=Asia/Shanghai，不然时间对不上或驱动加载失败。
• 前端刷新页面 404：如果用了 history 路由模式，Nginx 需要配置 try_files，把所有路径都回退到 index.html，否则刷新子路由页面直接白屏。
• 数据库数据乱码：建库建表统一用 utf8mb4，连接字符串追加 characterEncoding=utf8，前后端都统一编码，通常就不会乱码。
• 端口被占用：MySQL 占 3306，后端占 8080，前端 dev server 占 5173 或 8080，这三个端口是毕设里的常客，启动前先查占用。

把这些内容整理成部署文档时，不要只写“下一步下一步”，要把每步的意义和环境要求写清楚。毕业设计的部署文档，评阅老师是真的会照着操作的，你写得详细，他照着跑通了，和跑不通但你来解释，给分完全是两个级别。

6. 论文组织与答辩准备：把项目讲明白比炫技更重要

6.1 论文六章结构与核心图表的画法

论文结构一般六章：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试。这里最容易出的问题是第二章技术介绍整段抄官网，和你的系统毫无关联。正确的写法是每种技术一段，讲清楚它是什么、为什么本项目选它，比如写 Vue 时说“采用组件化开发的思想，将首页服务列表、下单表单等拆分为独立组件，提高代码复用”，这样才叫和技术结合。

需求分析部分要画用例图，把用户、管理员、家政人员三个角色分别能用哪些功能表达清楚。系统设计里重点画架构图、数据库 ER 图、订单状态流转图，这几张图是答辩时评委最常盯的地方。系统实现不要贴大段代码，选 3-5 个核心功能点，比如登录鉴权流程、下单接口的事务实现、订单状态流转的封装，用截图 + 关键代码 + 文字说明的形式展示即可。系统测试建议至少覆盖核心流程的测试用例表，包括正常场景和异常场景（比如重复下单、未登录访问订单接口），表格化呈现测试结果。

6.2 答辩高频问题与回答逻辑

答辩最怕的不是功能做得少，而是自己对项目讲不明白。我把评委最爱问的几类问题整理了一下：

• 为什么用 JWT 而不用 Session？答：前后端分离架构下 Session 跨域与集群共享成本高，JWT 无状态，服务端不存会话，天然适合分布式。
• 订单状态怎么防乱？答：维护状态流转允许表，不允许的流转直接抛异常，数据库层用枚举值限制，前端按状态渲染不同操作按钮。
• 你的数据库索引怎么建的？答：订单表对用户 id、状态建索引，高频联合查询（按用户查订单按状态筛选）建联合索引，不把空间浪费在低选择性的字段上。
• 遇到的难点是什么？答：防重复提交，解决方式是后端幂等校验 + 事务，前端按钮防抖。
• Vue 响应式原理是什么？答：Vue3 用 Proxy 代理对象，拦截 get 和 set，get 时收集依赖，set 时触发更新，渲染函数重新执行。

这些问题不要求背得多花哨，关键是结合自己的代码说，让评委觉得你是真做过。就算某个问题答得没那么全面，能立刻翻到自己的代码指着讲清楚，也是实打实的加分表现。

最后分享一个我做这类项目时的习惯：不动代码之前，先拿一页纸把订单从下单到完成之间经过的每一个状态、每一步由谁操作、涉及哪些表哪个字段写下来，贴在显示器旁边。开发过程中每懵一次就低头看一眼这张纸，十有八九是你漏了哪一步状态流转。这个习惯陪我顺利做完了不少系统，也帮我躲过不少答辩前的连环追问。如果你现在正为这个项目发愁，不妨也先试试这张“状态纸”，比盲目刷视频教程实在得多。