每年到这个时间点，总有同学拿着同一个题目来找我：家政服务预约平台。说实话，这个题目在计算机类毕业设计里属于“最熟悉的面孔”，网上随便一搜就是一堆源码和演示录像，标题大多写着“免费领源码+演示录像”，看着相当诱人。但这恰恰是问题所在——题目越常见，越容易做得平庸，答辩时翻车的概率也越高。我见过不少同学以为下载一份源码、录一段操作视频，就能顺利过关，结果被评委一个问题问懵：两个客户同时选了同一个保洁阿姨的同一个时间段，系统怎么办？回答不上来，项目直接被判“没有解决实际问题”。
这篇文章我就围绕家政服务预约平台这个题目，从需求分析、技术选型、数据库设计、后端实现、前端演示录像到论文写作，完整梳理一遍“拿优秀”的逻辑。说得直接一点：源码和录像只是入场券，真正拉开差距的是你对预约业务的理解深度，以及能不能把“做过的内容”在论文和答辩里讲透。以下内容全部来自我实际辅导项目的经验，适合正在做同类毕设、课设，或者单纯想把这个业务逻辑搞清楚的读者。
1. 家政预约平台这种题目，为什么常做常新、又容易翻车
1.1 从“看起来简单”到“真正做透”之间的距离
家政预约平台表面上就是一个多角色电商系统，核心是“下单”和“接单”，听起来比秒杀、电商简单多了。但偏偏是这种“看起来简单”的题目，最容易做成“增删改查大礼包”——用户表能加能删，服务表能改能查，预约订单表插一条记录，完事。去年有个同学来找我看项目，他做的就是家政预约，演示录像里操作行云流水，页面也不少，但我问了三个问题：
第一，同一名服务人员同一时间段被两个客户预约，你怎么拦截？第二，用户下单后一直不支付，订单挂在“待支付”状态好几天，谁来处理？第三，服务人员端几个人同时抢同一个订单，怎么保证只有一个抢到？他沉默了。
这就是典型的“功能做了，业务没做透”。预约类系统最值钱的地方不是那几个CRUD接口，而是围绕“时间”和“状态”的设计——时间段冲突检测、订单状态机、并发控制。这些才是评委愿意给高分的地方，也是这种题目能“常做常新”的原因：每年都有人选，但真正把业务逻辑闭环做完整的人很少。
1.2 优秀毕业设计的评判三角：工作量、技术深度、表达清晰度
接触过不少参与评审的老师之后，我总结出评委打分时最关注的三个维度，基本可以概括为一个三角形：工作量、技术深度、表达清晰度。
工作量不是代码行数，而是业务完整度。你的系统有没有覆盖客户、服务人员、管理员三种角色的完整操作链？有没有地址管理、订单取消、评价回复这些“边缘但必要”的功能？数据表能不能支撑起这些功能？如果一个项目只有三四张表，哪怕页面再花哨，工作量这一项就会明显失分。
技术深度则是解决真实问题的能力。系统设计时有没有考虑过并发预约？订单状态是怎么防止乱跳的？用户密码是怎么存储的？这些点不需要你做得像大厂一样复杂，但论文里必须能写出“我遇到了什么问题，我用什么方案解决，为什么这么选”。
表达清晰度经常被忽略，但它决定了前面所有工作的呈现效果。论文结构是否规范、演示录像是否逻辑顺畅、答辩时能不能三句话讲清系统核心，这些都属于表达范畴。我见过一个同学项目做得不错，但演示录像从头到尾在录“点菜单、拉下拉框”，没有旁白也没有重点，评委看完完全抓不住亮点，最后分数平平。
2. 需求不是罗列功能清单，而是画清楚用户的完整行为链
2.1 三种角色、七条核心业务流程的梳理方法
很多同学拿到题目就开始写代码，这是最大的错误。做需求分析的第一步，不是罗列“用户模块、订单模块、评价模块”这种词，而是把角色和流程走一遍，搞清楚每一步数据和状态发生了什么变化。
家政预约平台至少涉及三种角色：客户（下单的人）、服务人员（接单和上门服务的人）、管理员（平台运营方）。围绕这三种角色，我建议你梳理出下面七条核心业务流程，每条流程最后都要能对应到前端页面跳转和后端接口调用：
- 客户注册登录后，浏览服务分类，选择具体服务项目，选择上门地址和时间，提交预约订单。
- 订单提交后（视设计而定）进入待支付或待接单状态，客户可以取消订单，系统可以超时自动取消。
- 服务人员登录后查看可接订单，抢单或等管理员指派，接单后订单进入“待服务/已接单”状态。
- 服务人员上门服务，点击开始，再点击完成，订单进入待评价状态。
- 客户确认服务完成，填写评分和评价内容，订单最终完成。
- 管理员登录后台，审核服务人员入驻申请，管理服务分类和服务项目，处理异常订单。
- 管理员查看平台数据统计，比如每日订单量、热门服务类型、服务人员评分排名。
每一条流程走完，你会发现系统需要哪些页面、哪些接口、哪些字段、哪些状态，全部是水到渠成的。这比凭空想功能清单可靠得多。
2.2 从用例图到功能模块划分：哪些功能是“必须的”，哪些是“凑数的”
把流程梳理清楚之后，再画用例图就很顺手了。用例图不需要画得很复杂，关键是“参与者”和“用例”的关系要真实对应到系统实现，否则论文里的图和代码对不上，答辩时一眼就会被看出来。
功能模块划分上，我给一个比较实用的建议：核心功能必须有，加分功能适量加，凑数功能坚决不碰。
核心功能包括：用户注册登录、服务分类管理、服务项目管理、预约下单、订单管理（包含接单、服务中、完成、取消）、评价管理、服务人员入驻审核。这些是平台的骨架，任何一个缺失都会让系统显得不完整。
加分功能包括：多地址管理、服务人员评分排序、订单超时自动取消、通知消息（站内信）、管理端报表统计。这些功能不复杂，但能明显提升工作量和演示效果。
凑数功能指的是那些跟家政预约关系不大、但又特别耗时的功能，比如做一个全员在线聊天室、做一个多级分销体系、做一个积分商城。不是说不能做，而是它们会分散你的精力，导致预约核心逻辑反而没打磨好，得不偿失。记住，毕业设计求的不是功能多，而是“核心突出、闭环完整”。
3. 技术选型的逻辑：用“当前主流、自身能驾驭、论文能解释”三把尺子卡
3.1 为什么 Spring Boot + Vue + MySQL 是这类题目的最稳妥组合
技术选型是论文里“相关技术”那一章的核心内容，也是答辩时老师必问的环节。我的建议是，用“当前主流、自身能驾驭、论文能解释”这三把尺子来卡，不要盲目追新，也不要为了显得高级硬上微服务。
对于家政预约平台，最稳妥的组合就是 Spring Boot + MySQL，加一个前端框架。Spring Boot 的好处不用多说，它已经是目前 JavaWeb 领域的事实标准，配置简化、生态成熟，跟 MyBatis-Plus 搭配之后，基础 CRUD 的代码量会非常少，你可以把时间腾出来研究预约冲突和状态机这些核心逻辑，而不是耗在写 DAO 层。
前端我一般推荐 Vue + Element UI，因为组件库成熟，列表、表单、弹窗、分页这些后台管理常见的界面都可以快速搭起来。如果你的前端基础一般，也可以用 Thymeleaf + Bootstrap 做服务端渲染，本质上不影响系统功能，只是交互体验会弱一些。选哪个不重要，重要的是论文里能讲清楚“为什么选它”，以及你自己能驾驭。
数据库选 MySQL 没什么争议，预约系统的数据量级还远到需要上 PostgreSQL 或分布式数据库的程度，MySQL 的事务、索引、行锁机制已经足以支撑核心功能的实现，而且面试和答辩时大家都熟悉，沟通成本低。
3.2 可以加分的轻量级设计：Redis 缓存、定时任务、WebSocket 通知
技术栈里如果只有 Spring Boot + Vue + MySQL，系统的“技术深度”这一项会比较单薄。我建议在基础框架上，加一到两个轻量级组件，让论文的技术部分更有话可说，同时又不至于把项目复杂度拉爆。
第一个推荐是 Redis。它的用途不用做得多花哨，两个点就够了：一是缓存服务分类和热门服务列表，减少数据库压力；二是用于防止重复提交和抢单并发控制。论文里还可以顺带讨论一下缓存穿透、缓存失效的问题，这些内容网上资料很多，写出来既好懂又有深度。
第二个推荐是 Spring Task 定时任务。为什么需要它？因为你不可能要求用户点击“取消订单”按钮才处理超时订单。平台应该有一个后台定时任务，比如每五分钟扫描一次超过三十分钟未支付或服务人员长时间未接单的订单，自动将其关闭或释放时间槽。这个功能如果不做，系统会残留一堆僵尸订单，演示时非常难看。
第三个是实时通知。客户下单后，服务人员端怎么第一时间看到？最简单的方式是页面轮询，但如果有余力，可以引入 WebSocket，在服务人员端实时收到新订单提醒，在客户下单时实时看到接单状态变化。这个功能在演示录像里特别出彩，一眼就能看出系统不是单纯的后台“点来点去”。
下面是一个简单的选型对比，论文“相关技术”章节可以直接按这个思路展开。
| 技术选型 | 作用 | 加分理由 | 踩坑点 |
|---|---|---|---|
| MySQL | 持久化存储 | 事务、索引、行锁支撑并发控制 | 字段命名不规范会导致关联查询困难 |
| Redis | 缓存/分布式锁/防重复提交 | 体现并发处理能力 | 需要处理缓存与数据库的一致性问题 |
| Spring Task | 定时处理超时订单 | 体现系统自治能力 | 注意任务执行频率和数据库扫描跨度过大 |
| WebSocket | 状态实时推送 | 交互体验升级 | 需要解决连接管理和消息推送失败问题 |
| MyBatis-Plus | 简化数据操作 | 减少样板代码，效率高 | 复杂查询还是要手写SQL |
4. 数据库表设计：预约系统的灵魂藏在状态机和并发控制里
4.1 核心表结构与字段设计
数据库设计直接决定了系统能做多复杂，也决定了论文里ER图的质量。家政预约平台我建议至少设计六张核心表：用户表、服务分类表、服务项目表、用户地址表、预约订单表、评价表，如果涉及服务人员入驻审核，还需要单独的服务人员申请表或服务人员扩展表。
预约订单表是整个系统的核心，它的设计质量很大程度上决定了答辩成败。下面是我比较推荐的关键字段风格，你可以照着自己调整：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| order_no | varchar | 订单号，业务展示用，要唯一 |
| customer_id | bigint | 客户id，关联用户表 |
| worker_id | bigint | 服务人员id，可以为空（表示还没有人接单） |
| item_id | bigint | 服务项目id |
| address_id | bigint | 客户填写的服务地址 |
| expect_start_time | datetime | 预计开始时间 |
| expect_end_time | datetime | 预计结束时间 |
| status | varchar | 订单状态 |
| pay_status | varchar | 支付状态 |
| amount | decimal | 订单金额 |
| cancel_reason | varchar | 取消原因，取消时填写 |
| remark | varchar | 客户备注 |
| create_time | datetime | 下单时间 |
| actual_start_time | datetime | 实际服务开始时间 |
| actual_end_time | datetime | 实际服务结束时间 |
这里有一个经验要提醒：在设计订单表时，适当冗余一些字段，比如服务项目名称、服务人员姓名、客户联系电话，不要全部通过联表查询去获取。这样做的目的是让列表页和详情页的查询逻辑简单直接，减少联表，性能更好，论文里也好解释“我为什么做冗余设计”。但冗余也会带来数据一致性问题，比如服务项目改名后，历史订单里冗余的名字不会自动变，所以在论文里要说明这是“以快照方式保留历史信息”，这个说法反而会成为一个小亮点。
用户表建议区分角色字段，用简单的 role 字段标记 admin、customer、worker，权限控制通过拦截器实现，不要引入太复杂的权限框架。
4.2 订单状态机设计，以及“已被预约”这种并发问题怎么处理
家政预约系统的“灵魂”就在这里。订单状态不是随便存几个字符串，而要形成一套明确的状态机。我经常使用的状态定义如下：
待支付（PENDING_PAYMENT） → 待接单（PENDING_ACCEPT） → 已接单（ACCEPTED） → 服务中（IN_PROGRESS） → 待评价（PENDING_EVALUATION） → 已完成（COMPLETED）
其中待支付状态视你的设计而定，如果下单时不要求支付，可以去掉，让订单提交后直接进入待接单。取消和退款属于异常路径，任何时候都可以进入已取消（CANCELLED）或已退款（REFUNDED）。状态设计的核心原则是：状态只能按固定方向流转，不能乱跳。比如“服务中”不能直接变成“待评价”，“待支付”不能直接变成“已完成”。
随之而来的就是那个大名鼎鼎的并发问题：两个客户同时预约同一个服务人员的重叠时间段，怎么办？数据库层面，最简单可靠的方案是“查询冲突 + 事务 + 行锁”。流程是这样：在同一个数据库事务里，先锁定该服务人员的相关记录（SELECT ... FOR UPDATE），再查询指定时间段内是否存在重叠订单，如果没有则插入新订单并提交事务。行锁会让第二个请求排队等待，第一个事务提交后，第二个请求再执行查询时就能看到新插入的订单，从而判定为冲突。
代码上大概是这个感觉：
@Transactional public Long createOrder(CreateOrderRequest request) { // 锁定服务人员的档案记录，防止并发预约 WorkerRecord worker = workerMapper.selectByIdForUpdate(request.getWorkerId()); Assert.notNull(worker, "服务人员不存在"); // 在锁定状态下检查时间冲突 int count = appointmentOrderMapper.countOverlap( request.getWorkerId(), request.getExpectStartTime(), request.getExpectEndTime(), Arrays.asList("PENDING_ACCEPT", "ACCEPTED", "IN_PROGRESS") ); Assert.isTrue(count == 0, "该时间段已被预约"); // 创建订单 AppointmentOrder order = buildOrder(request); appointmentOrderMapper.insert(order); return order.getId(); }对应的SQL冲突判断逻辑，本质就是区间重叠判断：一条订单的起始时间要小于新订单的结束时间，且该订单的结束时间要大于新订单的起始时间。
SELECT COUNT(*) FROM appointment_order WHERE worker_id = #{workerId} AND status IN ('PENDING_ACCEPT', 'ACCEPTED', 'IN_PROGRESS') AND expect_start_time < #{newEndTime} AND expect_end_time > #{newStartTime};这里最容易被忽略的边界是“时间段首尾相接”的情况。比如订单A是10:00-12:00，新订单是12:00-14:00，这两个订单不应该冲突，因为上一个服务12:00结束，下一个正好12:00开始。所以判断条件用<和>而不是<=和>=，这点务必注意，论文里如果写清楚这个细节，非常加分。
5. 后端实现中最能体现水平的三个模块
5.1 预约时间冲突检测：最简单的表也能写出最复杂的判断逻辑
上面已经给了冲突检测的SQL，这里我想再展开讲讲这个模块的细节和延展。冲突检测不只是“写一个SQL”就完事，它包含三层判断逻辑。
第一层是格式校验：新增订单时，参数里的预计开始时间必须早于预计结束时间，时间不能是过去的时间，服务时长要和服务项目预设的时长一致。这一层看起来简单，但很多项目都漏了，导致脏数据能进库。
第二层是目标校验：预约的动作会锁定某个服务人员，所以要先判断这个服务人员是否存在、是否处于正常接单状态、是否因为差评过多被冻结。如果服务人员状态异常，订单应该直接拒绝。
第三层才是区间重叠检测，也就是上面的SQL。在此基础上，我建议再加一个粒度更细的处理：如果系统服务项目支持不同时长，那么每个服务项目在服务人员的“时间表”上可能占用不同长度，这时候冲突判断需要把时间段换算成统一的时间槽。比如平台可以按30分钟划分为一个时间槽，订单预约时将其转换为一个或多个时间槽占用记录，用一张独立的“服务排期表”存储。这样做冲突判断会变成简单的索引查询，效率更高，代码也更好理解，缺点是表结构变复杂、数据写入时需要维护排期记录。
两种方案怎么选？如果只是毕设体量，直接区间查询 + 索引就够用了，不必引入排期表。但我建议在论文的“系统设计”部分把两种方案做一个简单对比，说明你选择简单方案是基于业务量级的合理决策，而不是不懂高级方案。这种表达方式反而会提升老师对你的评价。
5.2 订单状态流转与权限校验：不要让用户“绕过”状态机
状态机在数据库里就是一张状态字段，但在代码里要形成一道“闸门”。很多项目的状态流转控制只在按钮上做，比如前端把“完成”按钮暂时隐藏，但直接调接口还是能操作成功。这是后端权限和业务校验的缺失，答辩被问“如果绕过前端直接提交接口怎么办”时很难回答。
我的做法是，把状态流转规则抽成一个固定的配置映射，后端在每次状态变更操作时统一校验。类似这样：
private static final Map<String, List<String>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put("PENDING_PAYMENT", Arrays.asList("PENDING_ACCEPT", "CANCELLED")); TRANSITIONS.put("PENDING_ACCEPT", Arrays.asList("ACCEPTED", "CANCELLED")); TRANSITIONS.put("ACCEPTED", Arrays.asList("IN_PROGRESS", "CANCELLED")); TRANSITIONS.put("IN_PROGRESS", Arrays.asList("PENDING_EVALUATION", "CANCELLED")); TRANSITIONS.put("PENDING_EVALUATION", Arrays.asList("COMPLETED")); }每次更新的代码都变成：先取出订单原本状态，判断“目标状态是否在允许的流转列表里”，不在就抛异常，在才执行更新。同一时刻还要用乐观锁控制，update语句里带上版本号或旧状态条件，防止多个人同时改同一订单：
UPDATE appointment_order SET status = #{newStatus}, version = version + 1 WHERE id = #{orderId} AND status = #{oldStatus} AND version = #{version};这个方法能保证状态变化是原子且有序的。为了论文更有料，我还会额外建一张“订单状态日志表”，记录每次状态变化的操作人、原状态、新状态、操作时间。既可以做审计，也能在答辩时展示“状态可追溯”的设计理念。
5.3 服务人员派单逻辑：抢单、指派与自动分配的实现对比
订单从“待接单”到“已接单”这一步，是家政预约平台又一个大考点。三种常见模式，你要选一个作为系统的主力逻辑，并在论文里说明选它的原因。
抢单模式最贴近真实场景。服务人员登录后看到“可抢订单列表”，点击接单。并发问题很明显：两个人同时点击同一个订单，必须保证只有一个成功。实现时可以在更新语句里加条件“WHERE id = ? AND status = 'PENDING_ACCEPT'”，update的返回影响行数为1才表示抢单成功，否则提示订单已被抢走。这种方式其实就是一个乐观锁，性能好，也不容易出错。
指派模式是管理员在后台把订单直接分配给某个服务人员。这种模式代码最简单，但客户无法指定服务人员，服务人员也没有选择余地，整体体验较弱。优点是很适合在演示录像里展示管理员的角色操作。
自动分配模式是根据规则自动派单，比如按服务人员评分、历史接单量、距离远近、当前空闲状态加权打分，把订单分配给分数最高的人。这种模式视觉上最“高级”，但实现复杂度也最高，需要做好异常兜底：如果算法选出来的人超过一定时间未响应，要自动转给第二顺位或变成公开抢单。
| 派单模式 | 实现复杂度 | 用户体验 | 演示效果 | 推荐度 |
|---|---|---|---|---|
| 抢单 | 中 | 灵活，但热门时段抢不到 | 可以演示两人同时抢单的并发控制 | 最推荐 |
| 指派 | 低 | 被动等待，体验一般 | 演示管理员操作 | 适合快速完成 |
| 自动分配 | 高 | 省心，有平台感 | 演示效果好 | 有余力再选 |
我自己最推荐抢单模式，原因很简单：它能自然引出“并发控制”这个技术亮点，答辩时你只需把两个浏览器同时抢单的测试截图放在论文里，就能实实在在证明你考虑过并发了。
6. 前端与演示录像：怎么让评委在几分钟内看懂你的全部亮点
6.1 页面设计的原则：演示模式下的“少即是多”
前端页面不需要做得像商业App一样华丽，但得做到“演示时看得清、截图时扛得住”。我建议遵循“少即是多”的原则：一个页面只解决一个核心任务。
客户首页就是展示服务分类、热门服务、搜索框和预约入口，不要堆太多横幅广告位；服务人员端就是抢单大厅、我的订单、个人评分三块核心内容；管理后台重点是数据看板、订单列表、审核列表。页面数量控制在十二个左右就够了，每个页面做到层级清晰、文字可读、按钮状态明显。
有几个容易被忽略的前端细节。一是所有演示数据必须是真实的、合理的，比如地址要写成“某某市某某区某某小区某栋某室”，服务项目价格要像真实价格，不要出现“测试1号”“111”这种数据，一眼就掉价。二是时间控件要设置好可选择的日期范围，避免演示时点出一堆乱码格式。三是按钮的禁用逻辑要跟订单状态联动，比如订单完成后“接单”按钮要置灰，这些细节能体现你的工程素养。
6.2 演示录像脚本：先讲典型流程，再讲技术亮点
演示录像在毕业设计中承担一个核心任务：在评委没有亲手操作系统的情况下，用最短的时间证明系统是完整可用的。所以录像不是打开系统随便点，而是要有脚本。
我建议录像时长控制在六到八分钟，结构分为两段。第一段走典型业务流程：客户登录 → 浏览服务 → 选择时间地址 → 提交订单 → 服务人员登录 → 抢单 → 开始服务 → 完成服务 → 客户评价 → 管理员查看订单和统计。这一段是证明系统“能跑通”。第二段走技术亮点展示：打开两个浏览器窗口，同时提交同一个服务人员的重叠时段预约，演示第二个请求被拒绝；再展示订单超时后自动被定时任务取消；最后展示订单状态日志表里一条条清晰的状态变更记录。这一段是证明项目“有深度”。
录制工具用 OBS Studio 就足够，分辨率固定为1920x1080，提前把要操作、要讲解的内容写在纸上。录屏的时候建议用鼠标高亮工具标出点击位置，声音要清晰、语速不要太快。回收站里所有临时文件都要清掉，避免录到一半弹出无关通知。如果对自己的即兴表达能力不自信，可以先把旁白写成逐字稿，再一边放录屏一边配音，这种方式出来的视频完成度非常高。
7. 论文拿优秀的四个写作要点：从摘要到测试，每一页都要有说服力
7.1 摘要和目录：让评审在30秒内建立“这项目很完整”的印象
论文评阅老师通常不会逐字读完整个系统实现，他们往往先看摘要、目录、图表，再挑几处关键章节翻一翻。所以摘要和目录这两页，决定了你的论文在老师心里的初始印象分。
摘要的写作可以按一个简洁的公式组织：先一句话点出背景和现状问题，再用两三句说明“本文设计并实现了什么样的系统，包含哪些功能”，接着写系统采用的技术方案，最后写系统经过测试达到了什么结果。关键词一般选三到五个，比如：家政服务、预约系统、Spring Boot、MySQL、并发控制。注意关键词不要跟题目大范围重复，要有区分度。
目录则是论文的结构地图。标准的毕业设计目录通常包含：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。每一个章节都要和实际内容对应，不要出现“需求分析”章节里贴满了代码这种结构错乱。目录做得规范，老师会默认你对论文写作流程是熟悉的，这是很划算的印象分。
7.2 系统测试不是截图堆砌，而是“验证了某个设计决策”
系统测试章节是很多同学的“重灾区”，常见的写法是放十几张页面截图，每张截图配一句“功能正常”，没有任何说服力。真正的测试章节应该回答一个问题：你前面设计里的关键决策，经过验证是否成立？
功能测试部分至少要包含一张完整的测试用例表，列清楚用例编号、测试模块、前置条件、操作步骤、预期结果、实际结果。不要只写通过用例，也要写一两条“预期失败”的用例。比如：客户预约已被占用的时间段，预期结果应该是“系统提示该时间段已被预约”，实际结果也是这个提示。这种负向用例比正向用例更能体现测试的严谨性。
性能与并发测试部分是体现系统深度的地方。你可以用JMeter设置一个线程组，模拟50或100个并发用户同时提交订单，然后查看系统的响应时间、错误率，特别是观察是否有并发情况下订单状态被写乱的问题。把测试结果截图放在论文里，旁边配一段分析，说明当前方案在什么并发量下表现良好、瓶颈在哪，这就比单纯截图高出一个档次。
7.3 图表一致性：ER图、用例描述、时序图要对得上
论文里图表的一致性是非常容易被忽视但又频繁失分的点。很多同学的ER图画了六个实体，正文里的数据库表却有八张；用例图里有“评价管理”，功能模块章节却只字不提；时序图画的调用顺序跟代码逻辑不一致。这些细节老师一眼就能看出来，一旦被发现，容易觉得论文是拼凑的。
我的建议是：在写论文之前，先把ER图、用例图、系统架构图、核心时序图这四类图确定下来，然后正文每个部分写完后回头检查一遍对应关系。画图工具用常见的在线绘图平台就行，注意统一图例、统一字体、统一编号。论文里每一张图都要在正文中因为分析需要而引用一次，不要出现“本文系统架构如图X所示”之后再也不解释图内容的悬浮图。答辩时你可以不看稿快速指出每张图对应的设计点，这种流畅感会让评委眼前一亮。
8. 源码拿到手之后，我是怎么帮别人“消化”成自己的
8.1 三步消化法：跑通、读懂、重构
前面说了那么多，现在回答一个很现实的问题：这类标题的项目到处宣传免费领源码和演示录像，你拿到了源码之后，到底应该怎么处理？我的建议是三个字：跑、读、改。
跑通是把环境配好，数据库导入，项目启动，把演示录像里的流程完整复现一遍。这一步看起来简单，实际是很多人会卡住的地方：JDK版本不对、Maven依赖拉不下来、MySQL密码没改成一致、前端npm包安装失败。每一处问题都是一次学习，也是答辩时可以讲的排错经历。
读懂是画出项目的模块结构图，然后挑一条主链路，比如“客户下单到服务人员完成服务”，把所有涉及的请求、方法、表、状态变化全部追踪一遍。完成这一步后，你对项目的理解才能说达到了可以答辩的水平。
重构是最关键的一步，也是让项目带上“个人痕迹”的唯一方式。你不必把全套代码重写，只需要做三个小改动：把前端界面的颜色、Logo字、布局微调，让它不像原版；在订单表里增加一个字段并且同步修改前后端；新增一个小功能，比如下单时留言备注，或者服务人员按评分排序展示。这三步做完，系统的答辩风险会大大降低，因为每一处你都亲手改过，被问到时你能答得有理有据。
8.2 答辩前最该准备的十个问题
最后，我把自己这些年整理的高频答辩问题，全部列在下面。这些问题不针对某个具体系统，但对于家政预约平台来说，命中率极高。
第一，你的系统有哪几种角色？权限是怎么控制的？第二，为什么选择当前这个技术栈？你有没有考虑过其他方案？第三，同一服务人员同一时间被重复预约，系统怎么处理？第四，订单有哪些状态？状态之间是怎么流转的？第五，取消订单以后，服务人员的时间什么时候被释放？第六，你的数据库有哪些表？核心表之间是什么关系？第七，密码是怎么存储的？有没有考虑安全性？第八，怎么防止恶意用户频繁提交订单？第九，系统如果将来用户量变大，哪个环节会最先成为瓶颈？第十，整个项目里，哪一部分是你独立完成并且最满意的？
前九个问题靠平时积累就能答好，最后一个问题我特别建议在答辩前认真想清楚。因为它是你主动引导评委注意力的机会：你希望老师记住这个项目的哪个亮点，就把哪个点作为答案。你想清楚之后，整个答辩的节奏都会往你熟悉的方向走。
我在实际帮别人做这类项目复盘时体会最深的一点是：家政服务预约平台能不能拿优秀，从来不取决于你下载的源码是否完整、录像是否清晰，而取决于你有没有真正吃透预约业务里“时间冲突”和“状态流转”这两个核心问题，并且把这些思考写进设计、写进代码、写进论文、讲给评委听。把这个逻辑打通之后，你会发现这类项目其实是很容易出彩的。
