PHP舞蹈工作室管理系统设计与实现：排课、课时与报表全解析

每年毕业设计季，我都会收到一批求助：“大哥，有没有能直接跑的PHP毕设？”今年最常被问到的一个题目，就是“基于PHP的舞蹈工作室管理系统的设计与实现”。说实话，这个选题很讨巧，它不像电商系统那么复杂，但业务闭环完整，特别适合用来展示计算机专业学生四年的核心能力。我前阵子刚带完一个学弟做这套系统，从需求分析、数据库设计，到远程调试、部署演示都完整走了一遍，这篇文章就把整个过程中最关键的部分整理出来，给正在做类似题目的同学做参考。

这套系统做出来以后，包含前台展示和后台管理，核心是帮助舞蹈工作室管理学员、课程、排课、收费和教师课时费。适合三类人看：第一类是准备做PHP毕业设计的在校生，想找个真实业务练手；第二类是刚开始学PHP、想从完整项目中理解“增删改查之外还有什么”的开发者；第三类是接毕设开发或带毕设的学长老师，希望有一套能快速交付、好讲解的通用方案。文章不写空话，全是能落地的表结构、代码片段、踩坑记录和答辩思路。

1. 舞蹈工作室管理系统到底在管什么：项目定位与功能拆解

1.1 为什么这个题目比图书管理系统更适合做毕设

很多学校默认的PHP毕设题目是“图书管理系统”“学生管理系统”，这类系统做的人太多，答辩时老师一眼就能看穿工作量。舞蹈工作室管理系统虽然也属于管理信息系统，但业务场景更贴近真实商业环境，天然包含“课程商品”“排课资源”“学员预约”“收费结算”这些概念，可以讲的东西立刻多了一个量级。

我选这个题目的另一个原因是：舞蹈工作室的规模通常不会太大，学员几十人到几百人，老师几位到十几位，教室一两间到三四间。这种规模决定了系统不需要考虑高并发，用PHP单机部署完全足够，但是业务流程必须严谨。比如一个老师不能同时上两节课、一个学员报名某门课程后剩余课时怎么扣、月底如何根据实际上课次数给老师结算课时费，这些问题都要在系统里闭环解决。

从答辩角度讲，图书管理系统的难点顶多是“借书还书冲突”，舞蹈工作室管理系统却能引出“排课算法”“事务操作”“报表统计”“权限控制”多个可深入展开的点，随便挑一个都能讲清楚，比干巴巴的CRUD有说服力得多。

1.2 一套完整的系统应该包含哪些具体模块

我做的版本包含下面几个模块，每个模块都有明确的业务对象。

这里尤其要关注“预约报名”和“收费管理”不是同一个模块。很多新手喜欢把报名和缴费混在一起，结果出现一个学员还没交钱就已经占用一个课程名额的情况。更合理的做法是：预约成功只代表占位，真正扣减课时和记录缴费要在“确认缴费”或“上课签到”时完成。我在实际设计里把这两个动作分开，后面会详细说。

1.3 技术选型怎么定：ThinkPHP还是原生PHP

这是很多学生一开始就会纠结的问题。我的建议很直接：如果学校没有明确要求“必须用原生PHP”，优先用ThinkPHP 6。原因不是原生PHP做不到，而是ThinkPHP提供了现成的数据库ORM、请求校验、中间件、模板渲染，能省下大量造轮子的时间，让你把精力集中在业务逻辑上。

如果学校比较传统，要求“纯PHP”，那也没有问题。只要用PDO预处理、MVC风格目录结构、Session做登录标记，同样能写出结构清晰的项目。关键在于“思想”，框架只是工具。

我最终给学弟用的是ThinkPHP 6 + MySQL 5.7 + Layui后台模板 + ECharts图表。这套组合在毕设里非常稳妥：ThinkPHP文档多，在线问题一搜就有答案；Layui对后端开发者友好，不用写大量JavaScript；MySQL是学校机房标配。运行环境用phpStudy或XAMPP都能一键搭建，不会在环境上卡太久。

2. 表结构设计：让学员、课程、排课、收费形成闭环

2.1 核心数据表应该怎么规划

数据库是这套系统能不能“圆回来”的关键。我见过不少半途而废的代码，就是因为后面发现“想统计某个数据但表里没有记录”。所以建表之前先把业务闭环画清楚，这里给出实际用的表结构，字段保留最核心的部分，方便直接借鉴。

学员表 student：

• id：主键
• student_no：学员编号，比如 ST20240001
• name：姓名
• gender：性别
• phone：手机号
• level：舞蹈基础等级，比如初级/中级/高级
• balance_periods：剩余课时数，整数
• status：状态，1在读，0停课
• create_time：建档时间

教师表 teacher：

• id：主键
• teacher_no：教师编号
• name：姓名
• phone：联系电话
• specialty：专长舞种，比如爵士/拉丁/芭蕾/街舞
• price_per_class：单次课时费，DECIMAL(10,2)
• hire_date：入职日期
• status：在职状态

课程表 course：

• id：主键
• course_name：课程名称
• category：舞种分类
• price_per_period：学员单节价格，DECIMAL(10,2)
• total_periods：总课时数，比如24节
• expire_days：有效期天数，比如90天
• introduction：课程简介

排课表 schedule：

• id：主键
• course_id：关联课程
• teacher_id：关联教师
• classroom：教室名称，比如A教室/B教室
• start_time：上课开始时间，DATETIME
• end_time：上课结束时间，DATETIME
• max_students：最大预约人数
• status：上课状态，1正常，2已结束，0取消

预约/报名表 booking：

• id：主键
• student_id：关联学员
• schedule_id：关联排课
• status：预约状态，1已预约，2已签到，3已取消
• create_time：预约时间
• check_time：签到时间

缴费表 payment：

• id：主键
• student_id：关联学员
• course_id：关联课程，如果缴费只关联课程可以简化
• payment_type：缴费类型，1报名，2续费，3退费
• amount：金额，DECIMAL(10,2)
• periods_bought：购买课时数
• pay_method：支付方式，微信/支付宝/现金
• pay_time：缴费时间

需要说明的是，上面的表已经做了合理的字段冗余。比如学员表里存了 balance_periods，这个字段是可以通过缴费和签到算出来的，但实际系统里会直接存一个冗余值，查询时不用反复SUM。冗余字段并不是坏设计，只要保证在缴费、退费、签到的代码里同时更新，就能避免性能问题和统计误差。

2.2 为什么金额字段必须用DECIMAL而不是FLOAT

这是我在带项目时一定会强调的坑。很多学生为了省事，把金额字段设成 float 或 double，结果到了月底算收入，发现报表里出现 9999.999999 这样的数字。因为浮点数在计算机里是近似存储的，不适合做精确计算。

正确做法是 DECIMAL(10,2)，表示最多10位数字，小数保留2位。例如 price_per_period DECIMAL(10,2)。这样PHP代码里做加法、乘法时不会出现精度丢失。这个知识点在答辩时也比较容易被问到，要能说清楚。

2.3 建表时最容易忽略的软删除和状态字段

我最初给学弟的草稿里，很多表都直接外键关联，比如 booking 表用 FOREIGN KEY 指向 student 和 schedule。后来发现踩了一个大坑：如果学员因为误操作被删除，关联的缴费记录也会被级联删掉，数据直接丢了。在真实管理系统里，很少真正物理删除数据，更多是用状态字段控制可见性。

所以我在所有业务表里都加了 status 字段。比如学员停课，不删除记录，只把 status 改成0；排课取消，不是DELETE，而是把 schedule.status 改成0。这样所有历史数据都保留，统计报表能基于全量数据运算，不会因为删除导致收入对不上。

外键约束我建议也去掉，或者只在数据库设计文档里体现，不在物理表上使用。原因是：ThinkPHP的ORM可以通过模型关联处理逻辑关系，而物理外键在批量导入数据、修改数据时容易受到约束限制，影响开发效率。这个做法在真实项目里很常见，不属于“不专业”。

3. 核心业务逻辑的实现：排课冲突、课时扣减与报表统计

3.1 登录认证与权限控制怎么做才安全

后台管理员登录是最基础的功能，但很多毕设代码写得非常原始：直接把用户密码明文存数据库，登录校验时用 SELECT * FROM admin WHERE username='xxx' AND password='xxx'。这个做法在答辩时会被老师一眼看穿。

我改用 password_hash() 加密密码，登录时用 password_verify() 校验。核心代码如下：

php复制// 登录校验
$user = AdminUser::where('username', $input['username'])->find();
if ($user && password_verify($input['password'], $user->password)) {
    Session::set('admin_id', $user->id);
    Session::set('admin_name', $user->real_name);
    return json(['code' => 1, 'msg' => '登录成功']);
} else {
    return json(['code' => 0, 'msg' => '用户名或密码错误']);
}

权限控制我用的是“角色常量”加“公共检测方法”。比如在后台基类控制器里写一个 initialize() 方法，所有需要登录的控制器继承这个基类：

php复制protected function initialize()
{
    parent::initialize();
    if (!Session::has('admin_id')) {
        $this->error('请先登录', url('login/index'));
    }
}

这样每个后台页面进去之前都会自动判断，避免在每个方法里重复写“是否登录”的判断。

3.2 排课冲突检测：老师时间重叠的算法

排课是舞蹈工作室管理系统里最有含金量的一块。一个老师同一时间段不能出现在两个教室，同一间教室同一时间段也不能被两节课占用。我一开始直接用“相等判断”去查，结果发现只堵住了一模一样的开始时间，老师9点到10点上课、另一节课9点半到10点半开始，依然没有拦截。

正确做法是判断两个时间区间是否重叠。判断条件是这样的：

假如已有排课 A：startTimeA 到 endTimeA，新排课 B：startTimeB 到 endTimeB。只要满足 startTimeA < endTimeB 并且 endTimeA > startTimeB，就说明产生冲突。

对应到SQL就是：

sql复制SELECT COUNT(*) FROM schedule
WHERE teacher_id = :teacher_id
  AND status = 1
  AND start_time < :end_time
  AND end_time > :start_time

如果查询结果大于0，则提示“该教师在该时间段已有课程，请选择其他时间”。教室冲突就用 classroom 字段替换 teacher_id 再查一遍。

需要注意边界条件：一节课的结束时间和另一节课的开始时间正好相等，比如10:00一节课结束，另一节课10:00开始，这不叫冲突，所以判断条件是严格的小于和大于是正确的。这个细节我特别跟学弟强调过：如果把条件写成 <= 和 >=，就会把刚好首尾相接的两节课误判为冲突。

3.3 学员预约、签到和课时扣减为什么要放在事务里

学员预约课程时，系统要做两件事：第一，验证剩余课时大于0；第二，更新剩余课时 balance_periods 减1。如果学员同时开了两个浏览器标签页，快速点了两次预约，两个请求同时读到剩余课时为1，然后同时减1，剩余课时就变成了-1。这就是并发问题。

解决方法是把“查询剩余课时”和“扣减课时”放在一个数据库事务里，并且使用行锁强制排队。在ThinkPHP中可以用事务闭包：

php复制Db::transaction(function () use ($student_id, $booking_data) {
    $student = Student::lock(true)->find($student_id);
    if ($student->balance_periods <= 0) {
        throw new \Exception('剩余课时不足，无法预约');
    }
    $student->balance_periods = $student->balance_periods - 1;
    $student->save();
    Booking::create($booking_data);
});

使用 lock(true) 会对这条 student 记录加锁，后进来的请求必须等前一个事务提交后才能读到数据，相当于给“扣款”操作加了一道保险。

签到功能也一样。每节课上完后，管理员可以点击“批量签到”，把该排课下所有状态为“已预约”的记录改成“已签到”，把 check_time 设为当前时间。签到以后，学员的课时才算真正消耗，教师课时费才能根据这些已签到的记录进行核算。

3.4 月度营收和教师课时费报表的计算思路

报表统计是很多学生最后才补的内容，实际上应该在设计表结构时就想清楚。我每个月给学弟梳理一下逻辑：

月度营业额 = 当月所有类型为“报名”或“续费”的支付记录金额总和，退费记录要减掉。

SQL可以这样写：

sql复制SELECT DATE_FORMAT(pay_time, '%Y-%m') as month,
       SUM(CASE WHEN payment_type IN (1,2) THEN amount ELSE 0 END) as income,
       SUM(CASE WHEN payment_type = 3 THEN amount ELSE 0 END) as refund
FROM payment
WHERE status = 1
GROUP BY month
ORDER BY month;

教师课时费 = 该老师在某一月份所有已结束排课中“已签到”的人次对应的课时费。如果该老师单次课时费固定100元，本月实际授课20节，那么课时费就是 20 × 100 = 2000元。这个逻辑可以独立查询，也可以在排课结束后自动生成一条“老师结算记录”。答辩时如果被问到“你这个课时费是怎么算的”，就把这个公式说清楚，比含糊其辞强一百倍。

4. 页面怎么做得专业：后台布局、图报表单和移动端适配

4.1 后台模板选择：Layui还是Bootstrap

页面是老师最容易直观评价的部分。我不想让后台看起来像二十年前的信息系统，所以前端没有自己写CSS，而是用现成组件库。

我这次选的是Layui。原因很简单：Layui的表单、表格、弹窗、分页都是后端开发者熟悉的模式，不需要深抠JavaScript。特别是数据表格 table.render 可以直接接受后端返回的JSON数据，绑定字段名就能展示，省掉大量拼接HTML的工作。

需要注意的是，Layui 2.8版本之后模块化方式有一些变化，如果你搜到的是老教程，代码可能跑不起来。我用的稳定做法是：直接通过 CDN 引入 layui.js 和 layui.css，然后在页面里用 layui.use(['table','form','layer'], function(){}) 初始化组件。如果部署环境没有外网，就把layui文件下载到本地public目录下，改成相对路径引入。

4.2 用ECharts把报表变成图表，而不是干巴巴表格

统计报表页是展示项目工作量最直观的地方。只放一个表格，老师会觉得你只是做了数据的简单展示；加上图表，档次立刻不一样。

我在管理后台首页放了三张图：近6个月营业收入折线图、各类舞蹈课程报名人数柱状图、教室使用率饼图。

实现步骤很简单：

php复制// 控制器中返回JSON数据
$sql = "SELECT DATE_FORMAT(pay_time, '%Y-%m') as month,
               SUM(amount) as total
        FROM payment
        WHERE status = 1
        GROUP BY month
        ORDER BY month
        LIMIT 6";
$data = Db::query($sql);
return json(['code' => 0, 'data' => $data]);

前端ECharts初始化时，把月份作为X轴，金额作为Y轴折线数据。接口返回的字段名和图表配置里的字段对应上就行。

有一点要提醒：如果直接用原生SQL查询，注意 table 前缀是否匹配。ThinkPHP默认表前缀是 think_，如果你数据库表建表时没加前缀，代码里要用 Db::name('payment') 而不是 Db::table('think_payment')，或者在建表时统一加上前缀，否则很容易查不到数据。

4.3 移动端适配不能不做

舞蹈工作室的前台或老板，很多时候是在手机上打开系统看当天排课和学员预约情况。如果后台页面在小屏手机上显示错乱，实际操作会很难受。

我并没有为移动端单独开发一套小程序或独立页面，只是在原有后台页面里引入了Layui自带的响应式栅格。比如把统计卡片放在一行，超小屏幕自动堆叠；表格数据量大的页面加横向滚动条，防止表格把页面撑破。

如果你有余力，可以再做一个简化的“今日课表”页面，只显示当前日期、时间段、课程名称、教师和预约人数。这个页面在手机上浏览效率极高，而且实现成本很低，只需要在排课表里按日期筛选取数据。

5. 远程调试排障：Xdebug配置与部署上线的注意事项

5.1 本地开发环境怎么搭：phpStudy还是XAMPP

本地环境我推荐phpStudy。原因很实际：它自带PHP、Apache/Nginx、MySQL，还有一键切换PHP版本的功能。如果学校机房只能装旧版PHP，你可以在自己电脑上用新版开发，最后到机房切换成兼容版本测试。ThinkPHP 6要求PHP 7.2.5以上，建议直接用PHP 7.4或PHP 8.0，这两个版本相对稳定，兼容性好。

项目放在 phpStudy 安装目录下的 WWW 文件夹，比如 D:\phpstudy_pro\WWW\project，然后通过 http://localhost/project/public/index.php 访问。如果不想在URL里带public，可以把站点根目录指向public目录，或者配置伪静态把访问重定向到入口文件。

5.2 PhpStorm + Xdebug 远程调试到底怎么配

很多同学写完代码，遇到问题只会 echo 打印变量，效率很低。远程调试功能可以用断点直接查看每一行执行时的变量值，绝对是PHP开发效率提升最明显的地方。

我用的是 PhpStorm + Xdebug 3。先打开 php.ini，确保有这一段：

ini复制[Xdebug]
zend_extension=xdebug
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=127.0.0.1
xdebug.client_port=9003

注意Xdebug 3的端口是9003，不是老版本常用的9000。配置完重启Apache，打开phpinfo，搜索xdebug，确认扩展已加载。

然后到PhpStorm里配置“Settings -> PHP -> Servers”，点加号创建一个Server，名称随便填，Host填127.0.0.1，端口填80，勾选“Use path mappings”，把项目根目录映射到本机的项目路径。接着点击工具栏上的“Start Listening for PHP Debug Connections”电话图标，在浏览器安装Xdebug Helper扩展，切换到Debug模式，刷新页面。当页面执行到你在PhpStorm里打断点的代码行时，会自动停下来，这时可以查看变量、步进执行。

这个功能在排查“排课冲突为什么不生效”“支付金额为什么算错”这类问题时，效果立竿见影。我带的学弟第一次看到断点停下来时，整个人都兴奋了，因为过去他排错全靠猜，现在能看到执行过程，思路完全不一样。

5.3 部署到服务器后最常见的三个报错

我见过太多在本地好好的项目，传到服务器以后一片空白。最常见的三个原因如下：

第一，runtime目录没有写权限。ThinkPHP运行时要写缓存、日志，如果把项目传到Linux服务器，需要在项目根目录执行 chmod -R 777 runtime ，否则会报“目录没有写入权限”或直接白屏。

第二，缺少PDO MySQL扩展。服务器上PHP默认可能没有启用 pdo_mysql，连接数据库时会报“Driver not found”。排查方法是在服务器上创建一个phpinfo文件，搜索pdo_mysql，如果没找到就安装扩展。

第三，伪静态规则没配置。如果Nginx服务器只配置了访问入口地址，深层链接可能出现404。Nginx需要加一段规则，把非真实文件路径都转发到 public/index.php。Apache则要开启rewrite模块，并引入.htaccess文件。

远程调试在部署后同样可以使用，只需要把 xdebug.client_host 改成你本机IP，服务器防火墙放行9003端口，然后在本机PhpStorm里设置Server的Host为服务器IP。不过，毕设演示一般不需要上线很久，我更推荐在本地连好调试，最后部署时只要保证功能正常即可。省得在公网服务器上开调试端口带来不必要的安全风险。

6. 论文文档与答辩准备：让毕设不止于能跑

6.1 需求分析和系统设计文档怎么写得有含金量

很多学生拿到开题报告模板就开始抄，写得全是“本系统具有用户管理、课程管理、收费管理等功能”这种空话。真正有含金量的需求分析，要能体现“你对现实业务的理解”。

以排课管理为例，文档里不应该只写“管理员可以新增排课”，而应该写：

“管理员新增排课时，需要选择一个课程、一位授课教师、一间教室、上课时间段和人数上限。系统需自动验证教师和教室的时间冲突，若冲突则禁止保存。排课信息保存后，学员可以在前端看到课程并预约。”

这种描述说明你想清楚了业务规则。答辩老师看完会觉得你不是在背概念，而是真做了系统分析。

6.2 测试用例怎么设计才能体现规范性

软件工程课程里都会要求写测试用例，但很多同学临时拼几个“登录成功”“登录失败”就交差。我建议按照模块设计至少20条用例，重点覆盖边界条件。

这里给一个排课冲突模块的测试用例示例：

测试用例一定要和代码里的判断逻辑对应。老师顺着用例一测，发现真的能拦住，你这个“软件工程”的分数基本就到手了。

6.3 答辩高频问题与应对思路

答辩最怕问的不是“怎么实现”，而是“为什么这么设计”。把下面这几个问题提前想好，现场就不会慌。

为什么选择PHP而不是Java？可以答：PHP开发效率高、部署轻量，适合中小型管理系统；Java适合大型分布式系统，如果业务规模没有那么大，使用PHP能更快迭代。重点是要表现出“我对比过，这是基于项目规模做的选择”。

数据库表之间为什么不用外键？可以答：为了避免级联删除影响历史数据，改用应用层逻辑保证数据一致性；同时方便后续数据迁移和表结构调整。这个回答比“不会用外键”高级很多。

如何防止SQL注入？可以答：使用PDO预处理或ThinkPHP的查询构造器，绑定参数，不让用户输入直接拼接到SQL字符串中。我顺手写一段绑定参数示例最好。

如果用户量大了怎么办？这个问题是加分项。可以答：先做数据库查询优化，增加索引；再引入Redis缓存热点数据，比如课程列表和公告；做读写分离，把报表查询放到从库。不需要真做，能说出思路就说明你有扩展意识。

项目中最难的点是什么？就答排课冲突检测和课时扣减并发。前者涉及区间重叠判断，后者需要事务和行锁。这两个点只要你代码里真的实现了，基本可以撑起整场答辩的技术深度。

6.4 关于带毕设和定制扩展的一点经验

每次带项目我都会加一个默认功能：操作日志表。管理员每次新增、修改、删除操作，都记录操作人、操作时间、操作内容和请求IP。这个表不占多少开发时间，但答辩的时候很有用。老师问“系统怎么保证操作可追溯”，直接演示操作日志，比说一百句“我们的系统很规范”都有力。

如果你拿到的题目名称类似“健身房管理系统”“瑜伽馆管理系统”“艺术培训学校管理系统”，不需要推翻重来，只需要把课程名字段改成对应的业务名称，再调整收费规则就可以了。这套舞蹈工作室系统的数据库和业务逻辑，本质上是一套通用的“课时制培训管理系统”。

我个人的感受是：毕设检验的不是你能不能写出多高深的代码，而是能不能把一个现实问题拆清楚、做完整、讲明白。把学员、课程、排课、收费这条链想通，这套PHP舞蹈工作室管理系统就已经成功了一大半。最后再分享一个小技巧：在本地开发完以后，一定要用“导出数据库SQL文件 + 全新安装”的方式重新走一遍部署流程。很多人代码写好了，但数据库是手工建的，没有导出完整的初始化脚本，最后换一台电脑就跑了半天。提前把 install.sql 准备好，后面所有的调试、演示、交付都会顺利很多。