尧图网页设计 
简介likeshop家政系统开源版是一套基于likeadmin-php、ThinkPHP框架的上门预约系统面向家政服务商、本地生活平台及独立开发者用于搭建含线上下单、智能派单、支付核销等完整业务闭环的O2O服务平台。压缩包共2000个文件以Vue/JS/CSS前端代码、Java文件、JSON配置、Markdown说明及SQL数据库脚本为主要类型整体86.93MB含全部前后台无加密源码和搭建教程便于自行修改部署。功能覆盖地图定位、在线预约、系统派单/后台派单、微信支付宝支付、核销订单支持小程序与H5多端商品服务可设多规格预约时间段可自定义师傅端支持保证金与每日限单还能限定指定城市接单适合本地化运营。存储支持本地与OSS短信对接阿里云和腾讯云地图对接腾讯地图并附有详细搭建教程及关闭调试图标说明。目前已有114人学习浏览适合熟悉ThinkPHP和uniapp的开发者快速部署二次开发打造可商用的家政服务系统。1. 这套 likeshop 家政系统源码值不值得亲自部署一遍家政平台的源码市面上不缺缺的是拿到手能直接进入业务逻辑的完整项目。likeshop 家政系统源码就是这种类型——它不是一个只有前端页面的演示模板也不是一个后台里堆满假数据的分析原型而是一套具备管理后台、用户端、服务人员端三端入口的家政预约平台骨架。技术栈采用 ThinkPHP 6 做后端接口前端基于 uni-app 实现多端覆盖核心覆盖服务分类、预约下单、支付、派单、结算、评价这些家政业务的关键链路。如果你有 PHP 和 Vue 基础想基于开源项目快速搭一个本地生活类垂直平台或者拿来做课程设计和毕业设计这套源码比从零搭建省的事不是一星半点但如果你指望下载后直接上生产可能会被部署环境和二开成本劝退。这套资源真正的价值在动手部署完、把它拆开看过之后才会体现出来。2. 读懂技术栈与目录结构先看这三处再动手2.1 为什么是 ThinkPHP 6 uni-app选型背后的实际考量很多家政系统其实是普通商城系统改的把服务当商品卖下单支付流程走完就结束了。但家政业务有上门时间、服务时长、服务人员派单、平台抽成结算这些动作跟电商的“加购物车—付款—发货”完全不是一回事。likeshop 家政系统选 ThinkPHP 6 做后端核心原因是这套框架在国内开源项目里的生态太成熟了文档、社区问答、招聘要求到处都是二开过程中遇到问题几乎都能搜到现成的解决方案。TP6 的中间件、依赖注入、注解路由这些机制对家政这种多端接口项目来说也够用不需要引入更重的框架把复杂度堆高。前端用 uni-app 的原因更直接家政平台的用户端至少要做微信小程序和 H5 两个出口服务人员端还可能要跑在 App 里uni-app 一套代码编译到多个端比 Android、iOS、小程序各写一套要划算得多。这套源码里用户端和服务人员端大概率就是两个 uni-app 工程但共用了同一套接口协议所以改业务逻辑时大部分场景只用动 server 端接口前端只是重新编译打包的事。这一点对刚接触项目的开发者来说非常重要——不要一上来就改前端先看后端接口能不能满足需求。2.2 根目录结构server 端与前端代码怎么区分下载解压后不要急着找 index.php先花五分钟把目录结构理清楚。常见的 likeshop 家政项目会分几个顶层目录server 是后端口里面同时包含了管理后台的前端页面、接口控制器、业务逻辑、数据库初始化脚本另一个目录放 uni-app 工程也就是用户端和服务人员端的小程序/App 代码如果打包时带了 PC 端还会有一个后台管理的独立前端目录。我之前拆过一套类似的源码刚拿到手时被 server 目录误导了以为整个后端只有一个入口后来才发现后台管理页面也在 server 里通过 public 目录下的静态资源入口访问。这里整理一份比较典型的目录对照表你可以对照着手里的源码看目录常见作用部署后访问方式server/public后端唯一入口Nginx root 要指到这里域名直接访问server/application控制器、模型、业务逻辑动态接口不能直接暴露server/routeTP6 路由定义决定接口 URL 结构server/config数据库、缓存、日志等配置二开主要改这里server/sql 或 database初始化 SQL 脚本部署时导入uni-app 工程目录用户端和服务人员端代码需编译后发布小程序或 H5这个表的意义在于你要知道哪些目录能直接改、哪些目录改完必须重新编译、哪些目录只做配置不需要动代码。比如数据库连接写在 .env 文件里而不在 config 目录里写死这在 TP6 项目里是标准做法如果你改完 config/database.php 发现不生效就要去检查根目录的 .env 是不是还在被读取。2.3 三端入口与角色权限后台、用户端、服务人员端各自管什么家政平台和其他本地生活平台最大的区别是多了一个服务人员端。用户端选服务、下单、支付、评价管理后台做服务项目录入、价格设置、派单、结算审核服务人员端接收订单、上门服务、确认完成、申请提现。三个角色围绕同一个订单流转这个闭环在源码里对应着多个控制器和状态字段。我第一次看这套源码时把用户端和服务人员端搞混了以为都是同一个 uni-app 工程。结果发现服务人员端的接口路径和用户端完全分开权限校验方式也不同。用户端用的是用户登录态服务人员端用的是员工登录态管理后台又是管理员会话三套认证体系互相独立。所以二开的时候先搞清楚你要改的是哪个角色的接口再去对应控制器里找代码不然容易改错了地方还找不到问题。3. 本地部署与运行从 PHP 环境到后台登录全流程3.1 环境要求与 PHP 扩展检查likeshop 家政系统基于 ThinkPHP 6PHP 版本至少要 7.4 以上我建议直接用 PHP 8.0 或 8.1跑起来更稳。但要注意PHP 8 对旧代码的兼容性比 7.4 严格如果你发现某些接口在 PHP 8 下报 undefined index 之类的错误可能是源码里有些写法比较老这时候退回 PHP 7.4 反而省事。数据库用 MySQL 5.7 或 8.0 都行服务器用 Nginx 比 Apache 省配置伪静态规则也简单。在导入数据库之前先检查 PHP 扩展这一步能省下后面至少一个小时的排错时间。打开终端执行下面这段检查命令php -v php -m | grep -E pdo|mysql|redis|curl|fileinfo|openssl执行完你会看到一行扩展列表。重点关注 pdo_mysql它没了会导致数据库连接直接报错fileinfo 缺失会在后台上传图片或文件时翻车curl 扩展缺了支付接口和第三方推送全都通不了openssl 是 TP6 生成 token 和验签的基础依赖。如果检查发现缺哪一个在宝塔或 1Panel 里重新安装扩展即可不要在代码层面硬找原因因为服务启动时加载不到扩展代码写得再对也没用。3.2 数据库导入与 .env 环境配置环境检查通过后先把数据库建好。源码包里一般会有 SQL 初始化脚本可能在 server/sql 目录下也可能在根目录的 database 文件夹里。找到文件后按下面这个流程创建数据库并导入mysql -uroot -p \ -e CREATE DATABASE IF NOT EXISTS likeshop_home DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p likeshop_home /path/to/install.sql第一段命令创建了一个名为 likeshop_home 的数据库字符集用了 utf8mb4这是必须的因为家政服务项目里会有用户填写的地址信息可能包含特殊符号utf8mb4 能覆盖所有字符。第二段命令把 SQL 脚本导入到这个空库里注意一定要指定数据库名否则数据会进到默认库里后面连接不上又得排查半天。导入完成后进入 server 目录复制一份 .env.example 到 .env然后修改数据库连接。注意 .env 文件以点号开头在 Linux 终端里是隐藏文件用 ls -a 才能看到。配置代码长这样APP_DEBUG true APP_ENV local DATABASE_HOST 127.0.0.1 DATABASE_PORT 3306 DATABASE_NAME likeshop_home DATABASE_USER root DATABASE_PASSWORD your_password DATABASE_PREFIX ls_DATABASE_PREFIX 是表前缀默认是 ls_对应 SQL 里的 ls_order、ls_user 这类表名。这个前缀不要随意改除非你连数据库里的表名一起改了否则后台登录会直接报“表不存在”。很多新手在这里翻车改了前缀然后发现后台所有列表都变成空白还不明白是自己动了不该动的配置。APP_DEBUG 在本地调试时保留 true可以看到详细的报错堆栈部署到线上再改成 false避免暴露文件路径和 SQL 语句。3.3 Nginx 伪静态与后台访问数据库配置完成之后设置 Nginx 站点。TP6 的所有请求都走 index.php 入口所以必须配置伪静态否则访问任何二级路由都会 404。下面是 Nginx 站点配置里最关键的两个 location 块server { listen 80; server_name your-domain.com; root /www/wwwroot/likeshop_home/server/public; client_max_body_size 20m; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { fastcgi_pass unix:/tmp/php-cgi-74.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }root 必须指向 server/public不是 server 根目录这是 TP6 项目的安全红线。指向根目录时用户可以通过 URL 直接访问 application 里的源码文件这是很严重的代码泄露。fastcgi_pass 要根据你实际的 PHP-FPM 配置来填不同环境可能是 unix socket也可能是一个 127.0.0.1:9000 的端口号。location / 里的 rewrite 规则负责把所有不存在的路径转给 index.php 解析这是 ThinkPHP 路由生效的前提。配置完成后重启 Nginx直接访问你的域名。如果看到管理后台登录页面说明部署已经走通了一大半。后台管理路径常见是 /admin具体的初始管理员账号密码一般记录在 SQL 脚本末尾或源码内的 README 文件里。找到后第一件事是登录进去把默认密码改掉这一步不然后续数据安全性没法保证。4. 家政业务核心模块拆解服务分类、下单、派单与结算4.1 服务分类与 SKU家政服务的商品化设计家政服务不是标准商品卖的不是一个实物而是一段时间和服务人员的技能。比如“日常保洁”是一个服务项目“日常保洁 2 小时”和“日常保洁 4 小时”是两个不同规格价格和服务时长都不同。likeshop 家政系统在商品化模型上采用了服务项目加规格的方式类似电商里的 SPU 和 SKU 概念但库存字段不是普通商品的库存数量而是可预约时段。在这个模型下服务项目表里存的是服务名称、封面图、详情介绍、适用场景规格表里存的是时长、价格、人员数量要求。同一个服务项目可以挂多个规格前端展示时用户选择不同时长价格跟着变。二开时最容易踩的坑是直接改规格表的价格字段但订单表里同时存了快照价格旧订单显示的还是改之前的价格。家政行业经常调价如果快照机制没理解透就会遇到“后台改了价历史订单金额全变了”的问题。新手最容易困惑的是为什么需要规格表而不是直接在服务项目表里加一个价格字段。原因很简单一个保洁服务可能同时有包月、单次、深度保洁三种卖法每种价格不一样如果只用一个价格字段每次调整都要改服务主表不仅逻辑混乱历史订单也没法追溯。4.2 预约下单与订单状态机从待支付到已完成家政订单和电商订单的核心区别是多了一个“时间”维度。用户下单时必须填预计上门时间服务人员也要按这个时间安排路线。订单状态字段 design 通常是待支付 → 待派单 → 已派单 → 进行中 → 待验收 → 已完成中间还可能穿插取消、退款、售后等分支状态。下面是订单创建阶段一段简化后的后端逻辑路径以实际源码为准核心在服务校验这一步// application/admin/controller/Order.php路径以实际源码为准 public function create() { $serviceId $this-request-post(service_id); $specId $this-request-post(spec_id); $startTime $this-request-post(start_time); $spec ServiceSpec::find($specId); if (!$spec || $spec[service_id] ! $serviceId) { return json([code 0, msg 服务规格不存在]); } // 价格从服务端读取不能用前端传值 $price $spec[price]; if ($this-isTimeSlotOccupied($specId, $startTime)) { return json([code 0, msg 该时段已被预约]); } // 创建订单主记录状态为待支付 $order Order::create([ order_sn $this-makeOrderSn(), service_id $serviceId, spec_id $specId, price $price, start_time $startTime, status OrderStatus::WAIT_PAY, ]); return json([code 1, data $order]); }这段代码看起来简单实际上藏了三个重要设计第一规格查询后必须校验 service_id 是否匹配防止前端传一个别的服务项目的规格 ID 来绕过校验第二价格字段一定从服务端读取不能接收前端传过来的 price 参数否则用户可以自己改价格下单第三下单时就要检查时段占用这是家政系统特有的并发控制点。isTimeSlotOccupied 方法在二开时值得重点看如果它只是简单查了订单表而没加锁高并发场景下会出现两个订单重叠同一时段。订单状态机在前端表现成用户看到的“订单进度条”在后端则是一连串状态字段更新。每次状态变更都会记录操作日志所以二开时不要直接改订单表的 status 字段要走系统里的状态流转方法否则日志、通知、结算逻辑都会脱节。4.3 派单、接单与结算服务人员端的业务闭环订单创建后进入待派单状态管理员可以在后台手动指派服务人员也可以设置成抢单模式让服务人员端自己接。likeshop 家政系统源码里通常同时支持两种模式切换点在后台的订单配置里。管理员派单的操作核心是选择一个空闲的服务人员系统会校验这个人在上门时间点是否已有其他订单同时短信或模板消息通知服务人员。抢单模式则更像外卖平台的逻辑订单发布后所有符合区域条件的服务人员都能看到先到先得。这两种模式各有优劣手动派单适合高端家政服务质量可控抢单模式在订单高峰期能快速消化订单量但容易抢到不合适的人。结算模块是最容易被忽略但又最值得研究的业务点。服务人员完成订单后系统会根据平台设置的抽成比例把实付金额拆解成平台收入和人员收入生成结算单。后续服务人员申请提现管理后台再审核打款。这个流程涉及的数据字段包括订单实付金额、平台抽佣比例、服务人员分销比例、提现状态等。二开时如果要调整抽佣比例通常在后端配置里改一个参数即可不用动订单表里的快照数据。但注意比例修改只影响新订单历史订单的结算金额不会跟着变这是业务上的预期行为。派单、接单、结算三个环节最怕的是状态不同步。比如管理员派了单但服务人员长时间不确认订单就一直卡在已派单状态。这种问题一般通过定时任务兜底超过一定时间未确认的订单自动回落为待派单。后面避坑章节会单独讲定时任务配置。5. 避坑指南likeshop 家政部署与二开常见问题5.1 登录接口 500不是账号密码错误本地部署完成后打开后台登录页输入账号密码点击登录接口直接返回 500而不是“密码错误”的提示。这个现象最迷惑人因为它看起来像是业务代码有问题实际上绝大多数情况是环境问题。我当时排查这个问题的过程是先看 Nginx 错误日志发现是 PHP 报错但页面被 APP_DEBUG 吞掉了部分信息再定位到 User 模型发现登录时调用了缓存组件读写用户 token而本地环境根本没有装 Redis 扩展。原因就是 .env 里缓存驱动配置成了 redis但 PHP 缺少 redis 扩展导致登录逻辑走到 token 生成步骤就崩了。解决办法有两种要么安装 redis 扩展并启动 Redis 服务要么把 .env 的 CACHE_DRIVER 改成 file用文件缓存撑过本地调试阶段。建议本地开发时统一用 file 缓存线上再切 redis这样省去本地还要维护一个 Redis 服务的成本。改完 .env 后记得重启 PHP-FPMTP6 的配置读取是有缓存的不重启不生效。5.2 小程序请求不通不是代码问题是域名白名单用户端 uni-app 工程编译到微信开发者工具后请求接口一直报“url 不在合法域名列表中”。很多人以为是源码问题去改小程序代码折腾半天没效果。原因不在源码而在微信小程序平台的规定运行在小程序里的网络请求域名必须在小程序后台配置成合法 request 合法域名并且必须是 HTTPS。likeshop 源码默认接口地址配的是 http 格式或者配了一个示例域名到了你的环境当然不通。解决路径是三步先把服务端域名配上 SSL 证书确保接口能用 https 访问再登录微信小程序后台把域名加进 request 合法域名列表最后打开 uni-app 工程里封装请求的公共文件把 baseURL 改成你的线上域名重新编译。开发调试阶段可以在微信开发者工具里勾选“不校验合法域名”但真机预览必须走正规配置。5.3 支付回调一直失败签名校验和回调地址两个点家政系统接入微信支付后订单支付成功了但订单状态一直不变成已支付。这个问题的根源几乎都在支付回调环节。微信支付在用户付完钱之后会向配置的回调地址发送支付结果通知系统处理完通知后再把订单状态更新为已支付。回调失败常见两个点第一回调地址在商户平台配置的和你源码里路由不一致微信通知打到了错误路径上直接 404 或 500第二源码里的支付签名校验逻辑依赖的密钥没有配置正确导致收到通知后验签不通过系统拒绝更新订单状态。排查时先在商户平台看支付通知记录确认微信到底有没有把请求打到你的服务器再查后端请求日志看回调接口有没有收到数据、验签报了什么错。如果验签失败重点检查 v3 密钥或者 v2 API 密钥是否与商户平台配置的一致密钥里不能有多余的空格或换行符。5.4 派单后服务人员端看不到新订单先查状态再查推送管理员在后台给服务人员派了单但服务人员手机端刷新半天还是看不到这个订单。这种情况一般不是接口挂掉了而是状态流转条件不满足。订单停留在待派单状态时服务人员端的订单列表默认只展示已派单及以后的订单所以如果派单动作没有把状态从待派单推进到已派单列表里自然什么都看不到。派单失败的原因常见有两种一是该服务人员在对应时段已经存在订单系统做了冲突校验二是派单操作发出的通知依赖定时任务或者队列本地环境根本没启动队列消费者通知没送出去但订单状态其实已经变了。排查顺序应该是先看订单表里的 status 字段确认状态是否推进再查服务人员端的订单列表接口确认返回内容最后检查消息通知配置。很多人一上来就怀疑 websocket 没连上其实订单数据可能已经落库了只是没刷新出来。6. 二开前先落地这三件事定时任务、支付回调与消息推送这章是给那些已经能跑通系统、准备开始改业务的人准备的。如果你只搭完演示就收工可以不用管这里但如果你想加“用户下单 30 分钟未支付自动关闭”“服务人员超时未接单自动转派”这类业务规则定时任务是绕不开的基础设施。TP6 自带命令行指令机制家政系统里一般会把超时关单、自动确认收货这类逻辑写成自定义指令。部署时先在 server 目录下的命令行入口注册好命令再在系统 crontab 里加一条计划任务* * * * * cd /www/wwwroot/likeshop_home/server php think order:auto-cancel /var/log/likeshop_cancel.log 21这条 crontab 每分钟执行一次 order:auto-cancel 命令。注意一定要写绝对路径 cd 到 server 目录否则相对路径找不到 think 文件和 .env 配置日志输出重定向到固定文件排查时直接看这个文件就能确认任务有没有跑起来。调试阶段可以用 php think order:auto-cancel 手动执行不要等 cron 触发效率更高。支付回调验签是二开支付相关需求时的必查环节。不要自己重新实现一遍加解密逻辑直接用源码里封装好的支付服务类。但你要清楚验签的输入参数包括哪些回调参数全量字符串、平台密钥、签名类型三者必须一致才能通过。我在改一个支付分账功能时因为把回调参数按自己的习惯重新组装了一遍导致验签永远失败。从那以后我每次动这类代码都会在验签位置加一行日志把原始入参打出来对比省得在黑匣子里猜。消息推送在 likeshop 家政系统里承担的是“订单状态变了要主动告诉用户和服务人员”的任务。实现上一般走小程序订阅消息或短信通知。二开时最容易忽略的是模板 ID 的维护小程序后台改了模板源码里对应的模板 ID 没同步推送就会静默失败既不报错也不送达。建议在配置文件里集中管理所有模板 ID并标注每个模板对应的业务场景下次改起来不用全代码搜。三件事都落地后这套家政系统才算真正具备上线运营的基础条件。我接过不少套开源系统发现真正出问题的往往不是主流程而是这些边界动作没有兜底。从那以后我每次部署都会先把定时任务、支付回调、消息推送这三件事强制检查一遍再谈功能迭代——这些看不见的配置才是系统稳定运行的底气。希望帮到你。本文还有配套的精品资源点击获取 likeshop家政系统源码部署与二次开发实战解析
简介likeshop家政系统开源版是一套基于likeadmin-php、ThinkPHP框架的上门预约系统面向家政服务商、本地生活平台及独立开发者用于搭建含线上下单、智能派单、支付核销等完整业务闭环的O2O服务平台。压缩包共2000个文件以Vue/JS/CSS前端代码、Java文件、JSON配置、Markdown说明及SQL数据库脚本为主要类型整体86.93MB含全部前后台无加密源码和搭建教程便于自行修改部署。功能覆盖地图定位、在线预约、系统派单/后台派单、微信支付宝支付、核销订单支持小程序与H5多端商品服务可设多规格预约时间段可自定义师傅端支持保证金与每日限单还能限定指定城市接单适合本地化运营。存储支持本地与OSS短信对接阿里云和腾讯云地图对接腾讯地图并附有详细搭建教程及关闭调试图标说明。目前已有114人学习浏览适合熟悉ThinkPHP和uniapp的开发者快速部署二次开发打造可商用的家政服务系统。1. 这套 likeshop 家政系统源码值不值得亲自部署一遍家政平台的源码市面上不缺缺的是拿到手能直接进入业务逻辑的完整项目。likeshop 家政系统源码就是这种类型——它不是一个只有前端页面的演示模板也不是一个后台里堆满假数据的分析原型而是一套具备管理后台、用户端、服务人员端三端入口的家政预约平台骨架。技术栈采用 ThinkPHP 6 做后端接口前端基于 uni-app 实现多端覆盖核心覆盖服务分类、预约下单、支付、派单、结算、评价这些家政业务的关键链路。如果你有 PHP 和 Vue 基础想基于开源项目快速搭一个本地生活类垂直平台或者拿来做课程设计和毕业设计这套源码比从零搭建省的事不是一星半点但如果你指望下载后直接上生产可能会被部署环境和二开成本劝退。这套资源真正的价值在动手部署完、把它拆开看过之后才会体现出来。2. 读懂技术栈与目录结构先看这三处再动手2.1 为什么是 ThinkPHP 6 uni-app选型背后的实际考量很多家政系统其实是普通商城系统改的把服务当商品卖下单支付流程走完就结束了。但家政业务有上门时间、服务时长、服务人员派单、平台抽成结算这些动作跟电商的“加购物车—付款—发货”完全不是一回事。likeshop 家政系统选 ThinkPHP 6 做后端核心原因是这套框架在国内开源项目里的生态太成熟了文档、社区问答、招聘要求到处都是二开过程中遇到问题几乎都能搜到现成的解决方案。TP6 的中间件、依赖注入、注解路由这些机制对家政这种多端接口项目来说也够用不需要引入更重的框架把复杂度堆高。前端用 uni-app 的原因更直接家政平台的用户端至少要做微信小程序和 H5 两个出口服务人员端还可能要跑在 App 里uni-app 一套代码编译到多个端比 Android、iOS、小程序各写一套要划算得多。这套源码里用户端和服务人员端大概率就是两个 uni-app 工程但共用了同一套接口协议所以改业务逻辑时大部分场景只用动 server 端接口前端只是重新编译打包的事。这一点对刚接触项目的开发者来说非常重要——不要一上来就改前端先看后端接口能不能满足需求。2.2 根目录结构server 端与前端代码怎么区分下载解压后不要急着找 index.php先花五分钟把目录结构理清楚。常见的 likeshop 家政项目会分几个顶层目录server 是后端口里面同时包含了管理后台的前端页面、接口控制器、业务逻辑、数据库初始化脚本另一个目录放 uni-app 工程也就是用户端和服务人员端的小程序/App 代码如果打包时带了 PC 端还会有一个后台管理的独立前端目录。我之前拆过一套类似的源码刚拿到手时被 server 目录误导了以为整个后端只有一个入口后来才发现后台管理页面也在 server 里通过 public 目录下的静态资源入口访问。这里整理一份比较典型的目录对照表你可以对照着手里的源码看目录常见作用部署后访问方式server/public后端唯一入口Nginx root 要指到这里域名直接访问server/application控制器、模型、业务逻辑动态接口不能直接暴露server/routeTP6 路由定义决定接口 URL 结构server/config数据库、缓存、日志等配置二开主要改这里server/sql 或 database初始化 SQL 脚本部署时导入uni-app 工程目录用户端和服务人员端代码需编译后发布小程序或 H5这个表的意义在于你要知道哪些目录能直接改、哪些目录改完必须重新编译、哪些目录只做配置不需要动代码。比如数据库连接写在 .env 文件里而不在 config 目录里写死这在 TP6 项目里是标准做法如果你改完 config/database.php 发现不生效就要去检查根目录的 .env 是不是还在被读取。2.3 三端入口与角色权限后台、用户端、服务人员端各自管什么家政平台和其他本地生活平台最大的区别是多了一个服务人员端。用户端选服务、下单、支付、评价管理后台做服务项目录入、价格设置、派单、结算审核服务人员端接收订单、上门服务、确认完成、申请提现。三个角色围绕同一个订单流转这个闭环在源码里对应着多个控制器和状态字段。我第一次看这套源码时把用户端和服务人员端搞混了以为都是同一个 uni-app 工程。结果发现服务人员端的接口路径和用户端完全分开权限校验方式也不同。用户端用的是用户登录态服务人员端用的是员工登录态管理后台又是管理员会话三套认证体系互相独立。所以二开的时候先搞清楚你要改的是哪个角色的接口再去对应控制器里找代码不然容易改错了地方还找不到问题。3. 本地部署与运行从 PHP 环境到后台登录全流程3.1 环境要求与 PHP 扩展检查likeshop 家政系统基于 ThinkPHP 6PHP 版本至少要 7.4 以上我建议直接用 PHP 8.0 或 8.1跑起来更稳。但要注意PHP 8 对旧代码的兼容性比 7.4 严格如果你发现某些接口在 PHP 8 下报 undefined index 之类的错误可能是源码里有些写法比较老这时候退回 PHP 7.4 反而省事。数据库用 MySQL 5.7 或 8.0 都行服务器用 Nginx 比 Apache 省配置伪静态规则也简单。在导入数据库之前先检查 PHP 扩展这一步能省下后面至少一个小时的排错时间。打开终端执行下面这段检查命令php -v php -m | grep -E pdo|mysql|redis|curl|fileinfo|openssl执行完你会看到一行扩展列表。重点关注 pdo_mysql它没了会导致数据库连接直接报错fileinfo 缺失会在后台上传图片或文件时翻车curl 扩展缺了支付接口和第三方推送全都通不了openssl 是 TP6 生成 token 和验签的基础依赖。如果检查发现缺哪一个在宝塔或 1Panel 里重新安装扩展即可不要在代码层面硬找原因因为服务启动时加载不到扩展代码写得再对也没用。3.2 数据库导入与 .env 环境配置环境检查通过后先把数据库建好。源码包里一般会有 SQL 初始化脚本可能在 server/sql 目录下也可能在根目录的 database 文件夹里。找到文件后按下面这个流程创建数据库并导入mysql -uroot -p \ -e CREATE DATABASE IF NOT EXISTS likeshop_home DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p likeshop_home /path/to/install.sql第一段命令创建了一个名为 likeshop_home 的数据库字符集用了 utf8mb4这是必须的因为家政服务项目里会有用户填写的地址信息可能包含特殊符号utf8mb4 能覆盖所有字符。第二段命令把 SQL 脚本导入到这个空库里注意一定要指定数据库名否则数据会进到默认库里后面连接不上又得排查半天。导入完成后进入 server 目录复制一份 .env.example 到 .env然后修改数据库连接。注意 .env 文件以点号开头在 Linux 终端里是隐藏文件用 ls -a 才能看到。配置代码长这样APP_DEBUG true APP_ENV local DATABASE_HOST 127.0.0.1 DATABASE_PORT 3306 DATABASE_NAME likeshop_home DATABASE_USER root DATABASE_PASSWORD your_password DATABASE_PREFIX ls_DATABASE_PREFIX 是表前缀默认是 ls_对应 SQL 里的 ls_order、ls_user 这类表名。这个前缀不要随意改除非你连数据库里的表名一起改了否则后台登录会直接报“表不存在”。很多新手在这里翻车改了前缀然后发现后台所有列表都变成空白还不明白是自己动了不该动的配置。APP_DEBUG 在本地调试时保留 true可以看到详细的报错堆栈部署到线上再改成 false避免暴露文件路径和 SQL 语句。3.3 Nginx 伪静态与后台访问数据库配置完成之后设置 Nginx 站点。TP6 的所有请求都走 index.php 入口所以必须配置伪静态否则访问任何二级路由都会 404。下面是 Nginx 站点配置里最关键的两个 location 块server { listen 80; server_name your-domain.com; root /www/wwwroot/likeshop_home/server/public; client_max_body_size 20m; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { fastcgi_pass unix:/tmp/php-cgi-74.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }root 必须指向 server/public不是 server 根目录这是 TP6 项目的安全红线。指向根目录时用户可以通过 URL 直接访问 application 里的源码文件这是很严重的代码泄露。fastcgi_pass 要根据你实际的 PHP-FPM 配置来填不同环境可能是 unix socket也可能是一个 127.0.0.1:9000 的端口号。location / 里的 rewrite 规则负责把所有不存在的路径转给 index.php 解析这是 ThinkPHP 路由生效的前提。配置完成后重启 Nginx直接访问你的域名。如果看到管理后台登录页面说明部署已经走通了一大半。后台管理路径常见是 /admin具体的初始管理员账号密码一般记录在 SQL 脚本末尾或源码内的 README 文件里。找到后第一件事是登录进去把默认密码改掉这一步不然后续数据安全性没法保证。4. 家政业务核心模块拆解服务分类、下单、派单与结算4.1 服务分类与 SKU家政服务的商品化设计家政服务不是标准商品卖的不是一个实物而是一段时间和服务人员的技能。比如“日常保洁”是一个服务项目“日常保洁 2 小时”和“日常保洁 4 小时”是两个不同规格价格和服务时长都不同。likeshop 家政系统在商品化模型上采用了服务项目加规格的方式类似电商里的 SPU 和 SKU 概念但库存字段不是普通商品的库存数量而是可预约时段。在这个模型下服务项目表里存的是服务名称、封面图、详情介绍、适用场景规格表里存的是时长、价格、人员数量要求。同一个服务项目可以挂多个规格前端展示时用户选择不同时长价格跟着变。二开时最容易踩的坑是直接改规格表的价格字段但订单表里同时存了快照价格旧订单显示的还是改之前的价格。家政行业经常调价如果快照机制没理解透就会遇到“后台改了价历史订单金额全变了”的问题。新手最容易困惑的是为什么需要规格表而不是直接在服务项目表里加一个价格字段。原因很简单一个保洁服务可能同时有包月、单次、深度保洁三种卖法每种价格不一样如果只用一个价格字段每次调整都要改服务主表不仅逻辑混乱历史订单也没法追溯。4.2 预约下单与订单状态机从待支付到已完成家政订单和电商订单的核心区别是多了一个“时间”维度。用户下单时必须填预计上门时间服务人员也要按这个时间安排路线。订单状态字段 design 通常是待支付 → 待派单 → 已派单 → 进行中 → 待验收 → 已完成中间还可能穿插取消、退款、售后等分支状态。下面是订单创建阶段一段简化后的后端逻辑路径以实际源码为准核心在服务校验这一步// application/admin/controller/Order.php路径以实际源码为准 public function create() { $serviceId $this-request-post(service_id); $specId $this-request-post(spec_id); $startTime $this-request-post(start_time); $spec ServiceSpec::find($specId); if (!$spec || $spec[service_id] ! $serviceId) { return json([code 0, msg 服务规格不存在]); } // 价格从服务端读取不能用前端传值 $price $spec[price]; if ($this-isTimeSlotOccupied($specId, $startTime)) { return json([code 0, msg 该时段已被预约]); } // 创建订单主记录状态为待支付 $order Order::create([ order_sn $this-makeOrderSn(), service_id $serviceId, spec_id $specId, price $price, start_time $startTime, status OrderStatus::WAIT_PAY, ]); return json([code 1, data $order]); }这段代码看起来简单实际上藏了三个重要设计第一规格查询后必须校验 service_id 是否匹配防止前端传一个别的服务项目的规格 ID 来绕过校验第二价格字段一定从服务端读取不能接收前端传过来的 price 参数否则用户可以自己改价格下单第三下单时就要检查时段占用这是家政系统特有的并发控制点。isTimeSlotOccupied 方法在二开时值得重点看如果它只是简单查了订单表而没加锁高并发场景下会出现两个订单重叠同一时段。订单状态机在前端表现成用户看到的“订单进度条”在后端则是一连串状态字段更新。每次状态变更都会记录操作日志所以二开时不要直接改订单表的 status 字段要走系统里的状态流转方法否则日志、通知、结算逻辑都会脱节。4.3 派单、接单与结算服务人员端的业务闭环订单创建后进入待派单状态管理员可以在后台手动指派服务人员也可以设置成抢单模式让服务人员端自己接。likeshop 家政系统源码里通常同时支持两种模式切换点在后台的订单配置里。管理员派单的操作核心是选择一个空闲的服务人员系统会校验这个人在上门时间点是否已有其他订单同时短信或模板消息通知服务人员。抢单模式则更像外卖平台的逻辑订单发布后所有符合区域条件的服务人员都能看到先到先得。这两种模式各有优劣手动派单适合高端家政服务质量可控抢单模式在订单高峰期能快速消化订单量但容易抢到不合适的人。结算模块是最容易被忽略但又最值得研究的业务点。服务人员完成订单后系统会根据平台设置的抽成比例把实付金额拆解成平台收入和人员收入生成结算单。后续服务人员申请提现管理后台再审核打款。这个流程涉及的数据字段包括订单实付金额、平台抽佣比例、服务人员分销比例、提现状态等。二开时如果要调整抽佣比例通常在后端配置里改一个参数即可不用动订单表里的快照数据。但注意比例修改只影响新订单历史订单的结算金额不会跟着变这是业务上的预期行为。派单、接单、结算三个环节最怕的是状态不同步。比如管理员派了单但服务人员长时间不确认订单就一直卡在已派单状态。这种问题一般通过定时任务兜底超过一定时间未确认的订单自动回落为待派单。后面避坑章节会单独讲定时任务配置。5. 避坑指南likeshop 家政部署与二开常见问题5.1 登录接口 500不是账号密码错误本地部署完成后打开后台登录页输入账号密码点击登录接口直接返回 500而不是“密码错误”的提示。这个现象最迷惑人因为它看起来像是业务代码有问题实际上绝大多数情况是环境问题。我当时排查这个问题的过程是先看 Nginx 错误日志发现是 PHP 报错但页面被 APP_DEBUG 吞掉了部分信息再定位到 User 模型发现登录时调用了缓存组件读写用户 token而本地环境根本没有装 Redis 扩展。原因就是 .env 里缓存驱动配置成了 redis但 PHP 缺少 redis 扩展导致登录逻辑走到 token 生成步骤就崩了。解决办法有两种要么安装 redis 扩展并启动 Redis 服务要么把 .env 的 CACHE_DRIVER 改成 file用文件缓存撑过本地调试阶段。建议本地开发时统一用 file 缓存线上再切 redis这样省去本地还要维护一个 Redis 服务的成本。改完 .env 后记得重启 PHP-FPMTP6 的配置读取是有缓存的不重启不生效。5.2 小程序请求不通不是代码问题是域名白名单用户端 uni-app 工程编译到微信开发者工具后请求接口一直报“url 不在合法域名列表中”。很多人以为是源码问题去改小程序代码折腾半天没效果。原因不在源码而在微信小程序平台的规定运行在小程序里的网络请求域名必须在小程序后台配置成合法 request 合法域名并且必须是 HTTPS。likeshop 源码默认接口地址配的是 http 格式或者配了一个示例域名到了你的环境当然不通。解决路径是三步先把服务端域名配上 SSL 证书确保接口能用 https 访问再登录微信小程序后台把域名加进 request 合法域名列表最后打开 uni-app 工程里封装请求的公共文件把 baseURL 改成你的线上域名重新编译。开发调试阶段可以在微信开发者工具里勾选“不校验合法域名”但真机预览必须走正规配置。5.3 支付回调一直失败签名校验和回调地址两个点家政系统接入微信支付后订单支付成功了但订单状态一直不变成已支付。这个问题的根源几乎都在支付回调环节。微信支付在用户付完钱之后会向配置的回调地址发送支付结果通知系统处理完通知后再把订单状态更新为已支付。回调失败常见两个点第一回调地址在商户平台配置的和你源码里路由不一致微信通知打到了错误路径上直接 404 或 500第二源码里的支付签名校验逻辑依赖的密钥没有配置正确导致收到通知后验签不通过系统拒绝更新订单状态。排查时先在商户平台看支付通知记录确认微信到底有没有把请求打到你的服务器再查后端请求日志看回调接口有没有收到数据、验签报了什么错。如果验签失败重点检查 v3 密钥或者 v2 API 密钥是否与商户平台配置的一致密钥里不能有多余的空格或换行符。5.4 派单后服务人员端看不到新订单先查状态再查推送管理员在后台给服务人员派了单但服务人员手机端刷新半天还是看不到这个订单。这种情况一般不是接口挂掉了而是状态流转条件不满足。订单停留在待派单状态时服务人员端的订单列表默认只展示已派单及以后的订单所以如果派单动作没有把状态从待派单推进到已派单列表里自然什么都看不到。派单失败的原因常见有两种一是该服务人员在对应时段已经存在订单系统做了冲突校验二是派单操作发出的通知依赖定时任务或者队列本地环境根本没启动队列消费者通知没送出去但订单状态其实已经变了。排查顺序应该是先看订单表里的 status 字段确认状态是否推进再查服务人员端的订单列表接口确认返回内容最后检查消息通知配置。很多人一上来就怀疑 websocket 没连上其实订单数据可能已经落库了只是没刷新出来。6. 二开前先落地这三件事定时任务、支付回调与消息推送这章是给那些已经能跑通系统、准备开始改业务的人准备的。如果你只搭完演示就收工可以不用管这里但如果你想加“用户下单 30 分钟未支付自动关闭”“服务人员超时未接单自动转派”这类业务规则定时任务是绕不开的基础设施。TP6 自带命令行指令机制家政系统里一般会把超时关单、自动确认收货这类逻辑写成自定义指令。部署时先在 server 目录下的命令行入口注册好命令再在系统 crontab 里加一条计划任务* * * * * cd /www/wwwroot/likeshop_home/server php think order:auto-cancel /var/log/likeshop_cancel.log 21这条 crontab 每分钟执行一次 order:auto-cancel 命令。注意一定要写绝对路径 cd 到 server 目录否则相对路径找不到 think 文件和 .env 配置日志输出重定向到固定文件排查时直接看这个文件就能确认任务有没有跑起来。调试阶段可以用 php think order:auto-cancel 手动执行不要等 cron 触发效率更高。支付回调验签是二开支付相关需求时的必查环节。不要自己重新实现一遍加解密逻辑直接用源码里封装好的支付服务类。但你要清楚验签的输入参数包括哪些回调参数全量字符串、平台密钥、签名类型三者必须一致才能通过。我在改一个支付分账功能时因为把回调参数按自己的习惯重新组装了一遍导致验签永远失败。从那以后我每次动这类代码都会在验签位置加一行日志把原始入参打出来对比省得在黑匣子里猜。消息推送在 likeshop 家政系统里承担的是“订单状态变了要主动告诉用户和服务人员”的任务。实现上一般走小程序订阅消息或短信通知。二开时最容易忽略的是模板 ID 的维护小程序后台改了模板源码里对应的模板 ID 没同步推送就会静默失败既不报错也不送达。建议在配置文件里集中管理所有模板 ID并标注每个模板对应的业务场景下次改起来不用全代码搜。三件事都落地后这套家政系统才算真正具备上线运营的基础条件。我接过不少套开源系统发现真正出问题的往往不是主流程而是这些边界动作没有兜底。从那以后我每次部署都会先把定时任务、支付回调、消息推送这三件事强制检查一遍再谈功能迭代——这些看不见的配置才是系统稳定运行的底气。希望帮到你。本文还有配套的精品资源点击获取