Java开发上门家政预约平台：排期、状态机与支付回落实战

很多人拿到“Java 开发上门家政服务预约平台”这种标题，第一反应是“这不就是个普通CRUD项目吗”。但真正动手之后才发现，预约类系统的复杂度远高于表面——订单状态流转、技师排期冲突、时间窗口计算、微信支付回调对账、管理后台权限模型，任何一个环节设计不好，后面全是坑。

这篇文章就以我实际做过的一个“微信小程序 + Spring Boot 管理后台”的上门家政预约平台为例，把这套系统的设计思路、核心模块、关键代码和踩坑实录完完整整拆开来讲。无论你是准备做Java课程设计，还是想自个儿接私活做外包项目，这篇都能当作一份比较完整的参考清单用。

1. 项目概述与整体设计思路

1.1 这个项目到底做了什么事

上门家政服务平台，业务链路其实非常清晰：用户打开小程序，浏览服务项目（保洁、保姆、月嫂、家电清洗等），选择上门时间、地址、服务人员，在线支付下单；后台收到新订单后，管理员或系统自动派单给合适的服务人员；服务人员上门完成服务后，用户确认并评价。

听起来确实不复杂，但把这个流程落到代码里，涉及的东西就多了。小程序端要处理微信登录、地址管理、订单确认、支付唤起；服务端要处理预约时间校验、技师排期、订单状态机、支付回调；管理后台要处理员工管理、派单操作、服务项目管理、订单查询、统计报表。

我用到的技术栈是：Spring Boot 2.7 + MyBatis-Plus + MySQL 8.0 + Redis + 微信小程序原生 + Vue 2 + Element UI。选这套组合没别的特殊理由，就是生态最成熟、招人容易、出了问题网上一搜基本都有答案。

1.2 为什么选这套技术栈

先说服务端。Spring Boot 是Java领域做这类业务系统的默认选择，没有之一。Maven管理依赖、内嵌Tomcat、自动配置，开发效率比SSH那套老框架高太多。MyBatis-Plus 用起来比纯MyBatis顺手，单表CRUD基本不用写SQL，分页插件、逻辑删除、自动填充都是现成的。

管理后台用Vue + Element UI，原因也很实际：这套组合做中后台系统是成熟路线，表格、表单、弹窗、分页组件齐全，一个人开发也能快速搞定。小程序端用原生框架，不引入uni-app，因为家政业务本身不算复杂，页面数量控制在二三十个以内，原生完全够用，还能少踩一层框架的兼容性坑。

数据库选MySQL，Redis做缓存和分布式锁。预约系统的特点是读多写少——用户刷服务列表、查看技师档期、查订单状态，都是查询操作；真正写的只有下单、支付回调、派单、完成服务这几个节点。Redis在这里承担的不只是缓存，还要处理并发预约时的防重复下单问题。

1.3 核心业务闭环梳理

完整业务闭环拆开来看，分这么几条线：

用户线：微信登录 → 浏览服务 → 选时间选技师 → 下单支付 → 等待服务 → 确认完成 → 评价。

运营线：管理员登录后台 → 管理服务项目 → 录入技师与排班 → 处理订单（派单/改期/取消） → 结算对账 → 查看数据统计。

技师线：技师在小程序端（或后台H5端）查看待接订单 → 接单/拒单 → 开始服务 → 确认完成。

三条线之间通过订单这个核心实体串起来。用户和运营之间的关系，本质上是预约平台的供给侧管理问题——服务人数有限、时间段有限，系统要保证同一个技师在同一时间段不能被预约两次，这是整个系统最核心的约束条件。

2. 服务端核心细节与关键模块解析

2.1 数据库模型：最难设计的不是订单表，是排期表

很多刚接触这类项目的人，拿到需求就开始设计订单表、用户表、服务项目表，这没问题，但真正决定系统上限的是排期表的设计。

上门家政的预约维度横向要分三块：日期、时段、技师。设计时需要一个“排期表”来存储技师的可用时间段。我用的是最简单也最实用的一种方案：以“天”为粒度建排期条目，每条记录包含技师ID、服务日期、开始时间、结束时间、状态（可预约/已约满/休息）。

核心表结构大致是这样：

CREATE TABLE `technician_schedule` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `technician_id` BIGINT NOT NULL COMMENT '技师ID', `service_date` DATE NOT NULL COMMENT '可服务日期', `time_slot` VARCHAR(32) NOT NULL COMMENT '时间窗口，如 09:00-12:00', `service_item_id` BIGINT NOT NULL COMMENT '可服务项目ID', `status` TINYINT DEFAULT 1 COMMENT '1可约 2已满 3休息', `version` INT DEFAULT 0 COMMENT '乐观锁版本号', UNIQUE KEY `uk_tech_date_slot` (`technician_id`, `service_date`, `time_slot`, `service_item_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有两个关键点：第一，唯一索引要建在“技师+日期+时间段+服务项目”四个字段上，目的是防止并发插入导致重复排期；第二，加一个version字段做乐观锁，后面派单场景会用到。

订单表反而比较常规，字段无非是订单号、用户ID、技师ID、服务项目ID、服务日期、时间段、金额、支付状态、订单状态、地址快照、备注。需要特别说明的是，地址一定要做快照，不能关联用户地址表的主键——用户之后改了地址，历史订单里的服务地址不能跟着变，这一点做电商的朋友应该很熟悉，订单不仅要存ID，关键业务数据都要冗余一份快照。

2.2 预约流程的接口设计与状态机

预约流程的接口设计我拆成了两条路径：直接选技师下单和不选技师、由系统派单。

路径一：用户选择具体技师 → 下单时服务端做两件事：锁死排期记录 + 创建订单。

路径二：用户只选时间段 → 系统在支付成功后，从可用的技师列表里按规则分配。

不管哪条路径，接口传递的核心参数是一致的：serviceItemId（服务项目）、serviceDate（服务日期）、timeSlot（时间段）、addressId（地址）、remark（备注）。后端收到请求后，在事务里完成三项校验：项目是否存在且上架、时间段是否在当前可预约范围内（建议只开放未来7天）、该时间段是否仍有可预约名额。

预约下单整个流程我建议走“先锁排期、再创建订单、最后支付”的节奏。也就是说，用户点击“提交订单”时，后端立刻把对应的排期条目状态改成“锁定”（status=2），同时生成一个未支付订单，给用户15分钟的支付时间窗口，超时自动释放排期。

@Transactional(rollbackFor = Exception.class) public Long createOrder(CreateOrderReq req, Long userId) { // 1. 检查排期是否可约 TechnicianSchedule schedule = scheduleMapper.selectByCondition( req.getTechnicianId(), req.getServiceDate(), req.getTimeSlot(), req.getServiceItemId()); if (schedule == null || schedule.getStatus() != 1) { throw new BizException("该时间段不可预约"); } // 2. 乐观锁锁定排期 int rows = scheduleMapper.lockSchedule(schedule.getId()); if (rows == 0) { throw new BizException("手慢了，该时间段刚刚被抢走"); } // 3. 创建未支付订单 Order order = buildOrder(req, userId); orderMapper.insert(order); return order.getId(); }

订单状态机的设计，这块花点时间梳理清楚，后面写代码会省很多事。我定的状态流转是这样的：

待支付(0) → 待派单(1) → 已派单(2) → 待服务(3) → 服务中(4) → 已完成(5) → 已评价 待支付(0) → 已取消(6) // 用户主动取消或超时未支付 待派单(1) → 已取消(6) // 管理员取消

这里要强调一个容易被忽略的点：所有订单状态变更必须走统一的状态变更服务，不能到处直接update订单表。我用的办法是单独一张订单状态流转记录表，每次变更插入一条记录，包含订单号、原状态、新状态、操作人类型、操作人ID、备注、变更时间。这样做的好处非常明显——出问题时可以完整回溯，用户投诉时可以查到每一步谁在什么时间做了什么操作。

2.3 技师派单：自动派单还是手动派单

派单模块是这类平台最有业务含金量的部分。我的实现是两条路都支持，后台可以配置派单模式。

自动派单的逻辑，概括成一句话就是“在满足条件的技师里找到最闲的那个”。满足条件包含：服务项目匹配、排期空闲、在线状态正常、历史评价不低于阈值。排序规则先看当天已排订单数最少的，再看距离用户地址最近的。距离计算可以用经纬度边界框加Haversine公式来做简单筛选。

手动派单，就是后台管理员在订单详情里查看符合条件的技师列表，手动指定一位。手动派单的逻辑其实比自动派单更需要数据结构支撑——后台必须能在列表里展示技师的可服务时间、当日单量、平均评分、距离等综合信息。

自动派单有个业务细节需要处理好：支付成功后才进入可派单队列。用户下单未支付、支付回调还没确认成功时，不能把订单派给技师，否则用户反手取消支付，技师这边就空跑一趟。

public void autoDispatch(Long orderId) { Order order = orderMapper.selectById(orderId); if (order.getStatus() != OrderStatus.PENDING_DISPATCH.getValue()) return; // 查询可匹配技师：项目匹配 + 当日时段空闲 + 排单量最少优先 List<Technician> candidates = technicianMapper.findAvailable( order.getServiceItemId(), order.getServiceDate(), order.getTimeSlot()); if (candidates.isEmpty()) { // 进入人工派单池，推送提醒给管理员 notifyAdmin(orderId, "自动派单失败，等待人工处理"); return; } candidates.sort(Comparator .comparingInt(t -> t.getTodayOrderCount()) .thenComparing(t -> getDistance(t.getLat(), t.getLng(), order.getLat(), order.getLng()))); Technician assignee = candidates.get(0); // 再次锁定排期 + 更新订单 dispatchToTechnician(orderId, assignee.getId()); }

3. 小程序端与管理后台的实操实现

3.1 小程序端页面结构与用户路径

小程序端是用户直接接触的部分，这个项目里页面我拆成了下面这些：

• 首页：展示服务分类和服务项目Banner，搜索入口
• 服务列表：按分类筛选、按销量/价格排序
• 服务详情：服务介绍、价格、选择项目规格、查看评价
• 下单页：选择服务日期、时间段、上门地址、备注
• 订单列表：全部/待支付/待服务/待评价
• 订单详情：订单状态、倒计时、订单跟踪
• 个人中心：用户信息、地址管理、常用技师收藏

首页的核心是转化路径要短。家政用户的特征是想快速找到服务并下单，所以首页要直接露出两个核心入口：“立即预约”和“我的订单”，预约入口直接跳转到服务列表。

小程序登录用的是微信官方的code2Session接口，前端调用wx.login拿到code，传给后端，后端用code去微信接口换openid和session_key。这里要提醒一点：session_key是敏感数据，只能保存在服务端，坚决不能下发给小程序端。用户信息表里只需要存openid、昵称、头像、手机号。

3.2 管理后台的功能布局与权限控制

管理后台我按业务角色拆分成三个维度：超级管理员、运营人员、技师管理人员。不同角色看到的功能菜单不同。

后台核心模块包括：

• 仪表盘：今日订单量、营业额、待派单数、新注册用户数
• 订单管理：订单列表、订单详情、派单操作、取消/改期/退款
• 服务项目管理：服务类目、服务项、定价、上下架
• 技师管理：技师信息、资质材料审核、排期管理、服务区域管理
• 用户管理：用户列表、用户详情、账户状态
• 评价管理：评价列表、回复、违规评价处理
• 数据统计：订单趋势、服务项目销量排行、技师服务排行

权限控制用RBAC模型。用户表、角色表、菜单表、用户角色关联表、角色菜单关联表，这套是标准实现。后端用一个拦截器统一校验，加一个基于注解的权限标记：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequirePermission { String value(); }

在Spring MVC的拦截器里，从Redis中取出当前用户的权限列表，跟注解要求的权限比对。前端路由守卫再配合菜单权限做一次控制，用户没权限的菜单就不显示。这里的核心原则是：前端隐藏菜单只是体验优化，真正的权限校验必须放在后端接口层。如果前端隐藏了就以为安全，那离出事故就不远了。

3.3 前后端联调与接口约定

联调是这类项目比较耗时的一环。我的经验是先约定统一的接口返回结构，减少扯皮：

{ "code": 0, "message": "success", "data": { } }

code为0代表成功，非0代表业务错误，message是给前端直接展示的错误提示。这样前端的请求封装就可以做得很统一——拦截器里统一判断code，非0就走全局错误提示，不需要每个接口单独处理。

另一个比较重要的点：小程序端访问后台接口必须配域名白名单。微信小程序要求所有请求域名必须是HTTPS且在后台配置合法域名。开发阶段可以用“不校验合法域名”这个开关，但上线前必须换到正式域名，并且SSL证书要提前买好配置好。这个环节经常被忽略，结果就是明明接口通了，小程序里一请求就报错。

接口设计上，前后端联调最容易出问题的是日期时间的格式。小程序端传入的日期格式统一用yyyy-MM-dd，时间窗口统一用HH:mm-HH:mm字符串。千万别用时间戳在前后端之间传日期——数据库是DATE类型、Redis缓存的是字符串，直接用时间戳不仅可读性差，跨时区还会出莫名奇妙的问题。

4. 订单状态机、并发控制与缓存设计

4.1 并发预约场景的防重设计

家政预约平台看起来不像电商秒杀那样有超大并发，但“热门技师+黄金时间档”出现并发抢单的场景很常见。比如平台上有个评分4.9的保洁阿姨，周六上午的时段放出去，几十个用户同时下单，如果没有并发控制，就会出现同一时段被多个订单同时锁定的情况。

应对这个问题，我在三个层面各加了一层保障。

第一层是数据库唯一索引。前面提到的排期表唯一索引，保证了同一技师同一时间段的排期也不会插入重复数据。第二层是Redis分布式锁，下单接口进来时先尝试获取订单级锁：

String lockKey = "order:create:" + scheduleId; boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(5)); if (!locked) { throw new BizException("系统繁忙，请稍后重试"); }

第三层是数据库的乐观锁。锁排期的UPDATE语句带上version校验，更新影响行数为0说明排期状态已经被别人改了。

UPDATE technician_schedule SET status = 2, version = version + 1 WHERE id = #{id} AND status = 1 AND version = #{version}

三层防重设计下来，即使流量集中到某个热门时段，也能保证同一排期只会被一个订单成功占用。

4.2 Redis缓存的使用与一致性处理

缓存的主要使用场景是首页服务列表、热门服务推荐、技师排期信息、用户会话信息。

服务列表和技师排期是典型的读多写少数据，缓存策略比较简单：查询时先读Redis，命中直接返回，未命中查数据库并回填，设置合理的过期时间。

但订单状态这种高频变化的数据，缓存策略就要慎重了。我的做法是：订单状态不设业务缓存，全部直接查库。原因是订单状态变更时机分散且每个状态都可能被用户刷新查看，缓存带来的性能提升不明显，却引入了数据一致性问题。

而技师排期数据的缓存设计细节多一些：排期信息在用户浏览阶段直接读缓存，一旦用户提交订单，在事务内更新数据库，同时主动删除缓存中这位技师的相关排期key，让下一次请求重新回源加载。这里不推荐设置短过期时间等它自然失效，因为用户预约后若缓存还显示“空闲”，会造成误导。

另一个缓存使用细节：微信登录的session信息用Redis存储，key是用户ID，value存openid和session_key，过期时间设置为2小时。用户操作接口时通过请求头携带token换取用户身份信息。

4.3 支付回调与订单状态的一致性

家政平台支付用得最多的还是微信支付。微信支付的流程是：后端生成预支付订单，拿到prepay_id返回给小程序；小程序端调起支付；用户输入密码完成支付；微信服务器向后端配置的回调地址发通知。

支付回调的处理有几个容易踩坑的地方，我重点说两个：

第一个坑：回调接口要做幂等处理。微信官方会重试回调，直到开发者返回success。如果回调处理逻辑没有幂等，比如重复更新用户的订单状态从“待支付”改成“待派单”，第二次回调来了又执行一次更新逻辑，虽然最终状态还是“待派单”，但过程中的状态变更记录、资金流水记录可能就会产生脏数据。我的处理方案是：在回调逻辑里先检查订单当前状态，如果已经是“待派单”，直接返回success，不再重复处理。

第二个坑：金额必须校验。回调数据里有微信返回的实付金额，必须和订单表里的应付金额比对。不一致直接记录异常并告警，绝对不能以回调金额直接更新订单。

@PostMapping("/pay/notify") public String payNotify(@RequestBody String xmlData) throws Exception { Map<String, String> resultMap = WxPayUtil.xmlToMap(xmlData); // 1. 验签 boolean signValid = WxPayUtil.verifySign(resultMap, wxPayConfig.getApiV3Key()); if (!signValid) { return WxPayUtil.buildFailResp("签名验证失败"); } String orderNo = resultMap.get("out_trade_no"); Integer totalFee = Integer.parseInt(resultMap.get("total_fee")); // 2. 幂等校验 Order order = orderMapper.selectByOrderNo(orderNo); if (order.getStatus() != OrderStatus.PENDING_PAY.getValue()) { return WxPayUtil.buildSuccessResp(); } // 3. 金额校验 if (!order.getPayAmount().equals(BigDecimal.valueOf(totalFee, 2))) { throw new BizException("支付金额不匹配，订单号: " + orderNo); } // 4. 更新订单状态 + 插入支付流水 orderService.processPaidOrder(order); return WxPayUtil.buildSuccessResp(); }

5. 常见问题与排查技巧实录

5.1 小程序端高频问题排查

小程序端的坑基本集中在登录和网络请求上，我整理了一份高频问题速查表：

有一个比较隐蔽的问题：setData的数据量过大导致页面卡顿。有的新手喜欢把后端返回的整个订单列表setData上去，一次三四百条数据，低端安卓机上页面直接卡死。这里要做前端分页，每次只加载20条，滚动到底部再加载下一页。

5.2 服务端与后台的常见问题

服务端出问题的场景集中在数据一致性和权限控制上。最常见的一类问题：用户同时在两个设备登录操作，后台出现订单状态异常跳变。比如管理员在后台派单的同时，用户在小程序端取消订单，两个请求几乎同时到达，就可能出现“已派单的已取消订单”。我的处理方式是：所有订单状态变更接口都加乐观锁版本号，更新前比较版本，版本不一致直接返回失败，让操作方刷新后重试。

管理后台还有一个比较容易出错的地方是：多条件组合查询的SQL在分页时统计count不对。我用的办法是MyBatis-Plus的QueryWrapper配合分页插件，自带count优化，基本不用自己写count查询。但还是建议复杂查询先跑一遍真实数据，对比列表总数和导入的Excel记录数，防止漏查。

很多人在做后台列表的“筛选条件”时会忽略一点：时间范围和状态条件必须加到count查询里，否则列表页总数据量与分页总条数对不上。这个看起来简单的问题在项目上线后客户是最容易发现的。

5.3 项目上线前必须检查的清单

上线之前的检查清单，我根据实际经验总结了一份，照着逐一过一遍能够少掉很多坑：

数据检查：

• 服务项目、技师信息、排期数据是否完整没空数据
• 价格字段精度是否正确，金额相关的字段全部用分为单位存储
• 历史订单数据的地址快照是否包含省市区完整信息

功能检查：

• 预约流程完整走一遍：浏览 → 下单 → 支付 → 派单 → 服务 → 评价
• 取消订单、改期、退款流程各走一遍，确认状态流转正确
• 并发场景简单压测，同一热门时段连续下两单确认只有一单成功

安全与合规检查：

• 小程序域名已配置正确，HTTPS证书未过期
• 用户隐私协议、服务条款等文案已在小程序内展示
• 后台权限已配置好，普通管理员不能访问系统用户管理模块
• 后端接口做了登录校验，未登录不可访问业务接口

监控检查：

• 日志系统确认开启，除了业务日志，还要有时间记录和请求日志
• Redis和MySQL的慢查询监控开启
• 支付宝/微信支付的商户号配置正确，回调地址外网可访问

写在最后

这个项目的完整代码量差不多在2万行左右，工作量主要不在某个技术难点，而是分散在大量琐碎的细节里。排期冲突怎么处理、状态流转怎么设计、支付回调怎么保证幂等、后台权限怎么控制——每一步都值得认真打磨。

根据我做完这类项目的个人体会，有几个建议送给准备动手做的朋友：第一，先把状态机画清楚再写代码，状态流转不清晰的项目写起来就是一团乱麻；第二，排期表唯一索引一定会为并发问题兜底；第三，不要迷信复杂技术方案，这个业务用最简单可靠的工具就能cover住，过度设计才是最大的坑。