基于Java的预约制家政服务平台：Spring Boot订单调度与状态管理实战

简介：这是一份以家政服务平台为研究对象的毕业设计论文，完整记录了基于Java语言、Spring Boot框架和MySQL数据库从需求分析到系统实现的全部过程。平台面向管理员、雇主、雇员三个角色：管理员可进行个人中心、雇主管理、雇员管理、资料认证、项目类型、服务项目、需求信息、预约申请、合同管理、评价管理等操作；雇主能发布需求、支付报酬、签订合同并评价雇员；雇员可申请预约并提供服务，各角色权限和业务闭环在文档中均有清晰说明。文档包含中英文摘要、目录、绪论、需求分析、系统设计、数据库设计等章节，并给出了界面布局设计与数据安全管理的具体方案。资源包仅含一个docx文档，大小约1.07MB，结构完整，可直接作为毕业设计选题思路或论文写作结构的参考。目前已有49人学习浏览，适合正在从事同类型管理系统设计与开发的学生使用，尤其能帮助读者快速理解Spring Boot整合MySQL的典型开发模式。

1. 基于Java的家政服务平台：这个项目到底在解决什么

在接到「基于java的家政服务平台的设计和实现」这类课题时，很多人的第一反应是把它当成又一个 CRUD 练习：用户表、订单表、服务表，写几个接口就收工。但真正动手的人会发现，家政服务平台的复杂度远超表面——它不是单纯的信息展示，也不是标准电商，而是一套围绕「服务人员调度」和「时段履约」展开的业务系统。用户下的不是商品订单，而是「某天某个时间段内需要一个服务人员上门」的预约单。这直接决定了订单状态机的复杂度、数据库表的设计方式，以及并发处理的重点。

这个平台的核心价值在于：服务人员不是库存里的商品，而是有时段约束的人力资源。系统要同时处理用户预约、服务人员排班、订单改派、取消扣费、评价回流等多个环节，每一环都可能成为性能或逻辑上的坑。本文会按从业者做这套方案的完整路径来写：从选型到建模，从核心接口实现到订单调度里的常见翻车场景，最后给出一个能让系统更稳的进阶技巧。如果你正打算用 Spring Boot + MySQL 落地一个类似的预约制服务系统，这篇文章可以帮你少走大量弯路。

2. 技术选型与整体架构：先搞清楚为什么是 Spring Boot 而不是别的

2.1 为什么 Spring Boot 是这类平台的主流选择

做家政服务平台，技术选型的核心逻辑不是「哪个框架新潮」，而是「团队上手成本低、生态成熟、招人容易」。Spring Boot 在这一点上有明显优势：它把配置自动化、内置服务器、健康检查等基础能力全部封装好，项目从初始化到能跑通第一个接口只需要几分钟。对比早期 SSH 或纯 Servlet 方案，省掉的不只是 XML 配置，还有大量环境搭建的时间成本。

另一个务实原因是：家政平台的业务逻辑集中在订单流转、服务人员排班、结算统计上，这些都需要可靠的事务管理。Spring 的声明式事务@Transactional在这一点上非常成熟，比手动管理 Connection 或者用其他轻量框架可靠得多。而 MyBatis-Plus 或 Spring Data JPA 的选择，则取决于团队对 SQL 控制力的需求。

2.2 架构分层与技术栈清单

我一般会采用经典的四层结构：Controller 层负责参数接收和结果包装，Service 层承载业务规则，Mapper 层处理数据持久化，Entity 层与数据库表结构映射。对于家政平台，重点不在分层本身，而在于把「业务不被稀释」——比如订单状态的变更，不应该散落在 Controller 里通过多次 Update 拼凑，而应该收敛在 Service 层的统一方法内。

一个适合家政平台的推荐技术栈如下：

这里要特别说明 Redis 的角色。家政平台的典型并发场景是「同一位服务人员在同一个时间段被多个用户同时抢约」。如果直接查数据库再去更新状态，在高并发下会出现超卖式的重复预约。Redis 的原子操作（如SETNX或 Lua 脚本）能很好的承担时段占用的预检工作，数据库则作为最后的持久化兜底。

2.3 从零搭建项目骨架：最小可运行步骤

如果你从空项目开始，我建议用 Spring Initializr 生成基础工程，依赖勾选 Spring Web、MySQL Driver、Lombok。生成后手动加入 MyBatis-Plus 和 Knife4j 的依赖坐标。

<!-- pom.xml 关键依赖 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>com.github.xiaoymin</groupId> <artifactId>knife4j-openapi3-jakarta-spring-boot-starter</artifactId> <version>4.4.0</version> </dependency>

第一个依赖引入的是 MyBatis-Plus 的 Spring Boot 启动器，3.5.3 版本对 Spring Boot 2.x 的兼容性最好，自带分页插件和 ActiveRecord 模式。第二个依赖是 Knife4j 的 OpenAPI3 版本，注意如果项目基于 Spring Boot 3.x，需要引入的是knife4j-openapi3-jakarta-spring-boot-starter；如果是 2.x，则用knife4j-openapi3-spring-boot-starter。版本不匹配是这里的经典翻车点，接口文档页面会直接打不开。

项目骨架搭好后的第一件事是配置数据源。在application.yml里除了常规的数据库连接信息，务必开启下划线转驼峰的映射配置。

spring: datasource: url: jdbc:mysql://localhost:3306/housekeeping?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

map-underscore-to-camel-case的作用是把数据库里的service_type_id自动映射为实体里的serviceTypeId，少写大量@TableField注解。log-impl配置为 StdOutImpl 后，控制台会打印完整 SQL 和参数，这个调试习惯能让你在开发期省掉大量猜测。逻辑删除配置建议从第一天就加上，家政平台的服务人员履历和订单记录都有审计需求，物理删除会留下数据隐患。

一个结构清晰的启动类应该主动扫描 Mapper 接口，同时排除 DataSource 的自动配置干扰。

@SpringBootApplication @MapperScan("com.example.housekeeping.mapper") public class HousekeepingApplication { public static void main(String[] args) { SpringApplication.run(HousekeepingApplication.class, args); } }

@MapperScan指定了 Mapper 接口所在的包路径，这样每个 Mapper 接口就不需要再单独标注@Mapper注解。SpringApplication.run是启动入口，如果后续要扩展成多环境部署，可以在这里通过args传入--spring.profiles.active=prod来动态切换环境配置。

到这里项目骨架已经可以启动，下一步是设计数据模型。这是整个系统中决定后续开发成本的一步，值得花最多的心思。

3. 数据库模型设计：服务人员、订单、时段三张核心表的拆解

3.1 服务人员表的字段设计原则

家政平台的用户侧和服务人员侧是两个独立的角色体系。服务人员不是「用户表加一个 role 字段」就能解决的，因为他们身上挂着一套独立的属性：服务技能（保洁、月嫂、养老护理）、可服务区域、从业年限、评分均值、接单状态（在线/休息/禁用）。

我设计service_personnel表时会把字段拆成三组，以便于后续扩展：

service_type_ids用逗号分隔存储其实是刻意的。如果单独建一张关系表虽然更符合范式，但每次查询服务人员列表时都要多一次 JOIN，考虑到家政平台的服务分类数量有限（通常不超过 20 个），用字符串存储后配合FIND_IN_SET查询，性能更好且实现更直观。

3.2 订单表：不要试图一个表装下所有状态

订单表是整个平台的核心，但也最容易在设计阶段被过度设计。常见做法是设一个order_status字段，用 0、1、2、3 表示待支付、待指派、进行中、已完成，看起来清晰，但真实业务远不止这些节点——还有用户取消、服务人员取消、平台介入取消、退款中、已退款、待评价等状态。

我建议把订单表拆成两层设计：

• 主表service_order：记录一次服务预约的核心信息，包括用户 ID、服务人员 ID（可空，指派后才填充）、服务分类 ID、预约日期、开始时段、结束时段、服务地址、订单金额、状态、创建时间。
• 状态流转表order_status_log：只存订单 ID、变更前状态、变更后状态、操作人类型、操作时间、备注。

主表只要保证当前状态下正确即可，所有历史节点都沉淀在日志表里。这样做有三个直接好处：第一，排查问题时能清楚看到订单从创建到完成的每个时间节点；第二，用户端可以展示「订单轨迹」时间线；第三，财务对账时可以精确还原「用户什么时候申请退款，平台什么时候审核通过」。

3.3 时段与排班：最容易被低估的表

家政服务按预约制运行，核心约束是「一个服务人员同一时间段只能有一个预约订单」。这个约束不落到数据库上，就会在并发场景下出问题。

常见做法是为服务人员建立排班表personnel_schedule，记录服务人员 ID、可服务日期、开始时段、结束时段。真正写订单时，再用 SQL 判断这个时间段有没有已被占用的记录。但这里有个性能陷阱：反复用区间查询判断冲突，在单表数据量大了以后会成为瓶颈。

合理的做法是在 Redis 里存储一个以「服务人员 ID + 日期 + 时段」为 key 的占位标识，抢单时先用 Redis 的原子操作尝试写入，写成功后才允许创建数据库订单；数据库的排班表只做兜底校验和人工排班的展示。架构上可以这样理解：Redis 是前置闸门，MySQL 是最终账本。

-- 确认某个服务人员在指定时间区间是否可预约（兜底校验SQL） SELECT COUNT(*) FROM service_order WHERE personnel_id = #{personnelId} AND service_date = #{serviceDate} AND status NOT IN ('CANCELLED', 'FINISHED') AND start_time < #{endTime} AND end_time > #{startTime}

这段 SQL 的查询逻辑是：找到该服务人员在指定日期下状态不是已取消或已完成的订单，再判断是否有时间区间重叠。时间重叠的判断条件是现有订单的开始时间 < 新订单的结束时间且现有订单的结束时间 > 新订单的开始时间，这个条件覆盖了部分重叠、完全包含、首尾相接的所有情况。这条 SQL 不需要每天执行很多次，它在架构中的定位是最终防线，高频拦截交给 Redis 处理。

3.4 完整建表 SQL 与字段注释参考

CREATE TABLE `service_order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号，业务可读', `user_id` bigint NOT NULL COMMENT '下单用户ID', `personnel_id` bigint DEFAULT NULL COMMENT '服务人员ID，未指派前为空', `service_type_id` bigint NOT NULL COMMENT '服务分类ID', `service_date` date NOT NULL COMMENT '预约服务日期', `start_time` time NOT NULL COMMENT '预约开始时段', `end_time` time NOT NULL COMMENT '预约结束时段', `service_address` varchar(255) NOT NULL COMMENT '服务地址', `order_amount` decimal(10,2) NOT NULL COMMENT '订单金额', `status` varchar(20) NOT NULL COMMENT '状态：CREATED/PAID/ASSIGNED/IN_PROGRESS/FINISHED/CANCELLED', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `deleted` tinyint NOT NULL DEFAULT '0' COMMENT '逻辑删除标记', PRIMARY KEY (`id`), KEY `idx_personnel_date` (`personnel_id`, `service_date`), KEY `idx_user_date` (`user_id`, `service_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='家政服务订单主表';

状态字段用语义化字符串而不是数字，可读性更强，也避免 1 到底代表已支付还是已指派这类歧义。两个联合索引分别对应「服务人员查某天订单」和「用户查自己的历史订单」这两个高频查询路径，这是订单表使用频率最高的两个入口。

逻辑删除字段deleted之所以保留，是因为未来做数据统计分析时，物理删除的记录会导致对账口径不一致。比如某个月总共接了多少单，如果包含了被删除的测试单，统计结果就会失真。

4. 用户端核心接口实现：从登录鉴权到下单的完整链路

4.1 双角色登录与 JWT 鉴权怎么设计

家政平台有普通用户和服务人员两种角色，登录和鉴权需要从一开始就区分清楚。常见做法是统一走同一个登录接口，通过手机号和密码验证后，在 JWT 的 payload 里写入role字段，然后在拦截器里根据role做接口权限控制。

public LoginResponse login(LoginRequest request) { // 根据登录类型区分查询用户表或服务人员表 if ("USER".equals(request.getLoginType())) { User user = userMapper.selectOne(new LambdaQueryWrapper<User>() .eq(User::getPhone, request.getPhone())); if (user == null || !BCrypt.checkpw(request.getPassword(), user.getPassword())) { throw new BizException("手机号或密码错误"); } String token = JwtUtil.createToken(user.getId(), "USER", user.getNickName()); return new LoginResponse(token, user.getNickName(), "USER"); } // 服务人员登录逻辑类似，但可能额外校验账号是否被禁用 }

代码里的LambdaQueryWrapper是 MyBatis-Plus 提供的链式查询构造器，eq方法相当于WHERE phone = ?，能避免手写 SQL 字符串时容易出现的拼写错误。密码校验使用 BCrypt 而不是 MD5，因为 MD5 撞库风险太高且无法抵御彩虹表。JwtUtil.createToken中我习惯设置 24 小时的过期时间，同时在 Redis 里维护一个 token 黑名单，用户退出登录时把 token 标记为失效。

服务人员的登录需要多一步状态校验——如果账号已被平台禁用，应该在登录时就返回明确提示。这个逻辑放在登录接口里，比放在拦截器里更合适，因为拦截器只能拒绝访问，给不出「账号被禁用」这个具体的业务提示。

4.2 服务列表与时段查询接口：注意数据一致性

用户进入首页看到的是服务分类列表，点击某个分类后需要看到可预约的服务人员以及人员对应的可约时段。这个接口的查询频率很高，不适合每次都实时去数据库里算。我的处理方式是把「服务人员基础信息 + 今日是否有可约时段」先聚合到 Redis 缓存，缓存里只存放服务人员 ID 和最近一天的时段概览，具体时段详情仍回数据库查询。

@GetMapping("/personnel/available") public Result<List<PersonnelVO>> availableList(@RequestParam Long serviceTypeId, @RequestParam String serviceDate) { // 1. 查符合条件的服务人员（状态正常且服务类型匹配） List<Personnel> personnelList = personnelMapper.selectList( new LambdaQueryWrapper<Personnel>() .eq(Personnel::getServiceTypeIds, serviceTypeId) .eq(Personnel::getStatus, "ACTIVE") .apply("FIND_IN_SET({0}, service_type_ids)", serviceTypeId)); // 2. 逐一查询服务人员在指定日期的已占用时段 List<Long> personnelIds = personnelList.stream().map(Personnel::getId).toList(); List<OrderTimeSlot> occupiedSlots = orderMapper.selectOccupiedSlots(personnelIds, serviceDate); // 3. 用预定义的时段模板减去已占用的时段，得到可预约时段 return Result.success(buildAvailableSlots(personnelList, occupiedSlots)); }

这里有一个很关键的注意点：FIND_IN_SET({0}, service_type_ids)的写法是为了匹配逗号分隔存储的服务类型字段。如果你的服务人员可以同时提供保洁和家电清洗两种服务，那么service_type_ids字段的值可能是1,2，用FIND_IN_SET(1, '1,2')可以匹配到。如果使用LIKE '%1%'会发生误匹配——比如服务类型 ID 是 11 时，%1%也会匹配到，这就是经典的踩坑场景。

可约时段的计算逻辑是拿预定义的时段模板（比如上午 8:00-12:00 拆成 4 个时段）减去已占用时段。这一步可以在 Java 内存中完成，不必写复杂的 SQL。需要注意一个边界情况：如果某位服务人员当天完全没有配置排班，那么他/她在界面上应该显示「暂无排班」而不是「全天可约」。

4.3 下单接口：事务边界与防重复提交

下单是整个平台的核心链路，涉及订单创建、预占服务人员时段、可能的优惠金额计算三个动作。这里的事务边界要把握准——不是所有东西都放进同一个事务就是对的。

@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(CreateOrderRequest request) { // 1. Redis原子预占服务人员时段 String slotKey = "schedule:" + request.getPersonnelId() + ":" + request.getServiceDate() + ":" + request.getStartTime(); Boolean locked = redisTemplate.opsForValue().setIfAbsent(slotKey, "1", Duration.ofMinutes(30)); if (!Boolean.TRUE.equals(locked)) { throw new BizException("该时段已被预约，请重新选择"); } try { // 2. 数据库兜底校验，防并发下Redis失效导致重复预约 int conflictCount = orderMapper.checkConflict(request.getPersonnelId(), request.getServiceDate(), request.getStartTime(), request.getEndTime()); if (conflictCount > 0) { throw new BizException("该时段已被预约"); } // 3. 创建订单并锁定服务人员 ServiceOrder order = buildOrder(request); orderMapper.insert(order); return OrderVO.from(order); } catch (Exception e) { // 4. 创建失败时释放Redis锁 redisTemplate.delete(slotKey); throw e; } }

setIfAbsent是 Redis 的原子操作，相当于SETNX，只在 key 不存在时才能写入成功。这里设置 30 分钟过期时间很关键——防止用户创建订单后长时间不支付导致时段一直被锁住，但过期时间也不能太短，否则用户在填写服务地址时超时被释放锁，支付时就会出现时段被抢的情况。

订单创建和支付是异步的，所以状态机里一定会有「已锁定时段但未支付」的中间状态。我见过一些设计把订单状态直接定为「待支付」，没有意识到这个状态同时承担了「锁定时段」的职责。后续做超时未支付自动取消时，定时任务需要同时释放 Redis 里的时段占位——取消订单的代码里如果忘删 Redis key，那么这个时段会变成「永远被占用但订单不存在」的脏数据。针对这种情况，更好的做法是给 Redis 的 key 设置与支付超时时间一致的过期时间，这样即使漏删也能自动释放。

4.4 参数校验和异常处理：让前端少背锅、后端少甩锅

家政平台的接口参数校验很容易被忽略，但实际上用户的输入是相当随意的。比如服务地址可能填入一个表情符号、预约日期可能是三个月前、电话号码可能少一位。这些都需要进入 Service 层之前就被拦截。

我习惯使用 spring-boot-starter-validation 配合@Validated注解来统一处理，对核心字段做嵌套校验。

@Data public class CreateOrderRequest { @NotNull(message = "服务人员ID不能为空") private Long personnelId; @NotNull(message = "服务日期不能为空") @FutureOrPresent(message = "服务日期不能早于今天") private LocalDate serviceDate; @NotNull(message = "开始时段不能为空") private String startTime; @NotNull(message = "结束时段不能为空") private String endTime; @NotBlank(message = "服务地址不能为空") @Size(max = 200, message = "服务地址过长") private String serviceAddress; @NotNull(message = "服务分类不能为空") private Long serviceTypeId; }

@FutureOrPresent是一个经常被忽略的校验注解，它直接拒绝用户在界面上选择过去的时间。@Size(max = 200)限制了地址长度，防止超长字符串写入数据库时出现 MySQL 严格模式下的报错。这些校验逻辑放在 DTO 上而不是 Service 方法内，职责更清晰，前端联调时也能第一时间看到明确的错误信息。

配合全局异常处理器，业务异常返回的是带状态码和消息的 JSON，而不是 Spring 默认的错误页。前端只认{ "code": 50001, "message": "该时段已被预约" }这种结构，联调效率会明显提升。

5. 订单状态流转与调度背后的隐藏逻辑：避开 5 个高频坑

5.1 状态机设计：别用 if-else 满天飞的方式管订单

订单状态流转是家政平台里最容易做乱的部分。用户支付成功后，订单要先进入「待指派」状态，管理员或系统自动分配合适的服务人员后变成「待服务」，服务人员开始服务后变为「服务中」，完成后进入「待评价」。加上用户取消、服务人员取消、平台取消等分支，状态组合超过十种。

用if (status == 1 && nextStatus == 2)这种方式写，一旦状态变多，代码里会充满状态组合判断，出一个新状态就要改动一堆分支。我的做法是引入一个简单的状态机校验器，用配置集中管理什么状态下可以流转到什么状态。

public class OrderStatusMachine { private static final Map<String, Set<String>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put("CREATED", Set.of("PAID", "CANCELLED")); TRANSITIONS.put("PAID", Set.of("ASSIGNED", "CANCELLED")); TRANSITIONS.put("ASSIGNED", Set.of("IN_PROGRESS", "CANCELLED")); TRANSITIONS.put("IN_PROGRESS", Set.of("FINISHED")); TRANSITIONS.put("FINISHED", Set.of()); } public static boolean canTransition(String current, String target) { Set<String> allowed = TRANSITIONS.get(current); return allowed != null && allowed.contains(target); } }

状态机的价值是让非法流转在入口处就被拦截，比如已完成的订单不可能被改成待支付。这个校验可以在 Service 层更新的前后都调用，双保险。实际代码里Set.of是 JDK 9+ 的语法，如果你项目用的是 JDK 8，要改成Collections.unmodifiableSet(new HashSet<>(Arrays.asList(...)))，这也是一个容易忽略的兼容性问题。

5.2 自动指派服务人员的策略：距离优先还是评分优先

订单支付后如果没有人工指派，系统可以按策略自动分配服务人员。这个策略看起来很简单——找同区域、同服务类型、状态在线的人——但实际做起来有不少细节。

@Scheduled(cron = "0 */5 * * * *") public void autoAssignOrders() { // 扫描所有待指派订单 List<ServiceOrder> pendingOrders = orderMapper.selectList( new LambdaQueryWrapper<ServiceOrder>() .eq(ServiceOrder::getStatus, "PAID") .eq(ServiceOrder::getServiceDate, LocalDate.now())); for (ServiceOrder order : pendingOrders) { List<Personnel> candidates = personnelMapper.findAvailableCandidates( order.getServiceTypeId(), order.getServiceDate(), order.getStartTime()); // 按评分倒序、接单量正序计算综合优先级 candidates.sort(Comparator .comparing(Personnel::getAvgScore).reversed() .thenComparing(Personnel::getOrderCount)); if (!candidates.isEmpty()) { assignPersonnel(order, candidates.get(0)); } } }

这个定时任务的频率设为每 5 分钟一次，匹配家政平台的业务节奏——用户从下单到支付通常需要 1-3 分钟，支付完成后等待分配，5 分钟内的响应时间在用户可接受范围内。但如果平台后续扩大规模，这种定时扫描的方式会出现问题：一是每 5 分钟扫描全表待指派订单，数据量大时会有延迟；二是同一时间段多个人同时下单时，可能出现候选人重复推荐同一个人——这里又需要回到 Redis 锁去控制并发。

更好的做法是事件驱动：用户支付成功时触发分配逻辑，而不是等定时任务扫描。定时任务只作为兜底，处理那些支付成功但因异常没有触发分配的订单。这是两个方案结合的经验，能兼顾实时性和可靠性。

5.3 避坑一：用户支付成功后订单状态没更新

这是一个相当常见的现象：用户明明支付成功了，订单状态还停留在「待支付」，用户反复刷新页面都看不到订单进入待指派状态。原因通常是支付回调接口里更新订单状态的代码失败了，比如抛了异常但没被捕获，或者更新时WHERE status = 'CREATED'条件不满足，更新了 0 行却没有提示。

解决方式是：支付回调里不要只做一次数据更新，更新后要主动查询一次订单状态确认，确认失败则记录一条日志到独立的支付回调表，并触发补偿机制。这样以后排查时不用翻服务日志，直接看支付回调表就知道哪一步出了问题。

5.4 避坑二：服务时段重叠查询条件写反了

判断两个时间段是否重叠，正确条件是现有开始时间 < 新结束时间 AND 现有结束时间 > 新开始时间。但很多人在写的时候习惯写成新开始时间 > 现有开始时间 AND 新结束时间 < 现有结束时间，这样只判断了新订单完全落在现有订单时间段内部的情况。如果新订单时间段只是部分重叠，这条 SQL 查不出来，就会导致一个服务人员同一时段被安排两单。

我建议把这段判断 SQL 写成注释放在 Mapper 接口方法上面，并配上两个测试用例：一个是「现有订单 9:00-10:00，新订单 9:30-10:30」部分重叠，一个是「现有订单 9:00-10:00，新订单 10:00-11:00」首尾相接。确认边界情况行为符合预期后再上线。

5.5 避坑三：取消订单忘记释放 Redis 时段占位

这是一个线上容易翻车的场景。用户下单锁定了一个时段，后来支付超时或主动取消，数据库订单状态改成了已取消，但 Redis 里的schedule:{personnelId}:{date}:{startTime}这个 key 还在。30 分钟后过期还能自己恢复，但如果在用户取消订单后，另一位用户在同一时段下单，检查 Redis 时发现 key 存在，就提示「该时段已被预约」，但实际上那个时段是空闲的。

要根治这个问题，不只是在取消订单的业务方法末尾redisTemplate.delete(slotKey)，更要在设计层考虑：Redis 占位 key 的过期时间应该设计成略大于支付超时时间（比如支付超时 30 分钟，过期时间就设 35 分钟）。这样即使取消逻辑漏了删除 key，过期后也能自动清理，系统做到最终一致。

5.6 避坑四：定时任务重复执行导致服务人员被重复指派

当部署了多个应用实例时，@Scheduled 注解的定时任务会在每个实例上都执行一遍，导致同一个待指派订单被多个实例同时分配，最终可能分配给两个不同的服务人员。这就是分布式环境下的经典定时任务重复执行问题。

解决方式是在 Redis 里设置一个分布式锁，让同一时刻只有一个实例执行定时任务。

@Scheduled(cron = "0 */5 * * * *") public void autoAssignOrders() { String lockKey = "lock:autoAssign"; Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofMinutes(4)); if (!Boolean.TRUE.equals(locked)) { return; // 其他实例已拿到锁，本次跳过 } try { // 执行分配逻辑 } finally { redisTemplate.delete(lockKey); } }

锁的过期时间设置为 4 分钟，比任务执行间隔 5 分钟略短，这样即使任务执行时间过长，锁也会自动释放，不会造成后续任务永远无法获得锁。但要注意，这里设置的过期时间必须在可接受范围内——如果任务执行需要 10 分钟而锁 4 分钟就过期了，另一个实例会在第 5 分钟时再次拿到锁，造成冲突。所以更稳妥的做法是使用 Redisson 的看门狗机制自动续期，而不是固定过期时间。

5.7 避坑五：服务人员接单后爽约没有兜底

服务人员接单后如果临时爽约，用户端的体验是灾难性的。系统层面能做的兜底是：在服务即将开始前 2 小时，如果订单当前状态仍是「待服务」，主动发一条短信给服务人员确认；如果服务人员一直没有点击确认，系统标记为「待人工干预」，管理员介入改派或电话联系。

这个兜底机制不复杂，核心在于调度一个@Scheduled任务，扫描「服务开始时间 - 2小时」内的待服务订单，逐条更新确认状态。容易踩坑的点是时区问题——如果用LocalDateTime.now()去比较数据库里的service_date和start_time，一旦服务器时区不是 Asia/Shanghai，扫描结果的准确度就会受影响。数据库连接参数和 JVM 默认时区要统一配置。

6. 进阶落地技巧：用冗余字段和定时任务补齐统计与结算能力

6.1 月度结算的金额快照：别等服务做完再算数

服务人员完成订单后，平台需要计算他的月度收入。如果每次统计时都去关联订单表和服务价格表，一旦某位服务人员的服务价格调整过，历史订单的收入就会按最新价格计算，对账时就会产生差异。

我的做法是在订单完成时生成一个金额快照字段，记录当时的价格计算依据，包括基础服务费、平台抽成比例、服务人员应得金额。后续月度结算直接 SUM 订单的快照字段，不做实时计算。

UPDATE service_order SET settle_amount = order_amount * (1 - platform_commission_rate), commission_rate = platform_commission_rate WHERE id = #{orderId} AND status = 'IN_PROGRESS'

6.2 服务人员评分的数据修正技巧

用户评价产生的评分是服务人员排序的重要依据。但直接用平均值有一个问题：接单 2 单且都是 5 分的服务人员，会排在接单 80 单且平均 4.9 分的人前面，这对用户并不公平。我采用的方案是贝叶斯平均：用全平台平均分作为先验值，把接单量作为一个权重因子，让接单少的服务人员评分向平台平均分靠拢。

SELECT id, (order_count * avg_score + 10 * 4.8) / (order_count + 10) AS weighted_score FROM service_personnel ORDER BY weighted_score DESC

这个公式里的 10 是人为设置的权重常数，4.8 是全平台的平均分先验。当服务人员接单越来越多，评分就越贴近真实的 avg_score；接单少的人则被平均分拉回。真正落地时这个计算会放在定时任务里预计算成rank_score字段，避免每次列表查询都做全表计算。

6.3 最终收尾：我相信这套设计能帮你少走弯路

如果让我总结做这个平台最值得记住的一句话，那就是：家政平台的核心不在服务本身，而在时间维度上的资源调度。所有复杂问题——并发抢占、状态流转、对账结算——都可以回归到「某个服务人员在某个时间点是否可用」这个原始约束上。设计时抓住这件事，实现时就不会跑偏。

把状态机配置化、把 Redis 锁用在做前置拦截、把金额快照在完成时定格——这三个习惯是我自己反复踩坑后才固下来的做法。尤其是金额快照，早期我偷懒不做，结果调价后结算对不上账，半夜还在手工修复数据，很狼狈。如果你的平台也涉及多角色、预约履约和结算，建议从第一天就把这套机制设计进去。

希望这篇文章能帮到你，在做这个项目的路上少一点熬夜排错，多一些平稳上线。

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