校园学业预警系统设计与实现：Java规则计算与前端交互全解析

简介：基于Java、CSS和JavaScript构建的校园学生学业预警系统设计源码，面向需要开发教育管理系统或学习Web后端与前端整合的开发者。项目共39个文件，约55.1MB，包含12个Java源文件负责后端逻辑（学生信息管理、成绩分析、预警机制），10个JSP页面处理界面交互，5个XML和2个properties文件完成配置，并有CSS和JavaScript文件增强前端表现与动态验证，同时包含少量图片资源、项目说明文档及Maven构建配置。系统能对学生成绩进行跟踪、分析和实时预警，辅助教师及早发现学业困难并采取干预措施，也为管理者优化资源配置提供数据支持；代码采用模块化分层结构，并配合Git版本管理，便于二次开发与功能扩展。目前已有340人学习下载，是一套融合现代教育理念与Web技术、兼具教学参考和实际应用价值的完整工程源码。

1. 校园学生学业预警系统到底在“预”什么

在课程设计和教务系统开发里，“学业预警”经常被理解成一张不及格名单，就是普通查询。但真正用起来你会发现，辅导员要在学期中段就知道哪些学生处于风险中，不是等期末挂科列表出来才开班会。预警系统要做的是把成绩、缺勤、绩点这些零散数据按规则一起计算，产出黄色、橙色、红色级别，并留下完整的通知和处理轨迹。这套源码以Java为后端，提供预警计算和接口；CSS和JavaScript负责前端列表、悬停、点击处理和状态标记。下面按“规则拆分→Java计算→前端呈现→数据库设计→调参验证”的顺序，把能复现的细节串起来。

2. 用Java把预警规则拆成可维护的四步

预警系统的肉不在页面，在规则计算。很多源码把所有判断堆在一个方法里，结果每次调整阈值都要进去数括号。我习惯先定规则表，再把计算逻辑写成独立的服务。

2.1 预警规则先定清楚：黄色、橙色、红色看哪些指标

动手写代码前，先和教务老师确认四条规则，而不是自己想当然。这里是一份常见规则表，同时对应前端要显示的三种颜色：

这些条件里，“挂科”按培养方案里的必修课算，选修课挂科只记入档案但不触发预警；绩点用教务处统一算法。条件之间是“或”的关系，同一学生的预警级别取最高值，不把多个条件累加成更高级别。规则表用数据表或配置文件维护，别写死在Service里。

2.2 实体类：用Java记录学生、成绩和预警记录

校验和计算都需要承载对象。我会先把四个实体列出来：Student、Course、Score、WarningRecord。下面这些代码是从一个可运行的源码工程里抽出的核心字段，注释标明了每个字段在规则里的用途。

public class Student { private Long id; private String studentNo; // 学号，业务唯一键 private String name; private String deptName; // 学院/系，数据权限用 } public class Course { private Long id; private String courseNo; private String courseName; private Boolean isRequired; // 必修课标记，预警只认必修 } public class Score { private Long id; private Long studentId; private Long courseId; private Double score; // null表示缺考 private String semester; // 如 "2024-2025-1" } public class WarningRecord { private Long id; private Long studentId; private String level; // YELLOW/ORANGE/RED private String reason; // 挂科2门，缺勤1/3 private Integer processed; // 0未处理 1已通知 2已解除 }

参数说明：Score.score保存最终成绩，缺考用null而不是0，因为规则里“缺考”和“考了0分”的后续处理完全不同；WarningRecord.level用字符串是为了前端能直接显示，同时在Java里我会用枚举约束它的取值；processed不要设计成布尔，预警处理以后可能还有“已约谈”“已发通知”“已解除”多个状态，布尔值装不下。

2.2.1 课程表里要留一个属性区分必修和选修

第一版代码最容易漏掉的是Course.isRequired。没有这个字段，预警计算就只能对全部课程生效，选修课挂科也会被拉进来。我见过一个问题：体育选修挂了，系统给学生升到橙色预警，学生志愿者跑来质问为什么。这个问题从一开始建表就能避免。

2.3 预警计算服务：用Java 8 Stream把“挂科门数”算清楚

计算服务应该做成无状态的：输入学期和可选院系，输出一批预警记录，不改动任何成绩数据。这样手动跑、定时任务跑、单元测试跑结果都一样。核心方法如下：

public List<WarningRecord> compute(String semester, Long deptId) { List<Score> scores = scoreMapper.findBySemester(semester); Map<Long, List<Score>> groupByStudent = scores.stream() .filter(s -> s.getScore() != null && s.getScore() < 60) .collect(Collectors.groupingBy(Score::getStudentId)); List<WarningRecord> records = new ArrayList<>(); groupByStudent.forEach((studentId, failScores) -> { long requiredFailCount = failScores.stream() .filter(s -> Boolean.TRUE.equals(s.getCourse().getIsRequired())) .count(); if (requiredFailCount >= 1) { WarningRecord r = new WarningRecord(); r.setStudentId(studentId); r.setLevel(levelFor(requiredFailCount)); r.setReason("必修课挂科" + requiredFailCount + "门"); records.add(r); } }); return records; }

这段逻辑是预警计算的流量入口：先用filter过滤出低于60分的成绩，这决定了哪些学生进入统计；再按学生分组，之后在分组内用filter统计isRequired，这样不需要另开一个循环。levelFor按阈值返回YELLOW/ORANGE/RED，具体阈值从配置文件里读取。参数说明：findBySemester只查一个学期，避免把大一的旧账翻出来；如果你要算累计挂科，就得额外加一个retake字段表示补考是否通过，否则上学期挂科但下学期补考通过的学生会一直被预警。

2.4 落库时用状态字段挡住重复预警

计算和落库分开是一开始就要养成的习惯。因为定时任务每天都会跑一遍compute，同一学期、同一挂科情况不能每天产生一条新记录。persist方法专门处理这个幂等问题：

public void persist(List<WarningRecord> records, String semester) { for (WarningRecord r : records) { Integer count = warningMapper.countOpenByStudent( r.getStudentId(), semester, 0); if (count > 0) continue; warningMapper.insert(r); } }

countOpenByStudent的第三个参数0对应未处理状态。只要还有未处理的同学期记录，就跳过插入。注意“已处理”和“已解除”不算冲突，比如上学期红色预警已经解除，本学期又挂了一门，那该生成新的黄色预警，这是业务上合理的。

3. 前端用CSS和JavaScript把预警结果变成能操作的页面

后端把预警记录写进数据库后，前端要解决的是“怎么让辅导员在几秒内判断该先找谁”。这个场景不需要Vue或React，原生CSS和JavaScript就够了。下面这套页面组织方式在源码里改动最少，也最容易看懂。

3.1 页面布局：左侧名单、右侧详情、底部处理记录

我用一个两列布局把预警名单和学生详情分开：左侧是可滚动的名单，右侧是某个学生的挂科明细，底部再放一个处理记录流。三个区域职责清晰，后端接口也可以独立返回。

<div class="warning-layout"> <aside class="student-list" id="studentList"></aside> <main class="student-detail" id="studentDetail"></main> </div> <div class="action-log" id="actionLog"></div>

这个HTML骨架里没有任何静态数据，所有行都由JavaScript填充。好处是CSS只负责视觉，JavaScript只负责数据，后端字段变了也只改render函数。

3.2 CSS鼠标移入事件：预警列表悬停高亮和已处理删除线

名单行很多时，鼠标移入高亮能避免看错行。这不是一个真正的事件，而是:hover伪类，CSS层面上它完全能覆盖“鼠标移入”的需求。同时我顺手处理了“已解除”的记录：

.student-row:hover { background: #fff8e1; border-left: 4px solid #f57c00; } .student-row.processed .student-name { text-decoration: line-through; }

注意第二段删除线只加在姓名span上。不要给整行加删除线，否则右侧院系、级别信息也会带上横线，在中文语境里容易让人误以为整条记录被废弃。已处理行如果要整体弱化，正确做法是降低整行的透明度或背景明度，而不是划线。

3.2.1 搜索框居中：Flex才是input居中的可靠方案

名单上方要放筛选框。新手常给input直接写margin: 0 auto，却发现它纹丝不动，因为input是替换元素，auto外边距在普通流里不生效。用Flex把父容器改成居中即可，这正是“css中怎么把input居中”的常见做法：

.search-bar { display: flex; justify-content: center; padding: 8px 0; } .search-bar input { width: 240px; padding: 6px 8px; }

如果把input设置成width: 100%，再配合max-width: 240px，同样能居中，而且在小屏下会自动收窄。两种方式都行，选一种用到底。

3.3 JavaScript把后端返回的预警数据渲染成表格

名单区用fetch从/api/warnings拿数据，然后渲染。这里不引第三方库，原生代码够用：

async function loadWarnings() { const res = await fetch('/api/warnings?semester=2024-2025-1'); const list = await res.json(); renderWarnings(list); } function renderWarnings(list) { const container = document.getElementById('studentList'); container.innerHTML = list.map(item => ` <div class="student-row ${item.processed === 2 ? 'processed' : ''}" >document.getElementById('studentList').addEventListener('click', async (e) => { const row = e.target.closest('.student-row'); if (!row) return; const [studentRes, warningRes] = await Promise.all([ fetch(`/api/student/${row.dataset.id}`), fetch(`/api/warning/${row.dataset.id}`) ]); const student = await studentRes.json(); const warning = await warningRes.json(); const merged = Object.assign({}, student, { warning }); renderDetail(merged); });

两个接口并行请求，能省差不多一半的点击响应时间。Object.assign会从右往左覆盖左边对象的同名属性，所以把warning放到最后，可以确保不会丢掉预警信息。如果接口返回的字段名重复且类型不同，这个合并行为会直接暴露问题。

4. 校园学业预警系统的源码目录与数据库设计

这一章讲源码的文件组织方式以及数据库表设计。照着这个结构搭工程，后面加新功能不需要大规模动代码。

4.1 按Spring Boot的三层结构组织源码目录

虽然是课程设计，但我建议仍然按controller/service/mapper分目录，而不是全部塞在一个包里。一个通用目录结构如下：

src/main/java/com/school/warning/ ├── controller/ │ ├── WarningController.java │ └── StudentController.java ├── service/ │ ├── WarningService.java │ └── impl/WarningServiceImpl.java ├── mapper/ │ ├── ScoreMapper.java │ └── WarningMapper.java ├── entity/ │ ├── Student.java │ ├── Course.java │ ├── Score.java │ └── WarningRecord.java src/main/resources/ ├── mapper/ │ ├── ScoreMapper.xml │ └── WarningMapper.xml └── application.yml

这个结构的好处：规则计算在WarningServiceImpl里，controller只做路由和参数校验，mapper只放SQL。很多源码把业务计算写在controller里，当时跑得通，等到要加定时任务、批量导入时，只能复制一份代码，后患很大。

4.2 五张核心表的建表SQL

下面这套建表语句是精简过的，字段只保留和预警相关的内容，放到MySQL里可以直接跑：

CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) UNIQUE NOT NULL, name VARCHAR(50) NOT NULL, dept_name VARCHAR(50) NOT NULL ); CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_no VARCHAR(20) NOT NULL, course_name VARCHAR(100) NOT NULL, is_required TINYINT NOT NULL DEFAULT 1 ); CREATE TABLE score ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, score DECIMAL(5,1), semester VARCHAR(20) NOT NULL, UNIQUE KEY uk_stu_course_sem (student_id, course_id, semester) ); CREATE TABLE warning_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, semester VARCHAR(20) NOT NULL, level VARCHAR(20) NOT NULL, reason VARCHAR(255) NOT NULL, processed TINYINT NOT NULL DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );

score表中score字段允许为NULL，这就是缺考状态。UNIQUE KEY覆盖学生、课程、学期三个维度，保证同一学期同一门课只能有一条成绩。warning_record则故意不加唯一约束，因为幂等要依赖业务判断，如果学生挂科门数从2门变成3门，必须允许生成一条更高级别的新记录。

4.3 成绩批量导入和预警联动的坑

实际使用中最常见的入口不是手工录入，而是从Excel批量导入。读取Excel常用Apache POI或者EasyExcel，逐行读取后先校验再插入score表，最后触发预警重算。这里有一个很容易踩的坑：Excel中的空成绩可能代表“未录入”，也可能代表“缺考”，直接当成null存进去，会把还没有提交成绩的课程也纳入预警计算。我一般会先确认“成绩是否收口”的状态，即该课程的成绩录入在教务侧已锁定，再执行预警计算。

4.4 Controller层只做参数校验，不写业务

预警相关的接口不多，两个就够：查列表和修改处理状态。下面这段controller代码可以直接用：

@RestController @RequestMapping("/api/warnings") public class WarningController { @GetMapping public Result list(@RequestParam String semester, @RequestParam(required = false) Long deptId) { return Result.ok(warningService.findBySemester(semester, deptId)); } @PostMapping("/{id}/processed") public Result markProcessed(@PathVariable Long id, @RequestParam Integer status) { warningService.updateProcessed(id, status); return Result.ok(); } }

list接口的semester必须传，deptId可选。前端不传deptId时，后端不要默认给0，应该传null表示全量，避免把“未选择院系”和“ID为0的院系”搞混。updateProcessed里的status只接受1或2，如果收到0或其它值直接抛出参数异常。

5. 把预警系统调到能用的几个参数和验证办法

最后这部分是上线前我一定回去检查的地方，也是最容易让源码“能跑”变成“能用”的细节。

5.1 预警阈值放到配置里，改规则不用改代码

不要写死if (count >= 3) red。把阈值放到application.yml：

warning: yellow-fail-count: 1 orange-fail-count: 2 red-fail-count: 3

再定义一个WarningProperties类，用@ConfigurationProperties(prefix = "warning")读取。这样教务处想调整阈值时，改配置文件后重新启动即可，不需要动Java代码。注意规则里的“连续两个学期绩点低于1.8”这种时间维度条件，单独写在规则表里比堆在配置里更清晰。

5.2 定时任务让预警每天自动跑

很多源码只在启动时跑一次，成绩出来后几个月都没更新。给计算添加定时任务：

@Scheduled(cron = "0 20 2 * * ?") public void scheduledCompute() { String semester = semesterService.getCurrentSemester(); List<WarningRecord> records = warningService.compute(semester, null); warningService.persist(records, semester); }

cron表达式是每天02:20执行。选择凌晨是因为教务系统一般在夜间同步前一天的成绩，白天跑会把“还没录完”的数据也算进去，产生误报。

5.3 验证口径：同一份数据跑两次结果一致

预警计算必须可验证。简单方法是在本地准备一份固定数据，用curl连续调用两次compute接口，第二次的插入数量应当为0：

curl "http://localhost:8080/api/warnings/compute?semester=2024-2025-1" curl "http://localhost:8080/api/warnings/compute?semester=2024-2025-1"

第一次返回新增记录数，第二次返回0。如果第二次返回大于0，说明persist的幂等判断没生效，优先查countOpenByStudent条件是否和插入时一致。再手动把一条记录改成已通知，重新跑一次，预期会生成新的预警，这正好验证“已处理不等于永久忽略”。

5.4 浏览器侧快速定位问题

前端点击没反应时，先别急着改代码。打开Network面板看请求是否发出、状态码是否200、返回字段名和renderDetail里读取的是否一致。控制台的javascript运行时报错会精确指向某一行，一般出现在item.warning.courseList这种深层读取上，因为前端拿到了undefined。给renderDetail加一行console.log(merged)，能直接确认接口字段是否匹配。在Console里看到报错后，回到Network面板重新核对一次请求参数，问题基本就定位了。

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