企业官网建设流程全解析

简介：新畅美容美发平台 v1.9.10 前后端源码，面向美容美发行业商家与开发者，提供线上预约、订单处理、支付集成与后台管理的一体化解决方案。前端基于 HTML5、CSS3 与 JavaScript 构建响应式界面，并支持微信小程序访问，用户无需下载安装即可完成预约与查询；后端涵盖用户管理、预约排期、订单处理、支付接口及商家后台等模块，适合用于二次开发、毕业设计或行业系统学习。资源包共 2687 个文件，约 51.64MB，以 png 图片、html 页面、json 配置、js 脚本、wxss 与 wxml 小程序样式模板、php 后端文件为主，另含 css、字体与图标等静态资源，目录结构完整，便于按模块检索与部署调试。目前已有 219 人学习下载，可帮助读者快速理解预约类小程序的整体架构、前后端交互逻辑与商家管理功能实现，为美容美发行业的数字化转型提供可参考的代码基础。

1. 新畅美容美发平台 v1.9.10 前后端源码：一套能跑起来的门店管理系统到底包含什么

一家中型美容美发门店，前台用纸质登记本排班，会员卡余额记在 Excel 里，库存靠店长每周盘点一次。这种场景下，客户预约冲突、会员余额对不上、产品过期没预警，几乎是每周必翻车的保留节目。新畅美容美发平台 v1.9.10 前后端源码，就是针对这类门店经营场景的一套完整系统实现，覆盖预约排班、会员管理、收银开单、库存进销存、员工提成核算这几个核心模块。它适合谁？想给中小门店做定制化管理系统的小团队，或者手里有美业客户、需要一套能二次开发的底座的外包开发者。这套源码的价值不在于代码写得多优雅，而在于业务闭环是完整的——从前端预约到后端结算，链路能跑通，省去从零梳理美业业务逻辑的时间。

2. 前后端技术栈拆解与本地环境搭建

2.1 从源码目录结构反推技术选型

拿到一套前后端源码，第一件事不是急着装依赖，而是先看目录结构，判断技术栈和分层方式。新畅美容美发平台 v1.9.10 的典型目录布局大致如下：

xinchang-beauty/ ├── server/ # 后端服务 │ ├── app/ │ │ ├── controller/ # 接口控制层 │ │ ├── service/ # 业务逻辑层 │ │ ├── model/ # 数据模型层 │ │ └── middleware/ # 中间件（鉴权、日志） │ ├── config/ # 数据库、缓存、支付等配置 │ ├── route/ # 路由定义 │ ├── public/ # 静态资源与上传目录 │ └── composer.json # PHP 依赖声明 ├── admin/ # 管理后台前端 │ ├── src/ │ │ ├── views/ # 页面组件 │ │ ├── api/ # 接口请求封装 │ │ └── store/ # 状态管理 │ └── package.json ├── miniapp/ # 小程序端（用户预约入口） │ ├── pages/ │ ├── components/ │ └── app.json └── docs/ # 部署说明与数据库字典

从composer.json和package.json可以快速确认：后端大概率是 PHP 框架（ThinkPHP 或 Laravel 风格），管理后台是 Vue 系，小程序端是原生或 uni-app。这个组合在国内中小型门店管理系统中非常常见，部署门槛低，虚拟主机或轻量云服务器都能跑。

2.2 本地跑通后端服务的最小步骤

假设你本地已经装好了 PHP 7.4+、MySQL 5.7+、Composer 和 Node.js，按下面步骤操作：

# 1. 导入数据库 mysql -u root -p -e "CREATE DATABASE xinchang DEFAULT CHARSET utf8mb4;" mysql -u root -p xinchang < docs/xinchang_v1.9.10.sql # 2. 配置数据库连接 # 编辑 server/config/database.php，填入本地数据库信息 # 3. 安装后端依赖 cd server composer install --no-dev # 4. 启动后端服务（开发模式） php think run --host 0.0.0.0 --port 8080 # 如果是 Laravel 风格则用：php artisan serve --host=0.0.0.0 --port=8080

# 5. 安装管理后台前端依赖并启动 cd admin npm install npm run dev # 默认监听 3000 或 5173 端口，具体看 vite.config 或 vue.config # 6. 小程序端用开发者工具导入 miniapp 目录 # 修改 app.json 或 config.js 中的 API 地址为 http://localhost:8080

这里有几个参数需要特别注意。数据库配置文件里通常有hostname、database、username、password、hostport、prefix六个字段，prefix是表前缀，导入 SQL 时如果没改，保持默认即可。后端启动端口如果被占用，换 8081 或 9090，同时记得同步修改前端请求的 baseURL。小程序端在开发者工具里需要勾选“不校验合法域名”，否则本地 HTTP 请求会被拦截。

2.3 前后端联调时最容易卡住的三个配置

第一个是跨域。后端如果没配 CORS 中间件，管理后台在浏览器里请求接口会直接报Access-Control-Allow-Origin。常见做法是在后端中间件里加白名单，或者开发阶段用前端 devServer 的 proxy 转发。

第二个是 JWT 密钥。新畅这套源码的鉴权一般走 Token 方案，config/jwt.php或.env里有个JWT_SECRET，前后端必须一致，否则登录后所有接口都返回 401。

第三个是文件上传路径。门店系统里员工头像、商品图片、会员卡封面都涉及上传，后端public/uploads目录必须有写权限，Linux 下chmod -R 755，Windows 下检查是否被安全软件锁定。

提示：本地跑通后再往服务器部署，能省掉大量“到底是环境问题还是代码问题”的排查时间。

3. 会员管理与预约排班模块的落地实现

3.1 会员卡、储值、积分三张表的关联逻辑

美业系统的会员模块，核心不是“记录一个客户名字和电话”，而是会员卡、储值账户、积分账户三者的联动。新畅源码里通常对应member、member_card、member_balance_log、member_point_log几张表。会员开卡时插入member_card记录，储值变动写member_balance_log，消费赠送积分写member_point_log。关键字段设计如下：

储值扣减必须用数据库事务加行锁，否则并发开单时会出现余额扣成负数的情况。源码里如果用了lockForUpdate或SELECT ... FOR UPDATE，说明作者考虑过这个问题；如果没有，二次开发时建议补上。

3.2 预约排班的时间片冲突检测

预约模块的难点在于：同一个技师在同一时间段不能接两单，但不同技师可以并行。新畅源码里一般用appointment表记录预约，字段包括technician_id、start_time、end_time、status。冲突检测的 SQL 逻辑是：

-- 检测某技师在指定时间段是否已有有效预约 SELECT COUNT(*) FROM xc_appointment WHERE technician_id = ? AND status IN (1, 2) -- 1已确认 2进行中 AND start_time < ? -- 新预约结束时间 AND end_time > ?; -- 新预约开始时间

这个条件的意思是：已有预约的开始时间早于新预约的结束时间，且已有预约的结束时间晚于新预约的开始时间，两者重叠即冲突。参数传入时注意时间格式统一为Y-m-d H:i:s，时区在config/app.php里设置，默认Asia/Shanghai。

3.3 收银开单与提成计算的代码路径

收银开单是门店每天用得最多的功能。新畅源码里这条链路通常是：OrderController接收前端提交的会员 ID、项目列表、技师 ID、支付方式，然后调用OrderService创建订单，再触发CommissionService计算提成。提成规则一般存在commission_rule表里，按项目分类或技师等级配置比例。

// 简化的开单逻辑示意 public function createOrder($data) { Db::startTrans(); try { // 1. 扣减会员余额或次数 $this->deductMemberCard($data['member_id'], $data['amount']); // 2. 写入订单主表和明细表 $orderId = $this->saveOrder($data); // 3. 计算并记录技师提成 $this->calcCommission($orderId, $data['items']); Db::commit(); return $orderId; } catch (\Exception $e) { Db::rollback(); throw $e; } }

参数说明：$data['amount']是实收金额，$data['items']是项目数组，每项包含service_id、technician_id、price、quantity。提成计算时注意区分“指定技师”和“不指定技师”两种场景，后者通常由店长或前台平分。

4. 库存进销存与数据报表的二次开发要点

4.1 产品库存的入库、出库、盘点三条线

美业门店的库存不只是卖货，还包括做项目时消耗的耗材。新畅源码里库存模块一般有product、stock_record、stock_check三张核心表。入库对应采购单，出库对应销售或项目消耗，盘点对应定期校正。每条stock_record记录product_id、type（1入库 2出库 3盘点）、quantity、before_stock、after_stock、operator_id。

二次开发时最常见的需求是“低库存预警”。可以在product表加一个warn_stock字段，每次出库后检查stock <= warn_stock，触发站内消息或短信通知。源码里如果没有这个功能，加一个定时任务或模型事件钩子即可。

4.2 营业报表的 SQL 聚合与前端图表对接

店长最关心的是日报、月报：营业额、客单价、新客数、项目排行。这些数据不需要实时计算，每天凌晨跑一次聚合写入report_daily表，前端直接查这张表，比每次实时SUM快得多。

-- 按日聚合营业额与订单数 INSERT INTO xc_report_daily (report_date, total_amount, order_count, new_member_count) SELECT DATE(create_time) AS report_date, SUM(amount) AS total_amount, COUNT(*) AS order_count, COUNT(DISTINCT member_id) AS new_member_count FROM xc_order WHERE status = 1 -- 已完成 AND create_time >= CURDATE() - INTERVAL 1 DAY AND create_time < CURDATE() GROUP BY DATE(create_time);

前端图表用 ECharts 或 Chart.js 对接/api/report/daily接口即可。注意接口返回的日期格式要统一，否则图表 X 轴会乱序。

4.3 多门店数据隔离的实现方式

如果这套系统要给连锁店用，数据隔离是绕不开的。新畅源码 v1.9.10 里通常用store_id字段做逻辑隔离，所有业务表都带这个字段，查询时自动加WHERE store_id = ?。二次开发时建议在中间件或模型基类里统一处理，避免每个查询都手写条件导致遗漏。

注意：逻辑隔离不是物理隔离，数据量大了之后要考虑分库分表或按门店归档。

5. 部署上线与常见故障排查

5.1 从本地到服务器的部署清单

部署到 Linux 服务器（以 CentOS + Nginx + PHP-FPM + MySQL 为例）的步骤：

# 1. 上传代码到 /www/wwwroot/xinchang # 2. 设置目录权限 chown -R www:www /www/wwwroot/xinchang chmod -R 755 /www/wwwroot/xinchang chmod -R 777 /www/wwwroot/xinchang/server/public/uploads chmod -R 777 /www/wwwroot/xinchang/server/runtime # 3. 配置 Nginx 站点 # 将 root 指向 server/public，配置伪静态规则 # 4. 导入数据库并修改 config/database.php # 5. 导入 admin 前端构建产物到 server/public/admin cd admin && npm run build

Nginx 伪静态规则参考：

location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } }

5.2 五个高频故障的现象、原因与解决

现象一：后台登录后空白页。原因通常是前端构建时 API 地址写成了localhost，部署后浏览器请求不到。解决：修改admin/src/api/config.js里的 baseURL 为服务器域名或 IP，重新npm run build。

现象二：小程序端预约提交失败，提示“网络错误”。原因是小程序要求 HTTPS，且域名需在后台配置。解决：给服务器配 SSL 证书，在小程序管理后台添加 request 合法域名。

现象三：收银开单后会员余额没变。原因可能是事务未提交或扣减逻辑走了缓存。解决：检查OrderService里是否用了Db::startTrans()且commit()被正确执行，清一次 Redis 缓存再试。

现象四：上传图片提示“文件类型不允许”。原因是后端config/upload.php里的allow_ext没包含jpg或png。解决：补上允许的扩展名，同时检查php.ini的upload_max_filesize是否够大。

现象五：报表数据与实际不符。原因通常是聚合任务没跑，或者订单状态过滤条件写错。解决：手动执行一次聚合 SQL，核对xc_order表里status字段的实际值分布。

6. 二次开发时怎么改才不翻车

改这套源码，我自己的血泪经验是：先摸清数据流，再动代码。具体来说，任何功能改动之前，先把涉及的表和字段在数据库字典里标出来，画一条从 Controller 到 Service 到 Model 的调用链，确认没有隐藏的关联逻辑。比如你想改会员卡余额的扣减规则，不能只看deductMemberCard这一个方法，还要检查OrderService里有没有在别处也扣了余额，以及member_balance_log的写入是否完整。

第二个习惯是：所有涉及金额和库存的改动，必须写单元测试或至少手动跑一遍并发场景。我见过太多“本地测试没问题，上线后余额扣成负数”的案例，根因都是没加行锁或事务隔离级别不对。

第三个技巧是善用日志。新畅源码里一般有runtime/log目录，出问题时先看最近的错误日志，比盲目翻代码快得多。如果日志级别不够，临时把config/log.php的level调成debug，复现一次再调回来。

最后一个建议：不要在原代码上直接改，用 Git 开分支，每次改动只做一件事，改完立刻提交。这样出问题能快速回滚，也不会把别人的修改覆盖掉。这套源码的价值在于业务闭环完整，二次开发的空间很大，但前提是你得先让它在你手里稳稳跑起来。希望帮到你。

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