高校教师用的Django考试系统：MySQL题库+多条件组卷+在线阅卷

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

简介：专为高校教师设计的课程考试辅助工具，基于Django开发，后端用MySQL管理题库数据，支持按课程、章节、知识点、难度等级、题型（单选、多选、判断、填空、简答）等组合条件自动抽题或手动编排试卷。内置三类角色权限：管理员统筹全局，教师负责题库维护与试卷生成，学生参与在线考试并查看成绩。题库支持批量导入导出、题目分类标签、重复题检测和审核流程。试卷生成后可实时预览，通过html2canvas截图存档，兼容PDF导出准备。前端采用轻量级HTML+CSS+jQuery，适配PC与平板设备。项目结构规范，含完整Django应用模块（models/views/urls/forms/admin）、配置文件、测试脚本及依赖清单（requirements.txt），开箱即用，适合教学实践、课程设计或毕设二次开发。

1. 这不是又一个“在线考试Demo”，而是一套真正能进教室、进教务流程的考试辅助系统

我带过三届《Web开发实践》课程设计，每年都有学生想做“在线考试系统”。但翻看他们交上来的代码，90%停留在“登录页+两道单选题+提交按钮”的Demo阶段——题库硬编码在views里，试卷生成靠random.sample()随便抽几道，阅卷逻辑写死在模板里，连“教师改简答题”这种基础功能都得靠截图发微信。直到2021年，我们学院一位讲《数据库原理》的王老师，把这套Django考试系统部署到院内测试服务器上，连续两个学期用于《数据结构》期中随堂测验，我才真正理解什么叫“教学场景可用”。

它解决的从来不是“能不能跑起来”，而是“教师愿不愿意用、能不能嵌进现有教学节奏里”。比如教师录入一道填空题时，系统会自动提取题干中的下划线位置作为答案锚点；组卷时勾选“本章重点知识点：二叉树遍历”，后台不是简单匹配标签，而是通过章节-知识点-题目三级关联表反向追溯，确保抽取的题目确实覆盖该知识点下的全部子概念；学生交卷后，系统不只显示“得分85”，还会生成一份错题分析报告，标出哪道题对应教材第几章第几节，甚至提示“同类题型在往年期末卷中出现过3次”。这些细节，全来自王老师在监考现场随手记下的小纸条：“学生总问‘这题考哪一节’”“批简答题时想快速定位同一题的所有答卷”。

关键词里的Django考试系统，本质是把教学法逻辑翻译成代码结构；MySQL题库管理，核心不在数据库选型，而在如何用关系模型表达“一道题属于多个知识点、同一知识点分布在不同章节、某章节下有必考/选考题型”这种教育学语义；自动组卷工具，难点不是算法，而是让教师能像翻教材目录一样操作条件面板；在线考试平台，真正的门槛是让学生在宿舍用老旧笔记本也能稳定作答，而不是追求炫酷动画。这套系统没用Vue或React，坚持用jQuery，不是技术保守，是因为学院机房电脑平均安装的是IE11兼容模式——你得先让系统活下来，才能谈优化。

它适合两类人：一是计算机专业本科生做课程设计或毕设，代码结构干净、模块边界清晰、每个app职责单一（question_bank管题库、exam_paper管组卷、online_exam管考试流程），连tests.py里都写了模拟教师登录→创建章节→录入5道单选题→按难度抽卷→学生作答→教师阅卷的完整链路测试；二是高校一线教师，不需要懂Python，只要会Excel批量导入题库、会拖拽调整试卷顺序、会点击“导出PDF存档”，就能替代掉原来用Word手动拼卷、用Excel统计分数、用邮箱收作业的低效流程。下面我就以一个真实部署过的版本为基础，带你一层层拆解它怎么从代码变成教学生产力。

2. 系统整体设计与思路拆解：为什么选择Django+MySQL这个“老组合”

很多人看到项目描述第一反应是：“都2024年了，还用Django？前端就jQuery？是不是过时了？”这个问题我被问过至少二十次。答案很实在：教学系统的首要指标不是技术先进性，而是部署稳定性、维护可预期性和教师操作直觉性。让我用三个真实场景说明为什么这个看似“保守”的技术栈反而成了最优解。

2.1 教师视角：拒绝学习成本，拥抱操作惯性

王老师第一次试用时，我特意坐在旁边观察。他打开题库管理页面，看到“章节树形列表”和“知识点标签云”并排显示，立刻说：“这就像我备课用的思维导图软件。”当他把一道题拖进“第三章 树结构”节点下，系统自动在右侧弹出“关联知识点”多选框（预置了“先序遍历”“中序遍历”“后序遍历”三个选项），他勾选后点击保存，整个过程没看任何说明书。如果换成Vue组件，哪怕界面更美观，他也得先理解“组件通信”“状态管理”这些概念——而他的目标只是“把上周布置的5道编程题录进系统”。

Django Admin天然契合教师的操作习惯：增删改查就是表格操作，字段类型对应现实概念（CharField=题目文本，IntegerField=难度分值，ForeignKey=所属章节）。MySQL的ACID特性在这里不是技术炫耀，而是保障“教师同时编辑同一道题时不会丢数据”——去年有次学院统一录入题库，7位老师并发操作，没出现一条脏数据。

2.2 开发视角：用Django的“约定优于配置”对抗教学需求的碎片化

高校考试需求极其琐碎：《高等数学》要支持公式题（需MathJax渲染），《大学英语》要插入音频链接，《电路分析》要上传电路图。如果用纯REST API+前端框架，每个新需求都要重写前后端交互逻辑。而Django的Model-View-Template三层分离，让扩展变得可预测：

• 新增题型？只需在models.py里继承Question基类，定义MultipleChoiceQuestion或EssayQuestion，Django Admin自动识别新字段；
• 增加审核流程？在Question模型里加status = models.CharField(choices=[('draft','草稿'),('reviewing','审核中'),('published','已发布')])，然后在Admin里注册QuestionAdmin，重写get_list_display()方法显示状态列；
• 支持公式题？在Question.content字段上加help_text="支持LaTeX语法，如 $E=mc^2$", 前端模板里用{{ question.content|safe }}渲染，再引入MathJax CDN。

这种扩展方式，让王老师自己学会了给系统加功能。他发现学生常把“判断题”答成“单选题”，就在QuestionType模型里新增is_judgement=True字段，然后在组卷条件筛选器里加个复选框——整个过程只改了3个文件，不到20行代码。

2.3 运维视角：MySQL不是性能瓶颈，而是数据可信度的锚点

有人质疑：“题库量大了MySQL扛不住吧？”我们做过压力测试：当题库达到5万道题（含1.2万道图片题），单次组卷响应时间仍稳定在1.2秒内。为什么？因为真正的瓶颈从来不是数据库查询速度，而是教师对数据准确性的绝对要求。比如一道题被标记为“难度：困难”，但它在近三年5次考试中平均得分率是82%，系统必须能追溯到每次考试的原始成绩数据，验证这个标签是否失效。MySQL的事务日志（binlog）和外键约束，保证了“修改题目难度”操作必然同步更新所有关联试卷的统计报表——这点NoSQL数据库很难做到。

更关键的是，学院教务处要求所有考试数据留存10年，且能随时接受审计。MySQL的备份策略成熟（mysqldump+定时脚本），恢复流程标准化（导入SQL文件即可），而MongoDB的备份恢复在非专业运维手里容易出错。去年教务系统升级，我们把考试数据从旧系统迁入新库，用的就是MySQL的INSERT ... SELECT语句直接跨库迁移，全程无数据丢失。

所以这个技术选型的本质是：用Django的成熟生态降低教学场景的不确定性，用MySQL的强一致性守住教育数据的生命线。它不追求高并发，但必须零差错；不强调炫技，但要求每一步操作都有迹可循。当你看到requirements.txt里只有Django==3.2.23和mysqlclient==2.2.4这两个核心依赖时，就应该明白——这不是技术贫乏，而是精准克制。

3. 核心细节解析与实操要点：题库结构设计与多条件组卷的底层逻辑

很多开发者卡在第一步：题库数据库表怎么设计？网上搜到的方案要么太简单（一张questions表塞所有字段），要么太复杂（十几个关联表绕晕新人）。这套系统采用了一种“教育语义优先”的折中方案，核心是四张表：Chapter（章节）、KnowledgePoint（知识点）、Question（题目）、QuestionTag（题目标签）。下面我用《数据结构》课程的真实案例，带你走一遍设计背后的思考。

3.1 题库四表结构：为什么不用“一张大表”，也不用“过度规范化”

先看关键表结构（简化版）：

# models.py
class Chapter(models.Model):
    course = models.ForeignKey('Course', on_delete=models.CASCADE)
    name = models.CharField(max_length=100)  # 如"第三章 树"
    order = models.PositiveSmallIntegerField()  # 排序序号，方便前端拖拽调整

class KnowledgePoint(models.Model):
    chapter = models.ForeignKey(Chapter, on_delete=models.CASCADE)
    name = models.CharField(max_length=100)  # 如"二叉树的遍历"
    weight = models.FloatField(default=1.0)   # 权重，组卷时按此比例分配题量

class Question(models.Model):
    TYPE_CHOICES = [
        ('single', '单选题'),
        ('multiple', '多选题'),
        ('judgement', '判断题'),
        ('fill', '填空题'),
        ('essay', '简答题'),
    ]
    chapter = models.ForeignKey(Chapter, on_delete=models.CASCADE)
    type = models.CharField(max_length=10, choices=TYPE_CHOICES)
    content = models.TextField()  # 题干，支持HTML/LaTeX
    difficulty = models.PositiveSmallIntegerField(choices=[(1,'易'),(2,'中'),(3,'难')])
    status = models.CharField(max_length=20, default='published')

class QuestionTag(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    knowledge_point = models.ForeignKey(KnowledgePoint, on_delete=models.CASCADE)
    # 注意：这里没有主键，用联合唯一约束保证一道题对同一知识点只关联一次
    class Meta:
        unique_together = ('question', 'knowledge_point')

为什么这样设计？举个例子：一道关于“中序遍历”的填空题，它既属于Chapter（第三章 树），又关联到KnowledgePoint（二叉树的遍历），还可能同时打上“算法实现”“时间复杂度”两个标签。如果只用一张questions表，knowledge_points字段就得存JSON字符串，导致无法用SQL高效查询“所有涉及‘时间复杂度’的知识点的题目”。但如果拆成Question-KnowledgePoint多对多中间表，又会带来冗余——因为一道题必然属于某个章节，而知识点本身已绑定章节，所以Question直接外键Chapter更合理，QuestionTag只负责“题目-知识点”的多对多映射。

提示：QuestionTag表的设计是系统灵活性的关键。它允许一道题关联多个知识点（如“哈夫曼编码”既属“树结构”，也属“贪心算法”），也支持同一知识点下不同题型的分布统计。组卷时，教师选择“知识点：哈夫曼编码”，系统会自动找到所有关联该知识点的题目，无论题型是单选还是简答。

3.2 多条件组卷的实现逻辑：不是简单WHERE，而是权重博弈

组卷界面看起来只是几个下拉框和滑块，但后台执行的是一个“约束满足问题”（Constraint Satisfaction Problem）求解器。核心逻辑在exam_paper/utils.py的generate_paper()函数里，它分三步走：

第一步：条件预过滤（Pre-filtering）
根据教师选择的课程、章节、题型、难度范围，生成基础SQL查询：

SELECT * FROM question 
WHERE course_id = 123 
  AND chapter_id IN (45,46) 
  AND type IN ('single','multiple') 
  AND difficulty BETWEEN 2 AND 3

这步很快，但只解决“硬性约束”。

第二步：知识点权重分配（Weighted Distribution）
这才是精华。假设教师勾选了3个知识点：A（权重2）、B（权重3）、C（权重1），要求生成20道题。系统先计算总权重=6，然后按比例分配题量：A应占20×2/6≈7题，B占10题，C占3题。接着对每个知识点，从预过滤结果中随机抽取对应数量题目。如果某知识点题目不足（如C只有2道），则按比例缩减其他知识点题量，并触发告警：“知识点C题量不足，已自动调整为2题”。

第三步：难度均衡校验（Difficulty Balancing）
抽取完成后，检查整套试卷的难度分布是否符合教师设定的“易:中:难=2:5:3”。如果不符（比如抽到12道中等题），系统会启动“置换算法”：从题量最多的难度组里随机选题，替换为其他难度组的题目，直到满足比例。这个过程最多尝试10次，失败则返回“未找到满足条件的题目组合”，而非强行凑数。

实操心得：我在调试时发现，当教师设置“难度：仅困难”且“知识点：冷门概念”时，置换算法容易超时。解决方案是在Question模型里增加popularity_score字段（基于历史考试出现频次计算），预过滤时优先保留高流行度题目，大幅降低置换失败率。这个字段后来成了王老师最喜欢的“隐形助手”——他发现系统推荐的题，往往就是学生反馈最难的那些。

3.3 在线阅卷的特殊设计：简答题批改不是“打分”，而是“构建反馈闭环”

学生交卷后，教师进入阅卷页。表面看只是个评分表单，但背后藏着教学法设计：

• 简答题批改区：左侧显示学生答案（支持Markdown渲染），右侧是预置评语库（如“思路正确，计算步骤缺失”“未考虑边界条件”）。教师点击评语，系统自动在答案下方插入带时间戳的批注。
• 多人协同阅卷：当一道简答题需要两位教师共同评定时，系统生成ReviewTask对象，分配给指定教师。第二位教师批改后，分数取平均值，评语合并显示，且记录每位教师的原始评语供复核。
• 错题归因分析：阅卷完成后，系统自动生成QuestionAnalysis报告，不仅统计“本题正确率”，还关联到知识点维度：“在‘二叉树遍历’知识点下，填空题正确率62%，简答题正确率38%，表明学生掌握算法步骤但不理解原理”。

这个设计源于王老师的抱怨：“光给分没用，我要知道学生卡在哪。”所以系统把阅卷动作转化为教学数据采集点——每次点击评语，都在为后续的“个性化复习推送”积累训练样本。

4. 实操过程与核心环节实现：从零部署到首次组卷的完整链路

现在我们动手部署这套系统。别担心，整个过程控制在30分钟内，我以Ubuntu 22.04服务器为例（本地开发用Windows/Mac同理，只需替换路径分隔符）。重点不是命令本身，而是每个步骤背后的“教学场景适配逻辑”。

4.1 环境准备与依赖安装：为什么坚持Python 3.8 + Django 3.2

# 创建虚拟环境（避免污染系统Python）
python3.8 -m venv exam_env
source exam_env/bin/activate

# 安装依赖（注意：requirements.txt里指定了精确版本）
pip install -r requirements.txt
# 关键依赖包括：
# Django==3.2.23          # LTS版本，长期支持至2024年
# mysqlclient==2.2.4      # MySQL驱动，兼容Python 3.8
# html2canvas==1.4.1      # 前端截图库，版本锁定防API变更
# django-compressor==4.4  # 静态文件压缩，提升机房老旧电脑加载速度

为什么不用最新Django？因为学院机房电脑的Chrome版本停留在87，而Django 4.x的Admin界面依赖较新的CSS特性，会导致表格错位。Django 3.2.23是最后一个全面兼容Chrome 87的LTS版本，且安全补丁持续更新到2024年——这对需要长期运行的教学系统至关重要。

4.2 MySQL数据库初始化：建库、授权、导入初始数据

-- 登录MySQL
mysql -u root -p

-- 创建专用数据库（避免与教务系统冲突）
CREATE DATABASE exam_system CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- 创建应用用户（最小权限原则）
CREATE USER 'exam_user'@'localhost' IDENTIFIED BY 'StrongPass123!';
GRANT SELECT, INSERT, UPDATE, DELETE ON exam_system.* TO 'exam_user'@'localhost';
FLUSH PRIVILEGES;

-- 退出MySQL，导入初始数据（含默认课程、章节、管理员账号）
mysql -u exam_user -p exam_system < initial_data.sql

initial_data.sql包含什么？不是空库，而是预置了《数据结构》《大学英语》两门课的完整章节树、100道样例题（覆盖所有题型）、以及一个admin账号（密码Admin123!）。这样教师首次登录后，不用从零开始建课程，直接点“组卷”就能体验全流程。这个设计减少了80%的初期放弃率——很多教学系统死在“第一步太难”。

4.3 Django配置与迁移：settings.py的关键修改项

打开settings.py，重点修改以下几处（其他保持默认）：

# 数据库配置（替换为你自己的MySQL信息）
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'exam_system',
        'USER': 'exam_user',
        'PASSWORD': 'StrongPass123!',
        'HOST': 'localhost',
        'PORT': '3306',
        'OPTIONS': {
            'charset': 'utf8mb4',
            'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
        },
    }
}

# 静态文件配置（适配机房网络环境）
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')  # collectstatic输出目录
STATICFILES_DIRS = [
    os.path.join(BASE_DIR, 'static'),
]

# 允许的Host（防止HTTP Host头攻击）
ALLOWED_HOSTS = ['localhost', '127.0.0.1', 'your-server-ip']  # 生产环境必须指定IP

# 密钥（生产环境务必更换！）
SECRET_KEY = 'your-secret-key-here-change-it-now'  # 生成命令：python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"

注意：STATIC_ROOT和STATICFILES_DIRS的区分很重要。开发时静态文件放在static/目录，Django自动服务；生产部署时，用python manage.py collectstatic把所有静态文件（包括jQuery、html2canvas）打包到staticfiles/，再由Nginx直接提供服务——这样能减轻Django进程负担，让机房电脑访问更快。

4.4 首次运行与初始配置：三步完成教师可用

# 执行数据库迁移（创建所有表）
python manage.py migrate

# 创建超级管理员（用于首次登录）
python manage.py createsuperuser
# 输入用户名、邮箱、密码（记住密码！）

# 启动开发服务器
python manage.py runserver 0.0.0.0:8000

打开浏览器访问http://your-server-ip:8000/admin，用刚创建的管理员账号登录。首次进入Admin后台，你会看到已预置的Course、Chapter、Question等模型。这时要做三件事：

1. 添加教师账号：进入Auth > Users，点击“ADD USER”，填写教师姓名、邮箱，勾选“Staff status”，在“Groups”里选择“Teachers”组（系统已预置）；
2. 导入题库：进入Question Bank > Questions，点击右上角“Import questions”，上传Excel文件（格式见下文）；
3. 配置课程章节：进入Question Bank > Chapters，点击“ADD CHAPTER”，选择课程，输入章节名（如“第一章 绪论”），设置排序序号。

Excel题库导入规范（王老师亲测有效）：
- 第一列：题干（支持HTML，如<p>下列哪项是<strong>线性结构</strong>？</p>）
- 第二列：题型（single/multiple/judgement/fill/essay）
- 第三列：答案（单选填A，多选填AB，判断填True/False，填空用|分隔，如根结点|叶子结点）
- 第四列：难度（1/2/3）
- 第五列：所属章节ID（在Admin里查看章节列表获取）
- 第六列：知识点ID（同上，可多值用逗号分隔）
- 第七列：解析（可选，用于教师阅卷参考）

完成这三步，教师就能用自己账号登录http://your-server-ip:8000/teacher/，开始第一次组卷了。

4.5 首次组卷实战：手把手演示“生成《数据结构》期中卷”

教师登录后，进入试卷管理 > 创建新试卷。界面左侧是条件面板，右侧是实时预览区。我们按王老师的实际操作走一遍：

1. 选择课程与基本信息：课程选《数据结构》，试卷名称填“2024春期中测试”，总分设为100，考试时长60分钟；
2. 设置题型分布：拖动滑块，设定单选题30分（15道）、多选题20分（5道）、判断题10分（10道）、填空题20分（10空）、简答题20分（2道）；
3. 指定章节范围：勾选“第一章 绪论”“第二章 线性表”“第三章 树”，取消勾选“第四章 图”（尚未讲授）；
4. 知识点聚焦：在知识点标签云里，点击“时间复杂度”“线性表操作”“二叉树遍历”三个标签；
5. 难度控制：拖动难度滑块，设定“易:中:难 = 3:5:2”；
6. 点击“生成试卷”。

系统后台执行前述的三步算法，约2秒后，右侧预览区显示生成的试卷。王老师做的第一件事不是看题目，而是点击右上角“预览截图”按钮——html2canvas开始渲染整个试卷页面，生成PNG缩略图。他确认排版无误后，点击“导出PDF准备”，系统生成一个.pdf文件（实际是HTML转PDF的中间文件，需配合wkhtmltopdf服务）。

实操心得：html2canvas在机房电脑上偶发渲染失败（尤其含MathJax公式时）。我们的解决方案是在views.py里加降级逻辑：若截图失败，自动切换为纯文本预览，并提示“建议使用Chrome浏览器获取最佳效果”。这个细节让王老师在第一次试用时就建立了信任——他知道系统会坦诚告知限制，而不是假装完美。

5. 常见问题与排查技巧实录：一线教师和开发者踩过的坑

部署和使用过程中，我和王老师一起记录了27个典型问题。下面精选6个高频、高痛感的问题，给出根因分析和实操解决方案。这些问题不是理论推测，而是来自真实的监考现场、教师培训会和深夜运维电话。

5.1 问题：教师导入Excel题库后，部分题目显示“乱码”或“空白”

现象：题干中文显示为方框或问号，或整道题内容为空。

根因分析：Excel文件编码不是UTF-8。Windows自带Excel默认保存为GBK编码，而Django读取CSV/Excel时强制用UTF-8解码，导致字节错位。

解决方案：
1. 教师用Excel另存为时，选择“CSV UTF-8（逗号分隔）(*.csv)”格式；
2. 或在views.py的导入视图里加编码探测逻辑：

import chardet
with open(file_path, 'rb') as f:
    raw_data = f.read(1000)
    encoding = chardet.detect(raw_data)['encoding']
    if encoding.lower() != 'utf-8':
        df = pd.read_csv(file_path, encoding=encoding)
    else:
        df = pd.read_csv(file_path, encoding='utf-8')

注意：chardet库需提前安装。这个方案让系统自动识别GBK/Big5等编码，教师无需学习编码知识。

5.2 问题：组卷时提示“未找到满足条件的题目”，但题库明明有相关题目

现象：教师勾选“第三章 树”和“知识点：哈夫曼编码”，却提示无题可选。

根因分析：题目未正确关联知识点。Admin里显示QuestionTag表为空，或关联的KnowledgePointID错误。

排查步骤：
1. 进入Admin，打开Question Bank > QuestionTags，搜索该题目ID；
2. 若无记录，说明导入时知识点ID填错（如填了章节ID）；
3. 若有记录，检查KnowledgePoint对象是否存在，chapter字段是否指向正确章节。

预防措施：在Excel导入模板里，知识点列改为下拉选择（用django-import-export插件实现），禁止手动输入ID。

5.3 问题：学生考试时页面卡死，刷新后显示“考试已结束”

现象：学生点击“开始考试”后，页面长时间白屏，倒计时不动。

根因分析：机房电脑DNS解析慢，导致jquery-3.4.1.js等外部CDN资源加载超时，阻塞整个页面渲染。

解决方案：
1. 将所有前端库（jQuery、html2canvas）下载到本地static/js/目录；
2. 修改base.html模板，引用本地路径：

<!-- 替换CDN链接 -->
<script src="{% static 'js/jquery-3.4.1.min.js' %}"></script>
<script src="{% static 'js/html2canvas.min.js' %}"></script>

3. 在settings.py里启用DEBUG=False时的静态文件服务（Nginx配置见下文）。

实操心得：这个改动让机房平均加载时间从8.2秒降至1.7秒。王老师说：“以前学生总问我‘老师，网页是不是坏了？’，现在他们安静答题，这才是考试该有的样子。”

5.4 问题：教师阅卷时，简答题答案区显示“[object Object]”

现象：学生提交的简答题答案，在阅卷页显示为JavaScript对象字符串。

根因分析：学生用富文本编辑器（如mdeditor）提交答案，后端未正确解析Markdown，直接存了原始HTML字符串，前端模板又用{{ answer|safe }}渲染，导致XSS风险被Django自动转义。

修复方案：
1. 在models.py的EssayAnswer模型里，增加clean_content()方法：

def clean_content(self):
    # 移除危险标签，保留p、br、strong等教学必需标签
    from django.utils.html import strip_tags
    import re
    safe_html = re.sub(r'<(?!p|br|strong|em|ul|ol|li)[^>]*>', '', self.content)
    return strip_tags(safe_html, 'p br strong em ul ol li')

2. 在阅卷模板里，用{{ answer.clean_content|linebreaks }}渲染。

5.5 问题：导出PDF时公式显示为乱码或缺失

现象：含LaTeX公式的题目，在PDF里显示为$E=mc^2$原始文本。

根因分析：wkhtmltopdf默认不支持MathJax，需额外配置。

解决方案：
1. 安装支持MathJax的wkhtmltopdf版本（如wkhtmltopdf-binary-edge）；
2. 在PDF导出视图里，添加延迟等待MathJax渲染：

options = {
    'javascript-delay': 5000,  # 等待5秒让MathJax完成渲染
    'no-stop-slow-scripts': True,
}
pdf = pdfkit.from_string(html_content, False, options=options)

5.6 问题：MySQL连接超时，后台报错“Lost connection to MySQL server”

现象：教师长时间未操作后，点击“生成试卷”报数据库连接错误。

根因分析：MySQL默认wait_timeout=28800（8小时），但Django连接池未配置心跳检测，空闲连接被MySQL主动断开。

永久修复：
1. 修改MySQL配置/etc/mysql/mysql.conf.d/mysqld.cnf：

[mysqld]
wait_timeout = 28800
interactive_timeout = 28800

2. 在Django settings.py的DATABASES里，增加连接参数：

'OPTIONS': {
    'connect_timeout': 10,
    'read_timeout': 10,
    'write_timeout': 10,
},

常见问题速查表

这些坑，每一个都对应着一次真实的教学中断。填平它们，不是为了炫技，而是为了让系统真正成为教师讲台边那个“沉默但可靠”的助手——它不抢风头，但在关键时刻，从不掉链子。

6. 二次开发与教学延伸：从工具到教学法创新的跃迁

这套系统交付给王老师后，他没把它当终点，而是当作一个教学实验平台。半年内，他基于原始代码做了三次重要迭代，每一次都紧扣教学法痛点，而非技术炫技。这些实践证明：好的教育技术，最终要回归到“如何让学生学得更好”这个原点。

6.1 迭代一：错题本自动推送（解决“考完即忘”顽疾）

王老师发现，学生考完试拿到分数就扔一边，错题从不回顾。他在exam_paper/models.py里新增StudentWrongAnswer模型，记录每次考试中学生的错误题目、错误选项、提交时间。然后开发了一个简单的邮件推送服务：

• 每次考试结束后24小时，系统扫描所有错题，按知识点聚类；
• 生成个性化PDF错题集（含题目、正确答案、解析、关联教材页码）；
• 通过SMTP发送到学生邮箱，标题为“【数据结构】你的专属错题集（第3章）”。

这个功能上线后，学生错题回顾率从12%提升到67%。更妙的是，王老师把错题集里的“高频错误选项”反哺回题库——比如78%的学生在“二叉树遍历”题中选错“先序遍历”，他就新建一道针对性题目：“下列序列中，哪个不可能是某二叉树的先序遍历结果？”，把教学闭环真正跑通。

6.2 迭代二：小组协作考试模式（突破个体考核局限）

传统考试是个人行为，但工程能力需要协作。王老师在online_exam/views.py里新增GroupExamView，支持教师创建“小组考试”：

• 教师设定小组规模（如4人一组）、小组任务（如“设计一个哈希表实现”）；
• 学生组队后，共享一个答题区，所有成员可编辑同一份代码/文档；
• 系统记录每个成员的编辑痕迹（谁写了哪段代码），生成贡献度报告。

这个模式用于《软件工程》课程设计，学生反馈：“终于不用猜队友有没有写代码了，编辑历史看得清清楚楚。”教务处也认可其公平性——贡献度报告比口头答辩更能反映真实能力。

6.3 迭代三：知识点掌握热力图（让教学决策有据可依）

王老师最得意的功能，是在Admin后台新增一个“教学仪表盘”。它调用QuestionAnalysis模型的数据，生成动态热力图：

• X轴：课程章节（第一章到第五章）；
• Y轴：知识点（二叉树遍历、哈希冲突处理等）；
• 颜色深浅：代表该知识点下，学生平均得分率（红色=低于60%，绿色=高于85%）。

每次期中考试后，他不再凭经验判断“第三章讲得不好”，而是指着热力图说：“看，‘平衡二叉树旋转’这个知识点，全校平均得分率只有42%，但‘AVL树定义’有89%——说明学生理解概念，但不会应用。下节课，我们重点练旋转操作。”

这个热力图，让教学从“感觉”走向“证据”，也让学院教改有了扎实的数据支撑。

最后分享一个小技巧：王老师把系统部署在学院一台闲置的旧服务器上（i5-4590，8GB内存），用Nginx做反向代理，配置非常简单：

# /etc/nginx/sites-available/exam-system
server {
    listen 80;
    server_name exam.your-college.edu;

    location /static/ {
        alias /path/to/exam_env/staticfiles/;
    }

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

然后用systemctl管理Gunicorn进程，确保服务开机自启。整个过程，他只用了半天时间——因为系统设计之初，就考虑到了“非专业运维也能维护”。

这套Django考试系统，从来不是要取代教师，而是把教师从重复劳动中解放出来，让他们有更多精力去做真正不可替代的事：读懂学生的眼神，判断一个答案背后的理解深度，设计下一个激发思考的问题。技术在这里，只是那支安静躺在讲台上的粉笔，朴素，但足够锋利。

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

简介：专为高校教师设计的课程考试辅助工具，基于Django开发，后端用MySQL管理题库数据，支持按课程、章节、知识点、难度等级、题型（单选、多选、判断、填空、简答）等组合条件自动抽题或手动编排试卷。内置三类角色权限：管理员统筹全局，教师负责题库维护与试卷生成，学生参与在线考试并查看成绩。题库支持批量导入导出、题目分类标签、重复题检测和审核流程。试卷生成后可实时预览，通过html2canvas截图存档，兼容PDF导出准备。前端采用轻量级HTML+CSS+jQuery，适配PC与平板设备。项目结构规范，含完整Django应用模块（models/views/urls/forms/admin）、配置文件、测试脚本及依赖清单（requirements.txt），开箱即用，适合教学实践、课程设计或毕设二次开发。

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