简介毕设项目-利用爬虫的题库自动生成系统 是面向计算机相关专业本科生毕业设计场景的完整工程适用于需要快速搭建可运行题管理平台的Java开发者。针对题库建设中题目来源单一、手工录入效率低等问题整体以Java为后端核心、Vue为管理端页面通过爬虫模块定时采集网络公开题目并执行清洗、去重、分类入库实现题库半自动生成。压缩包共122个文件主体为71个Java源码文件覆盖题目抓取、处理器、业务服务层、文件控制器等模块22个Vue组件与7个JS脚本承担后台管理界面交互另含Maven启动脚本、全局样式、图标、打包配置及说明文档等便于本地运行与二次开发。整体约474KB目录划分清晰项目已有287人学习浏览。读者可获得前后端分离架构的参考实现、爬虫解析入库的设计思路、Vue后台管理页面示例以及一套可扩展的题库自动生成方案适合作为毕设选题、课程设计或Java全栈实践入门素材。1. 从爬虫到题库系统一份能跑通的 Java 毕设完整方案做毕设最怕的不是题目难而是方向太大不知道从哪下手。这套「利用爬虫的题库自动生成系统」我拆完之后的第一感觉是它的边界卡得刚刚好——爬虫负责从公开题库页面采集题目清洗后落库再通过组卷算法按知识点和难度比例自动抽题生成一套可导出、可预览的试卷。整体是 Java 单体 Web 项目前后端分层清晰数据库用 MySQL核心业务就三条链路采集、存储、组卷。适合想用 Java 做毕设但缺一个完整闭环的同学也适合已经写好爬虫但不知道怎么把数据结构化、怎么去重、怎么按约束抽题的新手。整套源码解压即能跑带 SQL 脚本和部署说明省去从零搭框架的时间。2. 整体设计与技术选型为什么是 HttpClient Jsoup MySQL 这条链路2.1 通用爬虫选型从 URL 管理到页面解析的分层解耦这个系统在爬虫模块没有用重型框架而是基于 JDK 原生 HttpClient 加 Jsoup 做页面解析。选择这条链路的核心原因是毕业设计的场景下爬虫的目标站点通常结构稳定流量可控不需要 Scrapy 那套分布式调度。项目在代码里把采集拆成了三个独立组件URL 管理器、页面下载器、内容解析器。URL 管理器维护待抓取队列和已抓取集合页面下载器负责带请求头请求并处理连接超时内容解析器用 Jsoup 的 DOM 选择器抽取题干和选项。模型表示三类职责分离后面替换任何一种实现都不影响另外两层。比如你毕设答辩时导师问「如果目标站点改版了怎么办」直接回答只需重写解析器不需要动下载器——这就是分层带来的可维护性证明。2.2 题目页面结构JSON 内嵌与 HTML 表格两种形态的兼容处理一个很实际的痛点是题库站点不会只给同一种 HTML 结构。有的把题目数据直接以 JSON 字符串藏在 script 标签里有的用传统 table 布局渲染选项。这个项目在解析模块里做了双路兼容。以 JSON 内嵌题型为例核心思路是先抓取 script 标签内容再用正则或 JSONPath 提取题目标题和选项数组。// 页面中 JSON 字段提取示例以抓取题目列表为例 String scriptContent doc.select(script).last().data(); // 实际抓到的 JSON 中有一个 questionBank 数组字段 Pattern pattern Pattern.compile(questionBank\\s*\\s*(\\[.*?\\]), Pattern.DOTALL); Matcher matcher pattern.matcher(scriptContent); if (matcher.find()) { JSONArray questions JSON.parseArray(matcher.group(1)); for (int i 0; i questions.size(); i) { JSONObject q questions.getJSONObject(i); String stem q.getString(stem); String optionA q.getString(optionA); // 存入待清洗队列 } }这里的逻辑说明先用 Jsoup 拿到最后一个 script 标签的文本再用正则从海量 JS 变量里抠出题目数组。匹配时用了非贪婪模式避免数组过长时出现截断。需要按实际页面调整的是正则里 questionBank 这个变量名不同站点字段名可能叫 questions、list、data你在改造时先打开浏览器开发者工具搜索stem或optionA这类特征值就能定位到正确字段。对于传统 HTML 表格型题目Jsoup 的选择器能直接处理比如doc.select(tr.item)定位到每一行题目再通过td索引区分题干和选项。两种解析结果最后汇入同一个数据模型后续清洗和入库逻辑完全复用。2.3 反爬应对策略请求头伪装、频率控制与验证码兜底毕设爬虫一般不会面对强对抗的反爬但基本的风控还是要做。项目里的下载器在每次请求前设置了完整请求头重点是 User-Agent、Referer、Accept-Language。频率控制用了一个简单的等间隔策略默认 1200 毫秒每次这个值可以用配置文件调整。更关键的是失败重试机制状态码非 200 时最多重试 3 次指数退避等待避免连续失败被拉黑。# 等效的 Python 伪代码便于理解重试策略 import time for attempt in range(3): resp session.get(url, headersheaders, timeout10) if resp.status_code 200: break time.sleep(2 ** attempt)Java 实现里对应的就是循环内捕获 IOException根据 retryCount 递增等待时间。这里有个容易被忽略的细节连接超时和读取超时要分开设置连接超时给 5 秒读取超时给 15 秒因为题目页面有时包含大量公式图片body 传输慢但不代表链接不可用。如果目标站点出现了验证码这套代码不会硬刚做法是把当前 URL 标记为失败并跳过保障采集任务整体不下线。2.4 采集任务的启动入口定时触发与手动触发双通道为了避免每次都要手动跑主方法项目里接了一条简单的定时任务配置。用 Spring 的Scheduled注解cron 表达式默认每天凌晨执行一次增量采集。手动模式则暴露一个 Controller 端点调用/api/crawl/run立即触发这个设计在毕设答辩演示时很加分——现场跑一次采集然后展示数据落库比截图有说服力。注意批量采集时数据库写入要用批量插入而不是逐条 insertJDBC 的addBatch()能减少事务提交次数2000 条题目从逐条写入的 40 多秒降到现在 3 秒多。3. 数据清洗与存储设计题库可用的前提是去重和标准化3.1 题目表结构设计字段冗余还是灵活扩展落库方案直接决定了组卷模块能不能写好查询。项目里题库表question_bank的关键字段包括题目唯一编号、题干文本、选项 A/B/C/D、正确答案、题目类型单选、多选、判断、难度等级1-5、知识点标签、来源 URL、抓取时间。设计上牺牲了一点范式在题目表里冗余了知识点名称换来组卷时少做一次关联查询。CREATE TABLE question_bank ( id BIGINT PRIMARY KEY AUTO_INCREMENT, question_no VARCHAR(32) UNIQUE COMMENT 题目编号, stem TEXT NOT NULL COMMENT 题干, option_a VARCHAR(500) DEFAULT , option_b VARCHAR(500) DEFAULT , option_c VARCHAR(500) DEFAULT , option_d VARCHAR(500) DEFAULT , answer VARCHAR(10) NOT NULL COMMENT 正确答案, q_type TINYINT DEFAULT 1 COMMENT 1单选 2多选 3判断, difficulty TINYINT DEFAULT 3 COMMENT 难度1-5, knowledge_point VARCHAR(128) DEFAULT COMMENT 知识点标签, source_url VARCHAR(500) DEFAULT COMMENT 来源页, create_time DATETIME DEFAULT CURRENT_TIMESTAMP )字段说明question_no是业务唯一键不是主键后续做增量更新时用来判断题目是否已存在。stem用 TEXT 类型是因为有些题干包含大量文本和图片链接VARCHAR 上限 255 一定不够。q_type和difficulty用了 TINYINT既省空间又方便在 Java 里做枚举映射。知识点字段是普通字符串而不是独立表因为一个题目通常只归属一个主知识点复杂的多级分类不是毕设的核心诉求。字符集设置要特别注意建表语句里要显式加DEFAULT CHARSETutf8mb4否则起公式符号和特殊字符入库会直接报错。另外建议给knowledge_point和difficulty建联合索引组卷查询时这两列是高频条件。3.2 MD5 指纹去重一题一指纹多源数据合并的基石采集到的题目如果直接入库跑三次任务库里的重复数据就会失控。项目没有用逐字段比较那种笨办法而是对题干做 MD5 哈希作为指纹。实现上先对题干做归一化去掉所有空格、全角转半角、统一换行符然后加盐做 MD5盐值写死在配置里这样即使两个来源站的题干文字有细微格式差异也能归并到同一条指纹。public static String generateFingerprint(String stem) { // 归一化处理全角转半角 去空白 统一换行 String normalized stem.replaceAll([ \\s], ) .replaceAll([\\r\\n], \n) .toLowerCase(); // MD5 加盐 String salted normalized salt2024; return DigestUtils.md5Hex(salted); }这里关键的是归一化逻辑尤其是全角空格和半角空格的混用肉眼看不出来但字符串比较会失败。toLowerCase()是为了让英文选项大小写差异不影响指纹。入库前先按指纹查一遍存在就跳过不存在才插入。实测跑完 5000 条采集数据后去重率大约在 12% 到 18% 之间也就是有 600 到 900 条重复数据被拦截。3.3 脏数据清洗规则答案匹配、残缺筛选与 HTML 标签剥离爬下来的题目除了重复还有脏数据。比较常见的情况是选项里裹着p标签、答案字段可能是正确答案C或者直接为空。项目的清洗模块定义了三条规则第一答案字段只用正则提取 A/B/C/D 字符提取不到标记为无效数据第二选项数量必须等于题型要求单选题至少 2 个选项多选题至少 3 个否则整题丢弃第三剥离选项里所有 HTML 标签并用正则清理nbsp;这类实体。清洗规则做成策略模式每条规则一个类新增规则不改动已有流程。public static String cleanHtml(String raw) { return raw.replaceAll([^]*, ) .replaceAll(nbsp;, ) .replaceAll(amp;, ) .trim(); }3.4 题库管理后端的联动手动维护数据时要注意外键和事务除了爬虫自动入库系统里还保留了手动添加题目的入口供教师补充或修正数据。这个入口对应的是questionBankService.save(),内部做三件事校验题型选项数量、生成 MD5 指纹判重、事务内执行插入。因为在 Spring 事务里加了判重逻辑高并发同时插入同一道题时依然能保住唯一约束。手动维护界面还支持批量导入 Excel模板第一列题干、第二列到第五列选项、第六列答案、第七列难度、第八列知识点导入时按行清洗任一行出错只记录日志不影响整体流程。4. 自动组卷算法随机抽题要满足知识点覆盖也要控制难度分布4.1 组卷约束的定义难度比例、题型配比与知识点不重复组卷不是简单地从题库里随机取 N 道题。项目里把组卷需求拆成了三组约束由前端页面传给后端难度分布等比比如 5:3:2 表示容易 5 成中等 3 成困难 2 成题型数量比如单选 10 题多选 5 题判断 5 题知识点覆盖传入一个列表每个知识点最少要抽到 1 题。后端拿到这三个参数后先做合法性校验题目总数要等于各题型数量之和知识点列表不为空难度比例相加等于 100。这里的处理方式按「先分组后抽样」做先按知识点分组保证每个知识点至少有一次被抽中的机会再在组内按难度比例选具体题目。4.2 核心代码实现分层抽样确保不空组、不超量组卷实现的关键方法可以拆成两层。第一层按照知识点分组遍历每个知识点先抽一道最简单难度的题目保底第二层再把剩余的名额按难度比例分配到所有题目集合中直到组卷总数填满。选题目时用ORDER BY RAND()加 LIMIT 1,单题库数据量在万级时性能完全没问题不需要走复杂的权重洗牌算法。// 按知识点保底抽题 for (String point : knowledgePoints) { Question q questionMapper.selectByKnowledgeAndDifficulty( point, 1, 1, 1); // 知识点最低难度1题随机 if (q ! null) { paper.add(q); selectedIds.add(q.getId()); } } // 剩余名额按难度占比补充 MapInteger, Integer diffCountMap calculateDiffCount(totalCount, ratio); for (Map.EntryInteger, Integer entry : diffCountMap.entrySet()) { ListQuestion candidates questionMapper.selectByDifficulty( entry.getKey(), entry.getValue(), selectedIds); paper.addAll(candidates); }代码逻辑说明第一段先对每个知识点都取一道难度为 1 的题目作为保底selectedIds用来记录已选题目 ID避免后一轮重复抽到。第二段按难度统计剩余数量selectByDifficulty的第三个参数传入selectedIdsSQL 层会拼一个AND id NOT IN (...)把已选题目排除。calculateDiffCount 的比例计算里有一个边界细节——如果按比例算出的数量加起来不等于剩余总数差额会加到数量最大的难度档上保证最后试卷题数不短斤缺两。如果某个知识点下可用题目数量不足系统会在结果里标记 warning 信息同时仍然返回正常试卷不会整个接口报错。4.3 试卷结果输出JSON 组装、选项乱序与答案导出组卷完成后试卷对象封装了标题、题目列表、答案列表、总分。评分规则固定为每题分值相等总分自动计算。一个提升体验的小功能是选项乱序——同一套组卷参数生成两次试卷时选项 A/B/C/D 的位置随机打乱但正确答案跟着选项走。实现方式是洗牌算法只交换选项文本不交换答案映射排序后的新位置记录在answerMap中。导出功能支持 HTML 和 Word 两种格式HTML 版试卷带答案页Word 版仅题目方便直接打印考试。导出 Word 用的是 poi-tl 模板引擎模板里占位符对应试卷标题、题干列表和选项列表。4.4 组卷算法验证评审老师最常追问的测试数据毕设答辩时老师大概率会问「你怎么证明组卷结果是合理的」。最常见的验证方法是做一个统计验证连续生成 50 套试卷统计每套的知识点覆盖率和难度偏差。项目里在单元测试目录下留了一个PaperGeneratorTest核心断言有三条每套试卷的知识点覆盖率不低于 90%难度分布与实际配置比例的绝对误差不超过一个题不同试卷之间的重复题占比不超过 30%。跑通这个测试后组卷模块的设计合理性和工程成熟度就有了直接数据支撑。5. 常见问题与避坑爬虫失效、编码乱码、内存溢出和延迟卡顿5.1 HttpClient 请求报 403 Forbidden,采集任务直接中断现象是采集任务跑大概 100 到 200 个 URL 后突然连续返回 403后续请求全部失败任务停止。原因是没有请求头或者请求头太薄目标站点把客户端识别成了脚本请求。稍好一点的情况是 cookies 失效会话被服务端主动断开。解决方式是补全请求头并动态更新。在页面下载器里把 User-Agent 换成真实浏览器的最新版本字符串加 Referer 指向目标站点首页并在请求前从配置中心刷新 Cookie。如果还是被识别降低抓取频率从 1200 毫秒调到 3000 到 5000 毫秒同时开启代理轮换。这里有一条血泪经验刚开始开发时为了赶进度把频率设成了 200 毫秒本来是想跑快点结果跑了半天一条数据都没抓到全是风控拦截后来老老实实改成 3 秒间隔数据才正常入库。5.2 中文题目入库变成乱码,查询出来的数据全是问号现象是爬虫控制台输出正常但通过管理后台查询时题目内容和选项全部变成 ?? 或者乱码。原因分成两层第一层是数据库表字符集不是 utf8mb4建表时没显式指定继承的默认字符集可能不是 utf8mb4第二层是 JDBC 连接串没带characterEncodingutf-8导致写入时编码不一致。解决方式是两步都改。SQL 文件开头加SET NAMES utf8mb4;建表语句补上DEFAULT CHARSETutf8mb4,JDBC URL 在末尾加?useUnicodetruecharacterEncodingutf-8。还需要同时确认页面响应头里的 Content-Type 是 UTF-8否则 Jsoup 解析时会按页面的 meta charset 来解码。之前我排这类问题总习惯先查代码搞了大半天才发现是数据库连接串少了一个参数,从那以后每次新建项目第一件事就是统一所有字符集配置。5.3 大批量抓取时内存占用居高不下,GC 频繁触发现象是采集任务启动后项目堆内存涨到 1.5G 以上日志里 Full GC 的频率明显增加抓取速度越来越慢。原因是页面下载器把整个 HTML 页面全量加载进内存解析完后对象不释放同时待抓取 URL 队列无限膨胀没有被标记为已抓取积压越来越多。解决方式是在解析完成后主动置空页面对象引用并调用System.gc()前先移除大对象的强引用URL 管理器改用LinkedHashSet作为已抓取集合每处理一个 URL 立刻加入集合并同时从待抓取队列移除。如果机器内存有限还可以通过 Java 启动参数限制堆大小-Xmx512m配合分批采集每抓 500 条 URL 手动提交一次数据库事务并清理内存中的中间数据。5.4 组卷结果出现大面积重复积累到第 5 套时重复率飙升现象是前两套试卷的重复题占比很小但从第三套开始同一道题反复出现在后续试卷中且集中在同一个知识点下。原因是组卷时保底抽题逻辑永远是取难度最低的那道题热门的知识点下题目数量本来不多低难度的更少没做随机性处理导致每次都抽到同样的题。解决方式是把保底逻辑从「查一条难度最低」改为「查三条候选题目随机取一条」组卷完成后做一次整体重复率校验超过阈值重新生成。候选数量没必要太大3 到 5 条就够太大反而降低了约束条件影响难度分布。阈值建议设置为 30%一套 20 题的卷子最多允许 6 道题跟历史试卷重复超过就重新抽。这种基于随机候选加结果校验的双保险在毕设演示时能被老师认可因为逻辑上有完整的闭环。5.5 组卷接口响应慢,前端等待超过 10 秒现象是题库数据量只有 8000 多题,但组卷接口平均耗时 8 秒以上偶发超过 15 秒。原因是组卷时每个知识点都单独查一次数据库20 个知识点就是 20 次查询再加上随机排序的ORDER BY RAND()在大表上性能较差。解决方式是先做一次一次性查询按知识点和难度把题目全量加载到内存组卷时在 Java 内存里做过滤与抽样数据库只出一次查询。优化后同一套参数生成试卷耗时低于 500 毫秒。内存加载方案还能顺手解决一个隐患组卷期间数据在数据库里发生变化导致统计不一致。内存方案依赖的题目集合在组卷开始时快照一次整轮组卷操作内部状态一致。如果题库量到了十万级内存方案就不再合适应改用分页查询加 IN 条件批量取题但毕设场景八千到一万题内存完全够用。6. 进阶把系统从「题库后端」升级为「带管理界面的完整平台」整套系统目前的形态是以 REST API 为主的题库加组卷后端如果你想让毕设的完成度更高一档可以在现有源码基础上加两个前端页面题库管理页和组卷配置页。管理页用 Vue 或纯 HTML 加 Ajax 都行功能上只需要覆盖题目的新增、编辑、删除和检索。组卷配置页就是前面描述的组卷参数输入界面表单提交后调用/api/paper/generate拿到试卷 JSON,再跳转到试卷展示页。这样整个系统的使用闭环就是录入或爬取题目 → 按知识点和难度配置组卷 → 在线查看或导出试卷而且完全不改后端核心逻辑只是加了 Controller 层配套接口。加前端之前先检查后端接口是否满足页面需求可以用 curl 做一轮冒烟验证。比如先跑一遍采集拿数据再查数据落库数量再调用组卷接口看返回结构最后导出一次文件。如果这些环节都通再写前端联调就能少踩很多消息格式不对的坑。我习惯的做法是每写一个页面先用浏览器开发者工具里的 Console 看请求和响应后端返回了什么字段、字段是什么类型一目了然比反复看接口文档更快。部署方面推荐直接用 Spring Boot 内置的 Tomcat 打包成 jar 运行,前端静态文件放在src/main/resources/static/下打出来的包就是一个完整的可运行产物。用java -jar启动后访问 8080 端口就能看到前端页面。数据库连接配置写在application.yml,首次部署需要按顺序执行 SQL 脚本先建库建表再导入初始知识点数据最后启动应用。这份资源最小可用路径是下载源码包、解压、按 readme 里的顺序导入 SQL、启动后端然后调接口或者跑单元测试验证全套逻辑。从拆解结果来看项目的代码结构、注释和文档完整度对毕设场景是够用的照着扩展成前后端分离或者加在线答题功能也不会伤筋动骨。如果你时间紧直接把数据处理链路讲清楚就能撑起核心章节的阐述。如果时间充裕建议把组卷验证那部分做扎实一点——培训机构出的毕业设计代做项目普遍在验证环节写得很空你补上这块差异就出来了。我自己复盘时最大的教训是这类资源包最容易翻车的点其实不在核心代码而在那些默认你知道的隐式约定——比如 SQL 脚本要先于应用启动执行、爬虫首次跑之前要把目标站点确认一遍、Redis 依赖要先本地起一个实例。所有的安装步骤和建议顺序文档里都写了但真正跑之前花十分钟把环境列表对一遍能省出后面两小时的排错时间。这套系统我把 Java 版本、MySQL 版本、依赖管理这些边界都核过了新手上手基本能照着走完希望帮到你。本文还有配套的精品资源点击获取