简介预约制服务是本地生活数字化的重要形态尤其在家政保洁这类强时间属性的场景中系统设计直接决定用户体验。本文从清洁服务预约的真实痛点切入讲解如何构建一个覆盖用户端、保洁端、管理后台的完整闭环。技术实现上以前端uniapp跨端方案和后端Spring Boot为核心深入拆解微信登录、地图选点、支付回调幂等、时段库存防超卖、订单状态机等关键链路的设计原理。源码不仅适用于家政行业也可复用到上门洗车、家电维修等同类预约服务是理解企业级小程序全栈开发的工程实践参考。 做家政小程序源码这事我是从一次找保洁的糟心经历开始的。电话打了七八个价格说不清师傅有没有档期全靠碰运气好不容易约上了上门服务完连个评价入口都没有。后来我干脆自己动手把“上门预约家庭保洁服务小程序源码”完整做了一遍——覆盖用户预约、保洁员接单、后台派单三个角色跑通微信登录、地图选点、微信支付、服务排期、订单流转这些核心链路前后端代码都整理干净了。现在放出来家政创业者可以拿去做二次开发独立开发者可以拆解开当全栈练手项目做毕业设计的同学也能从中找到完整的订单状态机设计和支付闭环思路。这套源码能解决的问题很直接第一用户不用打电话小程序里选服务、选时间、选地址就能下预约单第二平台方不再需要人工电话协调订单自动进后台按区域和时段派给保洁员第三每一笔服务的评价、售后、回访都有数据沉淀比传统的微信群派单靠谱得多。下面我把从需求分析到部署上线的完整过程拆开讲每个关键点都配合了源码说明和踩坑记录照着改就能用。1. 项目整体设计与需求拆解1.1 核心场景与用户角色家政保洁不是一个单边生意它至少有三方角色在同一个流程里协同用户约服务、保洁员接服务、平台做调度和结算。所以设计这套源码的第一件事就是先把三条角色链路的场景画清楚。用户侧的核心场景是“快速预约”打开小程序、选保洁套餐、选上门时间段、填家庭地址、微信支付、等待师傅上门的短信提醒。这里要特别注意保洁服务不像外卖那样“下单即送达”订单的时间属性特别强用户关心的不是“什么时候发货”而是“哪天哪个时段师傅能来”。所以预约表单的设计比普通商城要复杂日期选择、时段选择、服务时长、地址标签这几个字段缺一不可。保洁员侧的场景是“按日程接单”登录小程序或配套的 H5 端看到被指派的订单确认接受、按时上门、开始服务、完成服务、提交现场照片。很多家政源码只做了用户端保洁端逻辑全部砍掉这是不对的因为保洁员如果还在用微信群接单你的平台就永远跑不出真实数据。平台管理端的场景是“调度和结算”后台要能看到所有订单的状态流转能手动改派/指派保洁员能配置服务项目和价格还要能核销优惠券、处理退款和售后。我们做的是预约制平台不是即时派单平台所以后台的“排班表”视图反而比实时地图更重要。1.2 功能模块划分我最终把源码拆成了三个子系统小程序前端、API 服务端、管理后台 Web 端三者共用同一个数据库。小程序前端需要具备的功能包括微信授权登录、手机号绑定、服务分类页日常保洁、深度保洁、擦玻璃、家电清洗、服务详情页价格、时长、包含的清洁项目、预约表单页日期时段地址备注、在线支付与支付结果页、订单列表与订单详情、评价页、个人中心我的地址、优惠券、发票申请。API 服务端需要提供用户登录接口wx.login 换 openid、服务列表接口、可预约时段查询接口动态返回某个日期还有哪些时段可选、订单创建接口、微信支付统一下单与回调接口、订单状态流转接口待支付、已支付待派单、已派单、服务中、待评价、已完成、已取消、退款中、评价提交接口、后台管理接口鉴权分离。管理后台我用了独立的前端工程因为平台管理员的操作密集度和小程序完全不一样需要表格、筛选器、批量操作这类组件。功能包括订单管理列表、数据概览、服务项目管理、保洁员账号管理、优惠券配置、评价管理。1.3 为什么是“预约制”而不是“即时要单制”规划功能时不少朋友建议我做成类似打车类的“周边保洁员抢单”打开地图下单附近师傅抢。我特意没走这个路线原因是家政保洁和出行是两种完全不同的运力模型。出行是车辆随叫随到、路线标准化、司机数量在高峰时段接近无限供给而保洁员的产能是“按天切块的”一个师傅一天顶多接三到四单且服务时长无法压缩。如果做抢单制用户高峰期下单后可能十几分钟无人响应体验极差。预约制则可以让平台用“闲时折扣”把需求平移到低谷时段这是家政行业运营的核心手段。所以这套源码里订单状态机专门为“预约-排期-履约”设计而不是为“派单-接单-到达”设计。2. 技术选型分析与源码结构2.1 前端选型uniapp 还是原生微信小程序我在赶集网上看过大量家政小程序源码前端不外乎两种原生微信小程序写法或者 uniapp 跨端框架写法。这套源码最终选了 uniapp不是因为原生不行而是考虑到很多做家政创业的团队会同时需要支付宝小程序和微信小程序两个入口原生代码要写两套成本直接翻倍。uniapp 的坑也不是没有编译到微信小程序后部分 CSS 属性支持不一致原生组件比如地图需要条件编译Vue3 版本对低版本微信开发者工具兼容性有要求这个问题后面专门讲。但在“一套代码多端投放”这个大前提下uniapp 的优势是压倒性的。我的源码基座用的是 Vue3 语法 Vite 构建配合 uni-ui 组件库整体开发体验比原生的 Page/App 写法现代很多。2.2 后端选型Spring Boot 还是 PHP/Node.js后端我选了 Spring Boot 3.x MyBatis-Plus MySQL 8.0。很多家政项目的 PHP 源码也跑得不错适合快速上线、迭代成本低但如果订单量起来后Spring Boot 的生态和稳定性优势会明显一些。这里没有绝对的优劣核心看团队长期维护的技术栈。Spring Boot 3.x 相比老版本把 javax 迁移到了 jakarta 命名空间网上很多旧教程直接抄会报错我在源码里统一用了新版的 starter 依赖同时把 MyBatis-Plus 升级到 3.5.5 版本以兼容 Spring Boot 3。需要说明的是如果你下到的其实是 Spring Boot 2.x 的旧源码MyBatis-Plus 的版本要降到 3.5.3 以下否则启动时会出现循环依赖问题。2.3 源码目录与数据库设计要点整个项目仓库分三个主目录miniappuniapp 前端、serverSpring Boot API、admin-web管理后台。数据库一共设计了 9 张核心表user用户、cleaner保洁员、service_item服务项目、order预约订单、order_log订单状态变更日志、address用户地址、evaluation评价、coupon优惠券、schedule_slot可预约时段。重点说schedule_slot表这是预约制家政平台最容易设计错的地方。它存的是“某一天某个时段是否可约、最多几单”比如 2025-06-21 上午 09:00-11:00 这个时段平台最多接 5 个预约。用户查询时接口只返回“剩余可约名额大于 0”的时段用户下单时事务里先更新schedule_slot的剩余名额再创建订单两步必须放在同一个数据库事务里否则并发下会超卖。这个设计和挂号抢号的逻辑本质是一样的热门时段一样会被疯抢。CREATE TABLE schedule_slot ( id bigint NOT NULL AUTO_INCREMENT, service_date date NOT NULL COMMENT 服务日期, time_slot varchar(32) NOT NULL COMMENT 时段如 09:00-11:00, total_quota int NOT NULL DEFAULT 5 COMMENT 总可预约数, booked_quota int NOT NULL DEFAULT 0 COMMENT 已预约数, deleted tinyint DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_date_slot (service_date, time_slot) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT可预约时段表;3. 核心功能实现与实操要点3.1 微信登录与手机号绑定家政服务平台必须绑定手机号原因是用户预约后保洁员上门的沟通成本极高平台需要通过虚拟号或短信触达纯微信 openid 登录没法保证业务可触达。登录实现用标准的wx.login拿 code后端调微信接口换 openid返回自定义 token。需要注意code 是一次性的后端必须在拿到 code 后立即调接口而且应当通过后端调用微信接口而不是小程序端直接暴露 appsecret。手机号绑定这里有一个微信官方规则变化2023 年之后新注册的小程序getPhoneNumber接口需要先在后台申请开通而且用户手机号按钮不能伪装成普通按钮必须使用微信提供的button open-typegetPhoneNumber原生能力。旧源码里那种“输入验证码绑定手机号”的逻辑可以直接扔掉了因为微信严格限制了非认证小程序的短信验证码发送能力。button classphone-btn open-typegetPhoneNumber getphonenumberhandlePhone 绑定手机号 /button3.2 服务预约表单从单选框到日期排期预约表单是前端代码量最大的页面也是最容易写乱的页面。我把它拆成四个组件区块服务项目选择区、日期选择区、时段选择区、地址选择区。服务项目选择区不适合用下拉框建议用横向卡片式单选视觉上突出单价和时长。日期选择区不要自己写日历组件直接用uni-calendar或小程序原生picker modedate都可以但要注意start属性设置为明天避免用户选到当天导致保洁员无法排班。时段选择区用单选框组数据来自后端接口而且要动态禁用已约满的时段。这里有个实操细节用户在日期选择器里切换日期后必须重新请求时段接口因为每个日期的剩余名额不一样。如果 6 月 20 日约满了6 月 21 日还有 3 个名额你不可能让用户继续选 6 月 20 日然后下单时报错。为了避免这个问题我在日期组件上绑定了一个change事件切日期就重新拉时段同时把已选中的时段清空。function loadTimeSlots(date) { // date 格式2025-06-21 uni.request({ url: ${baseUrl}/api/schedule/slots?date${date}, success(res) { const slots res.data.data || []; // 将剩余名额为0的时段设置为 disabled timeSlots.value slots.map(s ({ ...s, disabled: s.bookedQuota s.totalQuota })); selectedSlot.value null; } }); }3.3 地图选点微信小程序可以用天地图组件吗做家政小程序地址选择是很核心的交互。用户得能选到具体的小区楼栋而不是手动打字。一个热搜词问的是“微信小程序能使用天地图地图组件吗”我的回答是技术上能但不推荐。微信小程序的原生地图组件用的是腾讯地图服务自带wx.chooseLocation这个 API拉起微信内置的选点页面返回经纬度和地址名称。这是成本最低、体验最顺的方案因为它不需要额外申请地图 key也不需要在页面里渲染地图组件。如果你所在业务有城市级别的合规要求非要用天地图可以借助第三方插件或者 web-view 嵌入天地图 JS API但 H5 端嵌套 web-view 性能损耗明显而且wx.chooseLocation的定位结果是经纬度加地址文本的组合已经能满足绝大多数家政平台的需求。真正需要加密经纬度的是国家规定的测绘合规场景普通家政项目根本不必自找麻烦。我实现时在地址表单里放了一个“地图选点”按钮调wx.chooseLocation后把地址名称回填到输入框再让用户手动补充门牌号这个组合比让用户纯手动输入要减少大量误差。3.4 微信支付与服务订单闭环订单状态机的设计我走的是这个链路待支付 - 已支付待派单 - 已派单 - 服务中 - 待评价 - 已完成这条链路里有两个坑必须提前解决。第一个坑是支付回调的幂等性。微信支付回调可能重复推送同一笔订单后端写成“收到回调就更新状态”会出大问题。正确做法是回调里先查订单当前状态只有“待支付”才执行更新其余状态直接返回成功。第二个坑是“已支付待派单”阶段用户可能突然发起退款。家政权重高、客单价也不低一单几百元是常态用户支付后过几分钟后悔的概率不低。所以我在订单详情页放了“申请退款”入口后端将订单状态置为“退款中”同时冻结保洁员派单等平台审核后执行微信支付退款接口。派单逻辑没有做全自动算法因为初始版本的小程序需要人工干预更稳妥。后台管理员在订单详情点击“指派保洁员”弹出可选保洁员列表按当日排班过滤确认后调接口更新订单的 cleaner_id 并推送给保洁员小程序端。Transactional public boolean assignCleaner(Long orderId, Long cleanerId) { Order order orderMapper.selectById(orderId); if (!OrderStatus.PAID.equals(order.getStatus())) { throw new BizException(当前状态不可派单); } Cleaner cleaner cleanerMapper.selectById(cleanerId); if (cleaner null || !cleaner.getAvailable()) { throw new BizException(保洁员不存在或不可用); } order.setCleanerId(cleanerId); order.setStatus(OrderStatus.ASSIGNED); orderMapper.updateById(order); // 记录状态变更日志 orderLogMapper.insert(OrderLog.create(orderId, PAID, ASSIGNED, 后台管理员派单)); return true; }3.5 优惠券、评价与售后的扩展位优惠券我使用了分布式锁加数据库唯一索引的双重防重避免用户在支付瞬间用同一张优惠券重复抵扣。评价功能相对简单前端提交星级和文字后端校验该订单状态必须是“待评价”才能提交提交后订单状态变为“已完成”。很多人问评价是不是必须做。我明确回答家政平台必须做评价因为保洁服务的质量高度依赖口碑用户选保洁员的核心参考就是历史评价不做评价的平台很难积累信任资产。评价提交后管理后台可以对差评订单进行回访和售后处理把“差评”变成“二次服务机会”这在实际运营中非常重要。4. 从零到一完整落地过程记录4.1 环境准备与源码导入拿到源码后不要直接双击打开先按顺序确认环境。前端 uniapp 用 HBuilderX建议 4.0 以上版本导入。后端要 JDK 17、Maven 3.8、MySQL 8.0。管理后台如果是 Vue3 工程则用 pnpm install 安装依赖Node 版本建议 18。环境准备阶段踩过最多的坑是端口冲突和 MySQL 版本兼容。Spring Boot 3.x 默认使用 MySQL Connector/J 8.x如果数据库是 MySQL 5.7需要调整驱动配置并确保useSSLfalse以免本地环境报 SSL 告警。我在源码的application.yml里统一配置了时区和 SSL 参数如果还有问题优先检查 MySQL 用户是否有远程连接权限新手在这一步最容易卡住。4.2 小程序前端流程贯穿前端页面总计 18 个核心流程是首页 - 服务列表 - 服务详情 - 预约表单 - 确认订单 - 支付 - 订单中心。首页我用了一个自定义搜索框加金刚区图标的方式服务分类做成宫格视觉上贴近主流电商小程序。服务详情页重点展示价格阶梯、服务包含项、服务前后对比图、用户评价列表这些信息直接影响转化率。预约表单提交前要做一个关键校验用户必须先登录且绑定手机号后端在订单创建接口里也做了同样的拦截防止绕过前端直接刷接口。支付环节我接的是公众号支付非小程序支付老版本和微信小程序支付两种方式源码里默认走微信小程序支付因为配置更简单wx.requestPayment直接拉起支付面板。4.3 后端预约接口与状态机实现后端接口设计遵循 RESTful 风格核心接口有/api/order/create、/api/order/pay/callback、/api/order/assign、/api/order/refund。创建订单时做了三步处理校验用户、校验服务项目下架状态、校验预约时段剩余名额。这三步必须放在事务里且应对schedule_slot行加锁SELECT ... FOR UPDATE以防止并发超卖。微信支付回调地址是 HTTPS 的必填项本地调试可以用内网穿透工具把回调转到本机但生产环境必须是备案域名。回调接收后验签保存transaction_id注意处理重复回调、失败重试的情况。订单状态机我单独写了一个枚举类所有状态变更都走OrderStatus.next()方法校验合法性比如“已完成”的订单不能再次退款“退款中”的订单不能派单非法流转直接抛异常。状态变更日志表记录了每次变化的操作人、操作时间和原因描述方便售后环节回溯。4.4 压力与边界预约高峰与并发控制家政平台的预约高峰一般出现在节假日前一周比如春节前除尘、国庆前大扫除热门时段往往开放一分钟内就被抢完。这个场景下select for update锁住 slot 行再更新配额是可以的但是吞吐量有限。如果预计并发下单量超过 100 QPS建议引入 Redis 预扣库存模式Redis 扣减成功后异步落库。我在源码里做了 Redis 版本的预留实现注释也写了切换方式。但坦白说90% 的家政创业团队用不上这么复杂的架构数据库锁方案在日均 3000 单以内是完全够用的。小程序端在下单前还会调用一次“剩余名额查询接口”从体验层尽量避免用户提交后才发现约满的挫败感。5. 常见问题与排查技巧实录5.1 uniapp 在手机上预览没问题开发者工具白屏这个搜索词出现的频率非常高我实测也遇到过。现象是 HBuilderX 运行到微信开发者工具后白屏但手机上预览一切正常。排查步骤按顺序做先看微信开发者工具的控制台有没有 JavaScript 报错如果有大多是基础库版本太低导致新语法无法解析然后点击开发者工具右上角“详情 - 本地设置”把调试基础库切换到 3.x 最新版。如果还不行在 HBuilderX 里执行“重新编译”并关闭开发者工具的 ES6 转 ES5 选项因为 Vite 构建产物已经是 ES6。还有一些情况是开发者工具版本太老无法识别 uniapp 生成的新组件格式升级微信开发者工具到最新稳定版基本能解决。总之记住一个判断原则手机上没问题、工具白屏优先怀疑工具本身和基础库不是代码问题。5.2 微信小程序分包异步化的正确打开方式家政小程序的页面数量很容易堆到 20 个以上主包体积一不小心就超过 2MB 限制。微信官方给出的方案是分包加载而“分包异步化”解决的是“分包之间互相引用资源”的难题。我的源码结构里把“评价晒单”和“售后申请”这类低频页面放进了subPackage主包只保留首页、预约、订单中心三个核心流程页面。使用分包异步化时要注意若在 A 分包里需要动态 import B 分包的 JS 方法必须使用异步调用不能直接静态引入否则编译报错。{ subPackages: [ { root: pages/order, name: order, pages: [order-detail, refund, evaluation] } ] }另一个注意点是分包之间的 CSS 隔离微信小程序不会自动共享自定义组件的样式公共样式要单独抽出来放进wxss并在 app.vue 中全局引入否则会出现同一段样式在分包页面里失效的诡异问题。5.3 自定义导航栏高度适配小程序顶部导航栏在 iPhone 的刘海屏、灵动岛和安卓全面屏之间的高度差异很大直接使用默认导航栏样式没问题但为了视觉统一很多源码会自定义导航栏。这时候就必须关注“微信小程序顶部导航栏高度”这个参数。正确做法是获取胶囊按钮的位置和状态栏高度动态计算导航栏内容区高度const menuButton wx.getMenuButtonBoundingClientRect(); const systemInfo wx.getSystemInfoSync(); const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height;这段代码的关键价值在于兼容所有机型。如果不做这个计算直接用 44px 固定高度在灵动岛机型上导航栏内容会明显偏上或偏下。5.4 小程序类目审核被拒怎么办家政预约小程序本身不涉及特殊类目但如果你在源码里加入了“保洁知识视频”“服务过程直播”这类功能微信审核时就会要求补充“文娱-其他视频类目”这就是热搜词里那句“你好,你的小程序涉及提供播放、观看等服务”的出处。处理办法很简单纯家政预约功能不要加视频板块如果确实需要展示视频教程请先办理《信息网络传播视听节目许可证》或选择接入已具备资质的第三方视频平台比如在 web-view 中嵌入腾讯视频链接。千万不要为了提高内容丰富度引用无资质视频源否则不仅审核过不了还面临处罚风险。5.5 时段库存扣减的并发问题有朋友问为什么用户点击提交订单后偶尔提示“时段已约满”但明明查询时还有名额。这就是并发下超卖问题的体现。两个用户同时查询时名额还剩 1 个但两人先后提交订单如果不做行锁或条件更新后提交的那个也能成功创建订单导致实际履约用户数超过时段上限。我给源码里加了一个条件更新的兜底 SQLUPDATE schedule_slot SET booked_quota booked_quota 1 WHERE id ? AND booked_quota total_quota如果影响行数为 0说明已约满事务回滚用户重新选择时段即可。这是最简单且不依赖 Redis 的防超卖方案。6. 部署上线与运营经验6.1 服务器、域名与备案后端部署我用的是 Linux 服务器2 核 4G 起步安装 Nginx 做反向代理MySQL 单独一台或使用云数据库配置不高也能跑得很稳。重点强调一下域名备案小程序 request 合法域名必须是 HTTPS且域名必须完成ICP备案否则线上环境直接报“不在以下 request 合法域名列表中”。申请 SSL 证书不一定要花钱我用的是 Let‘s Encrypt 的免费证书配合 Nginx 自动续期脚本一年下来零成本。API 服务的 Nginx 配置里还要注意将/api/前缀的请求代理到 Java 服务端口同时开启 Gzip 压缩因为小程序包体越小加载越快。6.2 迭代规划做好最小可用版本再扩展源码第一版我只做了最核心的预约闭环没有做会员卡、次卡、积分商城、拼团裂变这类花活。原因很简单先跑通业务真实流程再谈增长。第二版可以按需求优先级逐步加入次卡用户买 10 次深度保洁送 1 次、老客邀请有礼、保洁员定位打卡等功能。这个源码的架构还有一个额外价值它可以完整复用到“共享轮椅预约”“上门洗车预约”“家电维修上门”这类同城上门服务场景。你只需要把service_item表里的服务项目换掉重新设计一下价格模型其他登录、预约、支付、派单的逻辑基本可以原样复用。这也是我在结构上刻意保持通用的原因。6.3 个人实操感觉跑通这套源码后我最大的感悟是家政小程序源码难的不是技术而是把业务规则翻译成代码。比如预约时段的并发控制、支付回调的幂等、订单状态的非法流转校验这些细节任何一个没做到位真实跑业务的时候都会出事故。做的时候多问自己一句“如果两个用户同时做这件事会怎样”很多问题就提前暴露了。最后分享一个小技巧源码里我刻意留下了大量的中文注释OrderStatus、PaymentCallbackService这些核心类都写了详细的状态说明直接照着业务文档改就行。拿到源码后先别急着动代码花半小时把数据库表结构和订单状态机流程图过一遍再开始改业务配置效率会高得多。本文还有配套的精品资源点击获取