基于JSP的高校实验课表管理系统：从需求分析到部署实战

做过高校项目的人都懂一个画面：每学期初，教务员手里拿着一张写满奇怪符号的Excel表，办公室里排着长队，老师在问"我周四下午的实验课怎么和隔壁实验室冲突了"，学生在群里刷屏"这周实验到底在哪个机房"。实验课表的复杂度向来被严重低估，普通课表系统根本处理不了"一个实验室在多个时间段分配给不同班级、一个教师跨校区上课、设备类型决定机房"这种多维度约束。所以我当时接到这个基于JSP的高校实验课表管理系统（项目代号VY32G）时，第一反应是：这东西的难点不在写代码，而在把排课规则想明白。

这篇文章我会完整拆解这个项目的设计思路、数据库结构、核心功能实现和从源码到运行的全部部署过程。不管你是正在做JavaWeb课程设计的学生，还是第一次接触课表类管理系统的开发者，照着这个思路做下来，遇到的大部分坑都能提前避开。我先把话说在前面：这套系统用的技术虽然不是最前沿的，但它在真实高校场景里能跑得稳，恰恰是因为选型克制、结构清晰。

1. 实验课表管理系统的痛点：为什么教务员需要一个专门的排课工具

很多第一次接触这类需求的人会觉得，课表不就是"时间+地点+课程+老师"四个字段吗？做一张表CRUD不就行了。但等你真正动手整理需求，会发现实验课表远不止这么简单。我当初和某高校负责实验教学多年的教务员连续聊了几个下午，才把需求梳理到能落地的粒度，这里面的细节值得先说清楚。

1.1 实验课和普通理论课的区别

普通理论课的排课单位是"教室"，一个教室容纳一个班，桌椅固定，讲师站前面讲就行。实验课完全不同，它排课的核心资源是实验室，而实验室有非常硬性的属性约束。

比如说，某高校的电工电子实验室只有40台工位，其中带示波器的只有24台；计算机组成原理实验室装的是旧版教学软件，只能开特定的实验项目；还有一间实验室的位置在另外一个校区，教师和学生往返需要二十分钟。这些信息在普通课表系统里是没有办法体现的。所以实验课表管理系统，本质上是一个带资源属性约束的排课系统。

另一个区别在于时间粒度。理论课通常一次就是两小节连堂，实验课却经常出现"上午做不完下午接着做"的情况，也有部分实验项目要求学生分批进入，每批一小时轮换。课表里的每个时间段，在实验场景下还可能被拆成多个小组批次。如果所有信息都塞进一张"星期几+第几节"的表结构里，后面必然要返工。

还有一个关键点：实验课往往有专业特殊性。同一个班的学生可能分成A/B两组，一组做硬件实验，另一组做软件仿真，下一周互换。这个"周次轮换"逻辑，是普通课表系统几乎都不会考虑的。

1.2 主要角色都想从这个系统里得到什么

我梳理过这个系统的用户角色，最终定为四类，每一类的诉求都不一样：

• 系统管理员：负责维护实验室信息、课程基础数据、用户账号。最关心的是"能不能把实验室资源管清楚"，比如每个实验室当前被占用情况、设备状态是否正常。
• 教务员（排课管理员）：负责生成和调整实验课表。最关心的是"排课有没有冲突"，包括实验室、教师、班级三个维度，任何一个维度冲突都不能保存。
• 教师：查看自己的实验课表、所负责课程的选课学生名单。有的老师还希望能在系统里提交调课申请，而不是跑到教务处交纸质单子。
• 学生：查看自己的实验课表、上课地点、第几周上什么内容。由于学生经常同时参加多个组的实验，按班级和学号过滤查询是刚需。

调研完这些诉求，我把功能清单列成了几个模块：用户登录与角色权限管理、实验室管理、实验课程管理、排课管理（含冲突检测）、课表查询与导出、选课名单管理。整个项目最终的程序、源码、数据库文件和部署文档，都是围绕着这几个模块搭建的。实际开发的编码工作只占一半，另一半全在业务规则设计上。

2. 技术选型与项目结构：JSP+Servlet+MySQL经典组合的实际存续理由

现在做JavaWeb项目，很多人第一反应就是Spring Boot加MyBatis，再配个Vue。但你看这个项目标题就知道，它用的是JSP。别急着觉得"过时"，这套技术在高校课表类管理系统里仍然有非常强的生命力，我仔细说下原因。

2.1 为什么不选更"新潮"的框架

先讲一个事实：JavaWeb这门课在相当多的高校里，教学主线仍然是从JSP和Servlet开始讲起，结课作业也要求必须用JSP+Servlet完成。不是说学校不教Spring Boot，而是JSP方案对课程设计来说"够用且好理解"——学生能把MVC思想、JDBC操作、Session管理这些底层东西全部亲手写一遍，而不是在Spring Boot的自动配置里被包起来看不见。

从实际项目角度讲，这个实验课表管理系统的规模并不大。核心表就七八张，业务逻辑集中在排课和查询，并发量级是"一个学院几百个学生同时使用"。在这种量级下，JSP服务端渲染页面的方式反而简单直接，不需要前端工程化、不需要接口联调、不需要跨域处理，一个Tomcat把页面和接口一起跑完。

另外，部署环境也决定了技术选型不能太激进。某高校的实验中心和课程服务器常年运行着老版本操作系统，装的还是Tomcat 8系列，你拿一个需要JDK 17的Spring Boot 3项目过去，对方机房根本跑不起来。JSP项目只要打包成war丢进Tomcat就能运行，运维负担最小。我做技术选型时非常看重这一点：系统能不能在目标环境里稳定跑起来，比用什么框架更重要。

2.2 项目目录结构与分层思想

这个项目的目录结构我按经典三层架构来组织，但刻意控制类和包的数量，避免过度设计。源码仓库的根目录大概是这样的：

src ├── main │ ├── java │ │ └── com │ │ └── schedule │ │ ├── dao // 数据访问层，每个表对应一个Dao │ │ ├── entity // 实体类，和数据库表字段一一对应 │ │ ├── service // 业务层，排课冲突检测等核心逻辑 │ │ ├── servlet // 控制层，接收请求并跳转页面 │ │ ├── filter // 登录与角色权限过滤器 │ │ └── util // 工具类，数据库连接、日期处理 │ └── webapp │ ├── admin // 管理员和教务员页面 │ ├── teacher // 教师页面 │ ├── student // 学生页面 │ ├── common // 登录页、公共样式 │ └── WEB-INF │ └── web.xml // Servlet与Filter注册配置 └── sql └── vy32g_schedule.sql // 数据库初始化脚本

这个分层的核心思想很简单：客户端请求到达Servlet（控制层），Servlet调用Service（业务层），Service调用Dao（数据层），Dao操作MySQL数据库，返回结果后Servlet把数据放进Request域，转发到JSP渲染页面。每一层只做自己该做的事，出了问题你也能很快定位——页面显示不对查JSP，逻辑不对查Service，数据不对查SQL。

2.3 开发环境的具体版本搭配

关于开发环境，这个项目我实测过的组合是：

一个小提醒：如果用IDEA创建JSP动态Web项目，建议勾选"Web Application"模板，然后手动把Tomcat配置到Run Configuration里。很多人卡在"代码写完了但点击运行没法访问页面"，基本都是Tomcat集成配置出了问题，后面第5节我会专门讲部署。

3. 数据库设计：实验课表的实体关系与建表思路

数据库是整个项目里最不能糊弄的部分。我见过不少课程设计，代码写了一堆，数据库却只有"用户表和课表一张表"，结果排课冲突检测根本写不出来。这个系统我设计了七张核心表，下面对关键结构做一次完整还原。

3.1 核心表结构与字段说明

先讲用户相关的表。系统里存在学生、教师、管理员三类自然身份，但我没有把账号密码分散到三张表，而是统一放在一张sys_user表里，用role字段区分角色。学生姓名、学号、班级这些信息放在student表，教师信息放在teacher表，通过user_id关联，这样登录认证和业务查询可以分离，也方便以后扩展新角色。

sys_user表的关键字段：

CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, role VARCHAR(10) NOT NULL, -- admin/teacher/student real_name VARCHAR(50), status TINYINT DEFAULT 1 -- 1正常 0禁用 );

然后是实验室表lab。我把实验楼的"楼号+房间号+容量+适用课程类型"都放进去，并且加了一个equipment字段记录设备描述，方便教务员在排课时知道这间实验室能承担什么实验：

CREATE TABLE lab ( id INT PRIMARY KEY AUTO_INCREMENT, lab_name VARCHAR(100) NOT NULL, location VARCHAR(100), -- 例如：实验楼A区302 capacity INT NOT NULL, -- 工位总数 equipment VARCHAR(255), -- 主要设备说明 lab_type VARCHAR(50), -- 硬件类/软件类/综合类 status TINYINT DEFAULT 1 -- 1可用 0维护中 );

实验课程表course记录每门课的基本信息，注意这里存的是"课程模板"，具体哪个班什么时候到实验室上课，是由schedule表决定的：

CREATE TABLE course ( id INT PRIMARY KEY AUTO_INCREMENT, course_name VARCHAR(100) NOT NULL, course_code VARCHAR(20) NOT NULL, credit DECIMAL(3,1) DEFAULT 1.0, teacher_id INT, -- 授课教师 lab_type_required VARCHAR(50), -- 需要的实验室类型 weeks_total INT DEFAULT 8 -- 实验周数 );

3.2 这几张表之间的关联关系

核心中的核心是排课表schedule。给一张实验课排课，你需要同时确定：哪门课、哪个老师、哪个班级、哪间实验室、哪一周、星期几、第几节。这六七个维度缺一个，学生就不知道该去哪上课。我的schedule表结构如下：

CREATE TABLE schedule ( id INT PRIMARY KEY AUTO_INCREMENT, course_id INT NOT NULL, -- 关联course表 class_name VARCHAR(50) NOT NULL, -- 教学班，例如 计科2401 teacher_id INT NOT NULL, -- 实际授课教师 lab_id INT NOT NULL, -- 关联lab表 week_start INT NOT NULL, -- 起始周 week_end INT NOT NULL, -- 结束周 week_interval INT DEFAULT 1, -- 周间隔，例如 1表示每周，2表示隔周 day_of_week INT NOT NULL, -- 1-7，周一至周日 section_start INT NOT NULL, -- 开始节次，1-6 section_end INT NOT NULL, -- 结束节次 student_capacity INT, -- 本次课可容纳人数 group_info VARCHAR(100), -- A/B组等分组说明 status TINYINT DEFAULT 0 -- 0未发布 1已发布 );

这张表几乎包含了所有排课冲突判定需要的信息。后面写冲突检测时，只需要组合条件做查询，不需要再做复杂关联，这个设计后来在实际调试中帮我省了大量时间。

最后还有一张选课表student_course，用于教师查看选课名单和学生查看个人课表。它把student和schedule关联起来：

CREATE TABLE student_course ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, schedule_id INT NOT NULL, status TINYINT DEFAULT 0, -- 0待确认 1已确认 create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_schedule (student_id, schedule_id) );

3.3 从ER设计到建表SQL的注意点

我要强调一个非常容易踩的细节：周次存储。很多第一次做课表的人会把"第1周到第16周"拆成16个字段，或者用逗号拼接字符串，这两种方案都是灾难。用week_start、week_end加week_interval组合，既能表示连续周（1-16周），也能表示隔周（week_interval=2），比字符串解析可靠得多。

另外，day_of_week和section_start/section_end我都用整数而不是字符串。好处有两个：排序自然（周一永远在周二前面），计算重叠时间段时直接比较大小，不用处理中文或英文星期字符串。这个惯例我强烈建议保留。

建表时的字符集问题也要注意。在MySQL里建库一定要显式指定字符集：

CREATE DATABASE IF NOT EXISTS schedule_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

全程使用utf8mb4。曾经就是因为有人图省事用了默认latin1，数据写入中文后全部变成问号，排查了半天才发现是数据库字符集问题。项目里提供的vy32g_schedule.sql脚本把建库、建表、初始数据都写好了，导入即可，但我建议你自己重新执行一遍建表语句，弄清楚每张表的用途，后面调试SQL时心里才有底。

4. 核心功能实现：排课冲突检测、课表渲染与权限控制

这个项目真正的技术含量集中在三个地方：排课冲突的判定逻辑、课表的动态渲染方式、以及基于角色的访问控制。三个问题想明白，整个系统就通了一大半。

4.1 排课冲突检测：双重校验逻辑

排课冲突是实验课表系统最核心的业务规则。我实现了两个层次的校验：底层的SQL条件查询，加上层的Java业务判断。以"保存一条新排课记录"为例，核心思路是：查出所有和这条记录时间、地点、教师有关联的已有记录，逐条判断是否有重叠。

先看最关键的一条SQL。检查同一时段同一间实验室是否被占用：

public boolean checkLabConflict(Connection conn, Schedule schedule) throws SQLException { String sql = "SELECT COUNT(*) FROM schedule " + "WHERE lab_id = ? " + "AND day_of_week = ? " + "AND section_start <= ? AND section_end >= ? " + "AND status = 1"; PreparedStatement ps = conn.prepareStatement(sql); ps.setInt(1, schedule.getLabId()); ps.setInt(2, schedule.getDayOfWeek()); ps.setInt(3, schedule.getSectionEnd()); ps.setInt(4, schedule.getSectionStart()); ResultSet rs = ps.executeQuery(); rs.next(); return rs.getInt(1) > 0; }

这段代码里的条件可能有人看不懂，我解释一下：新排课占用的是第3节到第4节，那么已有记录如果从第2节上到第4节（section_start=2, section_end=4），它满足section_start <= 4且section_end >= 3，说明两个区间有交集，冲突。这种区间重叠判断比枚举每个节次再逐次匹配要高效得多，也不用循环写一堆if。

教师冲突同理，把lab_id换成teacher_id再查一遍。教学班冲突也按这个思路扩展。我最终把三种冲突检查统一封装成了一个ScheduleConflictChecker类，每次保存排课记录前按"实验室、教师、班级"三个维度依次校验，任何一个维度冲突都返回对应的中文提示信息。

补充一个很多人忽略的点：排课冲突校验必须考虑周次。同一间实验室如果在单周被占用，双周是可以再排的。所以最终的SQL还要加上周次判定，我建议把周次展开到Java层处理——查出该实验室在目标星期和节次的所有记录后，在Java里判断两个时间范围是否存在重叠周，这样逻辑更清晰。

4.2 课表视图渲染：二维数组与HTML表格映射

课表的展示是本项目里最直观、也最容易写乱的模块。很多人的第一版代码是在数据库查出记录后丢给JSP，然后在JSP里嵌套三层循环去匹配单元格，结果数据一多，页面渲染逻辑变成一团麻。

我的做法是：在Servlet层就把课表组织成二维数组，JSP只负责循环打印，不做任何业务计算。

UML类或伪代码不需要，直接看核心逻辑。以学生个人课表为例，在Servlet里执行查询后，把结果映射成一个table[day][section]的结构：

String[][] weekTable = new String[7][7]; // [星期][节次]，0下标空闲不用 List<Schedule> schedules = scheduleService.findStudentSchedule(studentId); for (Schedule s : schedules) { String info = s.getCourseName() + "@" + s.getLabName(); for (int sec = s.getSectionStart(); sec <= s.getSectionEnd(); sec++) { weekTable[s.getDayOfWeek()][sec] = info; } } request.setAttribute("weekTable", weekTable);

然后JSP页面用一个双层循环把二维数组渲染成HTML表格：

<table border="1" cellpadding="8" cellspacing="0"> <tr> <th>节次</th> <th>周一</th> <th>周二</th> <th>周三</th> <th>周四</th> <th>周五</th> </tr> <c:forEach var="sec" begin="1" end="6"> <tr> <td>第${sec}节</td> <c:forEach var="day" begin="1" end="5"> <td> <c:choose> <c:when test="${not empty weekTable[day][sec]}"> ${weekTable[day][sec]} </c:when> <c:otherwise>空闲</c:otherwise> </c:choose> </td> </c:forEach> </tr> </c:forEach> </table>

这套方案的好处非常直观：Servlet把数据准备好，JSP只负责展示。改样式不会碰到逻辑，改逻辑不会弄乱HTML。我在这个项目里前后改了三次课表样式（从纯表格到加色彩标记），每次都是只动JSP，Service层一次没碰。

4.3 基于Filter的角色权限控制

系统有管理员、教师、学生三种角色，权限必须严格分开。学生进来不能打开排课管理页，教师不能修改系统用户。这个需求用Servlet Filter实现最合适。

我写了一个登录和角色校验的过滤器，统一切入点拦截所有请求：

@WebFilter("/*") public class AuthFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI(); String contextPath = request.getContextPath(); // 登录页、静态资源直接放行 if (uri.endsWith("/login.jsp") || uri.contains("/static/")) { chain.doFilter(request, response); return; } // 判断是否登录 User user = (User) request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect(contextPath + "/login.jsp"); return; } // 角色白名单校验：访问路径前缀必须匹配角色 if (uri.contains("/admin/") && !"admin".equals(user.getRole()) && !"operator".equals(user.getRole())) { response.sendRedirect(contextPath + "/error/denied.jsp"); return; } if (uri.contains("/teacher/") && !"teacher".equals(user.getRole())) { response.sendRedirect(contextPath + "/error/denied.jsp"); return; } chain.doFilter(request, response); } }

这个Filter的设计思想是"先认证，后授权"：先检查有没有登录，再检查登录角色的访问范围。特别注意，@WebFilter("/*")会把JSP页面本身也拦截住，所以放行规则里要把登录页和静态资源单独排除，否则会出现"打开登录页却被拦截跳转到登录页"的死循环。

在web.xml里也可以配置Filter，两种方式都能跑通。如果你用的Servlet版本较老，不支持@WebFilter注解，那就老老实实去web.xml配置<filter>和<filter-mapping>。我在调试中发现，不少同学在Filter里绕了半天出不来，最后发现是映射路径写错，把/*写成了/，只拦了根路径，其它请求全部放行，权限控制等于没有。

5. 从源码到运行：调试部署全流程实录

拿到一个完整项目之后，怎么把它跑起来，这也是很多人卡住的点。这个项目的程序、源码、数据库、部署文档都是一起交付的，但如果你不按正确顺序操作，还是可能启动失败。我按实际部署顺序把整个流程过一遍。

5.1 环境准备清单

部署前先确认环境。我建议按这个清单逐项核对，不要凭感觉装：

IDE配置Tomcat这一步我多说一句。以IDEA为例，需要在File → Project Structure → Artifacts里确认项目打包方式是Web Application: Exploded，然后在Run Configurations里新增一个Tomcat Server → Local，把Deployment里的Artifacts添加进来，才会出现那个绿色的启动按钮。如果你点了Tomcat的启动按钮却弹窗报"Unable to ping server"，多半是Tomcat的端口或JMX端口和本地已有程序冲突，或者Tomcat home目录选错了。

5.2 数据库导入与应用配置

数据库导入相对无脑，但也要注意顺序。打开命令行，进入MySQL：

mysql -u root -p source D:/path/to/vy32g_schedule.sql;

建议使用绝对路径，避免因为中文目录问题导致source失败。导入完成后检查一下sys_user表，确认管理员账号存在。

项目里数据库连接信息通常在src/main/java/com/schedule/util/DBUtil.java里，或者如果你用了连接池，则在c3p0-config.xml文件中。修改成你本机的MySQL账号密码：

private static final String URL = "jdbc:mysql://localhost:3306/schedule_db?useSSL=false&characterEncoding=utf8"; private static final String USER = "root"; private static final String PASSWORD = "你的数据库密码";

这里有个经典坑：MySQL 8.0以上的JDBC驱动类名和URL参数和MySQL 5.7完全不同。MySQL 5.7用com.mysql.jdbc.Driver，MySQL 8.0用com.mysql.cj.jdbc.Driver，还要加serverTimezone=Asia/Shanghai参数。所以如果你的数据库是8.0，注意把驱动jar包和URL同步换成8.0版本。如果驱动和数据库版本不匹配，最常见的就是Communications link failure或者时区报错。

5.3 启动过程中最常见的四个报错

我把这个项目调试过程中遇到的最高频报错整理成一张表，每个我都实际踩过：

排查404问题时，我有个非常实用的习惯：访问页面时报404，先看一眼Tomcat控制台有没有打印Servlet初始化异常，再看IDEA的Artifact输出目录里WEB-INF/classes下有没有编译出.class文件。很多时候代码源文件改了，但IDEA没有自动编译，你跑的其实是旧的class。这个时候Project → Build → Rebuild Project一下，问题立刻解决。

如果你用的是Maven构建，部署前执行mvn clean package生成war文件，再扔到Tomcat的webapps目录下也能运行。这也是最接近真实环境的一种部署方式，适合最后验收时用。本地开发和测试阶段，用IDEA的Tomcat集成方式更方便，调试断点也更顺手。

6. 我在这个系统上踩过的坑与调试经验

最后这部分是纯经验输出。我在做这个实验课表管理系统时，前前后后调试了两周，有些问题折磨了我好几天才找到根因，写下来帮大家少走弯路。

6.1 中文乱码问题的根源

中文乱码这个事，大多数情况下不是一处问题，而是三个环节同时没做对。第一，数据库连接URL没有带characterEncoding=utf8；第二，JSP页面顶部没有设置contentType="text/html; charset=UTF-8"和pageEncoding="UTF-8"；第三，Servlet接收POST请求时没有执行request.setCharacterEncoding("UTF-8")。

这三个默认值在JavaWeb规范里都是"请自行设置"，你不设置就按平台默认编码来，系统是中文环境还好，Linux服务器上默认UTF-8，Windows本地默认GBK，页面编码和数据编码一混，乱码就出现了。我的建议是在项目一开始就固定一个规则：所有涉及文本传输的地方，全部显式指定UTF-8。数据库连接串、JSP指令、Servlet开头，一个都不能少。

顺手分享一个排查技巧：如果只有存入数据库的中文乱，而页面显示正常，基本可以锁定是数据库字符集问题，检查建库语句和连接URL即可。如果页面上的中文全是问号，那是JSP编码问题居多。如果表单提交到后台再显示就乱，先看Servlet有没有设置请求编码。按这个链路排查，十分钟内必出结果。

6.2 数据库连接泄漏

JDBC操作时忘记关闭连接，这个问题在大学项目里几乎人人都有，但后果可能比你想象得严重。Tomcat默认的连接池大小有限，如果你每次查询都new Connection且用完不关，高并发下连接数很快耗尽，页面会随机报连接超时，而且这种bug特别难复现。

我后期给这个系统做了整改，把所有数据库操作统一收口到一个DbUtil工具类，并且利用JDK 7的try-with-resources语法确保连接自动关闭：

public static <T> T query(String sql, ResultSetHandler<T> handler, Object... params) { try (Connection conn = getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { for (int i = 0; i < params.length; i++) { ps.setObject(i + 1, params[i]); } try (ResultSet rs = ps.executeQuery()) { return handler.handle(rs); } } catch (SQLException e) { throw new RuntimeException("数据库操作失败", e); } }

这样每个Dao方法里就不用重复写try-catch-finally了，连接也不容易泄漏。如果你用的是连接池，记住一个原则：你打开的连接，必须由你在同一个方法里关闭，千万别想着"等别的类帮我关"，那样基本等于不关。

6.3 时间与星期字段的存储设计教训

我第一次设计schedule表时，用的week字段是字符串"1,3,5,7"这样的格式来表示隔周上课，结果写冲突检测时，需要在Java里把字符串拆开再循环比较，不仅代码难看，还容易漏判。后来全部改成week_start、week_end加week_interval三个字段，冲突判断的SQL才变得清晰。

这个教训其实反映了一个通用规律：表达一个"范围"概念时，一定要用结构化的字段组合，而不要用字符串塞一堆信息。排课记录本质是时间范围（第几周到第几周）和空间范围（哪个实验室、哪几个节次）的交叉，如果你用字符串存储，后期做任何数值判断都要先做字符串解析，维护成本直线上升。项目里提供的vy32g_schedule.sql是按最终设计写的，建议照着理解，不要自己改回字符串方案。

6.4 给后来者的几条建议

最后分享几条我一直很受用的实操经验：

第一，先跑通最小闭环再扩展功能。拿到这个项目后，第一步不要急着做排课管理，先把登录模块跑通，然后用管理员账号进首页看看基本页面，再做一张实验室的CRUD，最后才碰排课。每一步都能看到效果，调试信心会稳很多。

第二，排课模块单独花时间设计测试用例。我给这个项目做过一张测试表，专门列了各种冲突场景：同一老师同一时间不同实验室、同一实验室不同老师、同一班级同一时间两个实验、跨周连续周的冲突、隔周上课与单周上课的冲突。每修完一个bug，就把这些用例重新跑一遍，防止改一处坏一处。

第三，源码里的注释和文档不要删。这个项目交付时带了完整的部署文档和源码注释，很多人拿到手先Ctrl+A全部删除重写，结果把自己坑了。原注释里很多都是针对实际环境写的说明，比如哪个配置是某高校服务器的特殊设置，删掉之后再出问题就只能靠自己猜。

第四，多看Tomcat日志而不是只看页面。页面报500错误，浏览器里可能只有一行"HTTP Status 500"，完整堆栈都在Tomcat的logs目录或者IDEA控制台。学会看异常堆栈定位到具体代码行，才是调试的正确姿势。我见过太多人在页面报错后原地发懵，实际上往下滑两行日志答案就出来了。

这个实验课表管理系统做下来，我最大的体会是：所谓"管理系统"，难点从来不在增删改查，而在业务规则怎么翻译成数据和逻辑。实验课排课课表背后其实是"资源调度"问题，一旦把实验室、时间段、教师、班级这几个维度之间的关系理清楚了，代码不过是水到渠成的事。希望这份从需求到数据库再到部署的完整复盘，能让你少踩几个我已经踩过的坑，把精力放在真正有意思的业务逻辑上。