维修小程序开发：从零搭建核心功能

做维修类小程序，核心不是把页面画得多漂亮，而是把「报修—派单—上门—结算—评价」这条链路跑通。本文按实施步骤拆解一套可落地的维修小程序开发方案，适合个人开发者或小团队快速起步。

一、先定角色与数据模型

维修业务至少有三类角色：用户、维修师傅、平台管理员。开发前先把数据表定清楚，后面写接口会顺很多。

• 用户表：openid、手机号、默认地址
• 师傅表：openid、技能标签、接单状态、评分
• 订单表：订单号、故障描述、图片、地址、状态、金额
• 服务分类表：家电维修、水电、开锁、管道等

订单状态建议用有限状态机管理：待接单 → 已接单 → 上门中 → 服务中 → 待支付 → 已完成 → 已评价，再加一个 已取消。状态流转必须由后端校验，不能只靠前端按钮控制。

二、核心功能模块拆解

1. 报修下单

用户填写故障描述、上传图片、选择地址和时间，提交后生成订单。图片建议直传云存储，数据库只存 fileID，避免接口体积过大。

// 下单接口伪代码
async function createOrder(ctx) {
  const { desc, images, address, categoryId } = ctx.data;
  if (!desc || !address) throw new Error('参数不完整');
  const order = await db.collection('orders').add({
    data: {
      desc, images, address, categoryId,
      status: 'pending',
      userId: ctx.openid,
      createdAt: Date.now()
    }
  });
  return { orderId: order._id };
}

2. 智能派单

派单有两种模式：抢单大厅和定向派单。小平台先用抢单模式，成本最低；订单量大后再加规则派单。

• 抢单：所有在线师傅可见，先到先得
• 定向：按技能标签 + 距离 + 评分筛选 3 公里内的师傅
• 兜底：超时未接单自动推送给管理员手动指派

3. 实时进度与消息通知

用户最关心「师傅到哪了」。可用微信订阅消息推送状态变更，师傅端上报位置后，用户端轮询或使用 WebSocket 展示。

// 订阅消息推送示例
await cloud.openapi.subscribeMessage.send({
  touser: userOpenid,
  templateId: 'ORDER_STATUS_TPL',
  page: 'pages/order/detail?id=' + orderId,
  data: {
    thing1: { value: '师傅已接单' },
    time2: { value: formatTime(new Date()) }
  }
});

4. 结算与评价

维修价格常是「上门费 + 材料费」，建议支持师傅填写报价单，用户确认后再支付。支付走微信支付 JSAPI，回调里更新订单状态。评价维度包括：准时、态度、专业度，评分写入师傅表用于后续派单权重。

三、实施步骤与排期建议

1. 第 1 周：确定需求边界，画原型，建数据库表
2. 第 2 周：开发用户端下单、订单列表、详情页
3. 第 3 周：开发师傅端接单、状态上报、报价
4. 第 4 周：接入支付、订阅消息、管理后台
5. 第 5 周：联调测试，灰度上线

独立开发者可以先用微信云开发，省去服务器和鉴权成本，等日订单超过 200 单再考虑迁移到自建后端。

四、容易踩的坑

• 地址选择要用微信原生 chooseLocation，别自己写地图选点
• 师傅端和用户端建议放同一个小程序，用角色字段区分入口，减少审核成本
• 订单状态变更务必加事务，避免并发接单导致一单多派
• 图片上传要压缩，否则用户上传慢、流量成本高

维修小程序的技术难点不在前端，而在订单状态与派单逻辑的严谨性。先把状态机写对，功能自然就顺了。

按以上步骤推进，一个可用的维修小程序 MVP 大约 4 到 6 周即可上线。后续再迭代会员、优惠券、师傅等级体系，逐步把平台做厚。