社区家政服务预约系统：时间冲突检测与订单状态机设计实战

社区家政服务预约系统这个题目，这两年在各类项目实践里出现频率相当高。一方面它确实踩中了真实需求——找保洁、找维修、找月嫂，线下信息不对称太严重；另一方面它又是一个典型的"看起来简单、做起来处处是坑"的系统：时间冲突怎么判、服务人员怎么排班、订单状态怎么流转、支付和退款怎么兜底，每一个点单拎出来都能写一整篇。我前后参与过几个类似形态的项目，从最早的课程作业级Demo到后来真正跑起来的小规模线上系统，踩过的坑基本覆盖了这个题目的所有关键环节。这篇就把这套系统的完整设计思路、核心代码逻辑、以及那些文档里不会写的实操经验摊开讲清楚，适合正在做类似项目的人直接参考复现，也适合想理解"一个预约类系统到底难在哪"的读者。

1. 先想清楚这个系统到底在解决什么问题

很多人拿到这个题目，第一反应是"不就是个增删改查吗"——用户表、服务表、订单表，三个表一建，页面一画，完事。真做出来之后你会发现，能跑和能用之间隔着一条鸿沟。所以动手之前，得先把业务本质想透。

1.1 家政预约和普通电商的本质差异

普通电商是"标准化商品+库存扣减"，你买一件衣服，库存减一，逻辑闭环。家政服务完全不是这个模型。它卖的是一段时间内某个人的劳动，核心资源是"人+时间"，而不是"商品+数量"。这个差异直接决定了三件事：

第一，库存是时间维度的。一个保洁阿姨一天最多接4单，每单2小时，那她的"库存"就是这8个小时的时间片。你不能简单地给她设个"今日可接单数=4"，因为4单可能时间重叠，必须精确到时间段。

第二，服务有地理约束。阿姨住在城东，你给她派个城西的单，路上通勤一小时，这单基本就亏了。所以派单逻辑里距离权重很高，这也是很多Demo系统忽略、但真实场景绕不开的点。

第三，状态流转复杂。电商订单基本是"待付款→待发货→待收货→完成"，线性。家政订单是"待支付→待接单→已接单→服务中→待确认→已完成"，中间还穿插"取消""改约""退款""投诉"，而且不同角色能触发的状态迁移不一样。这块设计不好，后面全是bug。

我见过太多项目把订单状态做成一个字段随便改，最后测试的时候发现"已完成的单还能被取消"，返工成本极高。状态机一定要在动手写代码前就画清楚。

1.2 三类角色的真实诉求拆解

系统里通常有三类人：用户（下单方）、服务人员（接单方）、管理员（平台方）。每类人的核心诉求完全不同，功能设计要围绕诉求走，而不是围绕"表结构"走。

用户最在意的是"我约的时间到底能不能来人"，所以时间选择的可用性校验必须实时准确；服务人员最怕的是"系统给我派了个我根本去不了的单"，所以排班和接单要有冲突检测；管理员最头疼的是"用户和服务人员扯皮"，所以要有完整的操作日志和纠纷处理入口。这三条想明白了，功能清单自然就出来了。

1.3 功能边界：哪些必须做，哪些可以砍

做项目最忌讳贪大求全。基于真实落地经验，我把功能分成三档：

必须做（MVP核心）：用户注册登录、服务分类浏览、服务详情、选择时间段下单、订单列表与详情、服务人员接单/拒单、订单状态流转、基础评价。

建议做（体验加分）：服务人员排班管理、订单改约与取消、简单的派单推荐（按距离或评分排序）、消息通知（站内信即可）、管理后台的订单检索。

可以砍（Demo阶段）：在线支付真实对接（用模拟支付即可）、复杂的智能调度算法、多城市多门店、优惠券营销体系、实时聊天。

这个划分不是拍脑袋，而是按"没有它系统跑不跑得起来"来定的。支付这块特别说明一下：很多项目卡在支付对接上耗掉大半时间，其实课程或实践项目用模拟支付完全够用——下单后点"支付"直接把状态改成已支付，把精力留给真正体现设计能力的订单流转和冲突检测上。

2. 数据库设计：整个系统的地基

表设计错了，后面代码写得再漂亮也是补丁摞补丁。这块我按"核心表+关键字段+设计理由"的方式讲，重点说清楚每个字段为什么这么设。

2.1 核心表结构与字段取舍

系统核心表大概七八张，我挑最关键的四张展开。

用户表（user）：除了常规的账号密码昵称手机号，一定要加role字段区分身份（0用户/1服务人员/2管理员），以及status字段（正常/禁用）。很多人把服务人员单独建一张表，其实早期没必要，用角色区分更灵活，等业务复杂了再拆。

服务表（service_item）：服务名称、分类、单价、时长（分钟）、描述、封面图、上下架状态。这里的关键是duration 字段——服务时长必须结构化存储，因为排班和冲突检测全靠它。别把"约2小时"写成文本描述，一定要存成整数120。

服务人员表（staff）：关联 user_id、擅长分类、服务区域、当前接单状态、评分、累计接单数。评分和接单数做成冗余字段，虽然违反范式，但列表页排序时能省掉大量聚合查询，这是典型的"用空间换查询性能"的取舍。

订单表（order）：这是最复杂的。核心字段包括订单号、用户id、服务id、服务人员id、预约日期、开始时间、结束时间、订单状态、金额、支付状态、创建时间、备注。其中开始时间和结束时间都要存，不能只存开始时间靠服务时长算——因为改约、加时等场景下实际时长可能和服务标准时长不一致，存下来才准确。

CREATE TABLE `order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单号', `user_id` bigint NOT NULL, `service_id` bigint NOT NULL, `staff_id` bigint DEFAULT NULL COMMENT '接单后才有值', `service_date` date NOT NULL COMMENT '预约日期', `start_time` datetime NOT NULL COMMENT '服务开始时间', `end_time` datetime NOT NULL COMMENT '服务结束时间', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待支付 1待接单 2已接单 3服务中 4待确认 5已完成 6已取消', `amount` decimal(10,2) NOT NULL, `pay_status` tinyint NOT NULL DEFAULT 0, `remark` varchar(255) DEFAULT NULL, `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_staff_date` (`staff_id`, `service_date`), KEY `idx_user` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意那个idx_staff_date联合索引，它是冲突检测查询的命脉，后面会讲为什么。

2.2 时间冲突检测的字段设计逻辑

这是整个系统技术含量最高的地方，也是面试和答辩时最容易被追问的点。核心问题：如何判断某个服务人员在某个时间段是否空闲？

最朴素的做法是查这个人的所有订单，逐条比对时间是否重叠。但这样有两个问题：一是订单多了查询慢，二是"服务人员主动设置的不可用时间"（比如请假）没地方存。

所以正规做法是单独建一张排班表（staff_schedule），把"可服务时间"和"不可服务时间"都结构化：

CREATE TABLE `staff_schedule` ( `id` bigint NOT NULL AUTO_INCREMENT, `staff_id` bigint NOT NULL, `schedule_date` date NOT NULL, `start_time` datetime NOT NULL, `end_time` datetime NOT NULL, `type` tinyint NOT NULL COMMENT '1可服务 2不可服务(请假等)', PRIMARY KEY (`id`), KEY `idx_staff_date` (`staff_id`, `schedule_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

有了这张表，判断逻辑就清晰了：一个时间段能被预约，当且仅当它落在某条 type=1 的可服务区间内，且不与任何已接订单的时间重叠，且不与任何 type=2 的不可服务区间重叠。这个"三重校验"是很多Demo系统缺失的，补上之后系统的专业度立刻不一样。

2.3 状态字段的枚举设计陷阱

订单状态用 tinyint 存数字没问题，但枚举值一定要在代码里定义成常量或枚举类，绝对不能到处写魔法数字。我见过一个项目，订单状态在A文件里 3 表示"服务中"，在B文件里 3 表示"已完成"，最后数据全乱。

public enum OrderStatus { WAIT_PAY(0, "待支付"), WAIT_ACCEPT(1, "待接单"), ACCEPTED(2, "已接单"), IN_SERVICE(3, "服务中"), WAIT_CONFIRM(4, "待确认"), COMPLETED(5, "已完成"), CANCELLED(6, "已取消"); // 构造、getter 略 }

另外，状态迁移必须集中管理，不能散落在各个Service里。我的做法是写一个OrderStateMachine类，定义"当前状态 + 操作 → 目标状态"的映射表，任何状态变更都走它，非法迁移直接抛异常。这样测试的时候一目了然，也杜绝了"已完成还能取消"这类问题。

3. 预约与派单的核心逻辑实现

数据库搭好之后，真正体现功力的就是预约流程。这块我按"用户下单→系统校验→派单→接单"的完整链路讲，每一步都给出关键代码和踩坑点。

3.1 时间段可用性校验的完整实现

用户在前端选了个"3月15日 14:00-16:00"，后端要判断这个时间能不能约。完整校验分四步：

第一步，基础校验：时间不能是过去，结束时间必须晚于开始时间，服务时长要和服务定义匹配（或允许一定浮动）。

第二步，可服务区间校验：查 staff_schedule 里该人员当天 type=1 的区间，看目标时间段是否被完整覆盖。

第三步，订单冲突校验：查该人员当天所有未取消订单，判断时间是否重叠。

第四步，不可服务区间校验：查 type=2 的区间，排除请假等情况。

时间重叠的判断是核心，公式很简单但容易写错：两个区间 [a1,a2) 和 [b1,b2) 重叠，当且仅当a1 < b2 && b1 < a2。注意用左闭右开区间，避免"上一单16:00结束、下一单16:00开始"被误判为冲突。

public boolean isTimeOverlap(LocalDateTime aStart, LocalDateTime aEnd, LocalDateTime bStart, LocalDateTime bEnd) { return aStart.isBefore(bEnd) && bStart.isBefore(aEnd); }

这个判断看着简单，但我见过至少三个项目在这里翻车：有人用<=导致相邻订单误判冲突，有人只比较了开始时间没比较结束时间，还有人把日期和时间分开比较导致跨天订单出错。跨天是个大坑——如果服务是"3月15日23:00到3月16日01:00"，只按 service_date 查当天订单就会漏掉，所以查询范围要按 datetime 而不是 date 来圈。

3.2 派单策略：从"抢单"到"推荐"的演进

派单模式有两种主流：抢单模式和派单模式。

抢单模式是订单进入"待接单"池子，所有符合条件的服务人员都能看到并抢，先到先得。实现简单，适合早期。但问题是好单被秒抢、差单没人接，体验不均。

派单模式是系统根据规则主动分配给某个人。规则可以是"距离最近""评分最高""当前接单最少"。实现上，用户下单后系统跑一个推荐逻辑，给出候选人员列表，用户确认或系统自动分配。

我的建议是混合模式：系统先按规则推荐3-5个候选人，用户可以选择"指定某人"或"让系统分配"。这样既保证了匹配质量，又保留了灵活性。推荐排序的权重可以这样设：

这套权重不是绝对的，但思路是"先保证能来（距离），再保证来得好（评分），再保证不超负荷（负载）"。实际调参时，距离的权重通常要再高一些，因为通勤成本是硬约束。

3.3 并发下的重复接单问题

这是个隐蔽但致命的坑。假设一个订单同时被两个服务人员看到，两人几乎同时点"接单"，如果不做并发控制，可能两个人都接单成功，或者订单状态被覆盖。

解决方案有三层：

第一层，数据库乐观锁。订单表加个version字段，更新时带上版本号：

UPDATE `order` SET staff_id = ?, status = 2, version = version + 1 WHERE id = ? AND status = 1 AND version = ?;

受影响行数为0说明被别人抢先了，直接返回"手慢了"。

第二层，分布式锁（可选）。如果系统部署多实例，可以用 Redis 对订单id加锁，SET order:lock:{id} 1 NX EX 10，拿到锁才能操作。单机部署的话乐观锁就够了。

第三层，业务兜底。接单成功后立即二次校验该人员时间是否真的空闲，因为从"看到订单"到"点接单"之间，他可能被派了别的单。这层校验能挡住绝大多数脏数据。

这三层不是让你全上，而是按部署规模选。单机Demo乐观锁足够，多实例加Redis锁，业务兜底永远要有。

4. 订单状态流转与异常处理

订单一旦创建，它的生命周期管理就是系统稳定性的核心。这块讲状态机落地、改约取消的处理、以及退款这类异常场景。

4.1 状态机的代码落地方式

前面提了用枚举+映射表管理状态，这里给个具体实现思路。核心是一个Map<String, OrderStatus>，key 是"当前状态:操作"，value 是目标状态。

private static final Map<String, OrderStatus> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put("0:pay", OrderStatus.WAIT_ACCEPT); TRANSITIONS.put("1:accept", OrderStatus.ACCEPTED); TRANSITIONS.put("1:cancel", OrderStatus.CANCELLED); TRANSITIONS.put("2:start", OrderStatus.IN_SERVICE); TRANSITIONS.put("2:cancel", OrderStatus.CANCELLED); TRANSITIONS.put("3:finish", OrderStatus.WAIT_CONFIRM); TRANSITIONS.put("4:confirm", OrderStatus.COMPLETED); // ... } public void transit(Order order, String action) { String key = order.getStatus() + ":" + action; OrderStatus target = TRANSITIONS.get(key); if (target == null) { throw new BizException("当前状态不允许该操作"); } order.setStatus(target.getCode()); // 记录操作日志 }

这样写的好处是，所有合法迁移一目了然，新增状态只改映射表，不用满代码找 if-else。配合操作日志表，每次迁移记一条"谁在什么时间把订单从A改到B"，纠纷处理时就是铁证。

4.2 改约与取消的边界条件

改约的本质是"取消原时段+占用新时段"，但比单纯取消复杂，因为要保证新时段可用。流程应该是：校验新时段可用 → 释放原时段 → 占用新时段 → 更新订单时间。这四步要么全成功要么全回滚，必须放在一个事务里。

取消则要分状态讨论：

• 待支付取消：直接改状态，无成本。
• 待接单取消：直接改状态，释放时段。
• 已接单取消：要通知服务人员，可能涉及违约金（比如服务前2小时内取消扣20%）。
• 服务中取消：一般不允许，走纠纷流程。

违约金规则建议做成配置项而不是硬编码，因为不同服务、不同时间段的规则可能不同。早期可以简单点，只做"服务开始前X小时可免费取消，之后取消扣一定比例"。

4.3 退款与纠纷的兜底设计

退款这块，Demo阶段用模拟退款即可，但流程要完整：用户申请退款 → 生成退款单 → 管理员审核 → 执行退款 → 更新订单和支付状态。每一步都要留痕。

纠纷处理的核心是证据链。系统要能回答：这个订单谁接的、什么时候接的、服务人员什么时候到的（如果有打卡）、用户什么时候确认的、双方评价是什么。所以操作日志表（operation_log）是必须的，字段包括操作人、操作类型、操作前后状态、时间、备注。这张表平时不起眼，出事的时候是救命稻草。

5. 前端交互里那些影响体验的细节

后端逻辑再严谨，前端体验拉胯用户照样骂。这块挑几个预约类系统特有的交互点讲。

5.1 时间选择器的可用性反馈

用户选时间，最怕的是"选完了提交才告诉我不可约"。正确做法是时间选择器直接置灰不可约的时段。实现上，用户选定日期后，前端调一个接口拿该日期的"可约时段列表"，然后渲染时把不可约的置灰。

这个接口返回的数据结构建议是"可约区间数组"，而不是"每个小时的布尔值"，因为服务时长不固定，按小时粒度会不准。比如返回[{start:"09:00",end:"11:00"},{start:"14:00",end:"18:00"}]，前端据此渲染可选范围。

5.2 订单列表的状态分组

订单多了之后，用户找单很痛苦。列表页要按状态分组：待支付、进行中、待确认、已完成、已取消。每组给个数量角标。这个设计看着小，但对体验提升巨大——用户打开就知道"哦我有2个单要确认"。

服务人员端则要突出"今日待服务"和"待接单"，因为他们的核心动作是接单和上门，不是浏览历史。

5.3 消息通知的最小实现

完整消息系统很重，但最小可用版本很简单：一张 message 表，字段包括接收人、类型、标题、内容、关联订单、已读状态、时间。关键节点触发写入即可：下单成功、接单成功、服务开始前2小时提醒、订单完成待确认、退款审核结果。

前端用轮询（每30秒查一次未读数）就够，不必上 WebSocket。等真有实时性需求了再升级，早期别过度设计。

6. 部署上线与源码组织的实操建议

最后聊聊工程层面的事，这些是"能跑起来"和"能交付"之间的差距。

6.1 项目结构怎么组织才不乱

推荐经典的分层结构：controller（接口层）、service（业务层）、mapper/dao（数据层）、entity（实体）、dto（传输对象）、config（配置）、util（工具）。关键是DTO和Entity要分开，别拿数据库实体直接当接口返回值，否则字段一多就失控，还容易泄露敏感字段（比如密码）。

订单相关的Service建议单独拆一个OrderService，把状态机、冲突检测、派单逻辑都收进去，别散落在各处。这样测试和复用都方便。

6.2 开题报告里该突出什么

如果这个项目要写开题或结题文档，别把篇幅浪费在"系统截图+功能列表"上。评审真正看的是：你解决了什么别人没解决好的问题。时间冲突检测的三重校验、订单状态机的设计、并发接单的处理，这三点讲透，比堆十个页面截图有说服力。

技术选型部分也要说清楚"为什么选它"。比如为什么用 MySQL 不用 MongoDB——因为订单和排班是强关系、强事务的，关系型数据库更合适；为什么状态用枚举不用字符串——防止魔法值、便于校验。这种"选择背后的理由"才是加分项。

6.3 上线前必须自测的清单

交付前，这几条一定要自己走一遍：

• 同一服务人员同一时段，两个用户同时下单，是否只有一个成功；
• 订单从下单到完成，每个状态迁移是否都符合预期，非法操作是否被拦截；
• 跨天服务（23:00-次日01:00）的冲突检测是否准确；
• 取消已接单的订单，时段是否正确释放、能否被重新预约；
• 服务人员请假（type=2）后，该时段是否立即不可约；
• 管理员强制改单状态后，操作日志是否有记录。

这六条覆盖了系统最容易出问题的地方，全过了基本就能稳定演示了。

我在实际做这类系统时最大的体会是：预约系统的难点从来不在"增删改查"，而在"时间和状态"这两个维度上的严谨性。时间要精确到分钟、要考虑跨天和时区（如果涉及）、要处理并发；状态要闭环、要可追溯、要防非法迁移。把这两块啃下来，剩下的都是体力活。源码组织上，宁可早期多花半天把状态机和冲突检测抽成独立模块，也别图快到处写 if-else，后面改需求的时候你会感谢当时的自己。