简介一份基于 Java SSM MySQL 微信小程序的家政服务管理系统完整毕业设计资源包适合高校学生用于毕设、课程设计或期末大作业。项目已通过导师指导并调试可运行包含前后端全部源码、数据库脚本及论文文档覆盖用户、家政服务、订单管理等核心业务模块界面美观且操作便捷。包体共1213个文件以 Vue/JS/Java 源码、微信小程序 WXML/WXSS、JSON 配置、SVG/PNG 图片及 SQL 脚本等为主另有说明文档、Maven 配置和部署工具压缩包约16.41MB目录结构清晰便于直接导入 IDEA 和微信开发者工具运行学习。目前已有86人学习下载。资源除可运行系统外还附带毕业设计论文和软件工具能帮助读者理解 SSM 分层架构、微信小程序前后端交互及 MySQL 数据设计是一份高完成度的实战参考。1. 家政项目小程序这套毕设到底在解决什么问题“基于 javassmmysql微信小程序的家政项目小程序”这个标题拆开看是一个很典型的本科毕设全家桶后端用 Java 的 SSM 框架数据库用 MySQL前端是微信小程序压缩包里还配套源码、SQL 脚本和一篇可以直接改的毕业论文。它的价值不在于技术有多前沿而在于把“用户下单-后台派单-服务人员接单-订单验收-评价”这条完整闭环串了起来这正是本科生拿得出手、也讲得清楚的系统形态。适合手里有一定 Java 基础、小程序写过简单页面的学生用一学期时间把系统设计和论文一次搞定。但先泼一盆冷水你最容易翻车的不是 Spring 配置而是订单状态流转、前后端参数名对不上这类细节。2. SSM 后端架构拆解先看懂三层再动手改代码2.1 这个项目为什么用 SSM 而不是直接上 Spring Boot很多刚接触 java、ssm、mysql、微信小程序这组搭配的读者第一反应是“老师为什么不让我直接用 Spring Boot”。原因其实很实际毕设答辩要看原理。SSM 是 Spring SpringMVC MyBatis 的缩写每一层都对应一个能讲清楚的概念Spring 负责对象创建和依赖注入SpringMVC 负责把微信小程序发来的请求映射到 Java 方法MyBatis 负责把 SQL 语句和 Java 对象互相转换。导师推荐 SSM 的真正理由是“透明”。Spring Boot 把 Tomcat 内嵌、自动装配、约定大于配置全部藏起来了学生跑起来很快但一问“请求是怎么进到 Controller 的”就卡壳。SSM 的请求链路是显式的小程序发 HTTP 请求到 TomcatDispatcherServlet 接收HandlerMapping 找到对应的 Controller 方法再往 Service、Mapper 一层层传下去。答辩时按这条链路讲老师会觉得你是真做了而不是只敲了一堆启动命令。另外注意一个差别网上现在搜“mybatisplus根据java实体类生成创建表的sql语句”能出来一堆教程那是 Spring Boot 配合 MyBatis-Plus 的玩法通过实体类注解自动维护表结构。这套毕设用的是传统 MyBatis 手写 SQL表结构以 SQL 脚本为准Java 实体类只负责映射不要把两套思路混在一起改否则项目管理器会扫不到 mapper 文件。2.2 Controller 层统一返回体与参数接收拿到这套源码后建议先从 Controller 层看起因为它是小程序和后端的第一道关卡。常见做法是项目里写一个统一的 Result 类封装 code、message、data 三个字段小程序端拿到响应后先判断 code 再取 data。下面是一段典型的下单与订单查询接口RestController RequestMapping(/api/order) public class OrderController { Autowired private OrderService orderService; PostMapping(/create) public Result create(RequestBody OrderCreateDTO dto) { // 小程序端传 serviceId、appointTime、address、remark Long orderId orderService.createOrder(dto); return Result.ok(orderId); } GetMapping(/list) public Result list(RequestParam(required false) Integer status, RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer pageSize) { return Result.ok(orderService.queryUserOrders(status, page, pageSize)); } }RestController 表示这个类的所有方法都返回 JSONRequestBody 让 SpringMVC 自动把请求体里的 JSON 绑定到 OrderCreateDTO 对象上status 参数可空空的时候查全部订单page 和 pageSize 给默认值避免小程序端少传参数导致报错。这里有个经验接收参数务必写 DTO 而不是直接用 Map。用 Map 接收确实省事但改字段名时编译器完全不提醒前端和后端经常要为“serviceId 还是 service_id”这种问题来回调半天。2.3 Service 层订单状态机是这套系统的灵魂家政系统的核心不是简单的增删改查而是订单状态流转。同一个订单要经历待接单、已接单、服务中、待验收、已完成、已取消这几个状态每一步都必须做前置校验。很多学生图省事用 updateByPrimaryKeySelective 直接改状态字段结果用户刚取消订单服务人员那边还能接单。正确做法是给状态变更加“前置状态”条件类似乐观锁public boolean changeStatus(Long orderId, Integer fromStatus, Integer toStatus, Long operatorId) { // 只允许在指定的前置状态下完成迁移防止多端同时操作互相覆盖 int rows orderMapper.updateStatusIfCurrent(orderId, fromStatus, toStatus); if (rows 0) { // 影响行数为 0说明当前状态已经不是 fromStatus禁止覆盖 throw new BizException(订单状态已变化请刷新后重试); } return true; }这段逻辑的关键在 updateStatusIfCurrent 这条 SQLwhere 条件里除了主键还要带上 status #{fromStatus}。这样即使用户取消订单和管理员派单同时发生也只有先到的那次操作能成功。答辩时老师问“怎么防止并发重复接单”把这段代码翻出来讲比背一堆并发理论更有说服力。2.4 MyBatis 映射文件订单列表的分页与模糊查询MyBatis 的 mapper XML 通常放在 resources/mapper 目录下或者和 Mapper 接口同包。订单查询是整套系统里最常被改的 SQL最常见的写法是带 where 条件拼接、多表左连接和分页select idpageUserOrders resultTypecom.example.pojo.OrderVO SELECT o.order_id, o.order_no, o.service_name, o.appoint_time, o.address, o.status, w.worker_name, w.phone FROM t_order o LEFT JOIN t_worker w ON o.worker_id w.worker_id where if testuserId ! null AND o.user_id #{userId} /if if teststatus ! null AND o.status #{status} /if if testkeyword ! null and keyword ! AND (o.order_no LIKE CONCAT(%, #{keyword}, %) OR w.worker_name LIKE CONCAT(%, #{keyword}, %)) /if /where ORDER BY o.create_time DESC LIMIT #{offset}, #{pageSize} /select标签会自动去掉第一个多余的 AND避免把所有条件都写在 where 11 里LEFT JOIN 而不是 INNER JOIN是为了防止订单还没派单时 worker_id 为空导致订单查不出来。LIMIT 分页里注意 offset 要在 Java 层算好通常传 (page-1)*pageSize。模糊查询一定要用 CONCAT 拼接 % 而不是直接写 %#{keyword}%后者 MyBatis 解析会出错。这条 SQL 里用 bind 或 concat 处理也顺手把 SQL 注入的风险挡掉了。3. 数据库设计与初始化先懂 6 张核心表再动工程3.1 拿到 SQL 脚本后先建库再按依赖顺序建表这类毕设压缩包里一般会带一份 xxx.sql有的表结构和初始化数据都齐全有的只有建表语句。常见做法是先建库再按依赖顺序建表最后插数据。MySQL 建议直接用 5.7 或 8.0 的稳定版本SSM 老工程用 5.7 更省心特别是 5.7.44 安装过程相对平滑遇到 utf8mb4 编码问题的概率也小。建表时要特别关注字符集SSM 项目里最常见的表结构如下表名作用核心字段t_admin后台管理员账号用于派单和内容管理admin_id, username, passwordt_user微信小程序注册用户user_id, openid, nickname, phonet_worker服务人员保洁、月嫂、维修工worker_id, worker_name, phone, service_typet_service服务项目目录service_id, service_name, price, unitt_order核心业务表记录每笔订单全生命周期order_id, order_no, status, appoint_timet_comment订单完成后的评价comment_id, order_id, score, content不要一上来就导数据先看外键关系。比如 t_order 里的 user_id 引用 t_userworker_id 引用 t_workerservice_id 引用 t_service如果 t_user 里一条数据都没有就插订单外键校验会直接报错。另外注意 t_worker 表不一定有 service_type 这个字段有些设计是把服务人员做成独立的表有些设计是直接挂在 t_service 下面不同版本的 SQL 脚本差异很大先花十分钟把表关系画出来再动工程。3.2 订单表字段设计这套 SQL 可以直接抄订单表是家政系统里信息量最大的表也是论文里“数据库设计”章节的重要组成部分。很多毕设只给订单表设计五个字段订单号、用户、状态、时间、金额结果做完下单功能才发现没有存服务地址、没有预约时间字段回头再改表结构特别痛苦。建议直接参考下面这种字段设计CREATE TABLE t_order ( order_id int(11) NOT NULL AUTO_INCREMENT COMMENT 订单自增主键, order_no varchar(32) NOT NULL COMMENT 订单编号例如 HG20250101001, user_id int(11) NOT NULL COMMENT 下单用户ID关联 t_user, worker_id int(11) DEFAULT NULL COMMENT 接单服务人员ID关联 t_worker, service_id int(11) NOT NULL COMMENT 服务项目ID关联 t_service, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待接单 1已接单 2服务中 3待验收 4已完成 5已取消, appoint_time datetime DEFAULT NULL COMMENT 预约上门时间, address varchar(255) NOT NULL COMMENT 服务地址, total_price decimal(10,2) DEFAULT NULL COMMENT 结算金额线下结算, remark varchar(500) DEFAULT NULL COMMENT 用户备注, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (order_id), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT家政服务订单表;这里有几个值得抄的设计决策status 用 tinyint 而不是 varchar状态码在 Java 层定义常量或者枚举类不要在代码里写魔法数字 3、4order_no 单独一列而不是直接暴露自增主键因为订单号要展示给用户看自增 id 会暴露系统每天的单量金额用 decimal(10,2) 而不是 floatfloat 的二进制精度问题在金额计算上是致命伤create_time 用数据库默认值生成不要依赖后端代码传时间这样小程序端就算不传时间字段也不会报错。3.3 初始化数据的导入顺序与常见报错初始化数据建议用 mysql 命令行导入而不是在 Navicat 里手动一条条点效率差很多。导入脚本前确认库已经建好mysql -u root -p housekeeping housekeeping.sql导完以后用 select count(*) from t_service 这类语句验证每个表的数据量。如果导入失败按字符集、外键顺序、SQL 语法三个维度排查表与表之间字符集不一致容易报 “Incorrect string value”统一用 utf8mb4多表插入顺序遵循“先主表后从表”先插 t_service 再插 t_order如果 SQL 脚本里有 DELIMITER 开头的存储过程命令行导入没问题但 Navicat 里直接执行容易出现语法错位。4. 微信小程序端登录态、请求封装与下单页对接4.1 原生小程序还是 uniapp先看清楚再动手压缩包里的小程序前端打开后如果看到 pages、utils、app.json、app.wxss 这些目录和文件说明是原生微信小程序开发不是 uniapp 工程。原生小程序用 WXML 描述页面结构、WXSS 写样式逻辑层用 JavaScript。很多网上的教程教的是 uniapp 写法代码里全是 和混用拿到项目后不要急着把两种语法混在一起改。判断方式很简单项目根目录有 manifest.json 的是 uniapp有 project.config.json 的是原生小程序。小程序端和后端联调前先确认开发者工具版本能正常编译。首次打开工程时AppID 可以先用测试号等要真机预览时再换成自己的小程序账号。后端接口地址那一栏不要写 localhost这个坑在 5.3 节会展开。4.2 封装 request.js统一带上 token 和处理错误码小程序原生 API wx.request 是回调式的如果每个页面都直接调用代码里会到处是 success/fail 嵌套。常见做法是封装一个 Promise 风格的 request 工具把 BASE_URL、token 注入、统一错误码判断都收敛在一个文件里// utils/request.js const BASE_URL http://192.168.1.100:8080/api; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method, data: data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success(res) { // 后端统一返回 {code, message, data} if (res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.message || 请求失败, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); } module.exports { request };BASE_URL 里的局域网 IP 写的是电脑的 IP不是 localhost真机调试时手机和电脑必须连同一个 WiFi否则网络异常。token 每次从 storage 里读取不能只在登录时读一次存到全局变量里因为小程序冷启动后全局变量会丢失。后端从 header 里取 Authorization再拿 token 解析出 userId。这里严格说叫登录态透传和“微信小程序登录获取手机号”的完整流程还差两步正规微信登录要 wx.login 拿 code后端再拿 code 去微信服务器换 openid。但在毕设阶段很多项目会简化成固定 mock 用户后端直接生成 token重点把订单流程跑通。等要上线时再补 getPhoneNumber 的 code 换手机号流程那是另一个量级的改造。4.3 自定义导航栏高度一个高频踩点微信小程序顶部导航栏高度在网上被问得很多主要是因为自定义导航栏时要手动适配刘海屏。如果项目用的是默认导航栏这段可以跳过如果代码里 navigationStyle 设成了 custom计算导航栏高度就成了必经步骤。常见做法是// pages/index/index.js const { statusBarHeight, menuButton } wx.getSystemInfoSync(); const menu wx.getMenuButtonBoundingClientRect(); const navHeight (menu.top - statusBarHeight) * 2 menu.height; Page({ data: { statusBarHeight, navHeight } });statusBarHeight 是状态栏高度menuButton 是右上角胶囊按钮的位置信息。导航栏的真实高度等于“胶囊到状态栏的间距”的两倍加上胶囊本身高度这个公式在处理 iPhone 刘海屏时特别好用。拿到这两个值后页面的自定义头部样式就可以用 padding-top: {{statusBarHeight}}px 和 height: {{navHeight}}px 动态撑开。不这么做的话在普通安卓机上正常一到 iPhone 上标题就会被刘海遮住。4.4 家政下单页对接后端首页浏览服务列表、进入详情页、点击立即预约这是一个标准路径。下单页表单一般包含服务项目单选框、预约时间、服务地址、备注。提交按钮的事件里调用封装好的 request 方法// pages/order/order.js const { request } require(../../utils/request); handleSubmit() { const appointTime this.formatTime(this.data.appointDate, this.data.appointTime); request(/order/create, POST, { serviceId: this.data.serviceId, appointTime: appointTime, address: this.data.address, remark: this.data.remark }).then(orderId { wx.showToast({ title: 下单成功, icon: success }); wx.redirectTo({ url: /pages/detail/detail?orderId${orderId} }); }); }appointTime 一定要转成字符串格式统一成 “2025-03-20 14:30”不要直接传 Date 对象或者时间戳。后端 DTO 里如果用 String 接收时间戳会被解析成纯数字字符串MySQL 存进 datetime 字段直接报错或者变 1970 年。建议在 formatTime 方法里用补零的方式拼字符串避免月份和日期是单位数时后端解析出错。这里还有个细节下单成功后跳转到订单详情页页面上根据 status 显示不同按钮状态0 显示“等待接单”3 显示“确认验收”4 显示“去评价”状态判断写在 WXML 的 wx:if 里不要在后端拼接 HTML。5. 跑通项目避坑清单环境版本、时间显示与联调排错5.1 环境版本问题JDK、Tomcat、MySQL 的搭配要顺势而为现象Tomcat 启动到一半报 ClassNotFoundException 或者 BeanCreationException控制台日志刷了好几十行项目就是起不来。还有人在 JDK 17 下编译通过但运行时 MyBatis 的 cglib 代理抛异常。原因这类 SSM 老工程大多基于 JDK 8 Tomcat 8/9 MySQL 5.7 编写。JDK 11 以后模块化变动较大JDK 17 更是移除了不少旧 jar 依赖的反射 APISSM 里常用的动态代理在这些新版本上兼容性很差。解决装 JDK 8IDEA 里把 Project Structure 的 SDK 和 language level 都切到 8再确认 Maven 的 compiler 配置是 1.8。数据库装 MySQL 5.7.44这是目前最稳妥的组合很多网上的“mysql安装配置教程”也是基于 5.7 版本讲的。安装时字符集选 utf8mb4root 密码记清楚JDBC 连接串里加上 useUnicodetruecharacterEncodingutf8不然小程序端显示中文全是问号。5.2 时间字段显示成 UTC 字符串现象小程序页面订单列表的时间列显示成“2025-01-01T08:00:00.00000:00”这种带 T 和无穷尾缀的字符串看起来就像数据错了。原因后端返回的是 java.util.DateSpringMVC 默认用 Jackson 序列化序列化格式是 UTC ISO 字符串小程序端拿到后直接渲染没有做任何格式化。另外 MySQL 取的 datetime 如果通过 JDBC 映射成 Date也会带时区偏移。解决在实体类的日期字段上加注解全局生效。JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private Date appointTime;这里有两个细节timezone 必须写 GMT8不然会少 8 小时如果项目里日期字段多建议在 SpringMVC 配置文件里注册一个全局 ObjectMapper统一日期格式不要每个字段都加注解后面改了表结构容易漏加。5.3 小程序请求后端失败三种情况分开排查现象小程序开发者工具请求后端报错信息要么是 errno 600001 超时要么是 “url not in domain list”要么是真机上完全连不上。原因与解决对照现象原因处理方式模拟器请求超时BASE_URL 写了 localhost改为电脑局域网 IP比如 192.168.1.100:8080报 url not in domain list小程序后台没配合法域名开发者工具右上角详情里勾选“不校验合法域名”但只在开发阶段可用真机预览连不上手机和电脑不在同一网段或电脑防火墙拦截手机连同一 WiFi关闭系统防火墙或给 Java 进程放行最后提醒一句开发阶段用局域网 IP 最省事真机预览时热点和同一 WiFi 两个条件必须同时满足。等要上线时再换成已备案的 HTTPS 域名在微信公众平台后台配置合法域名这一步躲不掉。5.4 订单状态被并发覆盖现象用户端刚提交取消订单管理端也随之点击“派单成功”刷新后订单状态显示“服务中”一个已经取消的单子莫名其妙被激活了。原因Service 层用的更新语句只按主键更新where 条件里没有前置状态两条事务交替执行时后写的数据覆盖了先写的结果。解决改 SQL把前置状态作为更新条件影响行数为 0 时说明状态已被别人改过。UPDATE t_order SET status #{toStatus}, worker_id #{workerId}, update_time NOW() WHERE order_id #{orderId} AND status #{fromStatus}Service 里判断 executeUpdate 的返回值如果返回 0 就抛出异常并提示前端“订单状态已变化请刷新后重试”。这个方案本质是乐观锁不引入悲观锁带来的性能开销也是答辩时能讲清楚的一个亮点。排查时可以打开 MySQL 通用日志确认两条 SQL 的执行顺序不过大多数情况看一眼 update 语句的 where 条件就能定位。6. 从“能跑”到“能答辩”论文同步、演示顺序与必问考点6.1 论文必须和源码保持一致常见的翻车案例源码里登录用的是 wx.login论文里却写“用户通过手机短信验证码登录”源码没有支付页面论文里却画了支付宝支付流程。答辩老师不一定逐行看代码但演示时随口问一句“支付功能在哪”答不上来就很尴尬。拿到论文后的第一件事是把“系统功能模块”章节和数据库表一对一对上管理员端对应 t_admin 的服务项目管理、派单管理、评价管理用户端对应 t_user 的微信登录、浏览服务、预约下单、取消订单服务端对应 t_worker 的接单、更新服务状态。论文里多写的功能要么删掉要么补代码不要留着当风险点。6.2 演示顺序提前走一遍不要现场挖坑建议的演示路径是进入小程序首页 → 选择保洁服务 → 选择预约时间 → 下单 → 切到管理端接单 → 切回小程序看到“已接单” → 再在管理端推进到“已完成” → 小程序端提交评价。演示前把管理端页面预置好登录状态海报上贴好测试账号不要现场注册新用户。订单金额这类数据提前在数据库里造好几笔不要现场输入一串容易出错的小数。演示时如果 WiFi 不稳定优先用开发者工具模拟器而不是真机模拟器访问 localhost 反而更顺畅。6.3 三个高频答辩问题的准备文案提问参考回答要点SSM 请求流程是什么小程序发请求到 DispatcherServlet经 HandlerMapping 找到 Controller再走 Service、Mapper 到 MySQL结果逐层反转返回现场手画一张流程图订单状态如何防并发更新状态时 where 条件带前置状态影响行数为 0 则拒绝操作本质是乐观锁数据库索引怎么设计的t_order 的 user_id 和 status 各建一个索引支撑“用户查自己订单”和“按状态筛选派单”两个高频查询这类问题在 java 面试题里也常出现提前把这三个回答背熟比背几十个零散概念有效得多。最后说个个人习惯我一般会在答辩 PPT 第一页放一张手绘的订单状态迁移图待接单到已取消每个箭头都标清楚谁有权限操作老师看完图基本就不再深挖流程了。希望这套避坑思路帮到你也祝你在这个项目上花的每一分钟都能变成答辩时的底气。本文还有配套的精品资源点击获取