企业官网建设流程全解析

简介：这是一份面向计算机专业学生毕业设计与期末大作业的实验室排课系统项目，基于JSP技术开发，解决高校实验室资源排课管理的实际需求。压缩包仅22.18MB，共1062个文件，涵盖java后端源码、jsp动态页面、css/js前端样式脚本、png/gif界面素材，以及doc论文与sql数据库文件，目录结构完整，便于按模块拆解学习。已有27人下载学习。项目包含论文、开发文档、数据文档和源码四大部分：论文阐述系统设计理念与架构选型，开发文档记录从需求分析到测试发布的完整流程，数据文档提供表结构与样本数据，源码则经过本地编译和严格调试，确保可运行。通过阅读源码，可直观理解JSP与Java后端的协作方式、MVC分层设计思想，并掌握分页、数据过滤、表单交互等Web开发常用技术，适合需要项目实战参考或直接用于课设验收的学习者。

1. 实验室排课系统+jsp.zip：老技术栈为什么还值得跑一遍

“实验室排课系统+jsp.zip”这个文件名，频繁出现在某高校实验中心的U盘里、教务处的共享文件夹里、各类课程设计的交付物里。它本质上是一个用JSP+Servlet打包好的Web应用成品：解压、导数据库、丢进Tomcat就能跑。它解决的问题很具体——实验员不必再用Excel记排课，冲突撞车、调课追溯都有页面入口。对于有Java基础但没完整写过Web项目的开发者，以及需要接手这类存量系统的技术人员，这套代码比花哨的微服务项目更值得跑通。这篇笔记不假装见过某个具体包，只按这类系统最常见的实现，把数据模型、部署路径、冲突检测和故障点讲透。

2. 实验室排课系统的数据根基：表结构设计与时间模型

2.1 三层架构在排课系统里的真实形态

JSP排课系统最常见的结构是三层：JSP负责展示排课列表和表单，Servlet接收请求和处理页面跳转，DAO层封装JDBC数据库操作。很多第一次接触的人误以为JSP页面里直接写Java代码就是全部，其实可维护的排课系统会把业务逻辑单独拆出来，页面只做渲染和参数传递。

这种结构在实验室排课场景下有实际的好处。排课规则是强业务逻辑，冲突检测会被多个入口调用——手动排课、批量导入、临时调课——独立成专门的Service类之后不需要复制粘贴。JSP的页面数量通常不多，登录页、实验室管理页、排课列表页、排课表单页，覆盖主流程就够了。Servlet的映射规则直白，后期维护的人翻开web.xml就能看懂每个URL对应什么功能。

我实际接手过的某高校实验室管理系统就是这套结构，维护了五六年没有推倒重写。原因不是技术选型先进，而是排课业务本身稳定，页面和接口数量被控制住了，依赖没有扩散。如果你拿到的zip包里层次混乱，JSP里塞了数据库查询代码，改造的第一步就是把这些逻辑抽到独立的类里，而不是急着加新功能。

2.2 核心表结构与字段设计

排课系统的核心是排课记录表，周围围着实验室表、教师表、课程表。下面这个建表脚本是这类系统中最常见的形态，也补上了两个很多课程设计Demo会漏掉的字段：学期和单双周。

CREATE TABLE t_lab ( lab_id INT PRIMARY KEY AUTO_INCREMENT, lab_name VARCHAR(50) NOT NULL COMMENT '实验室名称', lab_location VARCHAR(100) COMMENT '实验室位置', seat_count INT DEFAULT 40 COMMENT '座位数', lab_type TINYINT COMMENT '1机房 2电子实验室 3普通实验室', enabled TINYINT DEFAULT 1 COMMENT '是否可用' ); CREATE TABLE t_teacher ( teacher_id INT PRIMARY KEY AUTO_INCREMENT, teacher_name VARCHAR(20) NOT NULL, department VARCHAR(50) COMMENT '所属院系或部门' ); CREATE TABLE t_course ( course_id INT PRIMARY KEY AUTO_INCREMENT, course_name VARCHAR(50) NOT NULL, teacher_id INT NOT NULL, course_type TINYINT COMMENT '1理论 2实验 3综合实训', class_hours INT DEFAULT 0 COMMENT '总学时' ); CREATE TABLE t_schedule ( schedule_id INT PRIMARY KEY AUTO_INCREMENT, lab_id INT NOT NULL, course_id INT NOT NULL, teacher_id INT NOT NULL, semester VARCHAR(20) NOT NULL COMMENT '学期，如2024-2025-1', day_of_week TINYINT NOT NULL COMMENT '1-7表示周一到周日', start_section TINYINT NOT NULL COMMENT '开始节次，取值1-12', end_section TINYINT NOT NULL COMMENT '结束节次', week_start TINYINT NOT NULL COMMENT '起始教学周', week_end TINYINT NOT NULL COMMENT '结束教学周', week_type TINYINT DEFAULT 0 COMMENT '0全周 1单周 2双周', note VARCHAR(100), KEY idx_lab_time (lab_id, semester, day_of_week) );

设计上有三个值得注意的地方。semester字段不能省，很多早期系统没有学期维度，过完一个学期排课记录全部混在一起，查询和统计都变得不可用。week_type字段解决单双周排课的常见需求，实验室排课经常遇到“单周上机、双周实验”这种交替安排。day_of_week用TINYINT而不是字符串，排序和索引都更高效。

这里故意选择了普通索引而不是唯一索引。原因是实验室排课冲突的语义是区间重叠，同一个实验室周一1到2节被占用，那么周一2到3节的记录也应该被拒绝。唯一索引只能挡住完全相同的时间，挡不住区间交叉，真正的冲突判断必须交给业务层的查询逻辑。

2.3 时间冲突在数据库层面的表达方式

排课冲突的本质是区间重叠。假设一条已有记录的节次区间是[a,b]，新记录的节次区间是[c,d]，两个区间有交集的充要条件是a <= d 且 b >= c。

用SQL表达就是“已有记录的start_section <= 新记录的end_section”并且“已有记录的end_section >= 新记录的start_section”。这个写法覆盖了完全相等、部分重叠、完全包含三种情况，同时能正确排除首尾相邻的场景。比如已有记录是1到2节，新记录是3到4节，a=1, b=2, c=3, d=4，条件变成1 <= 4成立但2 >= 3不成立，所以不冲突，这符合实际作息。

周次的判断使用完全相同的逻辑。week_start和week_end构成一个闭区间，两个周区间有交集才可能冲突。节次和周次两个条件同时满足时，才真正占用同一个实验室的同一段时间。

2.4 单双周与学期维度带来的查询变化

加上week_type之后，冲突判定多了一个维度。全周排课与单周、双周都存在冲突，因为全周覆盖了所有周次。单周与单周冲突，双周与双周冲突，单周与双周互不冲突。

semester字段则强制改变了查询语句的风格。所有涉及排课记录的查询都要带上“semester = ?”的条件，否则会把往年数据拖进来造成误判。我在维护某实验室系统时遇到过跨学期数据显示混乱的问题，最后查下来就是一处列表查询漏写了学期过滤条件。补一个字段很容易，但遍历所有DAO方法逐一检查才是真正花时间的部分。

3. 从zip到能跑：部署实验室排课系统的最小路径

3.1 环境选型：JDK、容器、数据库的版本搭配

JSP系统的部署环境比较固定。我通常推荐JDK 8搭配Tomcat 8.5或9.x，数据库按zip包内JDBC驱动的情况选择MySQL 5.7或8.0。JDK 8在老项目里最稳，Tomcat 8.5能跑绝大多数JSP工程。MySQL版本要看驱动包的年代，这个细节在第5章会展开讲。

部署前先确认四件事：JDK是否已安装且JAVA_HOME配置正确、Tomcat安装路径、MySQL服务是否在运行、数据库账号密码是否齐全。如果zip包里带了SQL脚本，直接执行即可；如果没有，要根据实体类反向推导建表语句，工作量会增加不少。

以模拟项目X为例，环境是JDK 8加Tomcat 8.5加MySQL 5.7，操作系统不限，Windows和Linux部署步骤只差路径写法。

3.2 数据库初始化：导入SQL脚本

zip包解压后通常会有sql目录，或者直接放一个.sql文件在根目录。数据库初始化的完整命令如下。

# 进入解压后的目录 cd /opt/deploy/lab-schedule # 创建数据库，指定utf8mb4字符集 mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS lab_schedule DEFAULT CHARACTER SET utf8mb4;" # 导入表结构和初始数据 mysql -uroot -p lab_schedule < sql/lab_schedule.sql # 验证表是否创建成功 mysql -uroot -p lab_schedule -e "SHOW TABLES;"

CREATE DATABASE时指定utf8mb4很重要，很多中文乱码问题在数据库初始化这一步就埋下了。utf8mb4比utf8多支持生僻字和特殊符号，实验室名称里出现“Ⅰ号实验楼”“物理楼（东侧）”这类字符时不会报错。

导入完成后一定要用SHOW TABLES核实表清单。如果SQL脚本里自带CREATE DATABASE语句，就不要重复建库，直接导入即可，重复执行虽然不会崩，但会输出一堆“database exists”的提示。

3.3 部署到Tomcat的完整步骤

JSP工程部署到Tomcat最直接的方式是把整个工程目录放到webapps下。zip包里的目录结构如果本身就是Web工程，就不需要打成WAR包。

# 解压zip到Tomcat的webapps目录 unzip lab-schedule.zip -d /opt/apache-tomcat-8.5/webapps/lab-schedule # 查看解压后的目录结构 ls /opt/apache-tomcat-8.5/webapps/lab-schedule # 修改数据库连接配置 vim /opt/apache-tomcat-8.5/webapps/lab-schedule/WEB-INF/classes/db.properties

解压后要找到db.properties或jdbc.properties这类配置文件，修改三项：数据库地址、用户名、密码。连接串一般是jdbc:mysql://localhost:3306/lab_schedule?useUnicode=true&characterEncoding=utf8，如果数据库和Tomcat在同一台机器上，localhost不用动。

配置改完启动Tomcat：

# 启动 /opt/apache-tomcat-8.5/bin/startup.sh # 实时查看日志 tail -f /opt/apache-tomcat-8.5/logs/catalina.out

启动日志是关键。看到“Deployment of web application directory ... has finished”说明工程被正确加载。如果出现ClassNotFoundException，优先检查WEB-INF/lib下有没有对应jar包；如果出现数据库连接相关的异常，先回查配置文件里三项参数。

3.4 部署成功的三个验证信号

部署完成不等于能登录，按下面三个信号依次验证。

第一个信号是Tomcat日志中没有异常堆栈。浏览器访问http://服务器IP:8080/lab-schedule，出现JSP页面而不是404或500，说明工程加载成功。第二个信号是登录页面渲染完整，CSS样式生效、图片不缺失，说明静态资源路径没有硬编码错误。第三个信号是能登录并看到排课列表，说明数据库链路已经打通。

如果在第三步才报错，问题基本集中在数据库连接配置。这时候不要急着改代码，先把db.properties里的URL、用户名、密码核对一遍，再确认WEB-INF/lib下的驱动版本与数据库版本匹配。

zip包里的README.txt通常会注明初始管理员账号，模拟项目X的默认账号是admin/admin123，但具体账号以包内说明为准。这类信息放在第3章是为了让你少走查表的弯路。

4. 实验室排课冲突检测：从SQL到Java的完整实现

4.1 查冲突的核心SQL

新增或修改排课记录之前，必须检查目标实验室在目标时间段内是否有重叠记录。核心查询SQL如下。

SELECT schedule_id FROM t_schedule WHERE lab_id = ? AND semester = ? AND day_of_week = ? AND start_section <= ? AND end_section >= ? AND week_start <= ? AND week_end >= ?;

这条SQL的参数传递顺序是：实验室ID、学期、星期几、新记录的结束节次、新记录的起始节次、新记录的结束周、新记录的起始周。第4和第5个参数是交叉传入的，这是区间重叠判断的关键。

设已有记录的节次区间是[a,b]，新记录区间是[c,d]，两个区间有交集的充要条件是a <= d且b >= c。所以SQL里用已有记录的start_section去比新记录的end_section，用已有记录的end_section去比新记录的start_section。周次判断同理，week_start比新week_end，week_end比新week_start。

4.2 Java层完整实现

SQL把时间区间和星期几都重叠的记录查出来之后，还需要在Java层判断单双周是否匹配。完整实现如下。

import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; public class ScheduleService { public boolean hasConflict(Connection conn, Schedule newSchedule) throws SQLException { String sql = "SELECT schedule_id, week_type FROM t_schedule " + "WHERE lab_id = ? AND semester = ? AND day_of_week = ? " + "AND start_section <= ? AND end_section >= ? " + "AND week_start <= ? AND week_end >= ?"; try (PreparedStatement ps = conn.prepareStatement(sql)) { ps.setInt(1, newSchedule.getLabId()); ps.setString(2, newSchedule.getSemester()); ps.setInt(3, newSchedule.getDayOfWeek()); ps.setInt(4, newSchedule.getEndSection()); ps.setInt(5, newSchedule.getStartSection()); ps.setInt(6, newSchedule.getWeekEnd()); ps.setInt(7, newSchedule.getWeekStart()); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { if (isWeekTypeOverlap(rs.getInt("week_type"), newSchedule.getWeekType())) { return true; } } } } return false; } private boolean isWeekTypeOverlap(int existingWeekType, int newWeekType) { // 0表示全周，与任何类型都可能冲突 if (existingWeekType == 0 || newWeekType == 0) { return true; } return existingWeekType == newWeekType; } }

这段代码把冲突检测分成两层。SQL先粗筛出所有在星期几、节次区间、周区间上重叠的记录，Java层再根据单双周类型做精筛。全周排课覆盖了单周和双周的所有周次，所以只要任何一方是全周，就判定冲突。单周与单周冲突，双周与双周冲突，单周与双周互不冲突。

isWeekTypeOverlap的第一个判断逻辑要仔细理解。existingWeekType为0代表这条已有排课每周都有，那么新排课不管单双周都会撞车。newWeekType为0同理。所以两个值任一为0就直接返回true，不用再比较。

4.3 周次与节次的组合判断

冲突的成立条件是“同一实验室、同一星期几、节次区间重叠、周区间重叠、单双周匹配”五个条件同时满足。SQL里的WHERE已经覆盖了前四个，单双周在Java里兜底。

这里有一个容易漏的细节：周区间要同时考虑week_start、week_end和week_type三个字段。比如现有记录是week_start=1、week_end=16、week_type=1，新记录是week_start=2、week_end=10、week_type=2。两个记录的周区间确实有交集（2到10周），但一个是单周一个是双周，实际上课时间完全错开，不应该判冲突。这个判断必须放在Java层。

节次判断还有另一个现场问题：午休时段的表示。有些学校节次表是从1到12连续编号，午休被编成5到6节，如果不处理，中午时段会被系统误判为可排课。常见做法是在t_lab表增加一个不可用时段字段，或者在配置层把每天5到6节标记为不可排，排课前先过滤这个时间段。

4.4 参数调整与扩展点

冲突检测的SQL一共7个参数，实际维护中有一个调整点值得关注。semester字段可以改为可空，当新排课的semester为空时表示“全年有效”，SQL里对应把学期的过滤条件去掉。这个改动适合设备维护记录类的排课，不区分学期，全年保持一个基准安排。

扩展点方面，实验室类型筛选很实用。机房只能排上机课，电子实验室只能排电子实验，很多系统漏掉了这个约束。可以在冲突检测前加一道前置校验：根据lab_id查出t_lab的lab_type，再与课程的course_type做匹配，不匹配的直接返回业务错误，不进冲突检测。

5. 实验室排课系统避坑指南：五个高频翻车点

5.1 中文乱码

现象：登录后实验室列表页中文字符全变成问号或乱码，直接在数据库命令行查询却显示正常。

原因：JSP页面编码、HTTP请求参数编码、JDBC连接编码三个环节不一致。常见的是JSP页面用了GBK，Tomcat连接器用默认的ISO-8859-1，JDBC URL里没有设置characterEncoding，链路在某一环断掉。

解决：三层统一到UTF-8。JSP页面头部加pageEncoding="UTF-8"，Tomcat的server.xml里给Connector加URIEncoding="UTF-8"，JDBC URL追加useUnicode=true&characterEncoding=utf8。改完三处重启Tomcat。如果页面表单提交后中文还是乱码，检查form标签是否设置accept-charset="UTF-8"，或在Servlet里手动调用request.setCharacterEncoding("UTF-8")。

5.2 JDBC驱动与MySQL 8认证冲突

现象：Tomcat启动正常，但提交登录表单时页面报“Public Key Retrieval is not allowed”或“Communications link failure”。

原因：MySQL 8默认认证插件是caching_sha2_password，老版本mysql-connector-java使用旧协议握手，连接被数据库拒绝。zip包里自带的驱动如果是5.1.x时代的就会出这个错。

解决：把WEB-INF/lib下的mysql-connector-java替换为8.x版本，同时在JDBC URL加allowPublicKeyRetrieval=true&useSSL=false。替换后重启Tomcat，并确认lib目录下没有残留其他版本的驱动jar，两个版本共存会引入新的类加载问题。

5.3 并发提交导致重复排课

现象：两个管理员同时操作，先后提交了同一实验室同一时段的不同课程，两个提交都提示校验通过，数据库里出现两条冲突记录。

原因：先查询再插入之间存在时间窗口。A管理员查询时实验室空闲，B管理员也在同时查询，查到的是A插入前的状态，于是也都通过了检查。单机应用的这个时间窗口虽短，但真实存在。

解决：在t_schedule上建立精确的唯一索引，虽然挡不住区间交叉，但能拦住完全重复的记录。更稳的方案是把冲突检测和插入放进同一个数据库事务，并用SELECT ... FOR UPDATE对当天该实验室的排课记录加锁。这个锁的范围要控制好，锁全表会拖慢整个系统的操作。

注意：FOR UPDATE锁必须在事务内使用，否则锁自动失效。同一把Connection上先执行冲突查询，再执行INSERT，最后统一commit。

5.4 节次边界判断想当然

现象：给实验室排3到4节时系统提示与1到2节冲突，明明两个时段不挨着。

原因：冲突检测SQL里的区间判断写成了“已有记录的start_section <= 新记录的start_section AND 已有记录的end_section >= 新记录的end_section”，意思是已有区间完全包含新区间才算冲突。这只能识别包含关系，漏掉了部分重叠和交叉关系，甚至把相邻区间误判成重叠。

解决：按4.1节的写法改成“start_section <= 新end_section AND end_section >= 新start_section”。这个写法覆盖包含、相交、完全相等三种重叠形式，同时正确排除首尾相邻。[1,2]和[3,4]中，1 <= 4成立但2 >= 3不成立，不判冲突。

5.5 修改了代码却看不到效果

现象：改完一个首页展示的SQL，刷新页面还是旧内容，甚至怀疑自己改错文件了。

原因：JSP页面第一次被访问后会编译成Servlet class，Tomcat在开发模式下能自动检测JSP变化并重新编译，但Java类不会。如果项目以WAR包形式部署，Tomcat解压到webapps下的是WAR包的副本，直接改解压文件不会同步回WAR包，重启后改动被覆盖。

解决：开发阶段用目录部署，不打包WAR。修改JSP后清一下Tomcat的work目录再访问，通常不需要重启整个Tomcat。改Java类必须重新编译并重启，因为Servlet实例已经加载进JVM了。养成一个习惯：每次改动后先看catalina.out有没有重新编译的日志，再刷新页面验证。

6. 进阶：给实验室排课系统加学期维度与复核视图

6.1 补学期字段的正确顺序

如果你拿到的包里的t_schedule没有semester字段，改造第一步是ALTER TABLE而不是改Java代码。所有排课查询都围绕这张表展开，字段补齐后，把查询条件统一带上semester，改动集中在几个DAO方法里。

ALTER TABLE t_schedule ADD COLUMN semester VARCHAR(20) NOT NULL DEFAULT '2024-2025-1' COMMENT '学期编号';

默认值用当前学期，让历史数据先归到同一学期。注意字符串格式不要混用，有的地方写“2024-2025-1”，有的写“2024-2025学年第一学期”，过滤时一致性问题会成一枚隐性地雷。

6.2 按周维度做排课复核表

系统稳定运行后最常用的功能不是添加排课，而是按周查看某个实验室的空闲时段。常见做法是增加一个dashboard页面，查询参数传实验室ID和周次，表格以星期为列、节次为行，单元格里填充课程名称。

这个页面不需要新的SQL，把第4章的查询逻辑反过来：先查出该实验室该周所有排课，在Java层按day_of_week和start_section分组，渲染时映射到表格坐标。如果某个单元格出现两个课程名称，说明该时间段有冲突，复核视图能立刻暴露问题。

6.3 我的一个收尾习惯

每次做完排课系统改造，我都用一组故意冲突的测试数据做回归：排一条完全相同的记录、排一条包含关系的记录、排一条相邻节次的记录、排一条单双周不冲突的记录。这四条用例覆盖了冲突检测的大部分边界。没有这一手，多数冲突bug会在开学排课高峰期集中爆发，到那时候再排查，压力远大于改代码本身。希望帮到你。

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