SSM+微信小程序家政服务系统毕业设计：环境配置到答辩全攻略

简介：基于Java、SSM框架（Spring+SpringMVC+MyBatis）、MySQL数据库及微信小程序的家政服务管理系统毕业设计资源，面向计算机专业毕业生及需要课程设计、期末项目的学生。项目包含完整前后端源码、数据库脚本和毕业论文，开发环境为Idea、微信开发者工具，并配套Maven部署与Navicat数据库管理，已通过严格调试，可直接运行使用。

资源包共1213个文件，大小16.41MB，以png图片、js脚本、svg图标、vue页面、java类、json配置、wxss样式及wxml小程序结构文件为主，另有少量sql数据库脚本和docx论文文档，目录结构完整清晰。目前已有85人学习下载。系统实现了用户端与服务端的分离，覆盖家政服务发布、订单管理、评价反馈等核心功能，界面简洁美观，操作便捷。随附的论文详细阐述了需求分析、数据库设计与系统实现过程，既可作为毕业设计写作范本，也可作为二次开发的基础框架。

1. 家政小程序凭什么能当"高分毕业设计"：先把这套 SSM 加微信小程序组合拆开看

家政服务小程序这个题目，在计算机毕业设计里属于"经典款中的稳重款"：后端是 Java 语言，SSM（Spring、SpringMVC、MyBatis）框架，数据库用 MySQL，前端用一个微信小程序承载。它模拟的是真实到家服务平台的骨架——用户打开小程序浏览保洁、月嫂、家电维修这些服务，选中后填写地址和期望时间下单，服务人员接单、完成服务后双方还能评价。相比电商、外卖这些被写过无数次的选题，家政的业务链条更短但状态流转完整，正好卡在毕业设计"要完整不要复杂"的甜点上。

那这个项目解决的是谁的什么问题？如果你是 Java 方向的学生，手里已经学过 SSM 和 MySQL 教材，但从来没把浏览器、小程序、后端、数据库四层串通过，这套源码就是最好的练手素材。如果你是准备求职面试，需要一个能当场演示、讲得出设计细节的项目，家政小程序也比图书管理、学生管理这类 CRUD 项目更有记忆点。后面我不讲虚的，直接按拿到源码后从环境配置到答辩演示的完整路径展开。

2. 把 SSM 后端在本地跑起来：环境版本到接口验证的一整套配置

先泼一盆冷水：拿到"源码+数据库+论文"的压缩包，最耗时间的环节通常不是写代码，而是把项目跑起来。SSM 是 2015 年那会儿的主流 Java Web 技术栈，现在电脑上装的往往是新版 JDK、新版 Tomcat、新版 MySQL，版本不匹配时，光启动报错就能耗掉一个周末。这章我把从解压到接口验证的完整步骤写出来，每一步都标明版本和参数。

2.1 环境选型：JDK 8、Maven 3.6、Tomcat 8.5 的兼容性说明

这个项目能跑起来的前提是环境的兼容性。我一般固定用：JDK 1.8、Maven 3.6.x、Tomcat 8.5 或 9.0、MySQL 5.7（8.0 也可以，但连接参数要改）。不要尝试用 JDK 17 或 Tomcat 10，翻车概率极高。

为什么？因为老项目的 pom.xml 依赖的是 javax.servlet 命名空间，Tomcat 10 开始把包名改成了 jakarta.servlet，一启动就 NoClassDefFoundError。JDK 17 对 Spring 5.2.x 的反射访问也有限制，处理起来很闹心。这里没有捷径，照着老版本配，项目起来得最快。

Maven 的 settings.xml 里建议配上阿里云镜像。中国大陆网络访问 Maven 中央仓库经常超时，第一次拉 SSM 全家桶依赖会很大，不配镜像的话下载可能卡在某个 jar 上半小时。

2.2 导入 IDEA 与首次构建：Maven 镜像和编译检查

解压源码包后，先看目录顶层有没有 pom.xml。IDEA 打开时直接选择 pom.xml 所在的目录，IDEA 会识别为 Maven 项目。导入后打开右侧 Maven 面板，先执行 clean 再执行 compile：

mvn clean compile

如果依赖下载卡住，去改 Maven 全局配置文件 conf/settings.xml：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>aliyun maven public</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

参数说明：mirrorOf写中央仓库的 id，url指向阿里云的公共仓库。这一步是标准的 Maven 配置，不单是 SSM 用得到，以后所有 Java 项目都受益。

编译通过后，检查 src/main/webapp/WEB-INF 下有没有 web.xml。SSM 项目的请求分发全靠 DispatcherServlet 在 web.xml 里注册，没有这个文件，Tomcat 启动不会报错，但所有接口都是 404。

2.3 修改数据库连接：jdbc.properties 里的三个必改参数

SSM 的数据库配置通常收敛在一个 properties 文件里，常见路径是 src/main/resources/jdbc.properties 或 db.properties。修改的地方有三个：数据库地址、用户名、密码。

# 家政项目的 MySQL 连接配置 jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/household?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=123456

逐个说参数：useUnicode=true&characterEncoding=utf8是让 MySQL 连接按 UTF-8 字符集传输数据，不配这个，后面中文乱码问题会直接喷到小程序页面上；serverTimezone=Asia/Shanghai是给 MySQL 8.0 用的，不加可能报时区错误；useSSL=false是关闭 MySQL 8.0 默认的 SSL 握手。密码如果是空，也要写空字符串，否则 DBCP 连接池会用默认值去连，直接 Access denied。

改完之后，检查 Spring 的配置文件（通常是 applicationContext.xml 或 spring-mybatis.xml）里有没有引用这个 properties 文件。常见错误是路径写错或文件名打错，导致${jdbc.url}占位符解析失败。文件名的拼写错误很难发现，建议直接复制。

2.4 初始化 MySQL 数据库：建库、建表、数据字典对齐

源码包里一般带 sql 脚本。我建议把脚本内容从头到尾看一遍，不要无脑执行，原因后面说。执行方式有两种，命令行或者 Navicat。命令行建库和导表分开做，可读性最好：

CREATE DATABASE IF NOT EXISTS household DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE household; SOURCE /absolute/path/household.sql;

注意：SOURCE后面要写绝对路径。如果你的 sql 脚本第一行已经有 CREATE DATABASE，跳过建库这一步，直接mysql -u root -p < household.sql也行。脚本执行完后SHOW TABLES;确认表的数量。常见家政项目的核心表至少包含：用户表（sys_user 或 t_user）、服务分类表（t_category）、订单表（t_order）、评价表（t_comment）。如果你看到表很少，先不要慌，可能是题目本身功能精简；但如果论文里的数据字典有 15 张表而数据库只有 3 张，那是脚本版本不对，需要找完整版脚本，别自己硬补表。

这一步最容易翻车的点是执行后中文乱码。检查方法是用 SELECT 查一条带中文的记录，在命令行里显示正常，再去小程序里看。命令行显示乱码而数据库存储正常，那只是客户端字符集问题，不影响使用；如果数据库本身就存的是乱码，就要回到建库语句的 DEFAULT CHARACTER SET 检查。

2.5 启动 Tomcat 并验证接口：浏览器和 curl 双确认

数据库就绪后配置启动。IDEA 右上角点 Add Configuration，选 Tomcat Server -> Local，Deployment 里选择 war exploded 模式，Application context 填/household。确认 Tomcat 端口（默认 8080）没被占用后，点 Debug 启动。

启动日志出现这两行，说明 Spring 容器初始化完成：

Root WebApplicationContext: initialization completed Tomcat started on port(s): 8080

然后先用浏览器访问http://localhost:8080/household/，只要能弹出页面或 JSON，说明 web 应用已挂载。再用 curl 打一个真实的查询接口：

curl http://localhost:8080/household/api/service/list

返回 JSON 数组，说明 DispatcherServlet 和 MyBatis 查询链路都通。如果 404，检查 controller 的 @RequestMapping 和 web.xml 的 servlet-mapping url-pattern（常见是/或/api/*）；如果 500，看 IDEA 日志最底部的 Caused by，是 SQL 语法错了还是连接失败了。

后端跑通后，接下来是小程序端的接入。

3. 微信小程序端从 0 到真机预览：baseUrl、登录态与调试开关

后端跑通只是第一步，家政项目的主战场在小程序端。微信开发者工具的版本、appid 是否有效、请求地址指向哪里，这三个问题不开好头，后面全是黑匣子报错。这一章把小程序端从打开到真机预览的配置链路完整走一遍。

3.1 小程序目录结构：pages、utils、app.js 各管什么

拿到源码后，小程序部分通常是一个独立的文件夹，比如 miniprogram 或 house-app。先打开 project.config.json 看 appid：

{ "appid": "wx1234567890abcdef", "compileType": "miniprogram", "projectname": "household-app" }

如果没有自己的小程序账号，去微信公众平台注册一个个人主体小程序，或者用测试号。appid 和你后端调用 code2session 时要用的 appid 必须是同一个，不然后端生成的登录态永远对不上。

目录结构上，pages 下面每个业务页面一个文件夹，里面是四个同名的文件：wxml（结构）、wxss（样式）、js（逻辑）、json（页面配置）。utils 里通常放着 request.js 这种通用模块。app.js 是全局入口，App({...}) 里 onLaunch 做初始化。家政项目一般有首页（服务列表）、下单页、订单列表页、个人中心页这几个页面，先在 app.json 里确认页面注册路径没有写错，否则编译不报错但页面白屏。

3.2 修改 baseUrl：为什么 localhost 不行，局域网 IP 才行

这是小白最容易卡住的一个点。requests 的地址写在 utils/config.js 里，默认可能是http://localhost:8080。在开发者工具里，模拟器环境里访问 localhost 指向的不是你的 Windows 或 Mac，而是模拟器自己，所以请求必然失败。

改成你电脑在局域网里的 IP 地址，在终端里用 ipconfig（Windows）或 ifconfig（Mac）查：

// utils/config.js module.exports = { baseUrl: 'http://192.168.1.100:8080/household', // 指向本机后端 timeout: 10000 }

注意 baseUrl 末尾要不要带项目上下文路径，取决于后端 Tomcat 的 Application context 配置。如果 context 是/household，那这里就要带上；如果 context 是/，这里就是http://192.168.1.100:8080。

注意：换 IP 后，记得同步检查后端 Tomcat 的 context path，前缀不一致是最隐蔽的联调翻车点。

3.3 微信登录的完整闭环：wx.login 到 code2session

家政小程序的登录方式是"微信一键登录"，这套流程面试和答辩都爱问，值得彻底搞明白。前端逻辑是：用户点登录，小程序调 wx.login 拿到临时登录凭证 code，这个 code 有效期很短且只能用一次；前端把它 POST 给后端，后端拿着 code + appid + secret 去微信的 jscode2session 接口换 openid 和 session_key；openid 是用户在本小程序里的唯一 ID，后端拿它查表，查到就更新昵称头像，查不到就帮他注册一个新用户；最后后端生成一个自定义 token 返回给前端，前端存到 Storage。

后端参考代码：

@PostMapping("/api/login") @ResponseBody public Result login(@RequestBody Map<String, String> params) { String code = params.get("code"); String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + code + "&grant_type=authorization_code"; // 用 HttpClient 发起 GET 请求，解析返回的 openid String openid = httpGet(url).getString("openid"); User user = userMapper.selectByOpenid(openid); if (user == null) { user = new User(); user.setOpenid(openid); userMapper.insert(user); } String token = UUID.randomUUID().toString().replace("-", ""); return Result.ok(token); }

前端对应：

wx.login({ success: (res) => { if (res.code) { wx.request({ url: getApp().globalData.baseUrl + '/api/login', method: 'POST', data: { code: res.code }, success: (res) => { wx.setStorageSync('token', res.data.token) } }) } } })

要点有两个：一是 code 只能消费一次，前端不要在日志里反复重试；二是后端拿到 session_key 后可以不用保存它，openid 才是真正要落库的字段。token 的生成可以简单用 UUID，但更规范的做法是放到 Redis，这个项目没引入 Redis，用一张 token 表或把 token 和过期时间存到内存也行，答辩时能自圆其说即可。

3.4 真机预览前必须打开的调试开关与后台域名配置

本地开发时，微信开发者工具默认自带的校验规则会拦掉 HTTP 明文请求和未配置域名，具体动作是：工具右上角"详情" -> "本地设置" -> 勾选"不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书"。这个开关只管开发者工具，不影响正式发布。

真机预览要再走一步：手机微信打开项目后，点击右上角胶囊按钮 -> 打开调试。不开这个，手机端同样会拦截 http://192.168.1.100 的请求。这里要说清楚安全和示范的边界——正式上线必须用备案过的 HTTPS 域名并配置到公众平台后台的 request 合法域名列表，但毕业设计展示阶段，局域网 IP 直连后端是行业里最常见的演示做法，够用且高效。

小程序端接完，整个联调最核心的两段就通了。下面看数据库模型为什么长这样。

4. 家政业务的数据模型：订单表怎么设计才能撑起整个项目

前两章把项目跑通了，但很多照着做的人会卡在同一个问题：业务逻辑看不懂，改需求不知道动哪张表。这一章把家政项目的数据模型按"四张核心表 -> 状态流转 -> 设计理由"讲透。数据库设计是毕业设计论文里最好写又最容易写砸的部分，因为它直接反映你有没有真正理解业务。

4.1 核心表拆解：用户、服务分类、订单、评价四张表的字段设计

家政项目的骨相，用四张表就能撑住。第一张是用户表：

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL UNIQUE, -- 微信身份标识 nickname VARCHAR(64), avatar VARCHAR(255), phone VARCHAR(20), role TINYINT DEFAULT 1 COMMENT '1-用户 2-服务人员 3-管理员', create_time DATETIME );

openid加唯一约束，避免同一微信号注册多个账号。role字段决定了这个人的操作权限：普通用户能下单和评价，服务人员能接单，管理员能管理分类和人员。

第二张是服务分类表：

CREATE TABLE service_category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(32) NOT NULL, icon VARCHAR(255), sort_order INT DEFAULT 0, status TINYINT DEFAULT 1, create_time DATETIME );

第三张是订单表，这是整个系统的核心：

CREATE TABLE t_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, -- 业务订单号 user_id BIGINT NOT NULL, -- 下单人 category_id BIGINT, -- 服务分类 service_item VARCHAR(255), -- 服务项目描述 service_time DATETIME, -- 期望服务时间 address VARCHAR(255), contact_name VARCHAR(32), contact_phone VARCHAR(20), amount DECIMAL(10,2), status TINYINT DEFAULT 0 COMMENT '0-待接单 1-服务中 2-已完成 3-已取消', remark VARCHAR(255), create_time DATETIME );

第四张是评价表：

CREATE TABLE order_comment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL UNIQUE, -- 一单只能评价一次 user_id BIGINT NOT NULL, rating TINYINT, content VARCHAR(512), images VARCHAR(1000), create_time DATETIME );

四张表的关系一句话能说清：一个用户下多张订单，一张订单对应一个服务分类，服务完成后产生一条评价。设计时注意两个容易漏的点：一是订单表不直接存服务人员的 user_id，而是通过"接单动作"在订单状态里附加 service_staff_id 这类字段，这样从待接单到服务中，人员变更有记录可查；二是评价表对 order_id 加唯一约束，保证一单只能评价一次，这个约束放在持久层比在业务层判断可靠得多。

4.2 订单状态流转：用 status 字段表达待接单、服务中、已完成、已取消

订单表里的 status 是整个家政系统的"心跳"。我建议用整数做状态值，不直接用字符串，因为运算和比较方便，同时用常量类集中管理：

public class OrderStatus { public static final int WAIT_ACCEPT = 0; // 待接单 public static final int SERVING = 1; // 服务中 public static final int FINISHED = 2; // 已完成 public static final int CANCELED = 3; // 已取消 }

合法的状态流转是：用户提交订单 -> 0；服务人员接单 -> 1；服务完成确认 -> 2；用户在状态为 0 时取消 -> 3。在 Service 层做守卫校验：已取消的订单不能再接单，已完成的订单不能再次修改。代码层面，可以在 update 语句里带上当前状态条件，比如：

UPDATE t_order SET status = 1, service_staff_id = #{staffId} WHERE id = #{orderId} AND status = 0

这条 SQL 的巧妙之处在于用AND status = 0保证只有待接单订单能被抢单，执行完后受影响行数为 0 说明订单已被别人接走。这是乐观锁思路在状态流转里的最小实现，比"先查再改"安全得多，也适合在答辩时讲。状态流转图画清楚，配合这段 SQL，老师再追问并发场景，你也有东西可讲。

4.3 这种数据模型为什么能撑起答辩：ER 图、索引与第三范式

答辩老师看数据库设计，第一眼找 ER 图，第二眼找数据字典，第三眼才问 SQL 细节。ER 图用 Visio 或 draw.io 画，关系是：用户 1—N 订单，服务分类 1—N 订单，订单 1—1 评价。不要把用户和评价直接连线，虽然从语义上说得通，但那样 ER 图就多了一条冗余关系。

索引方面，订单表的 user_id 和 status 建普通索引，评价表的 order_id 建唯一索引。这块的理由一句话：订单列表页按用户查询、按状态筛选是最高频路径，索引能让你在演示时用 WHERE 查询秒回。当然量小看不出差别，但索引设计意识本身就是答辩评分的观察点。

第三范式的话题要会讲。"订单里不冗余存服务名称，而是存 category_id，需要时 JOIN 分类表"，这个设计的本质是消除传递依赖。反过来举一个反面例子：如果订单表存了分类名称，分类改名后订单历史里还是老名字，这就是冗余带来的不一致。把"用空间换时间"和"用一致性换便利"的取舍讲清楚，比背诵三大范式定义有用得多。家政项目的业务量级根本到不了需要冗余来提高性能的程度，所以干净的关系模型是最优解。

另外，课程设计里最常见的翻车是把所有字段塞进一张大表，然后答辩时讲不出这张表的主键业务含义。家政项目四张表分工明确，每一张都能说出"为什么存在"，天然适合答辩。要注意的是表的命名风格，比如统一用 t_order 还是 order，中间不要混用，数据字典和建表语句对不上是老师最爱挑的毛病。

最后补一个家政项目特有的边界：真实平台会接微信支付，但毕设通常开通不了微信支付商户号（个人主体没有资质）。所以订单表的amount字段有时只是存一个金额，没有真实的支付回调链路。答辩被问到时，直接说"支付环节因商户资质限制未接入，属于项目裁剪"，这是合理做法。如果想加分，可以做一个模拟支付接口，前端点"立即支付"调后端 mock 接口更新订单状态，一句话就能挡住追问。

5. 联调避坑：SSM 后端对接小程序的五个高频问题

后端能启动、小程序能编译，只是通过了入场券。真正花时间的往往是联调环节——小程序发请求、后端返回结果、数据库读写数据，整条链路一层层查下去。这一章把我自己踩过和帮别人排查过的五个高频问题按"现象 -> 原因 -> 解决"写清楚。每一条都不需要动大手术，但对症下药能省出大半天。

5.1 数据库中文乱码：页面显示问号的真实原因

现象：小程序页面里服务名称、用户昵称显示成问号或空白。

原因：这一层层的编码链路里，最常出问题的是 MySQL 连接串和建库字符集。jdbc.properties 里没有characterEncoding=utf8，或建库语句没有指定 utf8mb4，都可能导致乱码。

解决：把连接串补全：

jdbc.url=jdbc:mysql://localhost:3306/household?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

同时确认库表字符集：

ALTER DATABASE household CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; ALTER TABLE t_order CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

注意顺序：先改后导。已经乱码的数据，ALTER 只能保证新数据正常，旧数据修复不了，只能删了重导。这个顺序问题属于血泪经验，我见过有人对着乱码数据改了三天字符集，最后发现是导库顺序反了。

5.2 8080 端口被占用：Tomcat 启动失败的快速处理

现象：IDEA 启动 Tomcat 时弹窗Port 8080 is already in use，或者日志里出现BindException: Address already in use。

原因：本机另一个进程占用了 8080，常见的是之前启动的 Tomcat 实例没有关干净，或者是别的开发服务。

解决：Windows 在命令行执行：

netstat -ano | findstr 8080 taskkill /pid 12345 /f

把12345换成实际占用的 PID。也可以不改系统层面的端口，直接在 IDEA 的 HTTP port 改成 8081，一劳永逸。改动端口后记得小程序端的 baseUrl 也要同步改，前后端端口不一致是联调里最隐蔽的翻车点。

提示：这是 Windows 下的命令，macOS 用lsof -i :8080然后kill PID处理。

5.3 小程序报 url not in domain list：本地调试怎么关校验

现象：小程序开发者工具里所有 wx.request 都失败，控制台报url not in domain list。

原因：微信平台规定，小程序 request 的域名必须在后台配置到合法域名列表，且要求 HTTPS。这是安全机制，正式发布必须先配置。

解决：本地联调阶段，开发者工具右上角"详情" -> "本地设置" -> 勾选"不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书"。真机预览时，手机上打开小程序后点右上角"..."，选择"开发调试"。勾选后请求立刻能通，这是差别排查里成本最低的一个开关。

5.4 微信登录 40029：code2session 调用失败的三个可能

现象：后端请求微信接口，返回{"errcode":40029,"errmsg":"invalid code"}。

原因：三个常见来源——小程序用了错误的 appid；secret 与 appid 不匹配；或者前端同一个 code 被请求了两次，微信的 code 是一次性的。

解决：第一，打开微信公众平台，核对小程序账号里的 AppID 和 AppSecret，重点是当前用的小程序到底是哪个账号。第二，后端日志里把请求微信的完整 URL 打出来，手动拼一下看 secret 末尾有没有多余的换行或空格。第三，前端 wx.login 的回调里只提交一次，不要把 console.log 里打印的 code 再手动 POST 第二次。40029 还有一个常见变体 40013，那是 appid 本身非法，方向不同。

5.5 时间字段变成一串数字：JSON 序列化日期格式

现象：后端返回的 createTime 是1718000000000这样的毫秒时间戳，小程序页面直接显示成数字串。

原因：SpringMVC 的 Jackson 默认把 java.util.Date 序列化为时间戳。

解决：在实体类的日期字段上加注解：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private Date createTime;

如果项目里日期字段多，也可以在 spring-mvc.xml 的注解驱动里配置全局格式。这个坑不大，但演示时页面上满屏数字会显得很业余，建议优先处理。另外注意 timezone 不写的话，时间会比北京时间差 8 小时，这是第二个隐藏点。

6. 论文和答辩怎么把这个项目讲成"高分"：十分钟演示脚本的三个准备技巧

项目能跑只是拿到了及格线，想冲高分，论文和答辩这块才是真正的加分项。这里说三个我最推荐准备的技巧，全部基于上面几章已有的内容，不需要额外做功能。

6.1 数据字典和 ER 图：让数据库设计章节对得上代码

打开论文的数据库设计章节，把第 4 章的四张表按字段逐个核一遍：字段名、类型、是否为空、注释，四者必须和 sql 脚本一字不差。ER 图用 draw.io 重画，导出矢量图，别用截图。这一章是老师最可能翻阅的地方，对得上，第一印象就稳了。

6.2 十分钟演示脚本：小程序操作和数据库验证交替进行

演示我建议按下单流程走：打开小程序首页 -> 选择"日常保洁" -> 填写地址和时间 -> 提交订单 -> 切到数据库用SELECT * FROM t_order ORDER BY id DESC LIMIT 1;展示新订单落库 -> 回到小程序刷新订单列表。整个链路完整走一遍，比任何讲解都有说服力。注意把 IDEA 的后端日志窗口提前调出来，下单时让老师看到接口调用日志在滚动，这种"活"的感觉很加分。

6.3 三个追问预案：登录态、订单并发、为什么选 SSM

老师最爱追问的问题基本集中在：微信登录怎么识别用户、两个用户同时抢同一单怎么保证不冲突、为什么用 SSM 而不是 Spring Boot。前两个从第 3 章的 openid 落库和第 4 章的AND status = 0乐观锁找答案，第三个只要实话实说"毕业设计要求指定 SSM，且自己熟悉配置过程"即可，不需要为老框架辩护。

我的习惯是答辩前一天把演示环境完整跑一遍，重启两次电脑再跑一遍。这步操作看起来土，但能挡住九成演示事故——至少我见过的现场翻车，有一半是前一天没重启、第二天 Tomcat 起不来。希望这篇拆解能帮你的家政小程序毕业设计少走弯路，把时间花在真正有分量的地方。

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