从大四下学期开始我周围几乎每天都有同学在群里问同一句话有没有XX课的作业借我参考一下作为计算机专业的学生我太清楚这种参考背后的潜台词了——课程作业的互相拷贝在高校里早就不是个别现象。也正是因为这个原因当我拿到毕业设计选题时我几乎没有犹豫就选了基于Spring Boot的大学生作业查重系统这个方向既有真实的应用场景又能把Java Web、Spring Boot、算法设计这些大学四年学的东西串起来是一个性价比很高的毕设选题。这篇博文我会尽量完整地复盘我整个系统的设计与实现过程从需求拆解、技术选型、数据库设计到查重算法的核心编码、异步处理的细节再到毕设答辩前做的各种准备。内容会比较长但每一步都来自我实际跑通项目的经验而不是教材上的理想化设计。不管你是准备拿这个题目做毕设还是想基于Spring Boot做一款类似的检测工具这篇文章都能给你省下大量踩坑的时间。1. 从课题需求到功能拆解查重系统到底要做什么很多同学拿到题目第一反应就是查重系统不就是一个文件比对工具吗把学生交上来的作业两两比较一下算个相似度完事。这个理解不算错但离毕业设计三个字的要求差得很远。一个能写进论文、能通过答辩的查重系统必须从用户角色、业务流程、核心算法、数据模型四个维度都想清楚。1.1 系统涉及的三类角色与核心痛点我最终把系统用户分成三类管理员、教师、学生。这个划分不是拍脑袋想的而是顺着真实教学场景推下来的。管理员负责最基础的支撑工作——维护课程信息、管理教师账号、查看全系统的检测统计比如某门课程的平均相似度、疑似抄袭作业数量这类宏观数据。教师是查重系统的主要使用者他们要创建课程、布置作业、查看学生提交情况、发起查重并查看检测报告。学生则是被检测方角色相对简单查看作业要求、上传自己的作业文件、查看自己的查重结果通常只能看到自己的不能看到别人的这个权限控制细节后面会讲。这三个角色的痛点其实很清晰教师的痛点是没时间逐份比对。一个班50人两两比较需要上百次人工比对根本不现实。学生的痛点是不知道自己哪些段落写得和别人重复如果能在提交前得到一个检测结果反而会促使他们主动修改而不是盲目抄袭。管理员的痛点是缺乏全局视图无法判断哪些班级、哪些课程抄袭问题严重。我把这些痛点直接转化成了需求点最终形成了六张功能模块表用户认证、课程作业管理、作业提交、查重引擎、报告管理、数据统计。接下来的编码工作基本都是围绕这六个模块展开的。1.2 查重流程的两个重要设计决策在需求分析阶段有两个设计决策非常关键直接影响了后面所有代码的写法。第一个是查重触发时机。市面上很多查重系统支持提交即查重也就是学生一交作业系统立刻实时检测。但落实到课程作业场景里这种方式有隐患如果每个学生交作业都触发一次全量比对系统压力会很大而且学生完全可以利用实时检测结果反复修改提交反而把查重系统变成了刷分工具。我最终采用的是教师手动触发批量检测模式作业截止后教师选择某次作业点击一键查重系统才对全班所有提交文件做两两比对。这个决策从业务上讲更合理从技术上讲也大幅简化了并发处理逻辑。第二个是比对范围。只比对本次作业的内部提交还是同时比对历史作业的提交考虑到课程作业经常有学长学姐的作业流传下来的情况我最终允许教师选择查重范围仅本次作业或者包含该课程下所有历史作业。这样做不仅在功能上更完整在毕设答辩时也更好讲——因为它体现了你对跨届抄袭这个真实场景的思考。1.3 非功能性需求同样要写进文档除了功能模块我还在需求分析阶段列了几个非功能性指标单次查重100份文档纯文本场景整体处理时间不超过5分钟系统需要能识别txt、doc、docx、pdf四种常见格式当时没做图片OCR一来复杂度太高二来本科毕设讲清楚文本查重已经够用不允许学生互相查看检测报告查重阈值分级要可配置。这些指标在我后面写论文和答辩时是很好的支撑素材面试官或答辩老师问你的系统性能怎么样时你手里有具体数字回答就有底气。2. 技术选型与整体架构为什么是Spring Boot而不是SSH题目里直接写了基于Spring Boot框架所以大方向是定死的。但Spring Boot内部还有很多细分选择。我花了一些时间做了完整的技术选型对比下面把当时的决策逻辑摊开说。2.1 后端框架对比与选型结论技术在选的时候一定要有对比意识。我整理了下面这张表方案开发效率学习成本生态丰富度我的选择理由SSHStruts2SpringHibernate低高一般配置繁琐已经被主流淘汰SSMSpringSpring MVCMyBatis中中较好适合学习底层原理但手写配置较多Spring Boot MyBatis-Plus高低丰富自动配置省去大量XML内置CRUD方法开发极快Spring Boot Spring Data JPA高中丰富复杂查询不够直观动态SQL支持弱我做毕设的周期就三四个月没有时间浪费在配置文件上。Spring Boot的自动配置机制帮我省掉了Spring MVC、事务管理、数据源、Jackson这些组件的所有XML配置起步就是写业务代码。MyBatis-Plus又在MyBatis基础上封装了通用的CRUD接口单表操作基本不用写SQL大段的时间可以集中到查重算法上——那才是这个项目的灵魂。有个细节提醒一下MyBatis-Plus的分页插件需要单独配置不是引入了依赖就自带分页功能。我当时漏了这一步查了半天才发现列表接口一直返回全量数据。2.2 标准项目目录结构这部分热点词汇里也提到了Java Web项目标准目录结构我按照Spring Boot的推荐约定建了包结构com.example.assignmentcheck ├── config // 配置类MyBatis-Plus分页、跨域、Jackson ├── controller // 控制层接收前端请求 ├── service // 业务层核心业务逻辑 │ └── impl // 业务实现类 ├── mapper // 持久层接口继承BaseMapper ├── entity // 数据库实体类 ├── dto // 前端交互对象接收参数 ├── vo // 视图对象返回给前端的数据 ├── common // 通用类结果封装、异常处理、常量 ├── utils // 工具类文件解析、文本预处理、查重算法 └── AssignmentCheckApplication.java // 启动类这里有一个容易被忽视的层级约束Controller层只负责参数接收和结果封装不写任何业务逻辑Service层负责业务编排和事务控制查重算法等重量级计算放在utils或单独的algorithm包中通过与Service的接口调用解耦。这样分层的直接好处是当查重算法出现性能问题需要优化替换时只需要改algorithm包里的类不影响上层接口。2.3 前端设计与数据交互方式前端我选择的是Thymeleaf Bootstrap jQuery ECharts的组合没有上Vue。原因很实际这是毕设核心工作量在后端和算法。Thymeleaf作为服务端渲染模板能直接在HTML页面里写Java风格的表达式th:each、th:text省去了前后端分离需要的那一套跨域、Token传递、拦截器配置。页面风格用Bootstrap保证不丑ECharts用来展示查重统计图表——课程平均相似度趋势、相似度分布直方图等展示效果非常加分。如果硬要用Vue Spring Boot做前后端分离也不是不行但要额外处理CORS、路由守卫、接口鉴权这些对初写毕设的人来说都是隐形的坑。我当时觉得这就是一个管理类Web系统服务端渲染完全够用等以后有真实企业项目需要分离的时候再学Vue也不迟。数据交互方面用户登录后我用JWT生成Token存放在LocalStorage中每次请求由jQuery的ajaxPrefilter自动携带到Header里。后端用一个拦截器HandlerInterceptor统一校验Token的合法性并解析出当前用户信息放到ThreadLocal中供后续业务使用。3. 查重引擎核心设计相似度算法选型与实现原理这是整个系统里最硬核的部分也是答辩时老师最可能追问的部分。网上关于查重的开源实现很多但多数是能用不是讲得清楚。我花了很多时间把三种主流算法都研究了一遍最后在自己系统里做了一个组合方案。3.1 三种主流相似度算法的对比分析在给学生作业做查重之前我先给这些算法自己做了个查重算法核心思路优点缺点适用场景余弦相似度将文本转为向量计算向量夹角余弦值实现简单结果直观适合长文本对词序不敏感同义替换难以识别综合性大作业、课程论文SimHash文本哈希为64位指纹用汉明距离度量差异大数据量下效率极高适合海量文档短文本效果差对微小改动较敏感大规模语料去重如论文库编辑距离Levenshtein计算两字符串转换所需的最少编辑次数对短文本精准能捕捉局部抄袭计算复杂度O(n*m)长文本不可用代码片段、简答题等短内容我的结论是课程作业的场景非常复杂没有单一算法能通吃。有的作业是几百字的实验报告有的是上千行的代码还有的是五六千字的小论文。如果用编辑距离跑长论文计算量会直接爆炸如果用SimHash跑三四行的代码实验报告因为文本太短哈希结果的区分度又不够。3.2 组合算法架构MD5 SimHash 余弦相似度的三级流水线我最终设计了一个三级流水线式查重架构第一级MD5精确去重。先对所有文本内容计算MD5值完全相同的文档直接标记为100%相似。这一级能快速过滤掉全班交同一份答案的情况。第二级SimHash粗筛。对剩余文档两两计算SimHash指纹和汉明距离距离小于等于3的文本判定为高度相似。这一级的优势是计算速度极快——比较两个64位整数的汉明距离只需一次异或运算加bitCount100份文档做两两比较也就是几千次运算量。第三级余弦相似度精算。对SimHash判断为可能存在重复的文档对再做一次余弦相似度计算得到更加平滑的相似度分值0到1之间的小数避免SimHash的非0即1式粗糙判断。这个三级流水线看起来复杂实际上每一级都有明确任务各自负责一段粒度的检测在效率和准确度之间取得了平衡。SimHash本身的实现要点如下对文本分词后为每个词计算一个64位哈希值我用的MD5后取前64位词语按权重用TF-IDF计算对hash的每一位进行加权累加——某位为1则加上权重为0则减去权重所有词处理完后最终每一位大于0记为1小于等于0记为0得到一个64位的指纹两个文档的相似度 1 - (汉明距离 / 64)。汉明距离的实现也很经典一行代码就能解决public static int hammingDistance(long hash1, long hash2) { return Long.bitCount(hash1 ^ hash2); }3.3 文本预处理查重准确率的隐藏决定因素查重算法再精妙如果喂进去的文本是脏的结果一定是一团糟。文本预处理是查重系统中最琐碎但最重要的一步我在这个环节踩过很深的坑。我的预处理流水线是不用mermaid我用文字描述这个流水线格式转换doc、docx、pdf统一用Apache POI和PDFBox解析成纯文本去掉页眉页脚、图片注释空白字符归一化把所有连续空白符换行、Tab、多个空格统一替换为单个空格这一步能防止每行换一个词这种低劣的规避手段中文分词使用HanLP的StandardTokenizer将中文句子切分为词语序列停用词过滤加载常见中文停用词表的、了、是、在、以及一些无实际意义的虚词和英文停用词表the、a、an等把不携带语义信息的词过滤掉同义词合并简单做了常见同义词映射如数据→资料、算法→方法——这个功能不是必需的但加上了可以显著提升对小幅度改写行为的识别能力。这里有一个加分项我提前对文本做了分句处理。先按句号、问号、感叹号把文本切成句子列表查重时不仅做全文对全文的整体比对还会做句子对句子的局部比对。这样原文中某一段话被抄走即使整篇文章相似度不高也能在报告中明确标出哪一句与哪一篇文档相似。这个功能在答辩演示时效果特别爆炸因为老师能看到的不只是一个冷冰冰的数字而是一段高亮标红的详细报告。汉语言文学专业的同学可能更容易理解这一步文本预处理的目的就是把语言表达上的皮毛差异剥掉只留下承载核心语义的骨骼然后在骨骼层面做对比。4. 核心模块落地数据库设计、业务流程与异步查重需求理清了算法选型定下来了接下来就是大量编码落地的工作。这一章我重点讲三个核心环节数据库表怎么设计、作业提交与文件解析怎么实现、查重任务用什么机制避免超时。4.1 数据库表结构E-R关系与关键字段我设计了7张核心表用户表、课程表、选课表、作业表、作业附件表、提交记录表、查重结果表。关键的字段设计我做了几个取舍值得说说提交记录表submission唯一约束设计成(homework_id, student_id)防止同一学生重复提交同一作业用submit_count字段记录第几次提交配合is_latest字段标记当前有效版本。因为教师查重需要知道是第几次提交的内容直接覆盖旧版本会丢失历史痕迹content_text字段存解析后的纯文本避免每次查重都重新解析文件file_url字段存原始文件路径供在线预览下载。查重结果表check_result每次查重任务产生一条任务记录关联homework_id、operator_id、range_type查重范围和start_time/end_time每对相似文档产生一条明细记录字段有source_submission_id、target_submission_id、similarity_rate整体相似度、similar_sentences重复句子明细存JSON格式的句子对列表。这里的JSON字段是很实用的设计后端把匹配到的句子对序列化成JSON数组后存到字段里前端拿到后直接渲染成报告表格不需要再单独建一张句子明细表节省了大量关系模型设计工作。4.2 文件上传与解析MultipartFile到纯文本的完整链路文件上传是学生端使用频率最高的功能但也是最容易出Bug的地方。核心链路是前端bootstrap-fileinput插件发出上传请求 → 后端MultipartFile接收 → 保存原始文件到本地磁盘 → 调用文件解析工具类提取纯文本 → 存入数据库。文件解析我用了一个策略模式根据扩展名分发到不同的解析器public class FileContentParser { private static final MapString, DocumentParser PARSERS new HashMap(); static { PARSERS.put(txt, new TxtParser()); PARSERS.put(doc, new DocParser()); PARSERS.put(docx, new DocxParser()); PARSERS.put(pdf, new PdfParser()); } public static String parse(String filePath) throws IOException { String ext FilenameUtils.getExtension(filePath).toLowerCase(); DocumentParser parser PARSERS.get(ext); if (parser null) { throw new UnsupportedOperationException(不支持的文件格式: ext); } return parser.parse(filePath); } }docx的解析用POI的XWPFDocument注意处理表格里的文字doc格式要用HWPFDocument但老版本兼容性较差实测对部分doc文件会解析失败pdf用PDFBox的PDFTextStripper但要注意它对扫描版PDF纯图片一点办法都没有这种文件只能标记为无法解析需人工查看。系统上线到演示阶段时我建议在作业要求里明确写出请提交可解析的文本格式文件能省掉很多麻烦。4.3 异步查重任务线程池 状态轮询避免请求超时第一次写完查重接口我直接用同步方式测试——一点查重按钮前端页面就卡死在原地转圈。100份文档两两比对就算算法再快也需要好几秒甚至几十秒。这个体验肯定是不能接受的。我后来改成异步任务 状态轮询方案实现思路是这样的教师点击查重时后端在check_task表插入一条任务记录初始状态为处理中立即返回task_id给前端后端把查重任务丢进一个线程池执行线程池核心线程数设为CPU核心数我的开发机是8核所以设为8前端拿到task_id后每3秒轮询一次任务状态接口如果状态变成已完成就自动跳转到查重报告页。线程池的创建方式要注意不能直接Executors.newFixedThreadPool()因为默认的任务队列是LinkedBlockingQueue队列大小无上限一旦任务积压会占满内存。我用的写法是这样的Bean(checkTaskExecutor) public ThreadPoolTaskExecutor checkTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(50); executor.setKeepAliveSeconds(60); executor.setThreadNamePrefix(check-task-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }CallerRunsPolicy这个拒绝策略值得多说一句当队列满了且线程数达到上限时新任务不会直接丢弃而是由提交任务的线程即请求线程自己执行。这样虽然会短暂阻塞请求但至少保证任务不丢。查重任务这种场景丢一个就意味着一份作业永远没结果那比慢慢跑几分钟更糟。4.4 查重算法主流程的编码实现查重主流程是我整个系统里逻辑最密集的部分抽出几个核心片段给大家看看。文本向量化的余弦相似度实现public class CosineSimilarity { public static double calculate(MapString, Double vector1, MapString, Double vector2) { SetString union new HashSet(vector1.keySet()); union.addAll(vector2.keySet()); double dot 0.0, norm1 0.0, norm2 0.0; for (String term : union) { double w1 vector1.getOrDefault(term, 0.0); double w2 vector2.getOrDefault(term, 0.0); dot w1 * w2; norm1 w1 * w1; norm2 w2 * w2; } if (norm1 0.0 || norm2 0.0) { return 0.0; } return dot / (Math.sqrt(norm1) * Math.sqrt(norm2)); } }向量来源于TF-IDF权重一个词在某篇文档中出现次数越多越重要但在整个语料库中出现越多反而越不重要。我实现了自己的TF-IDF计算器用HashMap存储词频用倒排索引统计文档频率。这一步是整个查重准确率的地基不要用简单的词频权重替代。查重主服务的流程可以概括为从数据库查出该次作业的所有提交记录逐条解析出content_text做文本预处理得到词频Map和SimHash指纹第一轮MD5去重第二轮SimHash粗筛第三轮对疑似文档对跑余弦相似度精算对相似度超过设定阈值我默认30%的文档对做句子级比对提取重复句子列表结果批量写入数据库。这里还有个性能优化点值得说解析文本、计算指纹这些操作都是先经过预处理缓存到内存Map里的。只有最终筛选出来的文档对才会做完整句子级比对否则每个文档对都做一次全文本句子匹配100份文档就是4950对计算量会非常夸张。5. 实际开发中踩过的坑与排查思路这个项目的开发过程不是一帆风顺的有几个坑我花了很长时间才定位到根因写出来算是帮后来人提前排雷。5.1 字符编码问题读取docx中文乱码的完整排查链路问题现象上传一份中文docx文件解析后存入数据库的文本全是乱码。排查过程第一步我用文本编辑器直接打开POI解析后的字符串发现控制台输出乱码。于是怀疑是POI解析的问题第二步单独写了一个单元测试用POI解析同一份docx文件打印字符串。结果控制台乱码依旧第三步检查IDE的默认字符集——IntelliJ IDEA的File Encoding默认是UTF-8这个没问题第四步重点检查读取文件InputStream时的编码声明。发现我用POI的XWPFDocument时没有指定编码POI底层用的是UTF-8理论上不该出问题第五步最后排查出来问题出在HTTP请求传输环节。前端上传文件时没有显式指定accept-charset后端Tomcat的URIEncoding默认是UTF-8但表单提交部分老旧的框架会把默认编码降级为ISO-8859-1。加了CharacterEncodingFilter并把forceEncoding设为true后乱码问题消失。这个坑的最终解法是Bean public CharacterEncodingFilter characterEncodingFilter() { CharacterEncodingFilter filter new CharacterEncodingFilter(); filter.setEncoding(UTF-8); filter.setForceEncoding(true); return filter; }顺带一提forceEncoding设为true很关键它不仅能处理请求体也能强制处理响应体否则页面返回中文时也可能出现锟斤拷式的乱码。5.2 滚动更新卡死MyBatis-Plus大批量插入的性能陷阱查重完成后要写入数据库第一次我直接用单条insert循环插入100份文档加上句子明细插了5分钟还没结束数据库连接池直接耗尽应用假死。这个问题的根因很清楚逐条提交会产生大量数据库往返每次往返都有固定的网络延迟和事务开销。解决思路是分两段走明细数据用MyBatis-Plus的saveBatch方法分批插入每批500条更重要的是处理时先批量插入明细最后统一更新任务状态而不是每条明细都各自提交一次事务。实测下来100份作业的查重结果大约3000多条明细从5分钟缩短到了不到15秒性能提升非常显著。5.3 JWT过期与跨页跳转的状态丢失问题由于我用的是JWT无状态认证这一套机制有个天然的小坑JWT一旦签发在过期时间之前是无法主动撤销的。如果学生在查重报告页面停留时间过长Token过期后再点返回列表请求带上的旧Token失效系统会直接跳转到登录页前面的浏览状态全部丢失。我的解决方案是前端封装一个全局的ajax响应拦截器当遇到401状态码时不立刻跳转登录页而是先弹出一个友好的提示框询问用户是否重新登录。如果用户选择重新登录并成功则自动重放之前的请求。这个细节在演示时挺加分因为说明你考虑到了真实使用场景中的用户体验而不只是机械地写CRUD。5.4 超长作业文本导致的内存占用过高有个学生的作业交了3万字文件解析后纯文本长达十几万字符。查重时每个文档的SimHash指纹和词频向量都在内存里如果100个学生都是这种长文内存占用会迅速飙升。我这里用了两个优化措施词频统计时设置最大特征词数每篇文档只保留TF-IDF值最高的200个词其余丢弃。实践证明查重准确率影响极小但内存占用下降了几个量级SimHash指纹本来就只有64位开销极小。真正耗内存的是保存词频权重Map所以特征词裁剪的意义主要在这里。5.5 前端图表数据显示为空的间歇性BugECharts数据加载偶尔显示空白刷新页面后又正常。排查发现是图表初始化时机太早——DOM元素还没渲染完成ECharts就执行了init()。这个问题通过$(document).ready()setTimeout解决更稳妥的方案是使用ECharts官方推荐的resize监听与数据请求完成后的回调来初始化图表$.get(/api/check/stats?homeworkId id, function (data) { let chart echarts.init(document.getElementById(chartBox)); chart.setOption({ title: { text: 相似度分布图 }, xAxis: { data: data.labels }, yAxis: { type: value }, series: [{ type: bar, data: data.values }] }); });核心原则就一条任何图表初始化的时机一定要放在数据就绪且DOM渲染完成之后。6. 系统演示与毕设答辩的准备经验系统写完只是第一步怎么把它展示好、讲清楚对最终成绩的影响非常大。这一节分享一些我在准备答辩时总结的经验。6.1 测试数据的准备技巧演示最怕的就是临时上传几份文档结果相似度算法算出来全是0%全场尴尬。我的做法是提前准备三组测试数据第一组两份完全相同的文档用于演示MD5精确去重第二组两份内容相同但文字顺序调整过、少部分词语换成同义词的文档用于演示SimHash余弦相似度的检测能力第三组一份原创文档和一份参考了其中两段并做了改写的文档用于演示句子级重复标记功能。这三组数据覆盖了系统所有核心功能演示时按顺序展示逻辑非常清晰。我还特意准备了一份相似度在30%-50%之间的案例用来展示系统中低风险判定的效果因为老师对这个分数区间的检测结果最感兴趣。6.2 答辩时的高频问题和应答思路把高频问题整理成下面的表每个问题的回答逻辑都写在里面了高频问题我的应答思路为什么选SimHash而不是某某算法只说简单不行要说大数据量下效率高、效果好但短文本区分度不够所以我又用了余弦相似度做精算展示组合方案的思想相似度阈值为什么定30%说明这是实践调优的结果低于30%的文本差异主要来自格式和措辞绝大多数为正常引用误报率高高于30%才有实际参考意义。也可以说阈值已在管理端做成可配置项你的系统准确率是多少坦诚说明无法像商业系统那样量化准确率因为缺少标准评测集但我用50份标注过的真实作业做了人工核对与人工判断的一致率在85%以上系统能防住倒装改写吗承认做不到100%防改写但句子级比对和同义词映射能覆盖大部分基础改写。同时强调这个系统的目标是辅助教师发现疑似抄袭而不是替代人工判断未来怎么优化说三个方向引入NLP的语义向量模型如BERT识别深层改写、支持图片查重OCR、构建更大规模的历史语料库做跨届查重这些回答都遵循一个原则不夸大、不回避先承认边界再说明自己的优化方向。答辩老师往往很吃这一套因为它反映的是你对自己系统的清醒认知而不是盲目自吹。6.3 关于论文写作的几个建议最后说说论文。很多同学代码写完了论文却卡住了。我的建议是论文结构一定要对应系统功能来写每一章要有交付物第一章绪论背景与意义重点写高校作业抄袭的现状和人工查重的局限第二章相关技术Spring Boot、MyBatis-Plus、SimHash、余弦相似度等每一节都用技术是什么 为什么选它的结构不要光堆概念第三章系统分析用例图、功能模块图、非功能性需求第四章系统设计架构图、流程图、E-R图、数据库表结构文档第五章系统实现每个核心模块贴关键代码和运行截图注意代码要精选别把整个类都贴进去第六章系统测试功能测试用例表、性能测试结果、测试结论第七章总结与展望。这套结构是我论文的最终骨架每一章的素材都是在开发过程中同步收集的。强烈建议不要最后两星期再集中写论文平时每做完一个模块就截图存好每次调通一个Bug就记录下问题原因——这些素材最后都是论文里最实在的内容。做这个系统的整个过程中我最大的体会是毕业设计不是比谁用到的技术高级而是比谁把自己的方案讲得最自洽。Spring Boot作为载体MyBatis-Plus作为效率工具真正体现专业能力的其实是查重算法的选型与实现以及你面对真实问题时的分析和取舍能力。如果你正在做类似的题目建议把主要精力放在这些深度问题上而不是纠结于又要多集成一个什么组件。最后再分享一个我在联调阶段发现的小技巧在本地演示前把数据库里的测试账号密码都设置得尽量简单比如admin/123456并且提前确认打印机的默认纸张设置——如果临时需要打印查重报告作为答辩材料这个细节真能救你一命。希望我的这些经验对正在做毕设的你有一点参考价值祝所有同学都能顺利通过答辩。