简介进云JYS系统应用上门服务源码v1.2是一套基于进云框架的原生插件定位为上门服务类业务的快速落地组件面向需要搭建维修、物业、家政或同城服务平台的开发者与运营者。源码覆盖维修类、物业类、服务类等主流业务场景支持自由开启员工入驻并允许用户通过手机端直接申请入驻极大降低了人员招募与管理的门槛。在实际部署中可以快速完成服务分类、预约派单、订单跟踪等基础流程同时后续还有机会对接物业小区、智慧酒店等新应用让平台向社区终端和酒店终端延伸。资源以ZIP压缩包形式交付整体仅117KB体积小巧、结构清晰适合在已安装进云框架的环境中直接安装或二次开发。目前已有251人学习浏览其依托的乐高场景体更新机制也会随依赖插件的迭代同步升级帮助使用者持续获得新功能或修复。对正在选型或自研上门服务系统的团队来说这份源码能有效缩短前期开发周期是一份值得收藏的落地参考。 做上门服务类业务最头疼的往往不是业务创意而是派单、结算、服务状态流转这一堆牵扯到人和钱的细节。最近我把一套进云jys系统的上门服务源码v1.2完整跑了一遍从部署到二次开发前后折腾了小两周总算把里里外外的实现思路摸了个清楚。这套源码面向家政保洁、维修安装、预约上门这类LBS业务服务端用PHP开发搭配小程序端和后台管理面板v1.2版本修复了不少早期版本在订单状态和支付回调上的老毛病整体设计务实、链路清晰很适合做本地生活服务的团队拿来二次开发。不管你是刚接触这套源码还是已经在琢磨怎么改派单规则这篇内容都值得看完。我会从系统定位开始把用户端、服务端、后台的完整逻辑拆开讲再给出一套可直接照着用的部署流程最后聊聊我实际踩过的坑和二次开发时最值得动刀的几个地方。1. 项目定位与核心设计思路1.1 这套源码到底解决了什么问题上门服务这类业务有几个绕不开的共性痛点用户在哪里下单、师傅怎么接单、订单怎么匹配区域、跑单了如何处理、费用怎么结算。进云jys系统v1.2的设计思路本质上就是把这些痛点收敛成一套“服务商品化 LBS派单 服务履约”的闭环。所谓“服务商品化”是指把一次上门服务包装成可以在线购买的商品包含服务名称、时长、价格、适用区域等属性。用户端看到的不是简单的“预约表单”而是像买普通商品一样选择服务、选地址、选时间、在线支付。这比传统电话预约或手工派单要规范得多所有过程都会留痕后续对账也有据可查。v1.2版本最明显的变化是把支付回调、订单状态机、服务人员分成计算从原来的订单控制器里拆了出来独立成模块。早期版本这几个逻辑是揉在一起的改一个地方容易影响另外两处经常出现支付成功但订单没更新、师傅提现金额算不准之类的问题。独立拆分之后每个模块的职责清晰很多二次开发时改起来也省心。1.2 为什么是PHP 小程序这套组合选PHP做服务端并不是因为它性能最强而是因为它部署成本低、生态成熟、招人容易。上门服务类项目的核心通常不是高并发而是业务规则复杂、线下履约环节多。PHP配合MySQL的开发效率高一台普通云服务器就能跑起来对于中小团队来说非常友好。小程序端则解决了用户侧“不想下载App”的问题。微信生态内的用户打开即用地理位置授权、地图选点、微信支付这些都是原生能力不需要额外接SDK。v1.2的小程序端做了分包处理把首页、下单流程、个人中心、订单详情拆成独立分包打开速度比整包加载快不少这个细节很多同类源码没考虑到。1.3 与普通电商系统的核心差异上门服务源码和普通电商系统有本质区别。电商卖的是实物商品核心流程是“下单-支付-发货-收货”订单发出去之后基本依赖物流公司平台方不需要管履约过程。上门服务则完全不同平台既要管销售又要管服务交付。订单创建之后系统要能根据位置派单给师傅师傅要能接单、开始服务、结束服务用户要能验收、评价。v1.2的整套设计就是围绕“服务履约”这条线展开的订单状态机比电商复杂得多这是看这套源码时最需要关注的地方。2. 系统功能模块与业务流程拆解2.1 用户从下单到服务完成的完整链路跑通一次完整的上门服务大致要经过以下流程用户进入小程序授权获取位置选择服务分类和服务项目填写服务地址可在地图上选点定位选择预约时间立即上门或指定时间提交订单在线支付或选择货到付款系统派单给附近的空闲师傅师傅接单并与用户联系师傅上门点击开始服务服务完成用户确认验收并评价这套流程在v1.2源码里都有对应的功能支持重点是每个节点都有状态记录订单日志表会把每一步操作的时间、操作人、备注全部记下来。我实际跑下来最大的感受是只要订单状态设计合理后续做售后、投诉、财务结算都轻松很多。2.2 两端三方的角色权限设计上门服务系统里至少有三种角色普通用户、服务师傅可以理解为技师/师傅/维修工、平台管理员。v1.2把不同角色的权限边界划分得比较清楚我整理了一个角色与核心功能对照表角色核心权限主要界面普通用户下单、支付、申请退款、评价、查看订单小程序用户端服务师傅接单/拒单、开始服务、完成服务、查看收益小程序师傅端平台管理员服务项目管理、订单管理、师傅审核、财务结算、营销配置Web后台这里要特别提醒一句v1.2里的师傅端也是小程序不是在Web后台操作。师傅端可以看到平台派给自己的订单可以一键导航到用户地址服务结束后可以查看本次收入。这种设计的好处是师傅不用装额外的App小程序里就能处理日常接单工作。2.3 营销与分销功能v1.2带了一套基础营销工具包括优惠券、分销推广、套餐次卡。优惠券支持满减和折扣两种类型可以设置使用门槛、有效期、适用服务分类分销功能主要用来做老带新用户分享给好友注册后好友下单原用户可以获得返佣套餐次卡适合保洁、洗车这类高频复购的服务。这块的设计与纯电商分销不太一样。上门服务的分销返佣不是按商品金额简单比例分成而是要考虑师傅分成、平台抽成、推广者佣金三层关系v1.2把这三层费率拆开配置不容易出现“卖一单亏一单”的情况。3. 技术实现与数据设计3.1 服务端架构与技术栈说明进云jys系统v1.2服务端基于ThinkPHP框架开发这是国内PHP项目里非常主流的选择。源码目录整体呈MVC结构控制器层、模型层、模板层分得很清楚以下是核心目录的大致结构application/ admin/ # 后台管理模块 controller/ # 后台控制器 model/ # 后台模型 view/ # 后台模板 api/ # 小程序接口模块 controller/ # 接口控制器 common/ # 公共模块 model/ # 公共数据模型 validate/ # 参数验证器 public/ uploads/ # 上传文件目录 static/ # 静态资源我建议拿到源码后先别急着改功能花半天时间把目录结构过一遍。特别是common模块里的公共模型和验证器很多通用逻辑都放在这里。比如用户的登录态校验、支付参数校验、订单编号生成规则都在公共层统一处理如果单独在某个控制器里重写后面维护会非常痛苦。3.2 订单表与服务单表的关系设计订单是整套系统的核心。v1.2在数据表设计上做了一个很关键的决定支付订单和履约服务单分开存储。用户下单支付时生成一条支付订单主要记录金额、支付方式、支付状态同时生成一条服务单记录服务项目、师傅、预约时间、状态流转。这样做有实实在在的好处。支付订单面向财务对账字段稳定、格式统一服务单面向履约过程状态频繁变化但和资金解耦。如果混在一张表里每次状态更新都要关联支付信息数据库负担重逻辑也容易乱。订单状态机是这套源码里值得研究的核心部分。我梳理了一下v1.2的订单状态流转状态值状态含义可执行操作0待支付用户取消、继续支付1待派单系统自动匹配师傅2已接单师傅联系用户、开始服务3服务中师傅完成服务4待验收用户确认完成5已完成用户评价、售后6已取消退款处理7退款中原路退回每个状态都有对应的操作权限校验比如只有状态为“服务中”时师傅才能点击“完成服务”只有状态为“待验收”时用户才能确认完成。这种约束在控制器里都有对应判断二次开发时别直接改状态值要通过封装好的状态流转方法来操作。3.3 小程序端与地图、支付、定位的对接小程序端用了微信原生框架没有引入特别重的第三方UI组件库。首页、订单列表、个人中心做得比较轻量。地理位置相关功能v1.2源码封装了定位组件获取用户经纬度后调起地图选择器用户可以在图上手动微调服务地址。服务端把经纬度存到订单表里派单时按距离计算附近师傅。派单逻辑是这套源码的亮点之一。创建订单后系统会查询服务区域内的空闲师傅按距离由近到远排序优先推送给最近的师傅如果该师傅30分钟内未接单系统会自动转派给下一位。这种“先到先得、距离优先”的策略对大部分上门服务场景都适用。支付方面走的是微信支付服务端统一生成支付参数小程序端调起支付收银台。v1.2在处理支付回调时做了幂等校验同一个订单的支付通知不会被重复处理这点一定要保留。回调逻辑里同时更新支付订单状态和服务单状态如果发现订单已支付直接返回成功不再重复执行后续流程。4. 部署上线与初始化配置4.1 环境准备与源码初始化部署环境建议使用Linux服务器搭配Nginx PHP 7.x MySQL 5.7的组合。PHP需要开启fileinfo、curl、openssl和PDO扩展MySQL需要开启InnoDB存储引擎。这套源码对服务器配置要求不高1核2G的云服务器跑个人项目完全够用如果是正式商用建议2核4G起步预留一些并发空间。拿到源码后的初始化步骤上传源码到服务器站点目录比如/www/wwwroot/jys配置站点伪静态ThinkPHP的URL重写规则要设置好否则访问后台会404创建一个MySQL数据库编码选择utf8mb4导入根目录下的数据库文件v1.2的SQL文件一般放在sql/或db/目录修改config/database.php中的数据库连接信息将站点运行目录指向public这样更安全给runtime目录和public/uploads目录设置可写权限否则会报错或无法上传文件注意不要把站点根目录直接指向项目根目录必须指向public子目录。这样所有的PHP文件都在上级目录中用户只能访问到入口文件和静态资源能避免很多安全隐患。4.2 后台配置与小程序发布要点后台入口默认是/admin首次登录需要修改管理员账号密码并且建议开启登录验证码。进入后台之后以下配置项是必须填写的配置项说明获取方式小程序AppID和AppSecret小程序端调用的身份凭证微信公众平台微信支付商户号、API密钥支付功能必需微信商户平台地图Key地图选点和距离计算的密钥腾讯位置服务服务区域可派单的坐标范围和半径后台地图配置小程序发布的流程比较固定在微信公众平台注册小程序账号把miniapp目录下的代码用微信开发者工具上传设置服务器域名时要把接口域名加进 request 合法域名里。这一步最容易踩坑很多人开发环境调得好好的一上线就白屏十有八九是合法域名没配或者没校验。支付商户号需要在小程序后台关联绑定还要配置支付回调域名。v1.2的支付回调地址格式一般是https://你的域名/index.php/api/pay/notify这个地址必须是可以被微信服务器公网访问的不能用localhost。5. 常见问题与二次开发实录5.1 部署、支付和派单问题速查我实际操作过程中遇到过不少问题整理了最容易出现的几个方便大家对照排查问题现象可能原因排查与解决办法后台打开404伪静态没有配置检查Nginx或Apache的伪静态规则是否生效小程序端空白request合法域名未配置登录微信公众平台把接口域名加到合法域名支付回调无响应回调地址不对或验签失败检查回调地址、商户API密钥是否一致地图选点定位不准Key类型选错腾讯位置服务需要申请WebServiceAPI类型的Key订单一直待派单服务区域未设置在后台设置服务坐标和派单半径上传图片失败目录权限不足检查public/uploads目录是否为可写状态5.2 二次开发中最值得改的三个地方第一个值得改的是派单策略。v1.2默认的派单逻辑是“距离优先”但实际业务里师傅的评分、单量、技能标签都很重要。如果要做精细化运营可以在派单算法里加入师傅评分权重或者让用户在下单时指定指定师傅这需要给服务项目加一个“是否可指定师傅”的字段。第二个是结算规则。v1.2的师傅分成计算公式是写死的只支持按订单金额固定比例分成。实际上很多上门服务行业的师傅分成是按服务类型区分的比如家政服务平台抽20%维修服务平台抽10%再加阶梯奖励。这里建议把分成规则做成可配置的存储到数据库里而不是写死在代码中。第三个是消息通知渠道。v1.2的默认通知方式是小程序订阅消息加上框架内的站内信实际运营中短信通知也很关键尤其是师傅上门前、用户预约前一小时这类强提醒场景。可以接入短信服务商在订单状态发生变化时触发短信通知。5.3 关于源码安全的几点提醒拿到任何一套PHP源码第一步都不应该是急着部署而是先做一次安全梳理。v1.2整体代码风格算规整但二手源码市场鱼龙混杂有些渠道拿到的版本可能被加过后门。建议重点检查index.php入口文件、common.php公共函数文件里的可疑代码以及是否有多余的不明路由。上线之后还要做好日常安全防护。runtime目录缓存能清就定期清一下上传目录不要允许执行PHP文件服务器配置里把允许访问的目录严格限定在public内。数据库账号不要用root单独创建一个只有当前数据库权限的账号密码设置复杂一些。另外后台登录接口务必加频率限制防止暴力破解。跑完整套源码我的体会是进云jys系统v1.2并不追求花哨的技术但它在业务链路上的完整度确实让人省心。从下单、派单、服务到结算每个环节都留有二次开发的接口和余地。如果你正准备做本地生活服务类的项目建议先别急着堆新功能把订单状态机、派单逻辑和财务结算这三块吃透后面的路会顺很多。本文还有配套的精品资源点击获取