家政上门预约小程序源码实战：订单状态机、排班冲突与支付分账

简介这份家政上门预约服务小程序源码面向希望快速搭建本地化家政预约平台的开发者与创业者可帮助解决从服务展示、师傅调度到订单确认的完整业务闭环问题。源码支持多城市定位提醒、服务下单、次卡购买与管理员发单等多种下单方式并内置抢单与派单机制后台可设定距离范围师傅仅能抢范围内订单管理员派单页面按师傅与客户距离排序并显示电话便于提前沟通。营销层面提供分销促销、会员折扣、积分兑换与子卡功能后台功能较为完整。资源包共1779个文件以js、php、html、json、wxss、wxml等前后端与小程序页面文件为主另含gif、png、jpg等图片素材及css、less、scss样式文件压缩包约16.7MB目录结构清晰。目前已有4378人学习下载适合具备一定小程序与PHP基础的开发者参考二次开发快速理解家政预约类项目的模块划分与调度逻辑。1. 家政上门预约服务小程序源码从一套能跑通的代码说起家政上门预约服务小程序源码解决的是把“找阿姨、约时间、付定金、上门服务、评价结算”这条链路塞进微信生态里的问题。我见过太多团队拿着一个演示版小程序就敢接单结果卡在派单冲突、服务时段重叠、退款对账上。这套源码的核心价值不是界面多漂亮而是订单状态机、阿姨排班表、支付分账这三块能不能扛住真实业务。适合谁想快速验证家政 O2O 模式的小团队、需要二次开发接私活的开发者、以及想拿一套可运行代码学习小程序全栈的工程师。热搜里“源码”这个词被滥用了但真正能跑通支付和排班的家政源码市面上并不多。2. 家政预约小程序源码的技术选型与订单状态机设计2.1 为什么用微信小程序原生加云开发而不是 uni-app家政预约场景对微信生态依赖极深微信支付、订阅消息、手机号快速验证、位置权限这些用原生小程序加云开发是最短路径。uni-app 跨端听起来美好但家政用户 95% 在微信里多端适配反而增加调试成本。我一般会选原生小程序 云函数 云数据库理由有三第一云开发免鉴权直接拿 openid省掉登录态维护第二云函数定时触发器可以做超时未支付自动取消第三云数据库的 watch 能力让阿姨端和用户端订单状态实时同步不用自己搭 WebSocket。源码目录结构通常长这样miniprogram/ pages/ index/ 用户端首页 order/ 下单页 orderList/ 订单列表 aunt/ 阿姨端接单 components/ timePicker/ 时段选择器 utils/ request.js 云函数调用封装 cloudfunctions/ createOrder/ 创建订单 payCallback/ 支付回调 dispatch/ 派单逻辑 cancelOrder/ 取消订单2.2 订单状态机家政源码里最容易写崩的地方家政订单不是简单的“待支付→已支付→已完成”。真实状态至少有待支付、已支付待派单、已派单待接单、阿姨已接单、服务中、待确认完成、已完成、已取消、退款中、已退款。状态流转必须用云函数集中管理不能在前端随便改。// cloudfunctions/updateOrderStatus/index.js const cloud require(wx-server-sdk) cloud.init() const db cloud.database() // 合法状态流转表防止前端乱传状态 const VALID_TRANSITIONS { PENDING_PAY: [PAID, CANCELLED], PAID: [DISPATCHED, REFUNDING], DISPATCHED: [ACCEPTED, PAID], // 阿姨拒单退回 ACCEPTED: [IN_SERVICE, CANCELLED], IN_SERVICE: [PENDING_CONFIRM], PENDING_CONFIRM: [COMPLETED, REFUNDING], REFUNDING: [REFUNDED] } exports.main async (event) { const { orderId, targetStatus, operator } event const order await db.collection(orders).doc(orderId).get() const current order.data.status // 校验流转合法性 if (!VALID_TRANSITIONS[current] || !VALID_TRANSITIONS[current].includes(targetStatus)) { return { code: 400, msg: 非法状态流转: ${current} - ${targetStatus} } } // 权限校验只有阿姨能接单只有用户能确认完成 if (targetStatus ACCEPTED operator.role ! aunt) { return { code: 403, msg: 只有阿姨可以接单 } } await db.collection(orders).doc(orderId).update({ data: { status: targetStatus, updateTime: db.serverDate(), [timeline.${targetStatus}]: db.serverDate() } }) return { code: 0 } }这段代码的关键在VALID_TRANSITIONS表它把业务规则固化在服务端。参数说明orderId是订单唯一标识targetStatus是目标状态operator包含操作者角色。失败时先看云函数日志里的“非法状态流转”报错八成是前端按钮没做状态判断。很多家政源码翻车就翻在这里——用户还没付款阿姨端就显示可接单最后两边扯皮。2.3 阿姨排班表与时段冲突检测家政预约最核心的约束是同一个阿姨同一时段不能接两单。源码里通常用一张schedules集合存阿姨的可服务时段下单时先查冲突。// cloudfunctions/checkConflict/index.js const db cloud.database() const _ db.command exports.main async (event) { const { auntId, serviceDate, startTime, endTime } event // 查询该阿姨当天已有订单时间区间重叠即冲突 const conflict await db.collection(orders) .where({ auntId, serviceDate, status: _.in([DISPATCHED, ACCEPTED, IN_SERVICE]), startTime: _.lt(endTime), // 已有订单开始 新订单结束 endTime: _.gt(startTime) // 已有订单结束 新订单开始 }) .count() return { hasConflict: conflict.total 0 } }参数说明serviceDate用YYYY-MM-DD字符串存避免时区问题startTime和endTime用HH:mm格式。冲突检测的经典错误是只比较开始时间相等漏掉区间重叠。正确逻辑是“已有开始 新结束 且 已有结束 新开始”。如果查出来冲突但业务上允许阿姨赶场那就在源码里加一个bufferMinutes缓冲时间把endTime加上 30 分钟再比较。3. 从零跑通家政小程序源码环境、云函数与支付配置3.1 本地环境搭建与源码导入的四个步骤拿到一套家政上门预约服务小程序源码后别急着点编译。先确认三件事小程序 AppID 是否已开通云开发、微信支付商户号是否绑定、订阅消息模板是否申请。我一般按这个顺序操作第一步用微信开发者工具导入源码根目录工具会自动识别project.config.json。如果报“未找到 app.json”说明导入的是外层文件夹要选到miniprogram同级目录。第二步在app.js里替换云环境 ID// miniprogram/app.js App({ onLaunch() { wx.cloud.init({ env: your-env-id, // 替换成自己的云环境ID traceUser: true }) } })第三步右键cloudfunctions下每个云函数选择“上传并部署云端安装依赖”。注意payCallback依赖wx-server-sdk和tenpay如果云端安装失败检查云函数目录下是否有package.json。第四步在云开发控制台创建集合orders、aunts、users、schedules、transactions。权限设置为“仅创建者可读写”的集合是users其余设为“所有用户可读仅管理端可写”。3.2 微信支付配置家政源码里最容易卡住的环节家政订单通常收定金或全款源码里支付逻辑走的是云函数调用统一下单。配置支付需要商户号、APIv3 密钥、证书序列号、私钥文件。这些在cloudfunctions/payCallback/config.js里填。// cloudfunctions/payCallback/config.js module.exports { mchId: 1900000000, // 商户号 apiV3Key: your-api-v3-key, // APIv3密钥32位 serialNo: your-serial-no, // 证书序列号 privateKey: -----BEGIN PRIVATE KEY----- ...你的私钥内容... -----END PRIVATE KEY-----, notifyUrl: https://your-domain.com/pay/notify // 支付回调地址 }参数说明apiV3Key不是 API 密钥是 APIv3 密钥在商户平台“账户中心-API安全”里设置。serialNo是商户证书序列号不是平台证书序列号。回调地址必须 HTTPS 且不能带端口。支付回调云函数里要验签源码里一般用wxpay-jsapi或tenpay库。如果支付成功但订单没变状态先看回调日志有没有“验签失败”八成是apiV3Key填错。3.3 派单逻辑手动派单与自动派单的取舍家政源码里派单有两种手动派单是运营在后台选阿姨自动派单是按距离和评分排序。我建议初期用手动派单因为自动派单的权重调参是个玄学。源码里dispatch云函数通常长这样// cloudfunctions/dispatch/index.js const db cloud.database() const _ db.command exports.main async (event) { const { orderId, mode } event const order await db.collection(orders).doc(orderId).get() const { serviceDate, startTime, endTime, location } order.data if (mode auto) { // 查该时段空闲阿姨按距离排序 const aunts await db.collection(aunts) .where({ status: ACTIVE, serviceArea: _.geoNear({ geometry: location, maxDistance: 5000 })}) .get() // 过滤掉时段冲突的 const available [] for (const aunt of aunts.data) { const conflict await db.collection(orders).where({ auntId: aunt._id, serviceDate, status: _.in([DISPATCHED, ACCEPTED, IN_SERVICE]), startTime: _.lt(endTime), endTime: _.gt(startTime) }).count() if (conflict.total 0) available.push(aunt) } if (available.length 0) { return { code: 404, msg: 该时段无可用阿姨 } } // 取评分最高的 available.sort((a, b) b.rating - a.rating) await db.collection(orders).doc(orderId).update({ data: { auntId: available[0]._id, status: DISPATCHED } }) return { code: 0, auntId: available[0]._id } } }参数说明mode为auto时走自动派单location是 GeoPoint 类型。maxDistance单位是米。注意geoNear要求集合有地理位置索引在云开发控制台给aunts集合的serviceArea字段建索引。自动派单的坑在于评分最高的阿姨可能同时被多个订单选中所以派单后要立即更新状态或者用事务锁。4. 家政预约源码避坑订单、支付与排班的五个血泪教训4.1 坑一用户重复提交订单导致阿姨被重复预约现象用户网络卡顿连点两次提交生成两笔相同订单阿姨端看到两个待接单。原因前端按钮没做防抖云函数也没做幂等。解决在createOrder云函数里用openid serviceDate startTime做唯一键插入前先查重。const exist await db.collection(orders).where({ openid, serviceDate, startTime, status: _.neq(CANCELLED) }).count() if (exist.total 0) return { code: 409, msg: 请勿重复下单 }4.2 坑二支付回调没验签导致订单状态被伪造现象有人直接调回调接口把订单改成已支付。原因回调云函数没验签或验签逻辑写错。解决用微信支付官方 SDK 验签验签失败直接返回 500并且回调处理要加transaction_id去重。4.3 坑三阿姨端和用户端状态不同步现象用户已取消阿姨端还显示待接单。原因取消订单只改了orders集合没触发阿姨端刷新。解决用云数据库watch监听订单变化或者取消时往notifications集合写一条消息阿姨端轮询。4.4 坑四服务时段跨天导致冲突检测失效现象阿姨晚上 23:00 到次日 1:00 的服务和次日 0:00 到 2:00 的服务被判定不冲突。原因serviceDate只存了开始日期跨天时段没处理。解决把startTime和endTime存成完整时间戳或者跨天订单拆成两条记录。4.5 坑五退款金额算错平台贴钱现象用户用了优惠券退款时按原价退平台多退钱。原因退款逻辑没扣优惠分摊。解决在transactions集合里记录每笔订单的实付金额和优惠金额退款按实付退。5. 家政小程序源码的二次开发把派单算法换成自己的源码跑通后真正拉开差距的是派单算法。默认的“距离评分”太粗糙我一般会加三个因子阿姨接单率、用户偏好、时段利用率。接单率低的阿姨降权用户收藏过的阿姨加权时段利用率高的阿姨优先派近单。// 自定义派单评分 function scoreAunt(aunt, order) { const distanceScore 1 - Math.min(aunt.distance / 5000, 1) // 距离越近越高 const ratingScore aunt.rating / 5 const acceptRateScore aunt.acceptRate || 0.5 const preferenceScore order.userFavAunts?.includes(aunt._id) ? 1 : 0 return distanceScore * 0.3 ratingScore * 0.25 acceptRateScore * 0.25 preferenceScore * 0.2 }权重怎么调先跑一周日志看每个因子的方差方差大的因子说明区分度高权重可以加大。验证方法是 A/B 测试一半订单用默认算法一半用新算法对比接单率和完成率。我踩过的坑是权重调得太激进导致新阿姨永远接不到单最后在评分里加了一个“新阿姨保护期”加权。另一个进阶技巧是给源码加“预约提醒”服务前 2 小时给阿姨和用户各发一条订阅消息。订阅消息模板要提前在小程序后台申请云函数里用cloud.openapi.subscribeMessage.send发送。注意一次性订阅只能发一条长期订阅需要用户每次授权。最后说个习惯每次改完派单逻辑我都会用云开发控制台的“数据库回滚”功能先备份orders集合。家政订单数据丢了用户和阿姨两边都找你那可不是写个后悔药能解决的。希望帮到你。本文还有配套的精品资源点击获取