简介这是一套面向家政服务创业者与小程序开发者的上门预约家庭保洁服务解决方案源码专为快速构建轻量级微信小程序而设计解决传统家政行业预约低效、服务不透明、支付流程割裂等痛点。资源共2005个文件涵盖317个PHP后端逻辑文件、294个JS交互脚本、86个WXML页面结构、87个WXSS样式文件及234个HTML静态页含Layui与Font Awesome等前端组件完整呈现小程序Web管理端双模架构压缩包大小22.28MB结构清晰pages目录按功能模块划分models与services层封装数据操作与API调用便于二次开发扩展会员系统、多服务类型或第三方支付接入。目前已有210人学习下载开发者可直接部署调试快速掌握家政类小程序的预约调度、实时定位导航、微信支付集成及服务评价闭环等核心实现逻辑。 “上门预约家庭保洁服务小程序源码”这个话题在社群和私信里被问过很多次。很多人手里拿到一份源码却不知道怎么把它跑起来、改成能上线接单的状态甚至分不清前端和后端分别该干嘛。这类源码的本质是一个连接用户、保洁阿姨和管理后台的三端业务系统核心不是代码本身而是预约履约的状态流转。这篇文章我会从业务拆分、技术选型、核心功能落地到联调排坑把家政预约小程序从0到上线的完整脉络捋一遍帮你真正做到“拿到源码能看懂、能改、能上线”。1. 项目整体构思与核心功能拆分1.1 家政保洁预约的业务角色与核心闭环上门保洁和卖实物商品最大的区别在于实物电商关心的是库存和物流家政服务关心的是“人”的排期和履约状态。一套完整的家庭保洁预约小程序至少要包含三个角色用户、保洁阿姨、平台运营者。用户端核心动作是“浏览服务-选择阿姨-选择时间-支付-等待上门-评价”阿姨端核心动作是“接单-查看地址-上门签到-开始服务-完工上传照片”运营端核心动作是“管理服务项目-审核阿姨-处理退款投诉-财务对账”。围绕这三个角色整个系统形成了一个核心闭环预约单从创建到完成的完整生命周期管理。在这个闭环里最关键的是“订单状态机”。我见过不少源码把订单状态只做成一个数字字段前端写死几个状态判断结果一到运营环节就乱套。正确的做法是事先定义好状态流转路径待支付用户提交预约单但还没付款。待接单支付成功系统推送给附近阿姨等待阿姨确认。已接单阿姨确认接单用户可以看到阿姨的联系方式和实时位置。服务中阿姨到达用户家中点击开始服务。待验收阿姨点击完工用户确认服务完成。已完成用户确认无误订单结束进入评价和结算环节。已取消用户在服务开始前取消或超时未支付系统自动取消。每一个状态之间的流转必须有对应的操作入口、权限校验和通知触达。很多入门源码这里做得特别简陋比如用户都能直接调接口把订单改成“已完成”这在真实项目里是致命的。1.2 核心功能模块与数据表设计思路理解了业务角色后下一步是拆功能模块和设计数据表。一份能用的家政预约源码数据库层面通常至少包含以下核心数据表用户表memberopenid、昵称、头像、手机号、默认地址。阿姨表worker姓名、头像、服务区域、服务项目、评分、接单数、状态空闲/忙碌/休息。服务分类表service_category日常保洁、深度保洁、擦玻璃、家电清洗等。服务项目表service_item属于哪个分类、单价、所需时长、是否支持预约指定阿姨。预约单表appointment订单号、用户ID、阿姨ID、服务项目ID、地址、经纬度、预约时间、状态、金额、支付单号。订单状态流转表appointment_log记录每一步操作人、操作时间和状态变化。评价表comment用户对阿姨服务内容和态度的评价。表格设计时最容易忽略的是“预约时间”字段。很多源码只存一个日期没有存时间段导致用户和阿姨之间频繁沟通补充时间。同时家政服务是按时间段排期的建议预约单里直接拆成service_date和time_slot例如上午9:00-12:00、下午13:00-18:00两个字段后面做阿姨排期冲突校验时会省很多事。另外地址字段建议存两份一份是用于展示的文本地址如“XX小区3栋2单元502”另一份是用于计算距离和派单的经纬度坐标。做“附近阿姨”推荐时直接通过经纬度计算筛选比模糊匹配地址文本靠谱得多。2. 技术选型解析前端小程序 后端接口这套组合怎么选2.1 前端小程序选型原生小程序还是uni-app拿到源码后最先需要确认的就是前端技术栈。家政预约小程序目前市面上主流源码有两种微信原生小程序和uni-app跨端项目。如果你只做微信小程序原生小程序是首选。原因很直接原生组件调用最直接地图、蓝牙、支付这些底层能力原生方案踩坑最少。微信小程序单选框radio-group、地图map等组件在原生环境下的兼容性和文档支持都是最好的。使用radio-group做服务项目单选、checkbox-group做多选加购都是常规操作但要注意radio在部分安卓机型上默认样式会变形建议label包裹元素并自定义选中态样式。如果你有同时发布支付宝小程序、抖音小程序甚至App的需求那uni-app是更合理的方案。uni-app用Vue语法开发一套代码多端编译。但要注意多端编译不是银弹——地图组件、支付组件在各端的API命名和参数存在差异你在微信端调通的代码编译到支付宝端大概率需要写条件编译代码单独适配。这里提醒一个具体坑很多人在开发工具里使用uni-app预览正常一到真机就白屏这个我后面第三节专门讲。2.2 后端技术栈Spring Boot、PHP、Node怎么选后端源码是我在看大家发来的代码时最想吐槽的部分。家政预约小程序的后端常见的有三种技术栈JavaSpring Boot MySQL Redis结构清晰、适合复杂业务和后续扩展但对服务器要求相对高部署配置比PHP复杂。PHPThinkPHP/Laravel MySQL部署简单虚拟主机都能跑适合个人开发者和低成本起步国内大量建站源码都走这个路线。Node.jsExpress/Koa MySQL/MongoDB适合前端开发者全栈上手IO密集型场景表现不错但生态相对小众。我的建议是如果这份源码你打算长期维护、后续要接多商户、财务分账、复杂的派单调度选Spring Boot体系如果只是本地跑通、给客户演示、快速上线验证业务PHP源码的部署成本最低。但无论选哪种数据库设计一定要先看代码可以乱一点表结构乱后面改起来真的想哭。小程序端请求后端接口时务必确认小程序后台配置的“服务器域名”是HTTPS且已在备案。很多源码自带的接口地址是http://localhost或http://192.168.x.x这种内网地址在微信开发者工具里可以勾选“不校验合法域名”跑通但在真机上会直接请求失败这是新手最常踩的坑。3. 核心功能实操从登录到订单完成每一步怎么落地3.1 微信登录与手机号授权用户打开保洁小程序后第一步是微信登录。标准做法是小程序端调用wx.login获取临时code把code发给后端后端拿着code去微信接口code2session换取openid和session_key。openid是用户在小程序里的唯一标识绝对不能只靠前端传一个昵称和头像来识别用户这是前后端分离项目里很常见的安全漏洞。登录之后是手机号授权。这里要注意微信官方在2023年后调整了规则获取用户手机号需要使用企业认证的小程序并且调用button组件开放能力通过getPhoneNumber事件拿到动态令牌code再交给后端换取真实手机号。个人主体小程序无法直接获取用户手机号。源码里如果写着能直接拿到手机号多半是老版本接口现在上线审核会挂。实操中手机号这块我建议做成“非强制授权”用户可以先浏览服务和阿姨真正下单时才需要手机号。强制登录会白白流失大量只想看看的用户。3.2 服务选择与阿姨匹配的实现细节服务选择页面在情感上很像外卖点单但逻辑上更复杂——因为家政服务是非标品用户选择的不只是“服务项目”还包括“谁来服务”和“什么时候服务”。服务项目页面我用radio-group和checkbox-group组合来实现选择。典型交互是用户先单选一个大分类例如“日常保洁”然后勾选多个具体的保洁项例如“厨房深度清洁”“阳台清洗”最后合计金额和时长。这种场景下radio-group绑定当前选中分类checkbox-group绑定已选中的保洁项列表代码逻辑上要把“分类”和“项目”数据分开处理。阿姨匹配推荐部分是家政小程序源码技术水平的分水岭。简单版本的做法是后端根据用户下单地址的经纬度查询服务区域覆盖该点的阿姨。再筛选出在用户选择的时间段内没有排班的阿姨。按评分或接单量排序取前几位返回给前端展示。这里涉及一个经纬度范围计算的SQL写法。用MySQL可以直接按地球半径公式算距离但数据量大了以后性能会变差优化手段是把阿姨的服务区域提前编码成矩形或半径圆用“经纬度在范围内”的枚举查询代替实时计算。如果你拿到的源码是直接用6371 * acos(...)这种全表计算的建议后面数据量上来再优化起步阶段完全够用。3.3 地址选择地图组件与经纬度的妙用地址选择是家政类小程序和普通电商最不一样的地方。用户要服务上门必须给到精确的小区和门牌号。小程序端我用map组件结合微信的wx.chooseLocation接口用户在页面里搜索或拖动地图选点拿到选择的经纬度后再用逆地址解析腾讯位置服务反推出详细的文本地址。这里有几个细节wx.chooseLocation需要在小程序后台申请开通位置接口权限否则调用会报错。逆地址解析建议用腾讯位置服务小程序插件在app.json里声明插件后通过requirePlugin调用按官方文档配置好key。如果用uniapp跨端项目要特别注意各端的map组件和定位API差异。用户手动输入的详细门牌号“3栋2单元502”要和地图选点产生的地址分开存。不要篡改用户填写的门牌信息否则阿姨上门找不到人。在技术群看到有些源码地址选点只是个摆设选了之后没有存经纬度导致后面派单完全失效。这个一定要核对清楚。在业务层经纬度还有一个场景计算用户与阿姨的距离用于向用户展示“阿姨距离您约3.5公里”以及用于运营做服务区域的电子围栏。若实现电子围栏可以预先在后台配置服务范围中心点和半径下单前小程序先判断用户经纬度是否在服务范围内不在则提示“当前地址暂未开通服务”。这个功能看起来小对砍掉大量无效订单帮助很大。3.4 下单、支付与回调的完整流程用户选择好服务、阿姨、时间、地址后点击“提交订单”进入支付流程。家政小程序最常见的支付方式是微信支付。完整流程为前端把订单信息服务项目、阿姨、时间、地址、金额等提交给后端。后端创建一条待支付订单并生成唯一订单号。后端调用微信支付“统一下单”接口传入金额、回调地址等参数拿到支付参数返回给前端。前端用wx.requestPayment拉起微信支付收银台。用户输入密码支付成功后微信服务器回调后端设置的回调地址后端在回调里校验签名和金额把订单状态更新为“待接单”。前端在wx.requestPayment的success回调里再向后端查询一次订单状态刷新页面。这里有两个高频坑。第一是金额单位微信支付接口里金额的单位是分如果你后端的价格单位是元一定要乘100再传否则就会出现“用户付了1分钱”的线上事故。第二是回调幂等性微信支付回调可能因为网络问题重复推送后端处理回调时必须先判断订单当前状态如果已经是“待接单”就不要再重复更新和推送通知否则用户会收到多条服务通知。家政行业还有一个业务细节定金模式。很多平台允许用户先付20%定金锁定阿姨时间剩余费用服务完成后线下结算或线上补付。如果你想做这个功能支付流程要增加一个“定金支付”和“尾款支付”两段逻辑订单状态机也会多出“待付尾款”的中间状态。这部分源码里如果是单次全额支付模式后续加定金功能时要仔细梳理状态流转别硬塞导致状态混乱。3.5 阿姨端接单与状态流转实现阿姨端通常是一个独立的小程序或同一小程序的不同角色入口。用户支付成功后后端要为阿姨生成一条“新订单待处理”的通知实现方式有两种轮询阿姨端小程序每隔几秒请求一次后端接口查询是否有新订单。实现最简单但浪费资源和流量。订阅消息小程序通过wx.requestSubscribeMessage申请订阅消息权限后端在订单生成后通过微信服务端接口给阿姨推送“新订单待处理”通知。用户侧也可以使用这个能力在下单成功后订阅“服务进度提醒”。阿姨点击“接单”后预约单状态从“待接单”变为“已接单”同时后端要把阿姨的ID写入订单并锁定该阿姨在对应时间段的排班避免重复接单。很多人忽略“排班锁定”这一步导致阿姨同一个上午接了三个单线下炸锅。上门服务过程中阿姨端的操作流一般是点击“导航上门”唤起地图导航 - 到达后点击“签到” - 开始打扫后点击“开始服务” - 完成后拍照上传并点击“完工”。每一步操作都在appointment_log表里留痕方便运营端后续处理纠纷。完工后用户端会收到提醒可以确认完成、联系客服或发起投诉。只有用户确认完成后订单金额才会进入可结算状态阿姨对应的账户余额增加运营端财务可以按周或按月给阿姨打款。4. 常见问题与排查技巧实录4.1 真机预览白屏与小程序不同端适配很多人在拿到源码后第一步就卡在“小程序跑不起来”。尤其是uni-app项目开发工具里预览正常手机一扫码就白屏。我排查过很多次常见原因有三类。第一基础库版本不一致。老源码可能基于某个旧版本的基础库开发新手机微信基础库版本过高部分废弃API调用直接抛异常导致白屏。解决办法是在app.json里显式指定libVersion或者升级源码中废弃的API调用。第二自定义导航栏高度适配。很多源码会关闭默认导航栏navigationStyle: custom自己画一个头部。但安卓和iOS的状态栏高度不一致源码里如果直接写死一个高度值在部分机型上就会出现头部内容被刘海遮挡或整体布局异常。正确做法是用wx.getSystemInfoSync()拿到statusBarHeight再动态加上导航栏自身高度。这里的“微信小程序顶部导航栏高度”是微信小程序社区里搜索量很高的词因为几乎每个自定义导航栏的项目都会遇到。第三域名白名单问题。真机上所有请求都要走HTTPS而且域名必须在小程序后台配置到request合法域名里。如果你用的是IP地址或未备案域名真机上所有请求都会被拦截前端没有数据渲染看起来就是白屏。调试阶段要开启“不校验合法域名”上线前务必换成正式域名。4.2 接口联调与抓包排查思路小程序接口联调我一般按三个步骤来。第一步先在微信开发者工具里开启“不校验合法域名”模式直接请求本地或测试环境接口看返回数据是否符合预期。第二步如果真机上出问题用开发者工具的“真机调试”功能同时打开vConsole查看前端日志。第三步如果涉及支付回调、第三方回调等复杂链路联调再用抓包工具看完整请求和响应。说到抓包有人会问“怎么抓小程序的包”——在命令行里输入抓包命令、用Fiddler或Charles设置代理抓HTTPS流量、用Reqable在手机上抓包。必须提醒大家抓包调试只能用于自己开发或已获授权测试的应用不要拿这个技术去调用或分析未授权的第三方接口尊重他人服务条款和数据安全。联调时还有一个高频问题后端返回的JSON字段命名不统一有的接口返回userId有的返回user_id前端取值时经常取到undefined。这个纯粹是团队协作规范问题建议后端统一输出驼峰命名或者在前端封装一层字段映射工具函数统一处理数据格式。4.3 类目审核与上线资质家政预约小程序上线前在小程序后台设置服务类目时要选择“生活服务 家政服务”类目。这个类目在微信官方规定里一般需要提供营业执照经营范围包含家政服务、清洁服务等个体户执照也可以。部分类目还需要额外资质比如涉及“保洁清洗”服务可能还需要提供相关的服务质量承诺或行业资质文件具体以最新版小程序类目资质要求为准。审核最容易踩的坑是“功能与类目不匹配”。比如你选择了“家政服务”类目但小程序里明显有视频播放功能审核就会驳回要求补充“文娱-其他视频类目”或移除相关功能。类似地涉及付费内容要确认是否开通微信支付涉及用户上传图片要提前准备好《用户隐私保护指引》并声明采集的信息用途。另外提一句小程序名称也很重要。你起名叫“XX家政保洁”但小程序里没有任何家政服务内容审核会被拒。名称最好和实际服务高度一致。个人主体的小程序如果做不了企业认证很多接口也用不了这类源码建议找企业资质的主体来注册和上线。4.4 家政预约小程序常见问题速查表问题现象可能原因排查思路与解决建议真机请求接口报“url not in domain list”小程序后台未配置合法域名登录微信公众平台在“开发管理-服务器域名”中配置request合法域名或调试期勾选不校验合法域名支付时提示“商户号未开通”或“调用支付JSAPI缺少参数”微信支付商户号未关联小程序或参数传错检查商户号是否已与AppID绑定核对timeStamp、nonceStr、package、signType等参数拼写和数据格式用户能下单但阿姨看不到新订单阿姨端轮询/订阅消息链路出问题先查后端日志有没有推送记录再确认阿姨端是否申请了订阅消息权限最后检查订单状态是否停在“待接单”订单重复推送/重复回调回调处理未做幂等后端回调入口先按订单号查状态已处理过直接返回成功不重复执行业务逻辑地图选点后位置偏移坐标系不一致小程序和数据库里的经纬度用了不同地理坐标系统一使用GCJ-02火星坐标系避免直接用GPS原始坐标自定义头部在部分机型位置错位导航栏高度写死用wx.getMenuButtonBoundingClientRect()和statusBarHeight动态计算胶囊按钮与导航栏高度uni-app编译到其他端报地图组件错误各端地图组件API差异使用条件编译分别处理微信、支付宝等端的地图逻辑不要共用同一个文件阿姨端开始服务后用户端状态没变前后端状态同步依赖轮询周期用户端页面在onShow生命周期主动刷新订单详情服务中页面可加定时器每30秒刷新一次5. 从源码到产品家政小程序的扩展思考把源码跑通、上线只是第一步。真正运营起来你会发现家政服务的核心矛盾不是“有没有客户下单”而是“阿姨的时间怎么分配最合理”“如何让用户下一次还选你”。技术上可以做的扩展方向有几个。第一是多商户入驻。平台发展到一定规模后单个运营方自己管理阿姨会成为瓶颈可以扩展成服务商/商户模式每个商户有自己的阿姨团队和财务账户。这个扩展对数据结构的影响比较大阿姨表、订单表、结算表都要增加商户维度字段。第二是智能派单。现在的源码大部分是“用户选阿姨”但平台视角更希望系统按距离、评分、接单偏好为阿姨自动派单这里面会用到简单的贪心算法或排队策略。第三是会员和优惠券体系。家政是典型的高频低客单服务用户留存靠复购。增加次卡、充值、优惠券功能可以有效拉升复购率这部分在源码层面其实就是增删订单金额计算的逻辑。从我个人这几年看各种小程序源码的经验来说家政预约小程序这类源码最容易出问题的不是“有没有功能”而是“功能之间割裂”。很多源码把登录、下单、支付、地图、接单每一块都做出来了但串起来跑一遍就露馅——支付成功了订单状态没变、用户下单后阿姨端根本收不到任何通知、取消订单后阿姨的排班没有释放。所以拿到任何一份源码第一件事不是急着改UI而是先把整个订单生命周期完整跑一遍每一步的状态流转都验证过再开始叠加业务功能。另外给大家一个小技巧代码里一定要看预约单流水号的生成规则。我见过太多源码直接用数据库自增ID当订单号这在生产环境里相当于把业务量完全暴露给竞争对手而且不利于后续对账。建议生成规则用日期前缀随机数日期(YYYYMMDD) 4位随机数 时间戳后4位这样订单号可读性强同样一秒钟生成多个订单也不会重复也符合微信支付的订单号规则。如果你准备基于这份源码做二次开发我建议先集中火力把“预约单状态机”和“阿姨排班冲突检测”这两个核心逻辑吃透。家政预约的所有业务难点、运营纠纷几乎都集中在这两处。状态机清晰了退款、改约、投诉这些衍生功能都是锦上添花排班不冲突阿姨和用户的服务体验就稳住了大半。把这栋楼的地基打好上面盖什么样的功能都不会歪。本文还有配套的精品资源点击获取