企业官网建设流程全解析

简介：一套基于 likeadmin-php 开发的上门家政预约系统开源源码，面向需要快速搭建本地生活服务平台的开发者、创业者或运营团队。系统覆盖地图定位、在线预约、系统/后台派单、下单支付、核销订单等核心环节，用户端与师傅端融合，前端基于 Vue 与 uniapp，支持小程序和 H5 端。资源共 2000 个文件，以 JS、Vue、CSS 等前端代码为主，并包含 JSON、Markdown 说明文档和 SQL 数据库脚本，压缩包约 99.92MB，目录结构清晰便于按模块检索。当前已有 79 人学习下载。功能上支持多规格价格设置、首页 DIY、自定义预约时段、微信/支付宝支付、腾讯地图、本地或 OSS 存储，以及阿里云/腾讯云短信；师傅端具备保证金和每日限单机制，还可限定指定城市接单，适合本地化运营场景，整体源码无加密，便于二次开发与学习参考。

1. likeshop上门家政系统开源版是什么：先看值不值得拆开这个zip

拿到一个名叫likeshop上门家政系统开源版源码.zip的压缩包，第一反应不应该是双击解压，而是先问一句：这玩意儿是完整能跑的项目，还是某个项目的一部分？这决定了你接下来搭进去的时间是一晚上还是一星期。likeshop 本身是一套基于 ThinkPHP6 的开源商城系统，作者在社区里放出的多是通用商城版，而这个标题里的“上门家政系统开源版”，通常是指有人基于 likeshop 的框架结构，把商品、购物车、订单这套电商逻辑改造成了家政服务预约的行业版本。它的核心价值在于：预约下单、技师接单、微信支付、会员积分、分销裂变这些模块你不用从零写，直接改配置和模板就能上线一套家政平台。适合谁？想快速起盘做本地生活服务的技术负责人，或者接私活的 PHP 开发者——你手里如果只有一套商城源码就接家政单，面对的将是支付回调、服务时长计费、排班冲突这些翻车重灾区。这篇笔记就按我实际做过家政类小程序项目的流程，把这个源码包从解压到能上线，拆给你看。

2. 打开源码包：看目录、看依赖、看它到底改了什么

2.1 为什么选 likeshop 而不自己写——框架选型先想清楚

家政预约系统的本质是一个带复杂约束的订单系统。服务不是标准商品，它有上门时间、服务时长、技师状态、用户位置这些维度。你要是从零用 ThinkPHP 手写，光一个“师傅忙闲判断”就能让你加班到怀疑人生。likeshop 最讨喜的地方在于它把“营销插件”做成了可插拔结构，后台装个插件就像装 App，秒杀、拼团、优惠券这些电商玩法放到家政场景里改个名字就能用。更关键的是，它默认做了前后端分离——后台管理用传统的 PHP 模板渲染，前端用户端是独立的 Uniapp 工程，小程序、H5、App 一套代码出三端，这正好覆盖家政用户“微信里约、App 里查”的使用习惯。

2.2 解压后先别急着配环境，把目录骨架认全

打开这个 zip，常见做法是先解压到本地临时目录，不要直接扔到服务器上。解压完你会看到类似下面的结构，这是 likeshop 系列源码包里最常见的骨架，我一般会先对照这份清单确认文件是否齐全：

likeshop-home-service/ ├── admin/ # 后台管理端（PHP MVC，直接浏览器访问） ├── app/ # ThinkPHP6 核心代码 │ ├── admin/ # 后台控制器 │ ├── api/ # 用户端接口（小程序/H5 调用的 JSON 接口） │ └── common/ # 公共模型、服务层、枚举 ├── config/ # TP6 配置目录 │ └── database.php # 数据库连接配置 ├── public/ # 唯一可访问目录（部署时 root 指到这里） │ ├── install/ # 安装向导目录，装完必须删掉 │ └── static/ # 静态资源 ├── route/ # 路由规则 ├── runtime/ # 缓存、日志、session（需要写权限） ├── uniapp/ # 前端用户端项目（用 HBuilderX 编译成小程序） ├── sql/ # 数据库初始化脚本 └── think # 命令行入口

这套结构里最容易忽略的是uniapp目录。很多人以为后台能打开就是装完了，结果手机小程序端报接口 404，才发现前端项目要单独编译发布。likeshop 的接口鉴权用的是 token 机制，前端项目里配置的 baseUrl 要和后端域名对应上，这一步错位是新手最常见的翻车点。

2.3 运行环境要求——先对照再动手，省得装一半卡住

我做过一次部署，卡在 PHP 扩展缺失上花了半天，所以现在习惯先把环境要求列成一张表贴在旁边。likeshop 基于 ThinkPHP6，对运行环境有明确的底线要求。低于这个版本不是不能跑，而是你会遇到各种莫名其妙的报错，与其事后排查，不如一开始就满足它。

注意 PHP 版本别一上来就追求最新。PHP 8.2 对interbase这类扩展移除了支持，而 likeshop 的作者在早期版本里用了不少已经废弃的写法，你到时候去改源码还不如直接降级省时间。装环境的时候顺手打开php.ini里的open_basedir如果设置了限制，一定要把项目目录路径加进去，否则运行时会疯狂报权限错误，这个在宝塔面板里默认是关闭的，裸机部署最容易中招。

3. 把源码跑起来：部署步骤和最小可运行命令

3.1 从 zip 到可访问的站点——部署的完整 Bash 命令序列

拿到likeshop上门家政系统开源版源码.zip之后，我一般不会直接双击解压到服务器，而是先检查压缩包文件的完整性，因为从网络下载的源码包偶尔会有文件缺失，导致安装过程中文乱码或者模块加载失败。在 Linux 服务器上，常见的做法是用 unzip 命令处理：

# 1. 创建站点目录并解压 mkdir -p /www/wwwroot/home-service unzip likeshop上门家政系统开源版源码.zip -d /www/wwwroot/home-service/ # 2. 查看解压后的目录结构，确认核心目录存在 ls -la /www/wwwroot/home-service/ ls /www/wwwroot/home-service/sql/ # 确认有 .sql 初始化文件 # 3. 给予 runtime 目录写入权限，否则 TP6 会报 "runtime目录不可写" chmod -R 777 /www/wwwroot/home-service/runtime chmod -R 777 /www/wwwroot/home-service/public/static # 4. 防跨站和 PHP 版本设置（以宝塔为例，伪静态选择 thinkphp）

这段命令里最容易被忽略的是第 3 步。很多人在本地开发时用 Windows，权限模型不一样，直接 FTP 上传到 Linux 后，Nginx 运行用户www对runtime目录没有写权限，页面就会白屏。你在浏览器里看到的现象是“访问首页 500”，但查看runtime/log目录时发现里面根本没有日志文件——因为连日志目录本身都写不进去。

3.2 安装向导：数据库初始化和后台账号创建

解压完成后，浏览器里访问http://你的域名/install.php会进入安装向导界面。这是 likeshop 系列源码的比较友好的安装流程：填写数据库地址、用户名、密码、数据库名，点击下一步它就会自动创建数据表并写入初始配置。整个过程会在后台执行，核心相当于执行了下面等效命令（源码包里的实际安装向导主要是可视化引导）：

# 等效的数据库初始化——这是安装向导后台做的事 mysql -uroot -p你的密码 home_service_db < /www/wwwroot/home-service/sql/likeshop_home_service.sql # 初始化后台管理员（默认后台路径是 /admin） # 初始账号一般是 admin，初始密码在安装向导里让你设置

安装向导跑完，要立刻做两件事。第一，把public/install目录改名或删除，否则每次访问首页都会跳转到安装页面，这是一个安全漏洞的隐患；第二，修改后台默认管理员密码，likeshop 在初次安装时如果密码设置的过于简单，很容易被后台爆破。安装完成后config/database.php里会自动写入你的数据库连接信息，不需要再手动修改。

3.3 伪静态路由配置：Nginx 的 rewrite 规则

likeshop 的 URL 模式默认是 pathinfo 格式，Nginx 下如果不配置伪静态，所有页面包括后台登录首页都会返回 404。这是整个部署过程中报错频率最高的一个环节。我在 Nginx 里常用的配置如下：

# 在 server 块中添加 location 规则 location / { index index.php index.html; # 如果请求的文件/目录不存在，则交给 index.php 处理 if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s=$1 last; } } location ~ \.php(.*)$ { # 开启 Nginx 内置的 pathinfo 支持（适用于 PHP-FPM） fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }

这里有几点要提醒你。如果你的 Nginx 配置里没有location ~ \.php(.*)$这段，PHP 文件会直接被 Nginx 当成静态文件返回下载，而不是交给 PHP-FPM 解析。另外，fastcgi_pass的地址要和php-fpm的监听地址一致——我见过不少人配置成127.0.0.1:9000，但 PHP-FPM 实际监听的是 Unix socket 路径/tmp/php-cgi.sock，这时候所有 PHP 请求都会 502，而静态资源却正常加载。排查这种问题的时候，先看 Nginx 错误日志，再确认 PHP-FPM 监听方式，别一上来就重装环境。

3.4 前端用户端编译——小程序不是解压就能用的

这套系统里的uniapp目录是整个项目里最容易被当摆设的部分。很多人以为后端部署完成就算上线了，但用户实际在小程序里下单调用的是app/api目录下的接口。前端工程需要用 HBuilderX 或命令行工具进行编译：打开uniapp项目，修改根目录下config.js（有的版本里叫server.js）中的接口地址，指向你的后端域名，然后在 HBuilderX 里运行到微信开发者工具即可。

这一步的常见问题是跨域。如果你是用http://localhost本地调试，而后端接口跑在服务器上，小程序端会报“request 合法域名不在白名单”，微信开发者工具里要勾选“不校验合法域名”才能调通接口；真机预览时则必须在微信公众平台后台把接口域名配进 request 合法域名列表里，否则正式上线后用户的所有请求都会被微信拦截，页面白了还不知道怎么回事。

4. 家政场景业务配置：从商城逻辑转成上门服务逻辑

4.1 服务分类和服务项目——商城里“商品”变成了“服务”

likeshop 后台的“商品管理”照搬到家政场景会显得牛头不对马嘴。常见的做法是在后台的商品分类里重建一套家政分类，比如“日常保洁”“深度清洁”“家电清洗”“月嫂育儿”这类一级分类，再把服务项目挂在分类下。每一项服务对应的字段（价格、时长、简介、缩略图）在数据库里依然走的是商品表结构，但你在后台录数据时要留意服务时长这个字段——likeshop 原生商品没有“每个服务耗时多少分钟”的概念，而家政订单计算排班冲突、结算工资都依赖这个时长。

我用的一条 SQL 可以把服务时长字段补充进商品扩展表：

-- 添加服务时长字段（以分钟为单位） ALTER TABLE `ls_goods` ADD COLUMN `service_duration` INT DEFAULT 60 COMMENT '服务时长（分钟）' AFTER `sales_sum`;

4.2 技师管理——不存在的“员工表”需要自己建

likeshop 原生架构里没有员工表，这是家政系统改造里最硬的一块骨头。如果你手里这份源码没有内置技师模块，就得在后端加一张表来维护技师的技能等级、排班日期和服务区域。我一般会新建ls_technician表，结构大致如下：

4.3 预约与下单流程——小程序端接口改造重点

用户端有“立即预约”和“立即购买”两种入口。商城版默认的“购买”提交的是商品 ID 和数量，家政场景里要额外提交上门地址、期望服务时间、联系人信息。在app/api/order控制器的创建订单方法里，需要增加这些字段的接收和校验。这里给出一个改造片段：

// 订单创建接口中获取并校验家政参数 public function createOrder() { $params = $this->request->post(); // 校验上门地址 if (empty($params['address_id'])) { return json(['code' => 0, 'msg' => '请选择上门地址']); } // 校验期望服务时间 if (empty($params['expected_date']) || empty($params['expected_time'])) { return json(['code' => 0, 'msg' => '请选择期望上门时间']); } // 把额外字段写入订单扩展表 $extras = [ 'address' => $params['address'], 'expected_time' => $params['expected_date'] . ' ' . $params['expected_time'], 'technician_id' => $params['technician_id'] ?? 0, 'remarks' => $params['remarks'] ?? '', ]; // 创建主订单并写入备注 $orderSn = $params['order_sn'] ?? ''; // ... 后续流程和普通商城订单保持一致 }

这段代码最值得注意的变量是expected_time格式——存储时统一转成YYYY-MM-DD HH:mm格式，千万不能分开存日期和时间，否则后面做技师排班冲突检测时，要用 SQL 拼接字符串，既容易出错又慢。另外technician_id为 0 表示未指定技师，由后台派单员手动分配，这是家政系统比较常见的两种模式并存的做法。

4.4 支付回调与订单状态联动

家政服务的支付回调处理和商城逻辑基本一致，但要注意售后服务时限不同。家政订单一般是服务完成后才能申请退款的，而这个“服务完成”标记并不由用户确认，而是由技师在移动端点击“开始服务/服务完成”来带动订单状态流转。当技师端调用完成接口时，后台会把订单状态置为“待评价”，同时自动把该技师的today_orders减一，腾出排班容量。

这里经常踩的坑是支付回调幂等处理。微信支付的回调通知由于网络原因可能会多次推送同一个out_trade_no，如果订单状态已经是“已支付”却又执行一遍库存扣减，服务次数就会重复扣。我见过一个案子是雪天订单激增，回调重复通知把某技师的下午时段排了两次班，最后只能手工改数据库。如果你拿到这套源码，建议先检查回调入口是否有“订单 status 不等于待支付则直接 return”的判断，没有的话自己加上。

5. 上线避坑指南：从部署到跑业务，这几处最容易翻车

5.1 伪静态导致后台登录 404：先看 Nginx 错误日志再动手

现象：后台首页能打开，但点击登录后跳转到一个 404 页面，或者登录成功后刷新又回到登录页。原因99% 是 Nginx 的伪静态规则没生效。likeshop 的 URL 默认是 pathinfo 模式，如果 Nginx 没有把不存在的文件路径 rewrite 到index.php，登录表单提交的 POST 请求就会打到错误的后端路由上。另外，location /里的if (!-e $request_filename)这段在 Nginx 里要放在location ~ \.php规则之前，顺序错了也会影响 PHP 请求的解析。解决：备份当前 Nginx 配置，清空location /块，替换为上面 3.3 节的 rewrite 规则，然后nginx -t检查语法并nginx -s reload。如果还是不行，打开runtime/log/，看当天的日志文件尾部有没有 SQL 报错，有的话一般是数据库连不上，和伪静态无关。

5.2 小程序请求超时与接口 500：跨域和 URL 白名单是重灾区

现象：小程序开发者工具里请求后端接口，报request:fail或者 500、502。原因：两点。第一，你编译 uniapp 时config.js里的接口地址写的是http://localhost，微信开发者工具没有勾选“不校验合法域名、web-view（业务域名）”；第二，后端域名的 SSL 证书没配好，微信要求所有正式环境的请求一律 HTTPS，证书过期也会导致请求直接被拒。解决：本地调试时勾选“不校验合法域名”，真机预览和正式上线前一定把接口地址换成 HTTPS 域名，并且在微信公众平台后台的“开发管理 - 服务器域名”里添加 request 合法域名。php 端注意 CORS 跨域设置不是主要问题，因为小程序请求不强制走 CORS 预检，但服务端代码里如果用了$_SERVER['HTTP_REFERER']做防盗链判断，小程序请求会因为没有 Referer 而被拒绝，直接把这个判断删掉即可。

5.3 服务时长和排班冲突：UTC 还是本地时区

现象：用户在凌晨预约，后台显示的期望时间往前错了 8 小时；或者两个技师被排在同一个时间段。原因：PHP 默认时区如果没设成Asia/Shanghai，date('Y-m-d H:i:s')生成的是 UTC 时间。likeshop 安装向导里一般会写时区配置，但如果你是手动导入 SQL 部署的，config/app.php里的default_timezone可能还是空的。写数据库和读数据库都用 UTC，页面显示就会错位，进而导致判断同一时间段是否冲突时算错。解决：在.env文件（或config/app.php）里强制设置：

// config/app.php 'default_timezone' => 'Asia/Shanghai',

另外数据库连接配置里也可以加'datetime' => 'YYYY-MM-DD HH:mm:ss'，并确保 MySQL 时区和 PHP 保持一致。排查时用下面这句 SQL 看数据库当前时区：

SELECT NOW();

如果和服务器时间不一致，可以执行SET GLOBAL time_zone = '+08:00'，并在 MySQL 配置文件的[mysqld]段里固定写入default-time-zone = '+08:00'。不然后台看到的订单时间永远是歪的，用户差评你看不出原因，还以为技师迟到。

5.4 后台能登录但前台小程序白屏：baseUrl 写错成静态路径

现象：小程序编译成功，打开后是空白页或加载转圈 3 秒后报 “无法连接服务器”。原因：uniapp 工程的config.js（不同版本文件名不一样）里baseUrl指向的是后端 IP 或一个已经停用的域名，或者是相对路径/api。相对路径在浏览器里能解析，在小程序里没有域名上下文，是不可能自动补全的。解决：改成你的完整正式接口域名，注意结尾不带斜杠，例如https://h5.yourdomain.com/api。改完保存后，在 HBuilderX 里点“重新编译”，不要只刷新页面，必要的话把uniapp项目下的unpackage/dist目录删除再编译。这个目录是编译缓存，有次我改了域名不生效，删了dist立刻就好了，原因是开发者工具加载了旧的编译产物。

5.5 安装完成忘记删 install 目录：安全漏洞分分钟被利用

现象：网站跑了一段时间之后，突然发现后台密码被人改了，或者数据库被清空。查看访问日志，发现大量请求来自一个 IP，反复访问/install.php。原因：安装向导存在，任何人都能访问并触发数据库重置。likeshop 安装向导设计时并不是每次都让你输入数据库配置，如果你服务器留下了旧的.env备份文件，安装向导会直接读取它并重建数据库。某数据库就是被这样刷掉的，用户数据全没了，只能恢复到前一天的备份。解决：部署完立即改名或删除/www/wwwroot/home-service/public/install目录。这是铁律，没有例外。我自己的习惯是把整个install目录打包存到本地后删除服务器上的文件，防止误操作。更好的做法是在public/index.php入口文件里加一段环境判断，只要是生产环境就强制禁止访问 install：

// public/index.php 顶部加入 if (!is_file('../install.lock')) { // 开发环境中还没有安装锁，才允许访问安装向导 header('Location: /install/'); exit; }

同时记得在项目根目录创建一个install.lock空文件，双保险。安装锁文件是很多 PHP 安装向导的通用逻辑，不用改框架代码就能实现。

6. 上线前验证清单与二次开发方向：把源码用透而不是止步于能看

一套系统跑起来之后，距离“能用”其实还有一大截。我习惯在交付前按顺序做几轮验证。先从最核心的下单链路说起：新建一个测试会员账号，走一遍“选服务→选技师→选时间→提交预约→模拟支付回调→技师开始服务→服务完成→评价”全流程，确认每一步的订单状态流转符合预期。第二步检查支付回调的幂等，使用 Postman 模拟微信支付成功通知向回调地址抛两次相同数据，观察是否产生两个订单。第三步验证数据备份与恢复，手动导出一份 SQL，再新建一个测试库导回去，看有没有表缺字段，这是检验“坏表”最直接的手段。

性能层面，家政系统最怕的是用户集中在早上 10 点预约导致接口响应变慢。上线前我一般会用 Apache 的 ab 工具压一下订单查询接口：

ab -n 200 -c 20 -H "token: 你的测试token" "https://你的域名/api/order/lists"

重点关注两个数字：Requests per second如果低于 50，说明接口存在 N+1 查询——比如订单循环里又逐条查技师信息、查服务分类，这类查询在 likeshop 里很常见。解决方式是把常用数据（服务分类、技师列表）放进 Redis 缓存，并把config/cache.php里的驱动从file改为redis。给ls_order表的user_id和status字段加上联合索引，这一步对查询速度的提升最为明显，有时候一个表的扫描时间能从 0.2 秒降到 0.02 秒，性价比很高。

二次开发方向上，我建议你优先补齐两块：一是“技师派单池”——预约订单进入待分配状态时，自动推送给附近且时段空闲的技师，谁先抢单谁服务，闭店模式改成抢单模式，用户下单体验会好很多；二是“服务评价与复购”——家政用户很依赖历史评价来做决策，把服务完成后自动弹评价的入口做得顺畅一点，用户在 24 小时内评价赠送优惠券，能显著拉高二次下单的概率。这两块都在 likeshop 现有营销和会员体系上做增量，不需要动框架底层，用它的插件机制就行。

最后提醒你养成一个习惯：改任何文件之前先备份。我自己的做法是每天凌晨用 crontab 自动打包public和app目录到异地，数据库每天至少导出一份完整 SQL。家政系统的数据不像商城库存，订单里既有地址又有支付信息，丢了真的会砸招牌。这套源码如果你能跑通上面的验证清单，再补上排班和派单两个硬模块，做成一个区域性的家政调度平台是完全够用的。希望帮到你。

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