家政服务数字化并不是新概念但过去几年真正的变化在于源码开始开放、技术栈开始收敛、多端协同开始标准化。一套现代家政系统不再只是“小程序挂个服务列表”而是用户端、师傅端、商家/运营后台、开放 API 四端共用同一套业务内核覆盖「浏览 → 预约 → 派单 →接单 → 服务 → 核销 → 支付 → 评价」的完整闭环。源码:j.yunzes.top/er本文以“全端家政源代码开源”为题从架构设计、目录规范、核心模块、派单引擎、接口契约、部署运维、安全合规七个维度给出一份可直接用于二次开发的技术参考。文中示例兼容两类主流开源形态PHP 体系ThinkPHP Vue Admin UniApp 用户端/师傅端Java 体系Spring Boot / Spring Cloud Vue / React Admin 原生小程序一、为什么“全端 开源”是家政系统的合理形态1.1 家政业务的天然多角色性一个订单生命周期里至少涉及四方角色核心动作端形态C 端用户浏览服务、下单、支付、评价小程序 / H5 / App师傅接单、导航、上传凭证、核销师傅端 App / 小程序运营后台服务配置、派单干预、对账PC Web平台服务订单、支付、消息、调度API 服务集群单端系统做不到这件事。“全端”的本质不是页面多而是业务状态在多端之间一致性流转。1.2 开源解决了什么闭源家政 SaaS 的常见问题是派单规则黑盒无法按城市调整师傅端字段写死无法加“健康证到期提醒”支付分账不支持本地商户数据落在别人库里开源源码的价值不在“免费”而在三件事业务可审计订单状态机、退款逻辑看得见调度可改写派单权重、半径、技能标签可重排部署可私有化用户手机号、地址、家庭结构数据不出域这也是为什么目前开源社区里比较典型的家政项目基本都采用「后端 API 多端前端」分离结构。二、总体架构分层而不是“前后端分开”那么简单2.1 逻辑分层┌──────────────────────────────────────────────┐ │ 用户端小程序 / H5 │ │ 师傅端 App / UniApp │ │ 管理后台 Vue Admin │ └───────────────────┬──────────────────────────┘ │ HTTPS JWT ┌───────────────────▼──────────────────────────┐ │ API Gateway鉴权 / 限流 / 路由 │ └───────────────────┬──────────────────────────┘ │ ┌───────────────────▼──────────────────────────┐ │ 业务服务层 │ │ 用户服务 / 服务品类 / 订单服务 │ │ 派单引擎 / 核销服务 / 结算服务 │ └───────────────────┬──────────────────────────┘ ┌───────────┼────────────┐ ▼ ▼ ▼ MySQL Redis MQ 订单/用户 状态/库存 通知/异步 └───────────┬────────────┘ ▼ 对象存储 OSS 地图 API 支付 API这一层和传统“小程序 后台”的区别在于派单和订单状态机必须放在服务端前端只发指令不改状态。2.2 技术栈选型建议层轻量开源方案企业级方案后端ThinkPHP 6/8、原生 PHP PDOSpring Boot、Spring Cloud Alibaba管理端Vue3 Element PlusReact Ant Design Pro用户端UniApp小程序/H5/App 同仓微信原生 H5师傅端UniApp 或原生小程序React Native数据库MySQL 5.7MySQL ShardingSphere缓存RedisRedis Cluster消息直接调用 / Redis 队列RabbitMQ / RocketMQ部署单机 Nginx PHP-FPMDocker K8s选型原则很朴素团队会什么用什么。家政系统瓶颈不在语言性能在派单规则、地址解析、售后纠纷处理。三、开源源码目录应该怎么读以 PHP 系开源家政项目为例较合理的目录结构是这样的housekeeping/ ├── server/ # 后端 API │ ├── app/ │ │ ├── api/ # 用户端接口 │ │ ├── staff/ # 师傅端接口 │ │ ├── admin/ # 后台接口 │ │ ├── common/ # 公共服务层 │ │ └── model/ # 数据模型 │ ├── config/ │ ├── route/ │ └── public/ # 入口 ├── admin/ # Vue 管理端 │ ├── src/views/order/ │ ├── src/views/service/ │ └── src/api/ ├── user/ # UniApp 用户端 │ └── pages/ ├── staff/ # 师傅端 │ └── pages/ └── doc/ # 接口文档 / 部署文档二次开发入口只有两个controller参数校验、权限拦截、返回结构service派单逻辑、价格计算、状态流转前端改页面不难真正要小心的是绕过 service 直接写 SQL——开源项目最容易出现“页面能跑、订单会乱”的原因就在这。四、核心业务模型4.1 服务Service家政不是电商 SKU服务有“规格”。{service_id:1001,category:deep_clean,name:深度保洁,specs:[{spec_id:1,name:2小时,price:129},{spec_id:2,name:4小时,price:239}],city_ids:[1,2],skill_tags:[clean,glass]}开源系统里常见坑把价格写死在前端。正确做法是服务规格表独立订单只存spec_id快照避免后台改价导致历史订单异常。4.2 订单状态机家政订单状态建议显式建模created 待支付 paid 待接单 assigned 已派单 accepted 师傅已接 serving 服务中 finished 已核销 commented 已评价 refunding 退款中 closed 已关闭状态流转必须服务端校验// 伪代码if($order-status!paid){thrownewBusinessException(当前状态不可派单);}前端不能传statusfinished直接改库这是家政系统被刷单的高频漏洞。4.3 师傅Staffstaff ├── id, phone, real_name ├── city_id ├── lng, lat, online ├── skill_tags ├── rating ├── today_order_count └── cert_status健康证 / 身份核验派单不是“找最近的人”这么简单后面会单独讲。五、派单引擎开源后最值得改的模块5.1 派单维度成熟家政系统的派单权重通常是复合的维度说明距离GeoHash 或地图 API 算 3km 内技能订单 tag 与师傅 tag 交集时间窗师傅档期是否覆盖预约时段评分4.5 以上优先负载当日单量上限城市是否开放接单5.2 基础派单伪代码functionmatchStaff(Order$order):array{$candidatesStaff::query()-where(city_id,$order-city_id)-where(online,1)-where(cert_status,passed)-whereJsonContains(skill_tags,$order-category)-get();foreach($candidatesas$s){$s-distancegeoDistance($order-lng,$order-lat,$s-lng,$s-lat);$s-score$s-distance*0.4(5-$s-rating)*10*0.2$s-today_order_count*0.4;}return$candidates-sortBy(score)-take(5)-values();}5.3 抢单 / 自动派单双模式开源系统一般两种都要留抢单模式订单进派单池Redis ZSet师傅端轮询或 WebSocket 推自动派单按权重取第一名写入order.staff_id发短信 推送超时转派师傅 5 分钟不接 → 释放回池订单入池 → 推送师傅端 → 接单? ├─ yes → assigned └─ no (超时) → 下一候选派单失败必须有重试否则高峰时段订单会“假挂起”。六、接口契约设计6.1 统一响应{code:0,msg:success,data:{}}错误码按域分1xxx 用户2xxx 订单3xxx 派单4xxx 支付6.2 鉴权用户端微信登录拿openid→ 换token师傅端手机号 验证码 实名管理端账号密码 RBACAuthorization: Bearer jwtJWT 密钥生产环境必须改开源包默认密钥是头号风险。6.3 关键接口清单POST /api/service/list 服务列表 POST /api/order/preview 估价 POST /api/order/create 下单 POST /api/order/pay/callback 支付回调 POST /api/staff/accept 师傅接单 POST /api/order/verify 核销 GET /api/order/detail七、前端多端协同要点7.1 UniApp 用户端一套代码出小程序 H5// api.config.jsexportdefault{baseUrl:process.env.VUE_APP_API}页面结构pages/ ├── index/ 首页 DIY ├── service/ 服务详情 ├── order/ 下单 ├── my/ 个人中心 └── order-detail/7.2 师傅端差异点师傅端不是“用户端换皮”独立字段很多实时位置上报接单大厅服务前/中/后拍照核销码扫描今日收益位置上报建议节流setInterval(uploadLocation,15000)别每秒传Redis 会被打爆。7.3 管理后台后台核心不是“好看”是三块服务上下架 城市开关订单干预人工改派对账支付流水 vs 订单八、数据库设计要点避坑8.1 订单表orders-id-order_no(唯一)-user_id-staff_id nullable-service_id-spec_id-amount-status-city_id-address_json-appoint_at-created_atorder_no用雪花或日期随机别用自增 ID 暴露单量。8.2 地址与隐私用户地址不能随便联表裸查手机号脱敏地址加密存储SM4 / AES师傅端只在“已派单”后可见8.3 派单池ZSET order_pool:{city_id} score 派单优先级 value order_id定时任务扫池子超时重派。九、支付与核销9.1 支付微信支付 / 支付宝都行但逻辑必须下单写orders支付成功回调改paid触发派单退款走订单状态机不全额原路退“师傅已服务”单if($callback-success){OrderService::paySuccess($orderNo);}9.2 核销核销码建议6 位数字 单次有效或二维码带order_id sign师傅端扫码 → 服务端校验状态if($order-status!accepted)fail;$order-statusfinished;十、消息与通知至少四节点要推支付成功派单成功师傅出发服务完成渠道微信订阅消息短信阿里云/腾讯云App 推送WebSocket 实时状态可选消息走 MQ 异步别在订单接口里同步发短信。十一、部署架构11.1 最小可用单机Nginx ├── PHP-FPM / Java Jar ├── MySQL ├── Redis └── OSS适合本地家政试点。11.2 生产推荐Docker Compose / K8s ├── api ×2 ├── redis ├── mysql 主从 ├── admin └── cron自动取消订单定时任务别漏30 分钟未支付自动关单服务完成 24h 自动评价师傅当日单量重置十二、安全与合规上线前必看开源≠可直上生产。checklistJWT 密钥替换管理员默认密码改掉HTTPS 全站手机号/地址加密或脱敏师傅实名 健康证审核支付回调验签订单状态只能走 service后台 RBAC 细粒度数据库每日备份小程序隐私协议配置合规依据参照《网络安全法》《个人信息保护法》家政人员能力信息可对齐 GB/T 45440-2025。十三、二次开发路线建议不要一上来改首页动画顺序应该是跑通订单闭环下单→支付→派单→核销接本地地图 Key腾讯/高德改派单权重适配你城市加城市开关、师傅保证金、限单接短信加售后/投诉/退款再做数据看板开源代码的正确用法先当“参考实现”再当“底座”。直接改完就上生产多数死在状态机。十四、小结全端家政开源系统的技术核心不是“前端多了几个端”而是订单状态机在服务端唯一可信派单是可配置的规则引擎用户/师傅/后台共享同一套领域模型支付、位置、隐私都走服务端边界