简介：这是一份面向高校计算机专业学生的高校学生学业预警系统Python完整项目，适合用作毕业设计或课程设计。系统基于Python后台框架与MySQL数据库构建，前端页面、后端逻辑与数据库脚本一应俱全，围绕学业预警核心流程完成信息管理与数据展示，界面简洁、操作直观，经过严格调试可直接运行，能够帮助开发者快速理解项目结构并完成毕业设计文档与答辩准备。压缩包共319个文件，大小仅4.19MB，包含27个Python源码文件、1个SQL数据库脚本、14个HTML页面、33个JavaScript脚本、24个CSS样式文件，以及多张运行效果图和GIF演示动画，资源紧凑且目录清晰，便于按模块查阅学习。目前已有116人浏览学习。借助其中提供的项目源码、数据库脚本和部署说明，读者可以快速搭建一套可运行的学业预警系统，也能参考页面与逻辑设计进行二次开发，根据院校需求扩展预警规则或调整页面样式，有效节省毕业设计开发与调试时间。
1. 高校学生学业预警系统到底在预警什么：先读懂业务逻辑，再动手写代码
一个辅导员每学期期末都要对着几百条成绩记录，把挂科、绩点低、缺勤多的学生一个个挑出来，这个动作放到系统里就是学业预警。它不是一个复杂的算法问题，核心是“用明确规则把成绩数据变成预警名单”。基于python的高校学生学业预警系统，本质上就是Web后台 + 数据库 + 规则判定三件事。常见的毕业设计打包资源会带上源码、数据库初始化脚本和部署教程，你拿到的不是一个小到只能跑通的最小demo，而是一个需要自己复现、能讲清楚设计逻辑的完整工程。适合两类人：一类是准备做Python毕设的学生，一类是打算在校内真实部署这套系统的教务或辅导员老师。接下来我会按建库、写判定逻辑、避坑、进阶的顺序，把这个项目完整拆开讲清楚。
2. 把预警落到数据表：数据库设计是第一道门槛
2.1 为什么选 Flask/Django + MySQL，而不是 SQLite
做高校学业预警系统，技术栈其实没有太多争议。毕设场景下最常见的是 Python Web 框架 + 关系型数据库的组合，框架二选一：Django 自带 Admin 后台、ORM 和用户认证，答辩时能直接展示一个像样的管理界面，适合对前端不太熟悉的人；Flask 更轻，路由和视图自己写，代码逻辑完全透明，适合想讲清楚“每行代码在干什么”的人。我一般建议优先选 Django，因为学业预警系统天然需要学生管理、成绩管理、预警记录管理三块后台页面，Django Admin 能省掉大量增删改查的重复工作。
数据库方面我强烈建议用 MySQL，不要因为图省事选 SQLite。原因很现实：答辩和面试时，MySQL 的事务、索引、连接池这些概念都是高频问题，你用 SQLite 很难把话题引到这些点上；再说真实部署环境里，教务数据量不大但并发访问确实存在，MySQL 8.0 默认 InnoDB 引擎对这笔数据量绰绰有余。这个项目里的“数据库”不只是存数据的地方，预警规则的阈值配置、预警记录的落库去重都靠它。连接方式上，常见做法是 PyMySQL + SQLAlchemy 的连接池，避免每次请求都新建数据库连接。
2.2 五张核心表：学生、课程、成绩、预警规则、预警记录怎么建
学业预警的业务链条其实很短：读成绩、算指标、对照规则、生成记录。五张表就能把这件事说完整。建库时先写一段统一字符集的建库语句，避免后面编码踩坑：
CREATE DATABASE IF NOT EXISTS warning_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;学生表记录学生基本信息，注意学号用主键字符串而不是自增整数，因为学号是业务里天然的主键，也方便和教务导出的数据直接对齐。
CREATE TABLE student ( student_no VARCHAR(20) NOT NULL COMMENT '学号', student_name VARCHAR(50) NOT NULL COMMENT '姓名', college VARCHAR(100) COMMENT '学院', major VARCHAR(100) COMMENT '专业', class_name VARCHAR(50) COMMENT '班级', enroll_year VARCHAR(4) COMMENT '入学年份', status TINYINT DEFAULT 1 COMMENT '1在籍 0休学', PRIMARY KEY (student_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;课程表和成绩表是成对出现的。课程表存课程编号、名称、学分；成绩表是整张预警系统的数据底座，它的字段设计直接决定后面规则能不能算准。
CREATE TABLE course ( course_no VARCHAR(20) NOT NULL COMMENT '课程编号', course_name VARCHAR(100) NOT NULL COMMENT '课程名称', credit DECIMAL(4,1) COMMENT '学分', course_type VARCHAR(10) COMMENT '必修/选修/公选', PRIMARY KEY (course_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE score ( id INT AUTO_INCREMENT PRIMARY KEY, student_no VARCHAR(20) NOT NULL COMMENT '学号', course_no VARCHAR(20) NOT NULL COMMENT '课程编号', semester VARCHAR(20) NOT NULL COMMENT '学期编码，如2023-2024-1', score DECIMAL(5,1) COMMENT '百分制成绩', score_state TINYINT DEFAULT 1 COMMENT '1正常 0缺考 -1缓考 2作弊', score_std VARCHAR(10) DEFAULT 'normal' COMMENT 'normal正常/retake重修', UNIQUE KEY uk_stu_course_sem (student_no, course_no, semester, score_std) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;预警规则表和预警记录表是整个系统的灵魂。规则表独立成表而不是写死在 Python 代码里，是因为教务老师随时会改阈值：这学期挂科两门预警，下学期可能改成三门。把规则放进数据库，改一条记录就可以，不用改代码重新发布。
CREATE TABLE warning_rule ( id INT AUTO_INCREMENT PRIMARY KEY, rule_code VARCHAR(20) NOT NULL COMMENT '规则编码，如FAIL_COUNT', rule_name VARCHAR(50) NOT NULL COMMENT '规则描述', indicator VARCHAR(20) NOT NULL COMMENT '指标类型：fail_count/gpa/retake_count', threshold VARCHAR(20) NOT NULL COMMENT '阈值，支持数值或比较符', warning_level VARCHAR(10) NOT NULL COMMENT 'warning/severe', is_active TINYINT DEFAULT 1 COMMENT '是否启用', UNIQUE KEY uk_rule (rule_code, warning_level) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;2.3 成绩表的扩展字段：学期、成绩状态、重修标记一个都不能少
很多人在设计成绩表时只放student_no、course_no、score三列，做完后才发现整天翻车。成绩表至少要有三个容易被忽略的字段。
第一是semester学期字段。预警只针对“当前学期”或“某学年”，不带学期字段，跨年统计就会把大一挂的课和大三挂的课混在一起，阈值完全失真。第二是score_state成绩状态。教务导出的成绩单里经常混着“缺考”“缓考”“作弊”这样的文本，如果不加状态字段统一转成数值，缺考就会被当成 0 分，和真正考了 0 分的人混在一起，挂科门数瞬间爆表。第三是score_std是否重修。很多学生挂科后重新修这门课，同一课程编号会有两条成绩。统计“本学期挂科门数”时，如果不知道哪条是重修记录，很容易把同一门课算两次。这三个字段每个都对应一个真实踩过的坑，第四节我会逐个展开讲排查过程。
3. 跑通预警核心逻辑：成绩导入、规则判定、落库三步走
3.1 用 Pandas 读 Excel 成绩单，先清洗再入库
高校教务系统导出的成绩单，最常见格式是 Excel，列里有学号、姓名、课程编号、课程名称、学分、成绩。直接把这些数据读进 MySQL 很简单，但直接读不等于能直接算。先用 Pandas 做一次清洗，把字符串型成绩和状态型成绩拆开，再写库。
import pandas as pd from sqlalchemy import create_engine engine = create_engine( 'mysql+pymysql://root:你的密码@127.0.0.1:3306/warning_db?charset=utf8mb4' ) # dtype 把学号读成字符串，防止 1001001 被读成 1001001.0 df = pd.read_excel('2023_2024_1_scores.xlsx', dtype={'student_no': str}) # 把文本成绩映射成状态，数字成绩保留为正常 state_dict = {'缺考': 0, '缓考': -1, '作弊': 2} df['score_state'] = df['score'].apply( lambda x: state_dict.get(x, 1) if isinstance(x, str) else 1 ) # 不能直接转成数字的文本，统一变成 NaN df['score'] = pd.to_numeric(df['score'], errors='coerce') # 状态不是正常 1 的，即使成绩是 NaN 也要保留 df_valid = df[df['score'].notna() | (df['score_state'] != 1)].copy() df_valid['semester'] = '2023-2024-1' df_valid['score_std'] = 'normal' df_valid.to_sql('score', engine, if_exists='append', index=False)这段代码的关键在于errors='coerce'和score_state的分工。errors='coerce'会把“缺考”“缓考”这些文字转成 NaN，避免整列数据类型变成 object 导致后面没法比较大小；score_state负责记住原始状态是缺考、缓考还是作弊。注意df_valid的过滤条件：只要成绩不是 NaN 就保留，或者状态不是正常也保留，这样缺考记录虽然成绩是 NaN，但它的状态信息完整，后面规则判定时能单独识别。
还有两个容易忽略的点：dtype={'student_no': str}必须加，不加的话学号列会变成 float，后面和 student 表关联时会对不上；to_sql的if_exists='append'是追加模式，重复执行同一份 Excel 会导致重复数据，所以这个脚本只适合首次初始化或配合去重逻辑使用。
3.2 规则怎么定：挂科门次、绩点、重修记录三层判定
预警规则表建好了，但真正可复用的判定逻辑要放在 Python 里，从规则表动态读取阈值，而不是在代码里写死 if。这个设计的好处后面会说，先看核心判定函数。
import pandas as pd def calc_gpa(score_row): """简化的课程绩点：60分=1.0，每高1分+0.1""" if score_row['score'] >= 60: return round((score_row['score'] - 50) / 10, 2) return 0.0 def evaluate_student(scores_df, rules_df): """对单个学生的成绩记录做预警判定，返回预警等级与原因""" if scores_df.empty: return 'none', [] # 正常考试且成绩小于60，算挂科 fail_df = scores_df[(scores_df['score'] < 60) & (scores_df['score_state'] == 1)] fail_count = len(fail_df) # 重修记录单独统计 retake_count = len(scores_df[scores_df['score_std'] == 'retake']) # 平均学分绩点，按学分加权 total_credit = scores_df['credit'].sum() if total_credit > 0: gpa = (scores_df['score'].apply(lambda r: calc_gpa({'score': r})) * scores_df['credit']).sum() / total_credit gpa = round(gpa, 2) else: gpa = 0.0 result = [] level = 'none' for _, rule in rules_df.iterrows(): if rule['indicator'] == 'fail_count' and fail_count >= float(rule['threshold']): result.append(rule['rule_code']) elif rule['indicator'] == 'gpa' and gpa < float(rule['threshold']): result.append(rule['rule_code']) elif rule['indicator'] == 'retake_count' and retake_count >= float(rule['threshold']): result.append(rule['rule_code']) if any(rules_df[rules_df['rule_code'].isin(result)]['warning_level'] == 'severe'): level = 'severe' elif result: level = 'warning' return level, result这段代码的判定顺序是：先洗干净数据，再算挂科门次、重修门次、加权绩点，最后逐条比对规则表。注意calc_gpa这里用的是简化的单科绩点算法，实际很多学校用的是“成绩分段映射绩点表”，比如 90 分以上 4.0、85-89 是 3.7 这类，这个函数完全可以换成查表逻辑，不影响整体结构。
参数设置的要点集中在warning_rule表里。常见的一套初始配置是：挂科门次大于等于 2 触发“一般预警”，大于等于 4 触发“严重预警”；平均学分绩点低于 2.0 触发“一般预警”，低于 1.5 触发“严重预警”；重修门次大于等于 2 触发“一般预警”。这些阈值不要拍脑袋定，最好拿上一学年的真实成绩跑一遍，看预警告警人数占学院总人数多少，比例太高会失去参考价值，太低又会漏掉真正需要关注的学生。
3.3 预警落库与去重：别让同一个人被预警十遍
判定出预警等级后，下一步是把结果写进warning_record表。这块如果直接无脑 INSERT，跑一次任务就产生一批重复记录。经典的坑是：系统每天定时跑预警任务，同一个学生同一学期挂了三门课，他就被生成几十条一模一样的预警记录。解决思路是给预警记录表建立唯一索引，再借助INSERT IGNORE保证幂等。
import pymysql conn = pymysql.connect(host='127.0.0.1', user='root', password='你的密码', database='warning_db', charset='utf8mb4') records = [ ('20230001', '2023-2024-1', 'FAIL_COUNT', 'warning'), ('20230002', '2023-2024-1', 'FAIL_COUNT', 'severe'), ] sql = """ INSERT IGNORE INTO warning_record (student_no, semester, rule_code, warning_level, warn_date) VALUES (%s, %s, %s, %s, NOW()) """ with conn.cursor() as cursor: cursor.executemany(sql, records) conn.commit()配合第一节建表语句里的UNIQUE KEY uk_warning (student_no, semester, rule_code, warning_level)，只要这个学生的同一条规则在同一学期已经存在，INSERT IGNORE就会静默跳过重复记录，不会报错也不会产生脏数据。代码里executemany批量提交是为了减少数据库交互次数，几百个学生也就一眨眼的事。
还有一点容易被忽略：预警记录里带了warning_level，但去重时不能把这个字段去掉。如果一个学生先触发一般预警，后来挂科数量增加变成了严重预警，唯一索引要允许这两个不同等级各有一条记录，否则严重预警会被一般预警挡掉，导致升级预警无法写入。
4. 避坑指南：五个让我查了一整晚的问题
4.1 成绩数据清洗阶段的高频坑
坑一：Excel 里“缺考”混进数字列，导致整列变成字符串，成绩比较全部失效。
现象：从 Excel 导入成绩后，执行df[df['score'] < 60]报错，或者筛选出来空荡荡没有数据。查看df.dtypes，发现score列类型是 object 而不是 float64。
原因：Pandas 读取整列时只要有一个非数字的“缺考”文本，整列就会统一降级为字符串类型。字符串'58'和60比较时是逐字符比较，'58' < '60'没问题，但'100' < '60'也不成立，结果完全不可控。
解决：不要只做pd.to_numeric(df['score'], errors='coerce')，还要在进入判定逻辑前检查df['score'].dtype是否是 float64。同时用score_state把缺考、缓考、作弊单独拆出去，让分数列只保留真正的分数和 NaN，判定挂科时再叠加状态过滤。
坑二：学号被 Pandas 读成浮点数，关联学生表时对不上。
现象：数据库里 student 表的学号是20230001，导入成绩后关联查询却匹配不到任何学生。
原因：Excel 里学号列如果没设置成文本格式，Pandas 默认会把超过一定长度的数字读成 int64 或 float64，20230001可能保存成20230001.0，这串带小数点的内容当然匹配不上。
解决：pd.read_excel时必须传dtype={'student_no': str}，而且最好在读取后用.astype(str).str.strip()清理空白字符。如果成绩单是 CSV 格式，读取时还要注意编码，常见做法是pd.read_csv(file, encoding='utf-8-sig', dtype={'student_no': str})。
4.2 预警计算与运行阶段的高频坑
坑三：学生重修考过了，旧挂科记录仍然在触发预警。
现象：某学生大一挂过高数，大二重修通过了。系统统计挂科门数时，把大一和大二的成绩都算进去，导致他一直被预警。
原因：同一course_no、同一学生、不同学期存在两条成绩记录。统计“当前学期挂科”和“历史累计挂科”是两种需求，前者只取semester='2023-2024-1'的数据，后者要把同名课程取最高成绩或者只保留最终通过状态。把两条原始记录都丢进统计，必然重复计算。
解决：统计当前学期挂科时，先按semester过滤；统计历史累计挂科时，用group_by和学生课程维度取重修后的最终成绩。在建表时我给score_std字段留了'normal'/'retake'两个值，统计时可以直接df[df['score_std'] == 'normal']，把一次有效的原始成绩和重修成绩分开。
坑四：预警任务每天定时执行，预警记录无限重复。
现象：跑了三天定时任务，warning_record 表里同一个学生同一学期出现三四十条重复记录。
原因：任务脚本没有做幂等控制，每次执行都无条件批量插入新预警记录，哪怕上一条还没被辅导员处理。
解决：warning_record表增加唯一索引(student_no, semester, rule_code, warning_level)，插入时改用INSERT IGNORE。如果不想用INSERT IGNORE，也可以先SELECT判断再插入，但作为定时任务和考虑并发，INSERT IGNORE更稳。另外注意，处理状态字段process_status不能参与唯一索引，否则同一条预警从“未处理”变“已处理”时会被索引挡住。
坑五：Navicat 建库正常，Python 插入中文却报错或乱码。
现象：在 Navicat 里手动插入中文没问题，一跑 Python 脚本就报Incorrect string value。
原因：建库时没指定字符集，MySQL 默认库用了latin1，Navicat 连接时自动转了编码所以没暴露；PyMySQL 默认按utf8mb4发送数据，两边字符集对不上。
解决：建库语句统一加上DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。连接字符串里也显式写?charset=utf8mb4，不要省略任何一边的编码声明。遇到过这种情况后我养成了一个习惯：任何新建的 MySQL 库，第一件事先执行SHOW CREATE DATABASE，确认字符集，免得中途再收拾烂摊子。
5. 进阶玩法：预警规则配置化 + 手动核算验证
5.1 把阈值从数据库表升级成 JSON 配置，灵活应对改规则
规则表适合人工维护，但当规则数量多了，每次调阈值都要打开数据库改一行记录，还是不够直观。我习惯把常用规则做成一份 JSON 配置，Python 启动时读取，改了配置只重启服务就能生效，不需要改任何 SQL 和代码逻辑。配置结构很简单，按指标分类存阈值和等级：
{ "fail_count": {"threshold": 2, "level": "warning"}, "fail_count_severe": {"threshold": 4, "level": "severe"}, "gpa": {"threshold": 2.0, "level": "warning"}, "gpa_severe": {"threshold": 1.5, "level": "severe"}, "retake_count": {"threshold": 3, "level": "warning"} }加载这段配置时，优先用规则表里的数据覆盖同名字段，数据库里的配置是“活”的，JSON 是默认值。这样既能在演示时快速展示“阈值一改，预警名单立刻变”，也能保留规则表让非技术用户自行维护。我在第五节开头提到的规则判定函数也改成读取这份配置，判定逻辑本身不变，但参数从配置文件进来，测试不同阈值时就不用反复改代码再重启了。
5.2 验证方法：用手工核算盯住系统输出
系统没写验证逻辑就跑全量数据，很容易被一条脏数据带偏。我常用的做法是：挑三个典型学生手工核算。比如一个学生本学期挂两门课，每门 3 学分，平均绩点 1.87，按上面 JSON 配置，fail_count=2触发 warning，gpa=1.87 < 2.0也触发 warning，最终等级应为 warning。再挑一个只挂了一门课但重修了三门的学生，应该只触发retake_count规则。把手工结论和系统生成的warning_record对比，对不上的再去查原始成绩，基本就能定位是清洗问题还是规则问题。
除了手工核算，还可以在后台预警记录列表里加一个“预警因子”展示列，把result里的 规则编码显示出来。这个很小的改动对使用方非常友好，辅导员能直接看到“这个学生是因为挂科门次还是绩点被预警的”，而不是看到一个笼统的等级数字。
最后说一个我的习惯：预警系统跑完不是终点，名单出来之后一定要留一个“处理结果”字段，让辅导员把约谈、家长沟通、帮扶措施记下来。技术上这只是一行字段的事，但它会让整个系统从“跑一次就没用”变成“能持续运转的工作台”。数据的闭环比预警本身更重要。这套方案里的建表、清洗、去重和验证思路，我希望你能在拿到的毕设源码里逐个对应着看一遍，真正做到看得懂、讲得出、能改能动。希望帮到你。
本文还有配套的精品资源，点击获取
