简介likeshop上门家政系统开源版源码是一套基于likeadmin-php框架开发的家政服务预约管理系统提供全部前后台无加密源代码面向家政平台运营者、外包团队及具备PHP基础的开发者专注解决上门预约、系统派单、后台派单与订单核销等核心业务闭环。资源共2000个文件以644个js、639个vue、254个css等前端构建文件为主辅以135个java文件、sql数据库脚本和md说明文档整体压缩包约96MB完整覆盖小程序与H5端。系统内置腾讯地图定位支持自定义预约时间段、多规格服务价格、首页DIY装修并接入微信、支付宝官方支付以及阿里云/腾讯云短信、本地或OSS存储师傅端具备保证金和每日限单机制后台可设置指定城市开放接单适合本地化精准运营。目前已有138人学习下载部署建议使用PHP8.0需fileinfo扩展与MySQL5.7环境配合Thinkphp框架即可快速完成上线。1. 为什么用 likeshop 做上门家政系统这标题到底指什么“likeshop上门家政系统开源版源码”这句话在从业者群里大致翻译过来是以 likeshop 单商户/多商户 PHP 商城框架为基础二次开发出一套面向上门家政场景的预约、派单、结算一体化系统并把这套源码以开源形式分享出来。它解决的从来不是“做个官网”的问题而是把家政公司最头疼的三件事——顾客在线预约、师傅接单排期、平台分账售后——用一套后台管起来。这套东西适合谁适合两类人一是手里已有实体家政门店、想快速上线小程序/H5 预约入口的老板或运营二是接外包的技术团队想拿到一套结构清晰的 PHP 源码作为二开基底。你不需要从零写用户系统和支付系统likeshop 底层的会员、支付、营销、后台权限管理都能直接复用。需要你动手的是把“标准商城”里的订单逻辑改成“预约上门服务”再加一套服务人员的管理维度。我最早接触这个项目时也以为它是个独立家政系统解压后看目录才发现它是“商城框架 家政业务二开”的组合形态。这个判断很重要因为它决定了你后续所有改动都发生在哪些文件里订单模块、技师/服务人模块、预约时间轴这三块才是你的主战场。下面从整体结构讲起一步步把二开边界画出来。2. 先把骨架看明白likeshop 家政版的模块划分与二次开发边界2.1 从 B 端到 C 端的五张核心表订单、服务人、预约排期、售后、营销家政系统本质上是一个“人 时间 服务”的分配系统。likeshop 商城版已经有成熟的用户表ls_user、订单表ls_order、支付回调表ls_pay你在此基础上要新增或改动的是下面这几条主链路。服务人表存放保洁师、月嫂、维修工等从业人员信息。字段上要多出服务类目、接单状态、评分、服务次数、经度纬度。常见做法是在原ls_user上扩展一张ls_server_user用user_id关联避免改原表结构破坏商城逻辑。预约排期表这是家政系统区别于普通商城的核心。每次下单不只生成订单还要生成一条预约记录包含期望服务时间、服务时长、上门地址、服务人分配状态。表名常见为ls_appointment关联order_id。日程表ls_server_schedule按时间片记录某个服务人某天哪几个时段已被占用。派单冲突检测查的就是这张表。售后表ls_aftersale家政行业退款原因跟实物商品完全不同集中在“未上门”“迟到”“服务不满意”“客户临时取消”四类需要在售后类型字段上做定制。营销表优惠券、拼团、秒杀这类商城功能可以继续用但用法要改。家政行业真正有效的是“新客立减 老客复购券 指定时段折扣”不建议把商城满减机制直接套到服务上会造成毛利穿底。ls_order里的订单类型字段order_type建议直接沿用 likeshop 的设计新增一个类型值如service然后所有家政订单走独立的订单服务类OrderServerService。不要为家政订单另起一套订单表——支付回调、对账单、微信退款都绑定ls_order另起表会给财务对账带来麻烦。2.2 后端为什么用 ThinkPHP 6 MySQL前端为什么优先选 uni-applikeshop 开源版的技术栈基本是 ThinkPHP 6 后端 MySQL 5.7/8.0 前端 uni-app 多端编译方案。这套组合在 2024 年前后的 PHP 开源项目里非常主流选择它的理由不是因为性能最强而是因为“能省钱、好招人”。ThinkPHP 6 的文档和社区问答存量极大你招聘一个 3 年经验的 PHP 工程师就能上手改代码不必非得找熟悉 Swoole 或 Hyperf 的人。MySQL 加 Redis 的组合足以支撑家政公司在单城市五六百家门店量级、日订单一万以下的流量模型。要是你真有日订单十万的体量这套架构再考虑拆服务也不迟但那属于后话。前端 uni-app 的价值在于一次编写、多端发布。家政用户入口通常兼顾微信公众号 H5、微信小程序、抖音小程序三个端。用 uni-app 一个仓库可以编译到三端省掉的重复开发量相当可观。改端上接口前缀的配置在各端目录底下后面第四章会细说。2.3 “开源版”到底开放了什么源码目录里的四层结构拿到源码压缩包后先看根目录不要急着双击install。likeshop 家政版的目录常规是按以下分层排布的server ThinkPHP 6 后端目录 uniapp 前端多端工程目录 admin 后台管理端Vue 或基于 uni-app 的 H5 管理后台 sql SQL 安装脚本与数据结构文件第一层server里再分app、route、config、extend。家政二开要关心的集中在app/api/controller/order、app/api/controller/server和app/model下。第二层uniapp里看pages/order和pages/server所有家政页面在这里。第三层admin是运营后台的工程服务人录入、排期日历、派单操作都在这里。第四层sql下会有安装脚本和增量更新脚本后面升级数据表结构时靠的就是这些文件。我要特别说明一点开源版和商业版的差别通常不在代码质量上而在“可配置功能”上。开源版砍掉的往往是多商户分账、复杂的抽佣规则配置、营销活动模板这类商业能力核心的预约、派单、支付流程是完整的。你拿到源码后先跑通再评估缺什么功能不要一开始就想着找作者要全功能版——按自己业务写一版派单规则往往比通用功能更贴合实际。3. 本地跑通这套源码环境准备与最小部署流程3.1 环境要求与初始化PHP 版本、Composer 依赖与站点配置先看环境要求。likeshop 后端基于 ThinkPHP 6PHP 版本至少要 7.4建议直接用 8.0 或 8.1。这里有个坑PHP 8.2 上某些老版本扩展可能报弃用警告最稳妥是选 PHP 8.0 配上 Nginx。MySQL 建议 5.7 或 8.0Redis 必须装登录态和部分缓存依赖它。Nginx 伪静态规则直接参考 ThinkPHP 的标准配置。server { listen 80; server_name your-domain.com; root /www/wwwroot/server/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_param HTTP_PROXY ; } }这段配置里root指向的是server/public不是项目根目录这是 ThinkPHP 6 的入口安全机制。如果指到根目录application、config这些敏感文件会被直接访问属于低级的部署事故。rewrite规则把不存在的文件路径全部转给index.php处理前端路由才能正常工作。装完扩展、配好站点后需要在项目根目录执行一次依赖安装cd server composer install --no-dev --optimize-autoloader--no-dev跳过开发依赖减少生产环境的安全暴露面--optimize-autoloader生成优化过的自动加载映射PHP 运行时少做文件存在性判断QPS 能提升一点。执行完毕检查vendor目录是否生成如果看到vendor/autoload.php存在才算依赖就绪。3.2 用安装向导导入数据库从压缩包到后台可登录的完整步骤likeshop 家族的项目普遍带一个 Web 安装向导访问http://your-domain/install.php就能看到环境检测、数据库配置、管理员初始化三步。但这里有个实际问题家政版源码经常是在商城版基础上改的安装向导可能残留商城字段直接装完再改很费劲。我推荐的做法是把 SQL 脚本看清楚再动手mysql -uroot -p your_database sql/install.sql在导入之前先打开sql/install.sql搜索ls_server_user、ls_appointment这两张表是否存在。如果存在说明这份源码的家政表是完整打包的可以放心走安装向导如果不存在只有商城原生表那么你拿到的可能是半成品需要联系作者补二开增量脚本。安装向导填写的数据库账号不要用 root单独建一个最小权限账号只给业务库的select/insert/update/delete/create/alter权限。家政系统的后台员工账号共用一套用户体系如果数据库账号权限过大一旦后台被脱裤攻击者可以直接删库连后悔药都没有。初始化完成后后台默认地址一般是http://your-domain/admin。用安装时设置的管理员账号登录先进“系统设置”把站点名称、小程序 AppID、密钥填好。这一步不填前端所有微信登录、支付都起不来不用急着改代码配置文件填对反而更快。3.3 跑小程序/H5/公众号端修改 baseURL 与密钥的四个必改文件前端 uni-app 工程能否跑起来本质上只看一个东西所有请求是否打到了你的后端。uniapp 端编译到小程序时请求域名必须在微信公众平台配置为合法 request 域名同时在代码里找到 API 基础地址常量统一修改。// uniapp/config/env.js export default { // 开发环境本地后端地址 dev: { baseURL: http://127.0.0.1:8080, h5BaseURL: http://127.0.0.1:8080 }, // 生产环境正式域名必须为 https prod: { baseURL: https://api.your-domain.com, h5BaseURL: https://www.your-domain.com } }baseURL是接口请求地址h5BaseURL是 H5 页面分享、跳转时用的前端地址。小程序端要求所有网络请求必须走 HTTPS所以生产环境这两个字段不能写http://否则真机预览直接白屏。还有server/.env文件里的APP_URL要与上面的域名保持一致否则后端生成小程序码、分享海报时拼接出来的 URL 是错的。第四个必改文件是server/config/pay.php里的微信支付配置merchant_id、api_key、cert_path、key_path。证书文件放到server/extend/下路径用绝对路径或相对站点根目录的路径别用C:/Users/xxx/Desktop/cert/部署到 Linux 上必然 404。4. 二次开发重点把“预约派单支付”改成你门店的业务规则4.1 预约排期设计服务时长、上门时段与技师档期冲突检测家政系统最核心的业务规则是“时间即库存”。商品卖超了可以退款服务排重了就是事故——两个客户在同一个上午都约了同一个保洁师。所以预约表的设计必须把“时段”当作原子单位。常见做法是新增一张预约时段表按“半小时”或“一小时”为粒度预生成可约时段。下面是核心表结构的参考写法CREATE TABLE ls_appointment_schedule ( id int(11) unsigned NOT NULL AUTO_INCREMENT, server_user_id int(11) NOT NULL COMMENT 服务人ID, date date NOT NULL COMMENT 服务日期, start_time time NOT NULL COMMENT 开始时间, end_time time NOT NULL COMMENT 结束时间, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0空闲 1锁定 2已完成, order_id int(11) DEFAULT NULL COMMENT 占用订单ID, PRIMARY KEY (id), KEY idx_server_date (server_user_id, date, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段 SQL 的关键在于联合索引idx_server_date。每次客户选中一个时段系统先select ... where server_user_id? and date? and start_time? for update锁行再更新状态。注意for update必须放在数据库事务内执行否则锁不住并发请求高峰期两个订单同时抢到同一时段就是必然翻车。实际开发中更合理的做法是把时段锁定设计成状态机客户下单但未支付时时段标记为“锁定”支付成功后变为“已占用”超过 15 分钟未支付自动释放回“空闲”。这个释放逻辑用 ThinkPHP 的定时任务实现后续避坑章节会专门讲。4.2 派单逻辑距离、评分、接单状态怎么组合出分配队列派单是家政系统二开里争议最大的模块。市面上的开源版一般提供两种模式自动派单和抢单池。我建议首次上线只用“抢单池”因为自动派单算法需要大量历史数据校准没有数据就跑自动派单结果就是客户投诉“怎么给我派了个 2 小时路程外的师傅”。抢单池的查询伪代码public function getPoolOrders(int $serverUserId) { $server Db::name(server_user)-where(id, $serverUserId)-find(); $pool Db::name(order) -where(order_status, 10) // 待接单状态 -where(service_category_id, $server[category_id]) -where(appointment_date, , date(Y-m-d)) -where(appointment_date, , date(Y-m-d, strtotime(3 days))) -order(create_time desc) -select() -toArray(); // 按服务人当前位置距离排序 foreach ($pool as $item) { $item[distance] $this-calcDistance( $server[latitude], $server[longitude], $item[latitude], $item[longitude] ); } usort($pool, function ($a, $b) { return $a[distance] $b[distance]; }); return $pool; }这段逻辑里有两个值得注意的参数order_status 10是家政订单“待接单”的自定义状态码你开发时要在状态机常量文件里明确注释否则三个月后没人记得 10 代表什么3 days是“可预约窗口”家政行业一般只允许约未来 3~7 天的服务窗口太长会导致服务人排期被占满但客户实际履约率很低。calcDistance用球面距离公式足够不用接高德或百度的地图 API。家政派单的距离精度要求是“公里级”两种计算方式结果差不了 100 米但高德 API 每天调用次数限制和费用都是实打实的成本。自动派单模式建议至少满足三个条件再启用服务人数量超过 50 人有超过 30 天的订单履约数据客户取消率低于 15%。否则就用抢单池 人工干预后台管理员手动改派逻辑一定要保留。4.3 支付与售后退款、优惠券核销、服务完成后的评价闭环支付这块 likeshop 商城原生逻辑可以直接复用但“服务完成”的触发条件必须改。商城订单是发货后自动完成家政订单是服务人点击“开始服务”和“结束服务”两个动作才推进订单状态。这中间涉及服务时长校验如果订单是 3 小时保洁服务人 10 分钟就点了结束系统应弹确认框并通知运营人工复核。优惠券核销要特别注意使用条件限制。家政服务的客单价通常高于商城单品满减券很容易被凑单刷走。建议在营销配置里限定“家政专用券”仅限order_type service的订单使用并且一个订单最多用一张。开源版后台默认是商城逻辑你需要在优惠券表加一个scene字段区分使用场景。售后流程的服务人扣款逻辑是这个行业的敏感点。客户投诉服务不满意申请退款平台审核通过后系统要把退款金额按比例从服务人结算款中扣除。平均扣除比例可以设为订单金额的 50%但必须在服务人入驻协议里明确写清楚否则劳动仲裁找上门时后台数据再准确也没用。退款动作通过微信支付退款接口完成likeshop 自带的PayService-refund()可以扩展在回调里追加一条ls_server_settlement扣款记录即可。5. 常见问题与避坑记录从部署到上线的 5 个典型踩坑点5.1 PHP 版本不匹配导致安装向导白屏现象访问/install.php页面完全空白浏览器控制台只有 500 状态码错误日志没有输出。原因likeshop 源码里某些函数依赖 PHP 8.0 才有的特性但你环境是 PHP 7.4且display_errors未开启错误被藏住了。解决先改php.ini里display_errors On和error_reporting E_ALL再访问一次看具体报错。如果是版本问题最简单的方式是重装一套 PHP 8.0 环境用宝塔面板的话可以直接切换版本。不建议靠改源码兼容 7.4后面 Composer 依赖也会报错治标不治本。5.2 小程序端“请求域名不带端口也连不上”的玄学现象本地开发时后端跑在http://127.0.0.1:8080H5 端访问正常但编译到微信开发者工具后所有请求全部失败。原因uni-app 编译到小程序后baseURL里的localhost或127.0.0.1会被小程序的合法域名校验拦截。开发者工具有时能容忍真机预览一律拦截。解决开发阶段在微信开发者工具里勾选“不校验合法域名”真机测试必须使用 HTTPS 正式域名。后台“小程序设置”里的 request 合法域名也要同步加上缺一不可。这个问题整整卡了我一个下午最后发现是域名校验而不是代码问题。5.3 定时任务没配订单状态永远停在“待服务”现象客户下单支付成功但到了预约时间服务人未操作开始服务订单既不自动取消也不允许改派一直停在“待服务”状态。原因家政订单的状态推进依赖两个东西——服务人主动操作和后台定时任务兜底。开源版默认不会把定时任务注册到系统 crontab只提供了脚本。解决在系统 crontab 里加入一条*/5 * * * * php /www/wwwroot/server/think cron:handle /www/wwwroot/server/runtime/cron.log 21这条命令每 5 分钟执行一次 ThinkPHP 的命令行任务队列。第一次配置完后手动运行一次php think cron:handle再配合测试订单验证状态是否推进。注意runtime/cron.log所在目录必须有写权限。5.4 家政服务类目下微信支付回调地址的配置差异现象支付成功但订单未标记已支付客户付款了却显示待支付。原因家政服务类目在小程序微信支付里属于“本地生活”类目部分类目要求支付回调地址必须与小程序后台配置的服务器域名完全一致且不能携带路径参数。解决likeshop 后台支付配置里有个“回调地址”字段改成https://your-domain/index.php?s/api/pay/callback并且微信商户平台里的支付授权目录也同步设置注意末尾斜杠的差异。很多支付回调问题最后都出在这个字符串的头尾匹配上。5.5 二开改数据库导致后台菜单权限失效现象往数据库里新增了一张表格后台管理员登录后菜单栏直接消失了只有超级管理员能进。原因likeshop 后台菜单是存放在ls_menu表里的删除或改动菜单记录时关联的ls_role_menu权限映射没有同步更新。解决不要用delete from清理菜单使用后台菜单管理界面操作系统会自动维护关系表。如果已经出了权限问题SQL 修复思路如下-- 先查所有管理员角色ID SELECT id FROM ls_role; -- 把新菜单ID授权给所有角色menu_id取自上一次插入的自增值 INSERT INTO ls_role_menu (role_id, menu_id) SELECT id, 10086 FROM ls_role;把10086替换成你新增菜单的真实 ID。这条 SQL 一劳永逸避免菜单权限丢但如果你大面积调整菜单结构还是建议直接操作数据库前先导出ls_menu和ls_role_menu两张表做备份。6. 上线前做一次完整验证从数据回滚到发版清单家政系统上线前别急着把小程序提交审核先用命令行把订单状态机完整走一遍。我会在本地模拟一个完整生命周期下单 → 支付回调 → 派单 → 服务人开始服务 → 结束服务 → 自动结算 → 客户评价。这个流程在当前系统里最常出问题的是支付回调步骤必须验到“支付已确认”状态才算出关。我的发版检查清单是这几条定时任务已在 crontab 注册、前台接口全部走 HTTPS、退款证书路径在生产环境可读、后台管理员权限非超管账号可以正常访问新增菜单、数据库已备份且确认可恢复。最后一条永远最容易被忽略但一旦上线当天出事故备份就是唯一后悔药。维护阶段最值得投入的是“异常订单预警”脚本每 10 分钟扫描一次状态异常的订单并推送通知到运营群比如支付成功超过 6 小时未派单、服务人迟到超过 30 分钟、售后申请超过 24 小时未处理。这些规则比任何智能算法都管用因为它直接锁住行业里真正伤害口碑的指标。我会在每次改完派单逻辑后回放一遍订单历史数据做回归测试——不是验证新单正常而是确认旧数据处理结果没有异常。这套习惯帮我避免了好几次因为改动而影响线上数据的生产事故。希望这些基于真实踩坑的经验能帮到你在 likeshop 上门家政系统这条路上少走几步弯路。本文还有配套的精品资源点击获取