简介本资源是面向高校计算机专业师生的毕业设计全流程数字化管理平台聚焦选题分配、任务书审核、开题评审、中期跟踪、论文查重与答辩组织等核心环节解决传统人工管理效率低、流程不透明、进度难监控等问题适用于本科毕设教学管理与课程设计实践。压缩包共2005个文件涵盖1198个JavaScript前端逻辑文件、198个HTML页面模板、161个JSON配置与接口数据、155个Markdown说明文档、140个CSS样式资源以及PHP后端脚本、SQL数据库脚本和PDF/DOCX规范文档等整体23.57MB结构完整、模块清晰便于二次开发与部署。目前已有67人学习下载提供附赠教学资源、详细操作说明及gmis-master主项目源码覆盖前后端全栈实现可直接用于教学系统搭建或毕设管理课程实训。 每年到了四月系办教务老师的微信就开始爆炸“老师我的选题为什么还没审核”“老师指导老师说我开题报告格式不对能不能帮我退回”“老师查重报告传哪里”。纸质版的选题表、任务书、开题报告、中期检查表在不同办公室之间流转Excel表格被十几个人来回编辑最后汇总时版本对不上。我做了个计算机系毕业设计管理系统把从选题、任务书、开题报告、中期检查、论文提交查重到答辩安排的全流程塞进了同一个数字化管理平台一个学期跑下来总算让这套流程从“线下到处找”变成了“线上可追踪”。这篇文章会把整个系统的设计思路、数据库拆解、状态机设计、并发选题的踩坑方案、查重对接和文件管理的细节都摊开来讲。不管你是想拿这个课题当毕业设计还是真打算给系里做一套类似的管理系统这些内容应该都能帮你省掉不少弯路。1. 毕业设计流程的“混乱现场”我为什么要写这个系统1.1 纸质表格与Excel管理模式下的一天没做过教务管理的人可能很难想象一个两百人左右的计算机系年级毕业设计流程旺季时有多混乱。学生端选题通知发下来大家靠抢。有人找学长打听哪个导师给分高有人反复登录教务系统看自己有没有被选中还有学生和导师沟通全靠微信语音关键信息全写在聊天记录里一翻就几十屏。任务书交的时候要求打印签字格式错了要重新跑一趟打印店盖上系章才发现日期写错。导师端一个导师手下可能有七八个学生每个学生的开题报告、中期检查表都要下载、批注、再回传。文件命名常年是“开题报告_最终版3_真的最终版.docx”。光整理这些文件就够占掉一个星期的晚上。教务端手里一份总表记录了所有人的选题、导师、状态但这份总表是多人分工录入的数据经常对不上。张三选题是“已完成”任务书却还没交李四论文查重报告传了两次版本混在一起王五的答辩分组还没排但论文已经进入评阅阶段。教务老师每天干的事情就是“拉表—对账—催交”根本没时间去管流程优化。这套模式最大的问题不是效率低而是流程状态完全不透明。谁在哪个环节卡住了哪个环节缺材料除了教务老师拿Excel肉眼看其他人根本不知道自己该干嘛。所以当系里提出要做一个数字化管理平台时我直接奔着流程管理去而不是做一个简单的文件上传下载站。1.2 系统边界什么该做什么不该做项目启动之前我先画了一条边界线避免做成一个什么都要管的巨型系统。只做毕业设计过程管理不做课程、课表、成绩总管理。系统围绕选题、任务书、开题报告、中期检查、论文提交与查重、答辩这六个环节展开每个环节就是一个独立模块。查重不做替代品只做流程承接。学校有自己的查重服务系统不会去搞一个真正的知网同级别论文库而是接查重服务的接口把查重结果回传并归档。考虑到学生可能想先自己查一遍系统内置了一个本地预检方案用SimHash加余弦相似度给出参考值这个后面会详细讲。账号体系不做开放注册由教务统一导入。学生、导师、教务、答辩组这四类账号都由管理员批量导入不开放自助注册这样权限和数据边界一开始就是可控的。技术栈我选了 Spring Boot 2.7 MyBatis-Plus MySQL 8.0 Redis Vue 3 Element Plus部署形式就是单体应用加一个Nginx简单直接。其实对这种规模的管理系统没必要上微服务单体在开发和运维上的成本都低很多之后扩容数据库加一个索引就够了。2. 六大核心模块拆解从选题双选到答辩成绩回传2.1 选题管理导师申报题目、学生志愿填报、名额限制选题环节的设计上我没有用“先到先得”的抢题模式而是做成类似高考志愿的双选机制。流程是这样的导师在系统里申报题目题目字段包括题目名称、研究方向、难度等级、需要的基础能力、可带人数上限。教务审核通过后题目进入学生可见列表。学生在规定时间内填报1到3个志愿按优先级排列。系统关闭志愿填报后第一轮匹配开始导师进入系统看到的是申请了自己题目的学生列表可以根据学生成绩单、前修课程、项目经历判断然后确认接受或者拒绝。第一轮没匹配上的学生进入第二轮调剂由教务结合剩余名额手动分配。为什么不用先到先得因为计算机系的热门方向和冷门方向差异太大纯手速抢题会导致一批学生抢到“看起来有名字”的题目实际做不了而导师更希望根据学生实际情况来匹配。志愿制给了导师筛选空间也给了学生表达倾向的机会。这个模块在技术上有几个必须处理的细节题目必须校验“是否已满”“是否已下架”“学生是否已有人确认”导师确认时要判断该导师名下学生数是否超过上限一个学生一旦被确认他的其他志愿自动失效。这里最核心的是并发控制后面单独开一节讲。2.2 任务书与开题报告在线提交、逐级审核、版本留痕任务书是学生和导师对课题范围的确认文档开题报告是前期调研和方案论证。两个环节逻辑几乎一样学生上传文件导师审核退回则学生重新上传通过则进入下一环节。这里有一个设计决策比较关键文件上传后系统不直接改原记录而是生成一个新版本。每次退回和重新提交都保留历史版本数据库里的task_book表、opening_report表都带version字段审核记录里能看到“第2版提交时间、审核时间、退回原因”。带版本号的管理方式实话说最初不是从需求文档里来的而是被实际问题逼出来的。有学生反馈“老师我不小心传错文件了能不能删掉重传”如果没有版本设计那就是直接覆盖出了问题说不清。加了版本管理之后每次提交都是一条独立的审计记录传错了可以重新提交但旧文件依然保留师生纠纷和教务对账都简单很多。开题报告比任务书多一个评审环节。开题评审一般由答辩小组或教研室老师参与系统里做成“导师审核通过后再由教务分配的评审组长给出评审结论”。评审结论有“通过”“修改后通过”“重新开题”三种修改后通过的要在评审意见里写明修改要求。2.3 中期检查进度填报、异常标记与风险预警中期检查之所以单独做一个模块是因为它是整个毕业设计周期里最能反映“学生个人状态”的节点。很多学生前期不写最后一个月通宵赶中期检查能把这类问题提前暴露出来。表单设计上中期检查表包含当前完成进度百分比、已完成的主要工作、遇到的问题、需要导师支持的内容、下一步计划。学生填写后导师在系统里填写指导意见。教务设置了预警规则如果学生填写的进度百分比低于40%或者导师评定为“滞后”系统自动给教务和学生推送预警标记在管理后台的统计列表里用红色标出。这里顺便解决了线下“中期检查表交了没交”的确认难问题每次提交和审核都会在系统里留下时间线。谁什么时候交的导师什么时候审的一目了然。2.4 论文提交、查重结果登记与答辩管理论文提交模块是整个流程的收口环节也是教务最关注的地方。学生上传最终版论文格式限制为PDF或Word文件名系统自动改成“学号_姓名_论文题目_v1”。上传之后教务可在后台点击“送查重”系统调用查重服务。查重过程和结果必须留痕。用户提交查重两次第一次30%第二次28%取哪次以“最终送审版”所关联的那次为准。所以数据库里查重记录和论文版本是绑定的论文每一个版本对应一条查重结果。查重通过后论文进入评阅阶段。系统会按答辩分组自动生成评阅任务一个学生分配两个评阅人评阅人可在线下载论文、填写评阅意见和评分。最终答辩环节答辩秘书在系统里安排分组、时间、地点答辩委员会按小组录入评分表。成绩计算规则一开始就要配置清楚总评成绩由导师评分30% 评阅评分30% 答辩评分40%加权汇总。答辩评分又细分四项选题意义、论文质量、答辩表达、回答情况每项25分。这些规则全部做成配置项教务可以在后端调整不用改代码。模块和角色的关系我用一个表来总结开发的时候照着这个表分模块就够清晰了模块学生导师教务答辩/评阅组选题管理提交志愿、查看匹配结果申报题目、确认学生审核题目、手动调剂无任务书在线提交/修改审核/退回查看统计无开题报告在线提交/修改审核分配评审组长评审结论中期检查填报进度填写指导意见预警监控无论文提交与查重提交论文、查看重复率审核最终版送检、结果归档评阅论文答辩管理查看答辩安排上传答辩评分设置分组/权重录入成绩3. 数据库与状态机让每一次退回都有据可查3.1 核心表结构主流程表加环节附件表毕业设计流程的数据模型核心思路可以总结为“一张主流程表 各环节独立业务表 一张公共附件表”。主流程表存学生当前整体进度业务表存各环节的具体业务字段附件表存所有文件的位置和元信息。用户表不做过多扩展毕业设计系统只需要跟身份绑定所以字段是user_id、emp_no学号/工号、real_name、rolestudent/teacher/admin/defense、dept_name、phone、email。选题表topic包含topic_id、teacher_id、title、description、difficulty_level、max_student_num、status草稿/待审核/已发布/未选中/已下线。选课记录表selection_record是并发控制的主战场id、student_id、topic_id、preference_order、status待确认/已确认/已拒绝/已取消、update_time。各环节表长得很像以task_book为例id、student_id、version、file_id、content_text可选、status待提交/待审核/已通过/已退回、submit_time、audit_time、audit_user_id、audit_comment。开题报告表多了opinion、reexamine_flag中期检查表多了progress_percent、risk_flag。论文表和查重记录的绑定关系我单独做了关联因为一次论文提交可能对应多次查重记录。数据库字段里有几个容易踩坑的地方所有时间字段统一用datetime并明确时区避免之后出现“比实际时间早8小时”的诡异问题所有文件和状态字段设置默认值审核意见字段必须设为可空因为不是每次审核都会填意见。附件表是整个系统的地基结构是file_id、biz_typetopic/task_book/opening_report/midterm/thesis/defense、biz_id、file_name、stored_name、file_size、file_ext、uploader_id、upload_time。所有文件统一存一张表不分散到各个业务表里好处是后续做文件批量迁移、垃圾文件清理、上传频率统计都很方便。3.2 流程状态机十二个状态和六个流转动作整个毕业设计进度不是一个简单的“待办已办”布尔值我把它抽象成一条状态链状态含义可执行动作SELECTING选题阶段未提交志愿提交志愿CONFIRMING志愿已提交等待导师确认导师确认/拒绝CONFIRMED选题已确认提交任务书TASK_PENDING任务书待审核导师审核/退回TASK_APPROVED任务书已通过提交开题报告OPENING_PENDING开题报告待导师审核导师审核/退回OPENING_REVIEWING开题报告待评审评审组长给出结论OPENING_APPROVED开题报告已通过填报中期检查MIDTERM_PENDING中期检查待填报提交中期检查表MIDTERM_DONE中期检查已完成提交论文THESIS_PENDING论文待查重教务送检查重THESIS_APPROVED论文查重通过安排答辩DEFENSE_DONE答辩已完成录入成绩加上退回动作还会有更细的中间节点但状态机本身并不复杂。核心是要处理好“动作只能由指定角色执行”和“状态变更必须写进日志表”。每执行一个动作flow_log表插一条记录student_id、from_status、to_status、action、operator_id、comment、create_time。这个流水日志平时似乎没什么用等真正出现纠纷的时候就值钱了。比如学生说“我2号就交过任务书”导师说“没收到”从日志里直接把操作时间线拉出来清清楚楚。状态流转统一写在service层的一个模板方法里。所有业务操作都走同一个入口先查当前状态判断动作是否合法再执行更新最后写流水。这个方法唯一的缺点是写起来有点绕但好处是状态逻辑集中不会出现某个模块直接改数据库绕过流程的“后门”。3.3 数据权限四类角色能看到什么管理系统最容易犯的毛病是“登录进去什么都能看到”。毕设系统里的数据权限必须按角色卡死学生在自己的维度只能看到自己提交的流程单据、自己选题公开信息以及被公开的答辩安排。导师能看到自己申报的题目、申请了自己题目的学生列表以及自己名下学生的全流程进度。教务看全部数据并且可以查看统计报表。答辩组长和评阅人只能看到被分配的学生论文不能看到其他学生的个人信息。实现上我用了一个比较简单的方式MyBatis-Plus的数据权限插件在查询语句后面自动拼接“(teacher_id 当前用户id)”或者“student_id 当前用户id”。针对答辩组和评阅人这类以“被分配”为准的角色提前生成一张分配表defense_assignment然后数据权限拼的是“student_id in (select student_id from defense_assignment where reviewer_id 当前用户id)”。这套数据权限在开发初期不显眼但它决定了系统能不能真正落地。如果导师登录后能看到全系学生的选题信息哪怕只是多了几百行数据也会让使用体验变得非常怪异。4. 查重预检与文件管理系统里最容易被低估的两个技术点4.1 本地查重预检SimHash加余弦相似度的组合方案学校里买的查重服务通常有次数限制正式送检之前很多学生会拿论文到外面网上花钱查又贵又有论文泄露风险。所以我做了一个轻量级本地预检给学生一个参考重复率准确度肯定比不上商业库但用来排除明显的大段复制情况够用了。预检算法采用的是SimHash加余弦相似度组合。SimHash适合判断整篇论文的整体相似度效率极高一篇几万字的论文能在几十毫秒内算出指纹但在局部抄袭检测上它不够细所以配合余弦相似度把论文按段落切块对疑似重合的区块做精确比较。SimHash的具体做法是把论文文本做分词每个词算一个hash值然后根据词频设置权重把hash值逐位累加成一个64位指纹。两个文本的相似程度用汉明距离衡量距离小于等于3就认为非常相似。下面这段是我实现的核心部分public class SimHash { private final LongHashFunction hashFunction LongHashFunction.xx3(); public long simHash(String text) { MapString, Integer wordWeight segmentAndCount(text); int[] bits new int[64]; for (Map.EntryString, Integer entry : wordWeight.entrySet()) { long wordHash hashFunction.hashChars(entry.getKey()); int weight entry.getValue(); for (int i 0; i 64; i) { if (((wordHash i) 1) 1) { bits[i] weight; } else { bits[i] - weight; } } } long fingerprint 0L; for (int i 0; i 64; i) { if (bits[i] 0) { fingerprint | (1L i); } } return fingerprint; } public double similarity(long hash1, long hash2) { int distance Long.bitCount(hash1 ^ hash2); return Math.max(0D, 1D - distance / 64D); } }开题报告和论文初稿提交后系统自动做一次预检在页面显示“本地预检相似度”仅供导师参考。正式查重还是以学校服务为准预检结果不进入最终成绩计算。这个功能上线后反而成了学生用得最多的功能之一因为至少不用一稿二稿到处找亲戚朋友帮忙看重复率了。4.2 对接学校查重服务异步回调的流程设计查重服务调用是不能用同步接口硬等的。一次查重可能要排队几分钟到二三十分钟如果HTTP请求就这么挂在那里网关超时、连接池耗尽都是迟早的事。所以我这边做的是异步设计。学生或教务触发“送查重”后系统创建一个duplicate_check_request记录状态设为CHECKING然后调用查重服务的提交接口把论文文件传过去服务端返回一个task_id。本地不阻塞页面提示“查重任务已提交完成后将自动更新”。查重服务支持两种方式通知结果一种是回调服务端查完后POST一个结果到我们配置的回调URL另一种是轮询我们定期调用查询接口。回调是首选但为了兼容我也写了一个定时任务兜底每五分钟扫描一次超过十分钟还没有回调结果的CHECKING记录重新查询状态。回调接口的逻辑有一个容易忽略的点必须做幂等处理。外部服务可能因为网络原因回调多次每次回调都更新单据会把状态搅乱。我在duplicate_check_request表里加了request_no唯一键回调处理前先按request_no查一遍已经更新过的直接忽略。查重结果返回后系统更新论文版本的duplicate_result字段同时判断总评规则里的“查重不通过”条件如果超过阈值论文状态自动退回给学生修改。4.3 文件上传下载格式白名单、大小限制、路径安全毕业论文系统里有大量文件交互这块做不好系统会显得非常不专业。我的文件方案是“白名单校验 应用层大小限制 服务端重命名 按业务分目录存储”。文件扩展名白名单是硬编码在配置中心里的只允许doc、docx、pdf、zip、rar、jpg、png。上传接口会同时校验货真价实的文件头信息比如PDF文件头必须包含%PDFWord文件头要符合zip格式特征。只校验扩展名是不行的把exe改成pdf就能绕过文件头校验能极大提高防护水平。每个文件上传后被重新命名为“UUID 下划线 学生学号 扩展名”原文件名完整保留在附件表的file_name字段里。存储目录按biz_type分upload/topic、upload/task_book、upload/opening_report、upload/thesis、upload/defense。下载接口通过附件表里的stored_name定位文件不允许用户直接传路径访问。Nginx静态资源部分我直接映射了上传目录location /upload/ { alias /data/dfs/dept_upload/; expires 7d; add_header Cache-Control private, no-store; }还有一个细节是要处理文件预览。PDF可以用pdf.js直接预览Word文件先转成PDF再预览。我服务器上装了LibreOffice定时任务把上传的doc/docx转成pdf存放在预览目录。这个功能让导师不用下载文件就能在线看内容实际用起来体验提升相当明显。5. 选题秒杀场景Redis分布式锁与数据库唯一索引的双保险5.1 抢选题到底是什么样的并发模型选题志愿制不会出现所有学生抢一个题目的极致并发但“冷门热门”差距真实存在。开放志愿填报的第一小时一个热门题目可能同时收到几十个学生的申请记录。由于学生要填1到3个志愿系统内部出现了多个学生同时对一个topic插入selection_record的操作。如果代码是“先select判断题目有没有被选满再insert”这种写法一定会出问题。两个请求同时通过select发现名额还空着一个然后同时insert最终结果是两个人都被记录成“待确认”一名导师发现自己莫名多了超出名额上限的申请。这在功能上可能不算致命但会直接击穿导师对系统的信任。这里的核心目标是确保“同一时间对一个题目的有效选择记录”是唯一的并且题目名额不能超卖。我用了两级方案Redis分布式锁做前置拦截数据库唯一索引做最终兜底。5.2 Redis分布式锁setnx的正确姿势Redis分布式锁我用的是SETNX加过期时间但这里有个极容易翻车的细节——锁的释放必须校验持有者。如果只是简单地在finally里调用del删除key有可能把别的线程持有的锁误删掉。释放锁时用Lua脚本保证“先比较值再删除”的原子性public boolean lock(String key, String requestId, long expireSeconds) { return redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); } public boolean unlock(String key, String requestId) { String script if redis.call(get,KEYS[1]) ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); return redisTemplate.execute(redisScript, List.of(key), requestId) ! null; }在业务层先按topic_id加锁锁内执行选中校验和插入操作然后释放锁。这样同一时间只会有一个线程真正走到数据库写路径。分布式锁解决的是应用层并发但有一个前提Redis进程本身不能出问题。如果Redis宕机所有请求直接放行到数据库层此时数据库的兜底就上场了。5.3 数据库唯一索引最终防线数据库设计上给selection_record表加一个唯一索引建立在(topic_id, student_id, is_active)这三个字段上其中is_active是一个布尔标志位标记这条选择记录是否有效。插入前不需要查重直接执行insert让数据库来裁决。如果同一学生对同一题目已经有了一条有效记录插入会抛出DuplicateKeyException我在异常处理器里捕获并转换成友好的提示“你已经选择过该题目请勿重复提交”。针对导师名额限制SQL语句做成原子条件更新UPDATE project_topic SET confirmed_count confirmed_count 1 WHERE topic_id #{topicId} AND max_student_num confirmed_count 1只有当更新影响行数为1时才认为名额扣减成功否则提示“该题目名额已满”。这一步防止了导师确认学生时超额的问题。Redis锁、唯一索引、原子更新这三层叠下来并发场景基本能做到不慌不乱。6. 部署上线后的一学期真实使用数据、踩坑复盘和还想改的事6.1 一学期的运行情况系统三月底上线到六月答辩结束累计处理了本系两届学生的流程。数据大概是240余名学生40多位导师220多个有效题目2450多次文件上传1100余条审核记录查重记录300多条。选题阶段第一轮志愿匹配率在82%左右剩下的学生通过第二轮调剂全部落实。这个匹配率不算特别高但考虑到计算机系内热点方向确实集中志愿制加调剂已经能保证最终人人有题、题题有人。导师端的使用反馈普遍不错因为教学秘书不用再在微信群里一个一个催材料了系统会自动推送待办通知。最让我意外的是导师们用得最频繁的不是审核功能而是文件预览功能——不用下载附件就能快速看内容大大缩短了审核路径。6.2 上线后真实踩过的坑这套系统不是一次写完就躺平的运营过程中修了十几个问题挑几个典型的说说。第一个坑是MySQL时区。部署服务器用的UTC时区数据库连接串没指定serverTimezone导致前端显示的任务书提交时间比实际时间早了8小时。学生看到时间不对会很困惑因为这会直接影响“是否按时提交”的判断。解决方式是在MySQL连接串显式加上serverTimezoneAsia/Shanghai同时所有Timestamp字段在Java代码里统一用LocalDateTime避免Date对象隐式转换。第二个坑是EasyExcel导出大列表时的内存溢出。论文评审汇总表导出四千多行数据带十几个字段一次性查询全部然后写文件JVM堆直接爆掉。后来改成分页查询每页写一个Sheet区域的方式每页1000行内存占用降到原来的十分之一try (ExcelWriter writer EasyExcel.write(response.getOutputStream(), AssembleRow.class).build()) { WriteSheet sheet EasyExcel.writerSheet(答辩成绩).build(); int page 1; while (true) { ListAssembleRow rows assembleService.pageQuery(page, 1000); writer.write(rows, sheet); if (rows.size() 1000) { break; } page; } }第三个坑是邮件被反垃圾拦截。系统会给导师发审核通知邮件但学校邮件网关对群发邮件检查很严导致部分导师根本没收到通知一直等到学生来催才发现任务书在系统里躺了两天。后来我在站内信模块上增加了待办数角标并且提供每日汇总邮件导师打开系统首页就能看到待办列表不再完全依赖邮件。还有一个细节是文件下载时中文文件名在不同浏览器下的编码兼容。Chrome和Edge直接用UTF-8编码没问题但老的浏览器会显示乱码。我统一用URLEncoder编码文件名并在响应头里同时设置filename*解决不同客户端的兼容问题。6.3 如果再做一次这几个设计我会调整流程状态机的可配置化是个大方向。当前状态流转是写死在代码里的虽然逻辑清晰但要调整顺序必须改代码。比如有些学院可能会在中期检查和论文提交之间加一个“论文初稿审核”环节现在的代码结构就需要动不少地方。如果重写我会把流程定义做成JSON配置状态和动作全部读配置这样不同专业、不同学院可以自定义流程。消息推送可以上WebSocket实时通知。目前站内信需要刷新页面才能看到体验上还是有延迟。WebSocket把待办数主动推送到浏览器端虽然技术上不难但当时考虑到时间线没有排进去算是留下了明显的升级空间。还有个我一直想做但没做进去的功能是数据看板。需求方其实明确说过希望首页有一张“进度总览大屏”能实时显示当前各环节有多少人卡着哪个导师审核最慢。这个功能没做进去主要是因为当时教务说“表可以导出Excel我们自己看就行了”但真实使用下来导出Excel的频率确实不低。如果再做我会上一个简单的SQL聚合接口让教务端首页直接展示各状态人数分布。做这个系统最大的体会是毕业设计数字化管理这件事技术难度其实不高真正的难点在于流程设计要贴合学校真实的管理习惯能把“退回”“重报”“超时”这种例外情况处理得妥帖。系统内联的每一个状态、每一个审核节点都是跟教务老师、导师磨了无数次需求后才定下来的。如果你也打算做类似的项目建议一定把流程图先画透再动手写代码。流程不透明才是这种管理系统真正要解决的问题。本文还有配套的精品资源点击获取
基于Spring Boot的毕业设计管理系统：全流程数字化设计与实现
简介本资源是面向高校计算机专业师生的毕业设计全流程数字化管理平台聚焦选题分配、任务书审核、开题评审、中期跟踪、论文查重与答辩组织等核心环节解决传统人工管理效率低、流程不透明、进度难监控等问题适用于本科毕设教学管理与课程设计实践。压缩包共2005个文件涵盖1198个JavaScript前端逻辑文件、198个HTML页面模板、161个JSON配置与接口数据、155个Markdown说明文档、140个CSS样式资源以及PHP后端脚本、SQL数据库脚本和PDF/DOCX规范文档等整体23.57MB结构完整、模块清晰便于二次开发与部署。目前已有67人学习下载提供附赠教学资源、详细操作说明及gmis-master主项目源码覆盖前后端全栈实现可直接用于教学系统搭建或毕设管理课程实训。 每年到了四月系办教务老师的微信就开始爆炸“老师我的选题为什么还没审核”“老师指导老师说我开题报告格式不对能不能帮我退回”“老师查重报告传哪里”。纸质版的选题表、任务书、开题报告、中期检查表在不同办公室之间流转Excel表格被十几个人来回编辑最后汇总时版本对不上。我做了个计算机系毕业设计管理系统把从选题、任务书、开题报告、中期检查、论文提交查重到答辩安排的全流程塞进了同一个数字化管理平台一个学期跑下来总算让这套流程从“线下到处找”变成了“线上可追踪”。这篇文章会把整个系统的设计思路、数据库拆解、状态机设计、并发选题的踩坑方案、查重对接和文件管理的细节都摊开来讲。不管你是想拿这个课题当毕业设计还是真打算给系里做一套类似的管理系统这些内容应该都能帮你省掉不少弯路。1. 毕业设计流程的“混乱现场”我为什么要写这个系统1.1 纸质表格与Excel管理模式下的一天没做过教务管理的人可能很难想象一个两百人左右的计算机系年级毕业设计流程旺季时有多混乱。学生端选题通知发下来大家靠抢。有人找学长打听哪个导师给分高有人反复登录教务系统看自己有没有被选中还有学生和导师沟通全靠微信语音关键信息全写在聊天记录里一翻就几十屏。任务书交的时候要求打印签字格式错了要重新跑一趟打印店盖上系章才发现日期写错。导师端一个导师手下可能有七八个学生每个学生的开题报告、中期检查表都要下载、批注、再回传。文件命名常年是“开题报告_最终版3_真的最终版.docx”。光整理这些文件就够占掉一个星期的晚上。教务端手里一份总表记录了所有人的选题、导师、状态但这份总表是多人分工录入的数据经常对不上。张三选题是“已完成”任务书却还没交李四论文查重报告传了两次版本混在一起王五的答辩分组还没排但论文已经进入评阅阶段。教务老师每天干的事情就是“拉表—对账—催交”根本没时间去管流程优化。这套模式最大的问题不是效率低而是流程状态完全不透明。谁在哪个环节卡住了哪个环节缺材料除了教务老师拿Excel肉眼看其他人根本不知道自己该干嘛。所以当系里提出要做一个数字化管理平台时我直接奔着流程管理去而不是做一个简单的文件上传下载站。1.2 系统边界什么该做什么不该做项目启动之前我先画了一条边界线避免做成一个什么都要管的巨型系统。只做毕业设计过程管理不做课程、课表、成绩总管理。系统围绕选题、任务书、开题报告、中期检查、论文提交与查重、答辩这六个环节展开每个环节就是一个独立模块。查重不做替代品只做流程承接。学校有自己的查重服务系统不会去搞一个真正的知网同级别论文库而是接查重服务的接口把查重结果回传并归档。考虑到学生可能想先自己查一遍系统内置了一个本地预检方案用SimHash加余弦相似度给出参考值这个后面会详细讲。账号体系不做开放注册由教务统一导入。学生、导师、教务、答辩组这四类账号都由管理员批量导入不开放自助注册这样权限和数据边界一开始就是可控的。技术栈我选了 Spring Boot 2.7 MyBatis-Plus MySQL 8.0 Redis Vue 3 Element Plus部署形式就是单体应用加一个Nginx简单直接。其实对这种规模的管理系统没必要上微服务单体在开发和运维上的成本都低很多之后扩容数据库加一个索引就够了。2. 六大核心模块拆解从选题双选到答辩成绩回传2.1 选题管理导师申报题目、学生志愿填报、名额限制选题环节的设计上我没有用“先到先得”的抢题模式而是做成类似高考志愿的双选机制。流程是这样的导师在系统里申报题目题目字段包括题目名称、研究方向、难度等级、需要的基础能力、可带人数上限。教务审核通过后题目进入学生可见列表。学生在规定时间内填报1到3个志愿按优先级排列。系统关闭志愿填报后第一轮匹配开始导师进入系统看到的是申请了自己题目的学生列表可以根据学生成绩单、前修课程、项目经历判断然后确认接受或者拒绝。第一轮没匹配上的学生进入第二轮调剂由教务结合剩余名额手动分配。为什么不用先到先得因为计算机系的热门方向和冷门方向差异太大纯手速抢题会导致一批学生抢到“看起来有名字”的题目实际做不了而导师更希望根据学生实际情况来匹配。志愿制给了导师筛选空间也给了学生表达倾向的机会。这个模块在技术上有几个必须处理的细节题目必须校验“是否已满”“是否已下架”“学生是否已有人确认”导师确认时要判断该导师名下学生数是否超过上限一个学生一旦被确认他的其他志愿自动失效。这里最核心的是并发控制后面单独开一节讲。2.2 任务书与开题报告在线提交、逐级审核、版本留痕任务书是学生和导师对课题范围的确认文档开题报告是前期调研和方案论证。两个环节逻辑几乎一样学生上传文件导师审核退回则学生重新上传通过则进入下一环节。这里有一个设计决策比较关键文件上传后系统不直接改原记录而是生成一个新版本。每次退回和重新提交都保留历史版本数据库里的task_book表、opening_report表都带version字段审核记录里能看到“第2版提交时间、审核时间、退回原因”。带版本号的管理方式实话说最初不是从需求文档里来的而是被实际问题逼出来的。有学生反馈“老师我不小心传错文件了能不能删掉重传”如果没有版本设计那就是直接覆盖出了问题说不清。加了版本管理之后每次提交都是一条独立的审计记录传错了可以重新提交但旧文件依然保留师生纠纷和教务对账都简单很多。开题报告比任务书多一个评审环节。开题评审一般由答辩小组或教研室老师参与系统里做成“导师审核通过后再由教务分配的评审组长给出评审结论”。评审结论有“通过”“修改后通过”“重新开题”三种修改后通过的要在评审意见里写明修改要求。2.3 中期检查进度填报、异常标记与风险预警中期检查之所以单独做一个模块是因为它是整个毕业设计周期里最能反映“学生个人状态”的节点。很多学生前期不写最后一个月通宵赶中期检查能把这类问题提前暴露出来。表单设计上中期检查表包含当前完成进度百分比、已完成的主要工作、遇到的问题、需要导师支持的内容、下一步计划。学生填写后导师在系统里填写指导意见。教务设置了预警规则如果学生填写的进度百分比低于40%或者导师评定为“滞后”系统自动给教务和学生推送预警标记在管理后台的统计列表里用红色标出。这里顺便解决了线下“中期检查表交了没交”的确认难问题每次提交和审核都会在系统里留下时间线。谁什么时候交的导师什么时候审的一目了然。2.4 论文提交、查重结果登记与答辩管理论文提交模块是整个流程的收口环节也是教务最关注的地方。学生上传最终版论文格式限制为PDF或Word文件名系统自动改成“学号_姓名_论文题目_v1”。上传之后教务可在后台点击“送查重”系统调用查重服务。查重过程和结果必须留痕。用户提交查重两次第一次30%第二次28%取哪次以“最终送审版”所关联的那次为准。所以数据库里查重记录和论文版本是绑定的论文每一个版本对应一条查重结果。查重通过后论文进入评阅阶段。系统会按答辩分组自动生成评阅任务一个学生分配两个评阅人评阅人可在线下载论文、填写评阅意见和评分。最终答辩环节答辩秘书在系统里安排分组、时间、地点答辩委员会按小组录入评分表。成绩计算规则一开始就要配置清楚总评成绩由导师评分30% 评阅评分30% 答辩评分40%加权汇总。答辩评分又细分四项选题意义、论文质量、答辩表达、回答情况每项25分。这些规则全部做成配置项教务可以在后端调整不用改代码。模块和角色的关系我用一个表来总结开发的时候照着这个表分模块就够清晰了模块学生导师教务答辩/评阅组选题管理提交志愿、查看匹配结果申报题目、确认学生审核题目、手动调剂无任务书在线提交/修改审核/退回查看统计无开题报告在线提交/修改审核分配评审组长评审结论中期检查填报进度填写指导意见预警监控无论文提交与查重提交论文、查看重复率审核最终版送检、结果归档评阅论文答辩管理查看答辩安排上传答辩评分设置分组/权重录入成绩3. 数据库与状态机让每一次退回都有据可查3.1 核心表结构主流程表加环节附件表毕业设计流程的数据模型核心思路可以总结为“一张主流程表 各环节独立业务表 一张公共附件表”。主流程表存学生当前整体进度业务表存各环节的具体业务字段附件表存所有文件的位置和元信息。用户表不做过多扩展毕业设计系统只需要跟身份绑定所以字段是user_id、emp_no学号/工号、real_name、rolestudent/teacher/admin/defense、dept_name、phone、email。选题表topic包含topic_id、teacher_id、title、description、difficulty_level、max_student_num、status草稿/待审核/已发布/未选中/已下线。选课记录表selection_record是并发控制的主战场id、student_id、topic_id、preference_order、status待确认/已确认/已拒绝/已取消、update_time。各环节表长得很像以task_book为例id、student_id、version、file_id、content_text可选、status待提交/待审核/已通过/已退回、submit_time、audit_time、audit_user_id、audit_comment。开题报告表多了opinion、reexamine_flag中期检查表多了progress_percent、risk_flag。论文表和查重记录的绑定关系我单独做了关联因为一次论文提交可能对应多次查重记录。数据库字段里有几个容易踩坑的地方所有时间字段统一用datetime并明确时区避免之后出现“比实际时间早8小时”的诡异问题所有文件和状态字段设置默认值审核意见字段必须设为可空因为不是每次审核都会填意见。附件表是整个系统的地基结构是file_id、biz_typetopic/task_book/opening_report/midterm/thesis/defense、biz_id、file_name、stored_name、file_size、file_ext、uploader_id、upload_time。所有文件统一存一张表不分散到各个业务表里好处是后续做文件批量迁移、垃圾文件清理、上传频率统计都很方便。3.2 流程状态机十二个状态和六个流转动作整个毕业设计进度不是一个简单的“待办已办”布尔值我把它抽象成一条状态链状态含义可执行动作SELECTING选题阶段未提交志愿提交志愿CONFIRMING志愿已提交等待导师确认导师确认/拒绝CONFIRMED选题已确认提交任务书TASK_PENDING任务书待审核导师审核/退回TASK_APPROVED任务书已通过提交开题报告OPENING_PENDING开题报告待导师审核导师审核/退回OPENING_REVIEWING开题报告待评审评审组长给出结论OPENING_APPROVED开题报告已通过填报中期检查MIDTERM_PENDING中期检查待填报提交中期检查表MIDTERM_DONE中期检查已完成提交论文THESIS_PENDING论文待查重教务送检查重THESIS_APPROVED论文查重通过安排答辩DEFENSE_DONE答辩已完成录入成绩加上退回动作还会有更细的中间节点但状态机本身并不复杂。核心是要处理好“动作只能由指定角色执行”和“状态变更必须写进日志表”。每执行一个动作flow_log表插一条记录student_id、from_status、to_status、action、operator_id、comment、create_time。这个流水日志平时似乎没什么用等真正出现纠纷的时候就值钱了。比如学生说“我2号就交过任务书”导师说“没收到”从日志里直接把操作时间线拉出来清清楚楚。状态流转统一写在service层的一个模板方法里。所有业务操作都走同一个入口先查当前状态判断动作是否合法再执行更新最后写流水。这个方法唯一的缺点是写起来有点绕但好处是状态逻辑集中不会出现某个模块直接改数据库绕过流程的“后门”。3.3 数据权限四类角色能看到什么管理系统最容易犯的毛病是“登录进去什么都能看到”。毕设系统里的数据权限必须按角色卡死学生在自己的维度只能看到自己提交的流程单据、自己选题公开信息以及被公开的答辩安排。导师能看到自己申报的题目、申请了自己题目的学生列表以及自己名下学生的全流程进度。教务看全部数据并且可以查看统计报表。答辩组长和评阅人只能看到被分配的学生论文不能看到其他学生的个人信息。实现上我用了一个比较简单的方式MyBatis-Plus的数据权限插件在查询语句后面自动拼接“(teacher_id 当前用户id)”或者“student_id 当前用户id”。针对答辩组和评阅人这类以“被分配”为准的角色提前生成一张分配表defense_assignment然后数据权限拼的是“student_id in (select student_id from defense_assignment where reviewer_id 当前用户id)”。这套数据权限在开发初期不显眼但它决定了系统能不能真正落地。如果导师登录后能看到全系学生的选题信息哪怕只是多了几百行数据也会让使用体验变得非常怪异。4. 查重预检与文件管理系统里最容易被低估的两个技术点4.1 本地查重预检SimHash加余弦相似度的组合方案学校里买的查重服务通常有次数限制正式送检之前很多学生会拿论文到外面网上花钱查又贵又有论文泄露风险。所以我做了一个轻量级本地预检给学生一个参考重复率准确度肯定比不上商业库但用来排除明显的大段复制情况够用了。预检算法采用的是SimHash加余弦相似度组合。SimHash适合判断整篇论文的整体相似度效率极高一篇几万字的论文能在几十毫秒内算出指纹但在局部抄袭检测上它不够细所以配合余弦相似度把论文按段落切块对疑似重合的区块做精确比较。SimHash的具体做法是把论文文本做分词每个词算一个hash值然后根据词频设置权重把hash值逐位累加成一个64位指纹。两个文本的相似程度用汉明距离衡量距离小于等于3就认为非常相似。下面这段是我实现的核心部分public class SimHash { private final LongHashFunction hashFunction LongHashFunction.xx3(); public long simHash(String text) { MapString, Integer wordWeight segmentAndCount(text); int[] bits new int[64]; for (Map.EntryString, Integer entry : wordWeight.entrySet()) { long wordHash hashFunction.hashChars(entry.getKey()); int weight entry.getValue(); for (int i 0; i 64; i) { if (((wordHash i) 1) 1) { bits[i] weight; } else { bits[i] - weight; } } } long fingerprint 0L; for (int i 0; i 64; i) { if (bits[i] 0) { fingerprint | (1L i); } } return fingerprint; } public double similarity(long hash1, long hash2) { int distance Long.bitCount(hash1 ^ hash2); return Math.max(0D, 1D - distance / 64D); } }开题报告和论文初稿提交后系统自动做一次预检在页面显示“本地预检相似度”仅供导师参考。正式查重还是以学校服务为准预检结果不进入最终成绩计算。这个功能上线后反而成了学生用得最多的功能之一因为至少不用一稿二稿到处找亲戚朋友帮忙看重复率了。4.2 对接学校查重服务异步回调的流程设计查重服务调用是不能用同步接口硬等的。一次查重可能要排队几分钟到二三十分钟如果HTTP请求就这么挂在那里网关超时、连接池耗尽都是迟早的事。所以我这边做的是异步设计。学生或教务触发“送查重”后系统创建一个duplicate_check_request记录状态设为CHECKING然后调用查重服务的提交接口把论文文件传过去服务端返回一个task_id。本地不阻塞页面提示“查重任务已提交完成后将自动更新”。查重服务支持两种方式通知结果一种是回调服务端查完后POST一个结果到我们配置的回调URL另一种是轮询我们定期调用查询接口。回调是首选但为了兼容我也写了一个定时任务兜底每五分钟扫描一次超过十分钟还没有回调结果的CHECKING记录重新查询状态。回调接口的逻辑有一个容易忽略的点必须做幂等处理。外部服务可能因为网络原因回调多次每次回调都更新单据会把状态搅乱。我在duplicate_check_request表里加了request_no唯一键回调处理前先按request_no查一遍已经更新过的直接忽略。查重结果返回后系统更新论文版本的duplicate_result字段同时判断总评规则里的“查重不通过”条件如果超过阈值论文状态自动退回给学生修改。4.3 文件上传下载格式白名单、大小限制、路径安全毕业论文系统里有大量文件交互这块做不好系统会显得非常不专业。我的文件方案是“白名单校验 应用层大小限制 服务端重命名 按业务分目录存储”。文件扩展名白名单是硬编码在配置中心里的只允许doc、docx、pdf、zip、rar、jpg、png。上传接口会同时校验货真价实的文件头信息比如PDF文件头必须包含%PDFWord文件头要符合zip格式特征。只校验扩展名是不行的把exe改成pdf就能绕过文件头校验能极大提高防护水平。每个文件上传后被重新命名为“UUID 下划线 学生学号 扩展名”原文件名完整保留在附件表的file_name字段里。存储目录按biz_type分upload/topic、upload/task_book、upload/opening_report、upload/thesis、upload/defense。下载接口通过附件表里的stored_name定位文件不允许用户直接传路径访问。Nginx静态资源部分我直接映射了上传目录location /upload/ { alias /data/dfs/dept_upload/; expires 7d; add_header Cache-Control private, no-store; }还有一个细节是要处理文件预览。PDF可以用pdf.js直接预览Word文件先转成PDF再预览。我服务器上装了LibreOffice定时任务把上传的doc/docx转成pdf存放在预览目录。这个功能让导师不用下载文件就能在线看内容实际用起来体验提升相当明显。5. 选题秒杀场景Redis分布式锁与数据库唯一索引的双保险5.1 抢选题到底是什么样的并发模型选题志愿制不会出现所有学生抢一个题目的极致并发但“冷门热门”差距真实存在。开放志愿填报的第一小时一个热门题目可能同时收到几十个学生的申请记录。由于学生要填1到3个志愿系统内部出现了多个学生同时对一个topic插入selection_record的操作。如果代码是“先select判断题目有没有被选满再insert”这种写法一定会出问题。两个请求同时通过select发现名额还空着一个然后同时insert最终结果是两个人都被记录成“待确认”一名导师发现自己莫名多了超出名额上限的申请。这在功能上可能不算致命但会直接击穿导师对系统的信任。这里的核心目标是确保“同一时间对一个题目的有效选择记录”是唯一的并且题目名额不能超卖。我用了两级方案Redis分布式锁做前置拦截数据库唯一索引做最终兜底。5.2 Redis分布式锁setnx的正确姿势Redis分布式锁我用的是SETNX加过期时间但这里有个极容易翻车的细节——锁的释放必须校验持有者。如果只是简单地在finally里调用del删除key有可能把别的线程持有的锁误删掉。释放锁时用Lua脚本保证“先比较值再删除”的原子性public boolean lock(String key, String requestId, long expireSeconds) { return redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); } public boolean unlock(String key, String requestId) { String script if redis.call(get,KEYS[1]) ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); return redisTemplate.execute(redisScript, List.of(key), requestId) ! null; }在业务层先按topic_id加锁锁内执行选中校验和插入操作然后释放锁。这样同一时间只会有一个线程真正走到数据库写路径。分布式锁解决的是应用层并发但有一个前提Redis进程本身不能出问题。如果Redis宕机所有请求直接放行到数据库层此时数据库的兜底就上场了。5.3 数据库唯一索引最终防线数据库设计上给selection_record表加一个唯一索引建立在(topic_id, student_id, is_active)这三个字段上其中is_active是一个布尔标志位标记这条选择记录是否有效。插入前不需要查重直接执行insert让数据库来裁决。如果同一学生对同一题目已经有了一条有效记录插入会抛出DuplicateKeyException我在异常处理器里捕获并转换成友好的提示“你已经选择过该题目请勿重复提交”。针对导师名额限制SQL语句做成原子条件更新UPDATE project_topic SET confirmed_count confirmed_count 1 WHERE topic_id #{topicId} AND max_student_num confirmed_count 1只有当更新影响行数为1时才认为名额扣减成功否则提示“该题目名额已满”。这一步防止了导师确认学生时超额的问题。Redis锁、唯一索引、原子更新这三层叠下来并发场景基本能做到不慌不乱。6. 部署上线后的一学期真实使用数据、踩坑复盘和还想改的事6.1 一学期的运行情况系统三月底上线到六月答辩结束累计处理了本系两届学生的流程。数据大概是240余名学生40多位导师220多个有效题目2450多次文件上传1100余条审核记录查重记录300多条。选题阶段第一轮志愿匹配率在82%左右剩下的学生通过第二轮调剂全部落实。这个匹配率不算特别高但考虑到计算机系内热点方向确实集中志愿制加调剂已经能保证最终人人有题、题题有人。导师端的使用反馈普遍不错因为教学秘书不用再在微信群里一个一个催材料了系统会自动推送待办通知。最让我意外的是导师们用得最频繁的不是审核功能而是文件预览功能——不用下载附件就能快速看内容大大缩短了审核路径。6.2 上线后真实踩过的坑这套系统不是一次写完就躺平的运营过程中修了十几个问题挑几个典型的说说。第一个坑是MySQL时区。部署服务器用的UTC时区数据库连接串没指定serverTimezone导致前端显示的任务书提交时间比实际时间早了8小时。学生看到时间不对会很困惑因为这会直接影响“是否按时提交”的判断。解决方式是在MySQL连接串显式加上serverTimezoneAsia/Shanghai同时所有Timestamp字段在Java代码里统一用LocalDateTime避免Date对象隐式转换。第二个坑是EasyExcel导出大列表时的内存溢出。论文评审汇总表导出四千多行数据带十几个字段一次性查询全部然后写文件JVM堆直接爆掉。后来改成分页查询每页写一个Sheet区域的方式每页1000行内存占用降到原来的十分之一try (ExcelWriter writer EasyExcel.write(response.getOutputStream(), AssembleRow.class).build()) { WriteSheet sheet EasyExcel.writerSheet(答辩成绩).build(); int page 1; while (true) { ListAssembleRow rows assembleService.pageQuery(page, 1000); writer.write(rows, sheet); if (rows.size() 1000) { break; } page; } }第三个坑是邮件被反垃圾拦截。系统会给导师发审核通知邮件但学校邮件网关对群发邮件检查很严导致部分导师根本没收到通知一直等到学生来催才发现任务书在系统里躺了两天。后来我在站内信模块上增加了待办数角标并且提供每日汇总邮件导师打开系统首页就能看到待办列表不再完全依赖邮件。还有一个细节是文件下载时中文文件名在不同浏览器下的编码兼容。Chrome和Edge直接用UTF-8编码没问题但老的浏览器会显示乱码。我统一用URLEncoder编码文件名并在响应头里同时设置filename*解决不同客户端的兼容问题。6.3 如果再做一次这几个设计我会调整流程状态机的可配置化是个大方向。当前状态流转是写死在代码里的虽然逻辑清晰但要调整顺序必须改代码。比如有些学院可能会在中期检查和论文提交之间加一个“论文初稿审核”环节现在的代码结构就需要动不少地方。如果重写我会把流程定义做成JSON配置状态和动作全部读配置这样不同专业、不同学院可以自定义流程。消息推送可以上WebSocket实时通知。目前站内信需要刷新页面才能看到体验上还是有延迟。WebSocket把待办数主动推送到浏览器端虽然技术上不难但当时考虑到时间线没有排进去算是留下了明显的升级空间。还有个我一直想做但没做进去的功能是数据看板。需求方其实明确说过希望首页有一张“进度总览大屏”能实时显示当前各环节有多少人卡着哪个导师审核最慢。这个功能没做进去主要是因为当时教务说“表可以导出Excel我们自己看就行了”但真实使用下来导出Excel的频率确实不低。如果再做我会上一个简单的SQL聚合接口让教务端首页直接展示各状态人数分布。做这个系统最大的体会是毕业设计数字化管理这件事技术难度其实不高真正的难点在于流程设计要贴合学校真实的管理习惯能把“退回”“重报”“超时”这种例外情况处理得妥帖。系统内联的每一个状态、每一个审核节点都是跟教务老师、导师磨了无数次需求后才定下来的。如果你也打算做类似的项目建议一定把流程图先画透再动手写代码。流程不透明才是这种管理系统真正要解决的问题。本文还有配套的精品资源点击获取