企业官网建设流程全解析

简介：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 目录下的静态资源入口访问。这里整理一份比较典型的目录对照表，你可以对照着手里的源码看：

这个表的意义在于，你要知道哪些目录能直接改、哪些目录改完必须重新编译、哪些目录只做配置不需要动代码。比如数据库连接写在 .env 文件里，而不在 config 目录里写死，这在 TP6 项目里是标准做法；如果你改完 config/database.php 发现不生效，就要去检查根目录的 .env 是不是还在被读取。

2.3 三端入口与角色权限：后台、用户端、服务人员端各自管什么

家政平台和其他本地生活平台最大的区别，是多了一个服务人员端。用户端选服务、下单、支付、评价；管理后台做服务项目录入、价格设置、派单、结算审核；服务人员端接收订单、上门服务、确认完成、申请提现。三个角色围绕同一个订单流转，这个闭环在源码里对应着多个控制器和状态字段。

我第一次看这套源码时，把用户端和服务人员端搞混了，以为都是同一个 uni-app 工程。结果发现服务人员端的接口路径和用户端完全分开，权限校验方式也不同。用户端用的是用户登录态，服务人员端用的是员工登录态，管理后台又是管理员会话，三套认证体系互相独立。所以二开的时候，先搞清楚你要改的是哪个角色的接口，再去对应控制器里找代码，不然容易改错了地方还找不到问题。

3. 本地部署与运行：从 PHP 环境到后台登录全流程

3.1 环境要求与 PHP 扩展检查

likeshop 家政系统基于 ThinkPHP 6，PHP 版本至少要 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-FPM，TP6 的配置读取是有缓存的，不重启不生效。

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 2>&1

这条 crontab 每分钟执行一次 order:auto-cancel 命令。注意一定要写绝对路径 cd 到 server 目录，否则相对路径找不到 think 文件和 .env 配置；日志输出重定向到固定文件，排查时直接看这个文件就能确认任务有没有跑起来。调试阶段可以用 php think order:auto-cancel 手动执行，不要等 cron 触发，效率更高。

支付回调验签是二开支付相关需求时的必查环节。不要自己重新实现一遍加解密逻辑，直接用源码里封装好的支付服务类。但你要清楚验签的输入参数包括哪些：回调参数全量字符串、平台密钥、签名类型，三者必须一致才能通过。我在改一个支付分账功能时，因为把回调参数按自己的习惯重新组装了一遍，导致验签永远失败。从那以后我每次动这类代码，都会在验签位置加一行日志，把原始入参打出来对比，省得在黑匣子里猜。

消息推送在 likeshop 家政系统里承担的是“订单状态变了要主动告诉用户和服务人员”的任务。实现上一般走小程序订阅消息或短信通知。二开时最容易忽略的是模板 ID 的维护：小程序后台改了模板，源码里对应的模板 ID 没同步，推送就会静默失败，既不报错也不送达。建议在配置文件里集中管理所有模板 ID，并标注每个模板对应的业务场景，下次改起来不用全代码搜。

三件事都落地后，这套家政系统才算真正具备上线运营的基础条件。我接过不少套开源系统，发现真正出问题的往往不是主流程，而是这些边界动作没有兜底。从那以后我每次部署，都会先把定时任务、支付回调、消息推送这三件事强制检查一遍，再谈功能迭代——这些看不见的配置，才是系统稳定运行的底气。希望帮到你。

本文还有配套的精品资源，点击获取