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因为家政业务本身不算复杂页面数量控制在二三十个以内原生完全够用还能少踩一层框架的兼容性坑。数据库选MySQLRedis做缓存和分布式锁。预约系统的特点是读多写少——用户刷服务列表、查看技师档期、查订单状态都是查询操作真正写的只有下单、支付回调、派单、完成服务这几个节点。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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有两个关键点第一唯一索引要建在“技师日期时间段服务项目”四个字段上目的是防止并发插入导致重复排期第二加一个version字段做乐观锁后面派单场景会用到。订单表反而比较常规字段无非是订单号、用户ID、技师ID、服务项目ID、服务日期、时间段、金额、支付状态、订单状态、地址快照、备注。需要特别说明的是地址一定要做快照不能关联用户地址表的主键——用户之后改了地址历史订单里的服务地址不能跟着变这一点做电商的朋友应该很熟悉订单不仅要存ID关键业务数据都要冗余一份快照。2.2 预约流程的接口设计与状态机预约流程的接口设计我拆成了两条路径直接选技师下单和不选技师、由系统派单。路径一用户选择具体技师 → 下单时服务端做两件事锁死排期记录 创建订单。路径二用户只选时间段 → 系统在支付成功后从可用的技师列表里按规则分配。不管哪条路径接口传递的核心参数是一致的serviceItemId服务项目、serviceDate服务日期、timeSlot时间段、addressId地址、remark备注。后端收到请求后在事务里完成三项校验项目是否存在且上架、时间段是否在当前可预约范围内建议只开放未来7天、该时间段是否仍有可预约名额。预约下单整个流程我建议走“先锁排期、再创建订单、最后支付”的节奏。也就是说用户点击“提交订单”时后端立刻把对应的排期条目状态改成“锁定”status2同时生成一个未支付订单给用户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; // 查询可匹配技师项目匹配 当日时段空闲 排单量最少优先 ListTechnician 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是用户IDvalue存openid和session_key过期时间设置为2小时。用户操作接口时通过请求头携带token换取用户身份信息。4.3 支付回调与订单状态的一致性家政平台支付用得最多的还是微信支付。微信支付的流程是后端生成预支付订单拿到prepay_id返回给小程序小程序端调起支付用户输入密码完成支付微信服务器向后端配置的回调地址发通知。支付回调的处理有几个容易踩坑的地方我重点说两个第一个坑回调接口要做幂等处理。微信官方会重试回调直到开发者返回success。如果回调处理逻辑没有幂等比如重复更新用户的订单状态从“待支付”改成“待派单”第二次回调来了又执行一次更新逻辑虽然最终状态还是“待派单”但过程中的状态变更记录、资金流水记录可能就会产生脏数据。我的处理方案是在回调逻辑里先检查订单当前状态如果已经是“待派单”直接返回success不再重复处理。第二个坑金额必须校验。回调数据里有微信返回的实付金额必须和订单表里的应付金额比对。不一致直接记录异常并告警绝对不能以回调金额直接更新订单。PostMapping(/pay/notify) public String payNotify(RequestBody String xmlData) throws Exception { MapString, 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 小程序端高频问题排查小程序端的坑基本集中在登录和网络请求上我整理了一份高频问题速查表问题现象原因分析解决方案wx.login获取的code调后端报错40029code已使用或过期确认前端只调用一次wx.login后端用code换openid时不能重复提交请求后台接口报“url not in domain list”小程序后台未配置合法域名登录小程序管理后台在开发管理-服务器域名中配置request合法域名无法获取用户手机号手机号获取需要认证企业主体个人主体小程序无法获取手机号改用「填写手机号」的form表单方案request请求200但数据渲染不出来data路径取错或类型不匹配小程序setData前先console.log检查数据结构注意res.data是完整返回包取业务数据需要再往下一层flex布局不同机型显示不一致兼容基础库版本不一致统一设置libVersion: 2.x.x避免使用较新的CSS特性有一个比较隐蔽的问题setData的数据量过大导致页面卡顿。有的新手喜欢把后端返回的整个订单列表setData上去一次三四百条数据低端安卓机上页面直接卡死。这里要做前端分页每次只加载20条滚动到底部再加载下一页。5.2 服务端与后台的常见问题服务端出问题的场景集中在数据一致性和权限控制上。最常见的一类问题用户同时在两个设备登录操作后台出现订单状态异常跳变。比如管理员在后台派单的同时用户在小程序端取消订单两个请求几乎同时到达就可能出现“已派单的已取消订单”。我的处理方式是所有订单状态变更接口都加乐观锁版本号更新前比较版本版本不一致直接返回失败让操作方刷新后重试。管理后台还有一个比较容易出错的地方是多条件组合查询的SQL在分页时统计count不对。我用的办法是MyBatis-Plus的QueryWrapper配合分页插件自带count优化基本不用自己写count查询。但还是建议复杂查询先跑一遍真实数据对比列表总数和导入的Excel记录数防止漏查。很多人在做后台列表的“筛选条件”时会忽略一点时间范围和状态条件必须加到count查询里否则列表页总数据量与分页总条数对不上。这个看起来简单的问题在项目上线后客户是最容易发现的。5.3 项目上线前必须检查的清单上线之前的检查清单我根据实际经验总结了一份照着逐一过一遍能够少掉很多坑数据检查服务项目、技师信息、排期数据是否完整没空数据价格字段精度是否正确金额相关的字段全部用分为单位存储历史订单数据的地址快照是否包含省市区完整信息功能检查预约流程完整走一遍浏览 → 下单 → 支付 → 派单 → 服务 → 评价取消订单、改期、退款流程各走一遍确认状态流转正确并发场景简单压测同一热门时段连续下两单确认只有一单成功安全与合规检查小程序域名已配置正确HTTPS证书未过期用户隐私协议、服务条款等文案已在小程序内展示后台权限已配置好普通管理员不能访问系统用户管理模块后端接口做了登录校验未登录不可访问业务接口监控检查日志系统确认开启除了业务日志还要有时间记录和请求日志Redis和MySQL的慢查询监控开启支付宝/微信支付的商户号配置正确回调地址外网可访问写在最后这个项目的完整代码量差不多在2万行左右工作量主要不在某个技术难点而是分散在大量琐碎的细节里。排期冲突怎么处理、状态流转怎么设计、支付回调怎么保证幂等、后台权限怎么控制——每一步都值得认真打磨。根据我做完这类项目的个人体会有几个建议送给准备动手做的朋友第一先把状态机画清楚再写代码状态流转不清晰的项目写起来就是一团乱麻第二排期表唯一索引一定会为并发问题兜底第三不要迷信复杂技术方案这个业务用最简单可靠的工具就能cover住过度设计才是最大的坑。