家政派单小程序系统开发实战：从需求分析到上线指南
一、需求分析：明确三类角色与核心业务边界
在动手编码之前，需要先厘清系统的业务边界。家政派单平台至少有三种角色：发布需求的C端用户、接单服务的师傅或商家、以及平台运营方。三者对系统的诉求完全不同，需求分析阶段需要分别建模。
师傅端与商家端核心诉求：接收订单、抢单或派单、管理日程、记录服务状态。系统需要提供独立的师傅工作台或商家工作台（知识库中普遍提到的“独立用户端、商家端和师傅端”即指此）。在此基础上，部分平台还支持师傅入驻、员工管理、员工订单分配等功能，意味着角色权限体系需要支持多层级的组织关系：平台-商户-师傅。
管理后台核心诉求：全局订单监管、服务类目管理、佣金与分销配置、优惠券策略、消息推送。此外，管理端还需要具备对“抢单/派单”模式的规则配置能力，例如哪些服务支持抢单，哪些区域仅允许指定师傅接单。
关键需求决策点：
- 是否需要多商户入驻？如果需要，则需设计商户独立后台，并考虑分账逻辑。
- 是否需要分销推广？需要设计多级分佣关系以及提现审核流程。
- 是否支持视频或图片工单？这会影响云存储与CDN成本的评估。
二、系统架构设计：主流技术栈与工程结构规划
根据开源项目的常见技术选型与社区实践，推荐采用前后端分离架构。后端基础框架建议使用 Spring Boot 3.x + MyBatis Plus + MySQL 8.x；用户端与师傅端采用UniApp（Vue 3语法）实现跨端编译（小程序+H5+App）；管理后台采用Vue 3 + Element Plus。
后端工程结构建议拆分为多模块：
parent-project ├── gateway-module // 网关，统一认证与限流 ├── system-module // 用户、角色、权限、菜单 ├── worker-module // 师傅入驻、技能标签、日程 ├── marketing-module // 优惠券、分销、活动 ├── message-module // IM聊天、站内信、短信通知 └── common-module // 公共工具类、常量定义数据库建模需重点关注三张核心表：
工单表（work_order）：是整个派单系统的核心数据结构。除了常规的订单号、状态、金额字段外，必须包含期望上门时间区间（expect_start_time, expect_end_time）、服务地址坐标（经纬度 GEO 字段）、平台派单类型（manual/auto/rob），以便支撑后续派单与抢单逻辑。
派单轨迹表（dispatch_log）：记录每一次派单调度行为。包括：派单类型、候选师傅ID列表、终锁定的师傅ID、师傅反馈时间以及用户的取消时间。此表用于后续分析派单成功率与师傅响应的性能优化。
三、核心业务模块实现要点：派单、抢单与多端消息推送
3.1 派单策略引擎的落地
派单不能简单粗暴地做成“全量广播”，否则会造成差评师傅频繁抢单。建议设计两层筛选逻辑：基础过滤与智能排序。
基础过滤层通过 SQL 或内存过滤掉不满足条件的师傅：
- 距离用户定位是否在服务半径内（利用 MySQL 的 ST_Distance_Sphere 函数计算球面距离）；
- 师傅服务类目是否匹配（例如“空调维修”师傅不允许接“保洁”单）；
- 师傅当前日程是否存在时间冲突（需要查询该时间区间是否已有订单）。
- 师傅的服务评分是否低于阈值（例如低于4.5分的不允许进入自动派单池）。
智能排序层可以使用一个简单的评分表达式进行估算：score = w1 * 响应速度 + w2 * 距离 + w3 * 历史好评率 - w4 * 当前待处理单量。注意权重因子需要做成可配置项，避免调代码才能调整系统偏好。
3.2 抢单并发控制
抢单功能的高并发处理是一个容易踩坑的点。用户发布订单后，若通知 20 个师傅，那么这 20 个师傅可能在同一秒内点击“抢单”按钮。如果不加以控制，会导致一张订单被多个师傅抢到。
这里推荐采用Redis 分布式锁。锁的 Key 可以使用ORDER_LOCK:{orderId}，Value 使用“师傅ID + 时间戳”的组合，并设置一个失效时间（例如5秒）。当订单状态已被更新完成后，后续的获取锁请求必须直接丢弃。代码实现上可以利用 Redisson 的tryLock方法，或者使用SET NX EX命令进行原子操作。
3.3 即时通讯与消息推送
如果在系统内嵌入聊天功能，不要从零开始造轮子，建议直接集成现有的云厂商 IM SDK（即时通信），可以帮助团队节省至少数周的开发时间。消息推送方面（比如“新订单来了”的语音提示音），可以使用极光推送或个推，但一定要做好别名（alias）与标签绑定。师傅端登录后，后台需要将account_{workerId}绑定到设备 token，这样服务端向指定师傅推送时才能准确触达。
3.4 地图与路径规划
对于上门服务，结算距离和师傅位置的实时轨迹并不是简单的“红线”。如果业务要求展示师傅实时轨迹，需要注意避免高频上报坐标导致流量消耗过大，前端建议每5-10秒上报一个坐标即可，后端通过定时任务进行坐标纠偏与轨迹渲染。
四、多端部署与上线前检查：从开发环境到生产环境的完整流程
4.1 环境准备
开发环境建议采用 Docker Compose 搭建 MySQL、Redis、RabbitMQ（用于异步任务解耦，例如取消订单后的短信通知）。生产环境部署，建议使用集群方式（至少2台应用服务器）并使用 Nginx 做反向代理。静态资源（如用户头像、工单图片）需要存放在对象存储中，并使用 CDN 加速。
4.2 前后端联调与跨域问题
使用 UniApp 开发的小程序与 H5，在请求后端接口时会存在跨域问题。生产环境中必须配置 HTTPS 域名，并在网关层统一处理 CORS 跨域请求。需要注意的是，小程序中不校验 CORS，但需要将服务器域名配置在小程序后台，否则请求会直接拦截报错。
4.3 上线前功能检查清单
- 权限灰度测试：管理员角色无法看到师傅端的抢单页面，师傅端账号无法进入商户后台的员工管理页面。
- 金额精度验证：关于优惠券、分销佣金、退款金额的计算，需要使用
BigDecimal而非double，并且在测试环境中随机组合多组优惠券场景进行模拟计算。 - 高并发基线压测：只对一个核心接口（例如“用户确认下单”接口）进行超卖压测，在单台4核8G的服务器上，预估QPS（每秒查询数）至少要达到200以上，否则需要检查慢SQL。
- 日志监控：使用AOP（面向切面编程）方式打印所有Controller的入参、出参及耗时。一旦出现用户投诉，可以快速定位是接口报错还是前端渲染问题，排查效率更高。
- 消息重试机制：如果师傅没有点击“接单”，系统需要每隔1分钟自动推送一次“催单提醒”，多推送3次。此时需要利用消息队列的延迟队列能力，避免使用定时任务轮询数据库造成浪费。
五、FAQ：家政派单小程序系统常见问题解答
1. 家政派单小程序系统必须包含哪些端？
通常至少包含用户端（小程序）、师傅端（小程序）、管理后台（Web）。如果业务涉及多商户入驻，还需要增加独立的商家管理端。多端之间必须共享同一套后端API服务，业务逻辑保持一致。
2. 派单和抢单模式能否同时存在？
可以。根据知识库中的资料与行业通用做法，系统必须支持“手动派单”（管理员指定师傅）、“自动派单”（系统根据距离和评分分配）与“抢单”（师傅主动操作）。这三种模式在数据库中只需使用一个dispatch_type字段进行标识，但在业务流程上，建议不同模式对应不同的订单状态流转。
3. 技术栈选择有哪些搭配建议？
目前主流的落地组合方案为：Spring Boot + MyBatis Plus + MySQL 提供API服务，UniApp（Vue 3）负责小程序、App和H5的开发，Vue 3 + Element Plus构建管理后台。该组合的生态成熟，招聘研发人员相对容易，且对于后续维护与二次开发较为友好。
4. 如何保障回调通知（如支付回调）不丢单？
支付回调的处理必须遵循“接口幂等性”原则。回调接口内，先根据商户订单号查询本地订单状态，如果已经是“已支付”状态，则直接返回成功，不再重复修改余额或积分。同时，支付回调的日志需要单独保存，便于追踪链路。
5. 开发周期大概需要多久？
一个标准家政派单项目（包含用户端、师傅端、管理后台）在团队经历1-2个项目磨合后，通常需要2-3个月完成集中开发与测试。但这不包含反复的需求变更与UI调整时间。建议开发排期预留20%的缓冲时间用于应对上线前的Bug修复与体验打磨。
