上门保洁小程序开发实战指南

为什么上门保洁值得做成小程序

家政保洁是典型的高频刚需 + 本地化服务场景。用户下单前关心的是：附近有没有阿姨、什么时候能来、多少钱、干不干净。传统电话预约和微信群接单效率极低，而小程序天然适合解决这三个问题：

• 微信内直接下单，无需下载 App，获客成本低
• 可获取用户地理位置，快速匹配附近保洁员
• 支持微信支付、订阅消息，形成完整闭环

下面我从技术选型、核心功能、数据库设计到派单逻辑，完整讲一遍我的开发思路。

技术选型与整体架构

个人开发者做这类项目，我建议用微信小程序原生 + 云开发，能省掉服务器运维成本。如果业务量增长，再迁移到自建后端。

• 前端：微信小程序原生（WXML + WXSS + JS）
• 后端：微信云开发（云函数 + 云数据库 + 云存储）
• 支付：微信支付 JSAPI（云开发有云支付能力）
• 地图：腾讯位置服务，用于距离计算与地址解析

核心功能模块拆解

1. 用户端：预约下单

下单流程要尽量短：选服务类型 → 选时间 → 填地址 → 支付。地址可以调起微信地址簿，减少输入成本。

// 获取用户微信地址
wx.chooseAddress({
  success(res) {
    const { userName, telNumber, provinceName, cityName, countyName, detailInfo } = res;
    const fullAddress = provinceName + cityName + countyName + detailInfo;
    this.setData({ address: fullAddress, contact: userName, phone: telNumber });
  }
});

2. 保洁员端：接单与打卡

保洁员端可以用同一个小程序，通过角色字段区分入口。核心是接单列表和到店打卡。打卡时记录经纬度，判断是否在服务地址附近，防止虚假打卡。

// 打卡时校验距离
const distance = getDistance(lat1, lng1, lat2, lng2);
if (distance > 500) {
  return { ok: false, msg: '距离服务地址过远，无法打卡' };
}

3. 管理端：派单与结算

管理端可以做成小程序页面，也可以做成简单的 Web 后台。初期建议用云开发控制台直接操作数据库，等订单量上来再开发管理端。

数据库设计要点

云开发使用文档型数据库，集合设计如下：

• users：用户表，含 openid、角色（user/staff/admin）、手机号
• orders：订单表，含服务类型、时间、地址、金额、状态、接单 staffId
• services：服务项目表，含名称、价格、时长、封面图
• staff：保洁员表，含姓名、服务范围、评分、当前状态

订单状态建议用数字枚举：0 待支付、1 待接单、2 已接单、3 服务中、4 已完成、5 已取消。状态流转要严格校验，避免越权修改。

派单逻辑：从抢单到智能派单

初期订单少，用抢单模式最简单：订单进入待接单池，保洁员端轮询或订阅消息通知，谁先接谁做。

订单多了以后要升级为智能派单，核心是给每个候选保洁员打分：

// 派单评分：距离越近、评分越高、当前单越少，得分越高
function scoreStaff(staff, order) {
  const distScore = 1 / (getDistance(staff.loc, order.loc) + 1);
  const ratingScore = staff.rating / 5;
  const loadScore = 1 / (staff.activeOrders + 1);
  return distScore * 0.5 + ratingScore * 0.3 + loadScore * 0.2;
}

按得分从高到低推送，设置 30 秒响应超时，超时自动转给下一位。

几个容易踩的坑

• 订阅消息限制：微信一次性订阅只能发一条，重要通知（接单、服务开始）要提前让用户授权
• 地理位置精度：小程序获取的经纬度有偏移，展示地址建议用腾讯地图逆地址解析
• 支付回调幂等：云函数支付回调可能重复触发，务必用订单号做幂等校验
• 退款流程：取消订单要区分「未接单可全额退」和「已接单需协商」，规则写死在云函数里

小结

上门保洁小程序的技术难点不在页面，而在订单状态机、派单算法和支付闭环。先用云开发快速跑通 MVP，验证有真实订单后再投入精力做智能派单和管理后台。个人开发者完全可以在两周内做出可用的第一版。