简介这是一套面向本地生活服务创业者与PHP开发者的上门家政预约系统完整源码基于likeadmin-php与ThinkPHP框架构建前端采用Vue与uniapp覆盖用户端与师傅端双角色可解决预约、派单、支付、核销等业务闭环问题。压缩包共2000个文件约99.92MB以js、vue、css等前端资源为主辅以java、md、json、sql等配置与文档文件结构完整便于二次开发。系统支持腾讯地图定位、微信与支付宝官方支付、阿里云与腾讯云短信、本地与OSS存储并具备多规格商品、首页DIY、自定义预约时段、保证金与每日限单、指定城市开放接单等运营能力。目前已有78人学习下载适合希望快速搭建本地化家政平台的技术团队参考可从中获取前后台无加密源码、数据库脚本与部署配置直接用于功能验证与业务扩展。1. likeshop上门家政系统开源版源码一套能跑起来的家政派单底座长什么样likeshop上门家政系统开源版源码.zip 这个标题真正有价值的信息不是“likeshop”这四个字而是它背后代表的一整类系统把用户下单、平台派单、阿姨接单、上门服务、结算评价这条链路完整串起来的家政业务底座。很多做本地生活、社区服务、O2O 预约的团队卡住的从来不是前端页面好不好看而是订单状态怎么流转、服务人员怎么排班、多城市多门店怎么隔离数据。这套源码能解决的就是这些脏活累活它适合想快速验证家政业务模型的产品团队、需要二次开发交付给客户的外包团队以及想拿一套真实业务系统练手 PHP 全栈的开发者。你拿到压缩包之后第一件事不是急着改 UI而是先把它在本地跑起来看清楚它的订单状态机和权限模型再决定哪些模块留、哪些模块换。likeshop 这类系统通常基于 PHP MySQL 后台管理框架常见是 ThinkPHP 或 Laravel 系构建前端可能是 uni-app 或 Vue 打包成小程序/H5/App 多端。开源版一般会保留核心的家政服务下单、服务人员管理、订单派单、财务结算模块但可能在某些高级功能上做阉割比如智能调度算法、多级分销、精细化营销工具。你要做的第一件事是确认版本对应的技术栈和依赖因为不同版本的 likeshop 家政系统在目录结构、数据库表设计、接口鉴权方式上差异不小。下面按“先跑通、再拆解、后改造”的顺序把这条路径讲清楚。2. 把源码跑起来环境、依赖与数据库初始化2.1 先确认技术栈和目录结构再动手拿到压缩包解压后不要急着往服务器上传。先在本地看一眼根目录通常会有application、public、config、extend、vendor这些目录如果看到think命令行文件和composer.json基本可以确定是 ThinkPHP 系。前端资源可能在public/static或者独立的uniapp目录里。确认技术栈的目的是决定你本地要装什么PHP 版本常见 7.4 或 8.0、MySQL 版本5.7 或 8.0、Redis用于缓存和队列、以及 Node.js如果前端需要重新编译。我一般会先看composer.json里的require字段里面会写清楚框架版本和关键扩展依赖。如果require里有topthink/framework那就是 ThinkPHP如果有laravel/framework那就是 Laravel。这一步花两分钟能省掉后面半小时的报错排查。同时看一眼.env.example或config/database.php确认数据库连接配置的字段名不同版本可能用database也可能用dbname。2.2 用命令行把环境和依赖装到位本地跑通的最小路径是装 PHP Composer MySQL Redis然后拉依赖、导数据库、配伪静态。下面是一套在 Linux 或 macOS 上可复现的命令序列Windows 用户可以用 WSL 或宝塔面板替代。# 1. 确认 PHP 版本likeshop 家政系统常见要求 7.4 php -v # 2. 安装 Composer 依赖如果 vendor 目录已存在可跳过 composer install --no-dev # 3. 复制环境配置文件按实际情况改数据库账号密码 cp .env.example .env vim .env # 4. 创建数据库并导入 SQL 文件 mysql -u root -p -e CREATE DATABASE likeshop_house DEFAULT CHARSET utf8mb4; mysql -u root -p likeshop_house database/likeshop_house.sql # 5. 启动 PHP 内置服务器做快速验证 php think run --host 0.0.0.0 --port 8080这几条命令里composer install --no-dev会跳过开发依赖减少本地体积.env文件里重点改DB_HOST、DB_NAME、DB_USER、DB_PASS和REDIS_HOST导入 SQL 时注意有些版本会拆成多个文件比如install.sql加demo_data.sql要按顺序导。php think run是 ThinkPHP 自带的调试服务器只适合本地验证生产环境必须换成 Nginx PHP-FPM。2.3 数据库表里藏着业务模型先看这三张表跑起来之后别急着点页面。先打开数据库看三张核心表order订单表、service_staff服务人员表、service_item服务项目表。订单表里重点看status字段的枚举值通常会有待支付、待接单、已接单、服务中、已完成、已取消、退款中这些状态。服务人员表里看work_status接单状态、city_id城市隔离、store_id门店归属。服务项目表里看price_type按次/按小时/按面积和duration服务时长。这三张表决定了整个系统的派单逻辑。如果order表里有staff_id字段说明是直接指派如果有dispatch_log表说明有派单记录和抢单逻辑。我见过不少团队拿到源码后直接改前端结果订单状态流转对不上就是因为没先看表结构。建议把status的枚举值和对应的业务动作画成一张状态迁移图后面改代码时随时对照。3. 派单与订单状态流转家政系统最核心的改造点3.1 订单状态机怎么读、怎么改家政系统的订单状态机比普通电商复杂因为它多了“服务人员接单”和“上门服务中”这两个环节。以常见实现为例订单从创建到完成会经历待支付 → 待派单 → 待接单 → 已接单 → 服务中 → 待评价 → 已完成。每个状态变更通常对应一个order_status_log记录方便追溯。你要改派单逻辑就得先找到状态变更的触发点一般在app/service/OrderService.php或类似文件里。改状态机最容易翻车的地方是并发。比如两个阿姨同时抢一个单如果没有加锁或乐观锁版本号就会出现重复接单。常见做法是在update语句里加status 待接单作为条件用affected_rows判断是否抢到。下面是一段简化后的抢单逻辑示例// 抢单用条件更新防止并发重复接单 $affected Db::name(order) -where(id, $orderId) -where(status, wait_accept) // 只有待接单状态才能抢 -where(staff_id, 0) // 尚未分配人员 -update([ staff_id $staffId, status accepted, accept_time time(), ]); if ($affected 0) { // 抢单失败说明已被别人接走或状态不对 return json([code 400, msg 手慢了订单已被接走]); }这段代码的关键是where条件里带了status和staff_id数据库层面保证只有第一个更新成功。affected_rows为 0 就说明抢单失败直接返回提示。参数上wait_accept和accepted要和你数据库里的枚举值一致不同版本可能用数字 1、2、3改之前先查表。3.2 派单策略从手动指派到规则调度开源版通常自带手动派单和抢单两种模式。手动派单是后台管理员直接选人抢单是服务人员在 App 端看到待接单列表自己抢。如果你要做自动派单就得加一层调度逻辑常见规则包括按距离最近、按评分最高、按当前接单量最少、按服务人员技能标签匹配。这些规则不需要一上来就写算法先用 SQL 排序就能实现。比如按距离最近派单前提是订单表和服务人员表都有经纬度字段。你可以用 Haversine 公式在 SQL 里算距离也可以先用矩形范围粗筛再精算。下面是一个按接单量最少排序的简化查询-- 找出当前城市、对应技能标签、接单量最少的可用服务人员 SELECT s.id, s.name, s.rating, COUNT(o.id) AS active_orders FROM service_staff s LEFT JOIN order o ON o.staff_id s.id AND o.status IN (accepted, serving) WHERE s.city_id 1 AND s.work_status online AND FIND_IN_SET(保洁, s.skill_tags) GROUP BY s.id ORDER BY active_orders ASC, s.rating DESC LIMIT 5;这条 SQL 返回 5 个候选人你可以再结合距离做二次筛选。FIND_IN_SET用于技能标签匹配active_orders是当前进行中的订单数。注意order是 MySQL 关键字必须加反引号。这个查询在数据量大的时候会慢建议给staff_id、status、city_id加联合索引。3.3 服务人员排班与时间冲突检测家政系统绕不开排班。服务人员不是随时有空订单服务时间也不能重叠。常见做法是给服务人员建一张staff_schedule表记录每天的可服务时间段下单时检查目标时间段是否已被占用。检测逻辑可以用时间区间重叠判断新订单的开始时间小于已有订单的结束时间且结束时间大于已有订单的开始时间即为冲突。// 检查服务人员在指定时间段是否已有订单 $conflict Db::name(order) -where(staff_id, $staffId) -where(status, in, [accepted, serving]) -where(service_start, , $newEnd) -where(service_end, , $newStart) -count(); if ($conflict 0) { return json([code 400, msg 该时间段已被占用]); }参数说明$newStart和$newEnd是新订单的服务起止时间戳service_start和service_end是已有订单的时间字段。这个判断假设所有订单都是同一时区如果跨时区要统一转成 UTC。另外已取消和已完成的订单不参与冲突检测所以status条件里只保留进行中的状态。4. 多端适配与二次开发小程序、H5 和后台的边界4.1 前端目录怎么区分、怎么改likeshop 家政系统的前端通常是 uni-app 一套代码编译到微信小程序、H5 和 App。解压后你会看到一个独立的uniapp或frontend目录里面有pages、components、api、static等。改 UI 之前先看pages.json它定义了页面路由和 tabBar。改接口请求地址看api/request.js或common/config.js里面会有baseUrl配置。我一般会先跑 H5 版本因为浏览器调试最方便。进入前端目录执行npm install然后npm run dev:h5就能在浏览器里看到页面。如果接口跨域在manifest.json里配代理或者后端加 CORS 头。小程序版本需要微信开发者工具导入dist/dev/mp-weixin目录。注意开源版可能没有配置正式的 AppID你需要自己申请一个测试号。4.2 后台权限与多城市数据隔离后台管理通常基于 RBAC 权限模型有管理员、角色、权限节点三张表。多城市隔离是家政系统的关键常见实现是在几乎每张业务表里加city_id字段后台查询时自动带上当前管理员的城市条件。如果你要加新城市不是简单插一条城市记录还要检查服务项目、服务人员、价格策略是否都按城市做了区分。二次开发时最容易踩的坑是在 A 城市配了服务项目B 城市看不到但代码里写死了city_id 1。排查方法是全局搜索city_id看哪些地方是硬编码哪些是从登录态里取。正确做法是从管理员的city_id或请求参数里取并在中间件里统一注入查询条件。4.3 支付与结算模块的改造注意点家政系统的支付通常接微信支付和支付宝开源版可能只留了微信支付示例。结算模块涉及平台抽成、服务人员收入、退款分账。改这块之前先把order表里的pay_amount、platform_fee、staff_income三个字段的含义搞清楚。有些版本把结算逻辑放在app/service/SettlementService.php按订单完成时间触发。如果你要接自己的支付渠道重点改app/api/controller/PayController.php里的统一下单和回调验签逻辑。回调里必须做幂等处理防止重复通知导致重复加钱。常见做法是用transaction_id做唯一索引插入失败就忽略。退款逻辑同理要记录退款单号并校验可退金额。5. 避坑与排查跑 likeshop 家政源码时最容易翻车的五件事5.1 现象首页能打开但接口全部 500原因通常是伪静态没配或runtime目录没有写权限。ThinkPHP 系需要把请求重写到public/index.phpNginx 里要加try_files规则。另外runtime目录必须可写否则日志和缓存写不进去直接报错。解决Nginx 配置里加location / { try_files $uri $uri/ /index.php?$query_string; }然后chmod -R 755 runtime并确认属主是 PHP-FPM 运行用户。改完重启 Nginx 和 PHP-FPM。5.2 现象数据库导入报错“Unknown collation: utf8mb4_0900_ai_ci”原因是你本地 MySQL 是 5.7而 SQL 文件是从 MySQL 8.0 导出的排序规则不兼容。这是血泪经验里最常见的一条尤其是从别人那拿到的 SQL 文件。解决用文本编辑器打开 SQL 文件把utf8mb4_0900_ai_ci全部替换成utf8mb4_general_ci再把utf8mb4相关的字符集声明统一成utf8mb4。如果表数量多用sed批量替换更快sed -i s/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g likeshop_house.sql。5.3 现象小程序端请求接口返回 401 或签名错误原因通常是appid和secret没配或者 token 过期时间太短。开源版一般会在.env或config/wechat.php里留空需要你自己填。另外有些版本用 JWT 做鉴权token过期后没有自动刷新逻辑。解决先在后台把微信小程序配置填完整然后检查app/common/middleware/Auth.php里的 token 校验逻辑。如果是 JWT确认exp时间是否合理并在前端request.js里加 401 自动跳登录或刷新 token 的处理。5.4 现象派单后服务人员端看不到订单原因可能是城市隔离或技能标签不匹配。服务人员的city_id和订单的city_id不一致或者订单要求的技能标签不在服务人员的skill_tags里查询条件直接过滤掉了。解决先查数据库确认两边city_id是否一致再看skill_tags字段是否用逗号分隔且匹配规则正确。如果是抢单模式检查订单状态是否已经变成“待接单”有些版本在支付回调后才改状态支付没成功就不会进入抢单池。5.5 现象订单完成后结算金额不对原因通常是平台抽成比例配错或者退款后没有回滚结算。有些版本的抽成比例写在config/settlement.php里有些写在数据库config表里改了一处没改另一处。解决全局搜索platform_fee和commission确认抽成来源唯一。退款时检查是否触发了结算回滚逻辑如果没有需要在退款回调里补上。建议在结算前加一条日志记录订单号、金额、抽成比例和计算结果方便对账。6. 从能跑到好用二次开发时我固定会做的三件事第一件事是加一层接口日志。家政系统的订单流转涉及用户端、服务人员端、后台三端出问题时如果只看数据库根本不知道是哪一步断了。我一般会在中间件里记录请求路径、参数、返回码和耗时写到独立日志文件按天切割。这样排查派单失败、支付回调丢失时直接看日志就能定位。第二件事是把订单状态变更全部收口到一个服务类。开源版里状态变更可能散落在控制器、模型、回调里改一处漏一处。我会建一个OrderStatusService所有状态变更必须走它的方法方法里统一写日志、发通知、触发结算。这样后面加新状态或改流转规则只改一个地方。第三件事是给关键表加索引并做慢查询监控。家政系统订单表增长很快staff_id、city_id、status、create_time这几个字段的联合索引能救很多查询。我习惯在开发环境开slow_query_log把超过 1 秒的 SQL 都抓出来上线前逐条优化。下面是一个常用的联合索引示例-- 订单表按城市、状态、服务人员查询的联合索引 ALTER TABLE order ADD INDEX idx_city_status_staff (city_id, status, staff_id), ADD INDEX idx_staff_time (staff_id, service_start, service_end);这两个索引分别服务于后台按城市筛选订单和服务人员时间冲突检测。加索引之前先用EXPLAIN看现有查询的执行计划避免加了索引反而拖慢写入。我自己的习惯是每次改完派单逻辑先跑一遍EXPLAIN再压测 100 个并发抢单确认没有重复接单和死锁才敢提交。这套流程看起来麻烦但比上线后半夜被叫起来查订单丢失强得多。希望帮到你。本文还有配套的精品资源点击获取
likeshop上门家政系统开源版源码：从跑通到二次开发的完整指南
简介这是一套面向本地生活服务创业者与PHP开发者的上门家政预约系统完整源码基于likeadmin-php与ThinkPHP框架构建前端采用Vue与uniapp覆盖用户端与师傅端双角色可解决预约、派单、支付、核销等业务闭环问题。压缩包共2000个文件约99.92MB以js、vue、css等前端资源为主辅以java、md、json、sql等配置与文档文件结构完整便于二次开发。系统支持腾讯地图定位、微信与支付宝官方支付、阿里云与腾讯云短信、本地与OSS存储并具备多规格商品、首页DIY、自定义预约时段、保证金与每日限单、指定城市开放接单等运营能力。目前已有78人学习下载适合希望快速搭建本地化家政平台的技术团队参考可从中获取前后台无加密源码、数据库脚本与部署配置直接用于功能验证与业务扩展。1. likeshop上门家政系统开源版源码一套能跑起来的家政派单底座长什么样likeshop上门家政系统开源版源码.zip 这个标题真正有价值的信息不是“likeshop”这四个字而是它背后代表的一整类系统把用户下单、平台派单、阿姨接单、上门服务、结算评价这条链路完整串起来的家政业务底座。很多做本地生活、社区服务、O2O 预约的团队卡住的从来不是前端页面好不好看而是订单状态怎么流转、服务人员怎么排班、多城市多门店怎么隔离数据。这套源码能解决的就是这些脏活累活它适合想快速验证家政业务模型的产品团队、需要二次开发交付给客户的外包团队以及想拿一套真实业务系统练手 PHP 全栈的开发者。你拿到压缩包之后第一件事不是急着改 UI而是先把它在本地跑起来看清楚它的订单状态机和权限模型再决定哪些模块留、哪些模块换。likeshop 这类系统通常基于 PHP MySQL 后台管理框架常见是 ThinkPHP 或 Laravel 系构建前端可能是 uni-app 或 Vue 打包成小程序/H5/App 多端。开源版一般会保留核心的家政服务下单、服务人员管理、订单派单、财务结算模块但可能在某些高级功能上做阉割比如智能调度算法、多级分销、精细化营销工具。你要做的第一件事是确认版本对应的技术栈和依赖因为不同版本的 likeshop 家政系统在目录结构、数据库表设计、接口鉴权方式上差异不小。下面按“先跑通、再拆解、后改造”的顺序把这条路径讲清楚。2. 把源码跑起来环境、依赖与数据库初始化2.1 先确认技术栈和目录结构再动手拿到压缩包解压后不要急着往服务器上传。先在本地看一眼根目录通常会有application、public、config、extend、vendor这些目录如果看到think命令行文件和composer.json基本可以确定是 ThinkPHP 系。前端资源可能在public/static或者独立的uniapp目录里。确认技术栈的目的是决定你本地要装什么PHP 版本常见 7.4 或 8.0、MySQL 版本5.7 或 8.0、Redis用于缓存和队列、以及 Node.js如果前端需要重新编译。我一般会先看composer.json里的require字段里面会写清楚框架版本和关键扩展依赖。如果require里有topthink/framework那就是 ThinkPHP如果有laravel/framework那就是 Laravel。这一步花两分钟能省掉后面半小时的报错排查。同时看一眼.env.example或config/database.php确认数据库连接配置的字段名不同版本可能用database也可能用dbname。2.2 用命令行把环境和依赖装到位本地跑通的最小路径是装 PHP Composer MySQL Redis然后拉依赖、导数据库、配伪静态。下面是一套在 Linux 或 macOS 上可复现的命令序列Windows 用户可以用 WSL 或宝塔面板替代。# 1. 确认 PHP 版本likeshop 家政系统常见要求 7.4 php -v # 2. 安装 Composer 依赖如果 vendor 目录已存在可跳过 composer install --no-dev # 3. 复制环境配置文件按实际情况改数据库账号密码 cp .env.example .env vim .env # 4. 创建数据库并导入 SQL 文件 mysql -u root -p -e CREATE DATABASE likeshop_house DEFAULT CHARSET utf8mb4; mysql -u root -p likeshop_house database/likeshop_house.sql # 5. 启动 PHP 内置服务器做快速验证 php think run --host 0.0.0.0 --port 8080这几条命令里composer install --no-dev会跳过开发依赖减少本地体积.env文件里重点改DB_HOST、DB_NAME、DB_USER、DB_PASS和REDIS_HOST导入 SQL 时注意有些版本会拆成多个文件比如install.sql加demo_data.sql要按顺序导。php think run是 ThinkPHP 自带的调试服务器只适合本地验证生产环境必须换成 Nginx PHP-FPM。2.3 数据库表里藏着业务模型先看这三张表跑起来之后别急着点页面。先打开数据库看三张核心表order订单表、service_staff服务人员表、service_item服务项目表。订单表里重点看status字段的枚举值通常会有待支付、待接单、已接单、服务中、已完成、已取消、退款中这些状态。服务人员表里看work_status接单状态、city_id城市隔离、store_id门店归属。服务项目表里看price_type按次/按小时/按面积和duration服务时长。这三张表决定了整个系统的派单逻辑。如果order表里有staff_id字段说明是直接指派如果有dispatch_log表说明有派单记录和抢单逻辑。我见过不少团队拿到源码后直接改前端结果订单状态流转对不上就是因为没先看表结构。建议把status的枚举值和对应的业务动作画成一张状态迁移图后面改代码时随时对照。3. 派单与订单状态流转家政系统最核心的改造点3.1 订单状态机怎么读、怎么改家政系统的订单状态机比普通电商复杂因为它多了“服务人员接单”和“上门服务中”这两个环节。以常见实现为例订单从创建到完成会经历待支付 → 待派单 → 待接单 → 已接单 → 服务中 → 待评价 → 已完成。每个状态变更通常对应一个order_status_log记录方便追溯。你要改派单逻辑就得先找到状态变更的触发点一般在app/service/OrderService.php或类似文件里。改状态机最容易翻车的地方是并发。比如两个阿姨同时抢一个单如果没有加锁或乐观锁版本号就会出现重复接单。常见做法是在update语句里加status 待接单作为条件用affected_rows判断是否抢到。下面是一段简化后的抢单逻辑示例// 抢单用条件更新防止并发重复接单 $affected Db::name(order) -where(id, $orderId) -where(status, wait_accept) // 只有待接单状态才能抢 -where(staff_id, 0) // 尚未分配人员 -update([ staff_id $staffId, status accepted, accept_time time(), ]); if ($affected 0) { // 抢单失败说明已被别人接走或状态不对 return json([code 400, msg 手慢了订单已被接走]); }这段代码的关键是where条件里带了status和staff_id数据库层面保证只有第一个更新成功。affected_rows为 0 就说明抢单失败直接返回提示。参数上wait_accept和accepted要和你数据库里的枚举值一致不同版本可能用数字 1、2、3改之前先查表。3.2 派单策略从手动指派到规则调度开源版通常自带手动派单和抢单两种模式。手动派单是后台管理员直接选人抢单是服务人员在 App 端看到待接单列表自己抢。如果你要做自动派单就得加一层调度逻辑常见规则包括按距离最近、按评分最高、按当前接单量最少、按服务人员技能标签匹配。这些规则不需要一上来就写算法先用 SQL 排序就能实现。比如按距离最近派单前提是订单表和服务人员表都有经纬度字段。你可以用 Haversine 公式在 SQL 里算距离也可以先用矩形范围粗筛再精算。下面是一个按接单量最少排序的简化查询-- 找出当前城市、对应技能标签、接单量最少的可用服务人员 SELECT s.id, s.name, s.rating, COUNT(o.id) AS active_orders FROM service_staff s LEFT JOIN order o ON o.staff_id s.id AND o.status IN (accepted, serving) WHERE s.city_id 1 AND s.work_status online AND FIND_IN_SET(保洁, s.skill_tags) GROUP BY s.id ORDER BY active_orders ASC, s.rating DESC LIMIT 5;这条 SQL 返回 5 个候选人你可以再结合距离做二次筛选。FIND_IN_SET用于技能标签匹配active_orders是当前进行中的订单数。注意order是 MySQL 关键字必须加反引号。这个查询在数据量大的时候会慢建议给staff_id、status、city_id加联合索引。3.3 服务人员排班与时间冲突检测家政系统绕不开排班。服务人员不是随时有空订单服务时间也不能重叠。常见做法是给服务人员建一张staff_schedule表记录每天的可服务时间段下单时检查目标时间段是否已被占用。检测逻辑可以用时间区间重叠判断新订单的开始时间小于已有订单的结束时间且结束时间大于已有订单的开始时间即为冲突。// 检查服务人员在指定时间段是否已有订单 $conflict Db::name(order) -where(staff_id, $staffId) -where(status, in, [accepted, serving]) -where(service_start, , $newEnd) -where(service_end, , $newStart) -count(); if ($conflict 0) { return json([code 400, msg 该时间段已被占用]); }参数说明$newStart和$newEnd是新订单的服务起止时间戳service_start和service_end是已有订单的时间字段。这个判断假设所有订单都是同一时区如果跨时区要统一转成 UTC。另外已取消和已完成的订单不参与冲突检测所以status条件里只保留进行中的状态。4. 多端适配与二次开发小程序、H5 和后台的边界4.1 前端目录怎么区分、怎么改likeshop 家政系统的前端通常是 uni-app 一套代码编译到微信小程序、H5 和 App。解压后你会看到一个独立的uniapp或frontend目录里面有pages、components、api、static等。改 UI 之前先看pages.json它定义了页面路由和 tabBar。改接口请求地址看api/request.js或common/config.js里面会有baseUrl配置。我一般会先跑 H5 版本因为浏览器调试最方便。进入前端目录执行npm install然后npm run dev:h5就能在浏览器里看到页面。如果接口跨域在manifest.json里配代理或者后端加 CORS 头。小程序版本需要微信开发者工具导入dist/dev/mp-weixin目录。注意开源版可能没有配置正式的 AppID你需要自己申请一个测试号。4.2 后台权限与多城市数据隔离后台管理通常基于 RBAC 权限模型有管理员、角色、权限节点三张表。多城市隔离是家政系统的关键常见实现是在几乎每张业务表里加city_id字段后台查询时自动带上当前管理员的城市条件。如果你要加新城市不是简单插一条城市记录还要检查服务项目、服务人员、价格策略是否都按城市做了区分。二次开发时最容易踩的坑是在 A 城市配了服务项目B 城市看不到但代码里写死了city_id 1。排查方法是全局搜索city_id看哪些地方是硬编码哪些是从登录态里取。正确做法是从管理员的city_id或请求参数里取并在中间件里统一注入查询条件。4.3 支付与结算模块的改造注意点家政系统的支付通常接微信支付和支付宝开源版可能只留了微信支付示例。结算模块涉及平台抽成、服务人员收入、退款分账。改这块之前先把order表里的pay_amount、platform_fee、staff_income三个字段的含义搞清楚。有些版本把结算逻辑放在app/service/SettlementService.php按订单完成时间触发。如果你要接自己的支付渠道重点改app/api/controller/PayController.php里的统一下单和回调验签逻辑。回调里必须做幂等处理防止重复通知导致重复加钱。常见做法是用transaction_id做唯一索引插入失败就忽略。退款逻辑同理要记录退款单号并校验可退金额。5. 避坑与排查跑 likeshop 家政源码时最容易翻车的五件事5.1 现象首页能打开但接口全部 500原因通常是伪静态没配或runtime目录没有写权限。ThinkPHP 系需要把请求重写到public/index.phpNginx 里要加try_files规则。另外runtime目录必须可写否则日志和缓存写不进去直接报错。解决Nginx 配置里加location / { try_files $uri $uri/ /index.php?$query_string; }然后chmod -R 755 runtime并确认属主是 PHP-FPM 运行用户。改完重启 Nginx 和 PHP-FPM。5.2 现象数据库导入报错“Unknown collation: utf8mb4_0900_ai_ci”原因是你本地 MySQL 是 5.7而 SQL 文件是从 MySQL 8.0 导出的排序规则不兼容。这是血泪经验里最常见的一条尤其是从别人那拿到的 SQL 文件。解决用文本编辑器打开 SQL 文件把utf8mb4_0900_ai_ci全部替换成utf8mb4_general_ci再把utf8mb4相关的字符集声明统一成utf8mb4。如果表数量多用sed批量替换更快sed -i s/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g likeshop_house.sql。5.3 现象小程序端请求接口返回 401 或签名错误原因通常是appid和secret没配或者 token 过期时间太短。开源版一般会在.env或config/wechat.php里留空需要你自己填。另外有些版本用 JWT 做鉴权token过期后没有自动刷新逻辑。解决先在后台把微信小程序配置填完整然后检查app/common/middleware/Auth.php里的 token 校验逻辑。如果是 JWT确认exp时间是否合理并在前端request.js里加 401 自动跳登录或刷新 token 的处理。5.4 现象派单后服务人员端看不到订单原因可能是城市隔离或技能标签不匹配。服务人员的city_id和订单的city_id不一致或者订单要求的技能标签不在服务人员的skill_tags里查询条件直接过滤掉了。解决先查数据库确认两边city_id是否一致再看skill_tags字段是否用逗号分隔且匹配规则正确。如果是抢单模式检查订单状态是否已经变成“待接单”有些版本在支付回调后才改状态支付没成功就不会进入抢单池。5.5 现象订单完成后结算金额不对原因通常是平台抽成比例配错或者退款后没有回滚结算。有些版本的抽成比例写在config/settlement.php里有些写在数据库config表里改了一处没改另一处。解决全局搜索platform_fee和commission确认抽成来源唯一。退款时检查是否触发了结算回滚逻辑如果没有需要在退款回调里补上。建议在结算前加一条日志记录订单号、金额、抽成比例和计算结果方便对账。6. 从能跑到好用二次开发时我固定会做的三件事第一件事是加一层接口日志。家政系统的订单流转涉及用户端、服务人员端、后台三端出问题时如果只看数据库根本不知道是哪一步断了。我一般会在中间件里记录请求路径、参数、返回码和耗时写到独立日志文件按天切割。这样排查派单失败、支付回调丢失时直接看日志就能定位。第二件事是把订单状态变更全部收口到一个服务类。开源版里状态变更可能散落在控制器、模型、回调里改一处漏一处。我会建一个OrderStatusService所有状态变更必须走它的方法方法里统一写日志、发通知、触发结算。这样后面加新状态或改流转规则只改一个地方。第三件事是给关键表加索引并做慢查询监控。家政系统订单表增长很快staff_id、city_id、status、create_time这几个字段的联合索引能救很多查询。我习惯在开发环境开slow_query_log把超过 1 秒的 SQL 都抓出来上线前逐条优化。下面是一个常用的联合索引示例-- 订单表按城市、状态、服务人员查询的联合索引 ALTER TABLE order ADD INDEX idx_city_status_staff (city_id, status, staff_id), ADD INDEX idx_staff_time (staff_id, service_start, service_end);这两个索引分别服务于后台按城市筛选订单和服务人员时间冲突检测。加索引之前先用EXPLAIN看现有查询的执行计划避免加了索引反而拖慢写入。我自己的习惯是每次改完派单逻辑先跑一遍EXPLAIN再压测 100 个并发抢单确认没有重复接单和死锁才敢提交。这套流程看起来麻烦但比上线后半夜被叫起来查订单丢失强得多。希望帮到你。本文还有配套的精品资源点击获取
