尧图网页设计 
简介采用Spring Boot和MyBatis Plus构建的代码作业查重系统源码面向计算机专业学生、教师及后台开发人员解决作业提交、原创性检测与评分管理等问题。系统覆盖学生、教师、管理员三种角色支持代码与PDF作业的提交集成JWT安全认证、Redis缓存、Swagger接口文档查重模块基于开源JPlag可有效检测作业相似度便于快速部署与二次开发。压缩包共168个文件以95个Java后端业务类、21个Vue前端页面、16个XML配置和11个SQL数据库脚本为主另含JPlag查重工具jar、YAML环境配置与Markdown说明整体仅2.36MB目录划分清晰适合课程设计、毕业设计或小型作业管理平台参考。已有127人学习资源附带初始化SQL脚本与完整源码可帮助读者理解多角色权限控制、作业流程状态设计及查重服务集成方式减少重复造轮子直接用于功能演示或项目改造。1. 代码作业查重系统学生提交一版老师收一沓“疑似雷同”的判据代码作业查重系统和论文查重完全是两个物种。论文查重看连续字符串匹配代码里一行return ans;能被全校 200 人写得一模一样要是照搬论文那套老师邮箱会被误报通知塞爆。这个基于 Spring Boot 和 MyBatis Plus 的查重系统要解决的核心问题只有一个在“共性允许、抄法隐蔽”的代码作业里把真正雷同的学生挑出来并且让老师拿到能复核的证据。它做的事情不复杂——收作业、存源码、算相似度、出报告但难点全藏在相似度怎么算、算完怎么解释这两件事上。这套系统适合谁两类人最需要。一类是被期末 200 份实验报告逼到凌晨两点的老师另一类是想把“查重”做成毕业设计或小型商业工具的开发者。前者能直接获得可复现的查重报告后者能从这套源码里拆出 Spring Boot 的完整工程结构、MyBatis Plus 的分页与批量写入实践以及纯 Java 实现的文本相似度算法——不需要调外部 API不花钱离线就能跑。下面这份笔记是我按一个可运行方案的思路拆解的从工程骨架、数据表设计到三套相似度算法怎么选、怎么组合再到文件上传的坑和误报调优。我会把关键代码贴出来并解释参数含义最后收在几个能直接救命的进阶技巧上。先说明一点查重系统永远解决不了“判定”它只负责给老师提供“足够解释力”的证据链。2. Spring Boot MyBatis Plus 工程骨架为什么选这套组合以及建表的第一原则2.1 选型理由不是 Spring Boot 多优秀而是查重系统需要的它都有查重系统本质上是一个“文件上传 文本比较 结果展示”的 CRUD 应用但有几个特殊要求上传的源码文件可能同时有几百份、比对任务要排队跑、比对结果要分页查并且要能按相似度排序。这三个需求直接把技术选型框死了。Spring Boot 负责的是“胶水层”文件上传接口、异步任务调度、REST API。MyBatis Plus 负责的是数据层作业表、提交记录表、比对结果表的增删改查它的分页插件和saveBatch批量插入在这种“一次性写入大量比对结果”的场景里比手写 MyBatis XML 少掉一半样板代码。为什么不用 JPA因为查重结果的查询模式高度固定——按作业 ID 查、按相似度倒序、按学生分组MyBatis Plus 的 LambdaQueryWrapper 写起来比 JPA 的 Specification 直观得多而且 SQL 是透明可控的真到了要调索引的时候不至于抓瞎。这跟当年我在一个老项目里用 JPA 调多表关联查询的体验完全不同JPA 在复杂查询下生成 SQL 像黑匣子查重系统这种“老师随时可能按任意维度筛选”的业务SQL 能力透明比建模优雅重要得多。2.2 核心数据表设计五张表三张是必须两张是进阶查重系统的表结构核心就三张作业表、提交表、比对结果表。作业表存“哪门课的哪次作业”提交表存“谁交了哪份文件、文件存哪儿”比对结果表存“A 学生的作业和 B 学生的作业相似度多少、算法用的哪种”。下面是提交表和比对结果表的核心字段建表时第一原则是比对结果表不能存多余数据但必须留 json 字段。为什么因为查重的“判据”需要解释力A 和 B 相似度 78% 只是结果老师真正要看的是一段段高亮匹配的代码片段——这个片段列表就是存进 json 字段的。CREATE TABLE submission ( id bigint(20) NOT NULL AUTO_INCREMENT, homework_id bigint(20) NOT NULL COMMENT 作业ID, student_no varchar(32) NOT NULL COMMENT 学号, file_path varchar(255) NOT NULL COMMENT 源码文件存储路径, file_hash varchar(64) DEFAULT NULL COMMENT 文件MD5用于绝对重复检测, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待比对 1比对中 2已完成 3失败, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_homework_student (homework_id, student_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT作业提交表;file_hash这个字段很多人会忽略但它是最廉价的一层查重两份文件如果 MD5 完全相同相似度直接就是 100%根本不需要跑算法。等会儿在批量比对的时候先按 hash 分组能省掉一大半无效计算。比对结果表在设计时重点考虑的是“怎么让 200 人两两比对的结果不要爆炸式增长”。200 人两两对比是 19900 对每对存一条记录是能接受的但如果每对再存一份完整匹配片段 json表的体积会膨胀到几十 GB。做的时候要注意json 里只存相似度超过阈值的片段每对最多存 20 条片段摘要超过的只存条数。CREATE TABLE compare_result ( id bigint(20) NOT NULL AUTO_INCREMENT, homework_id bigint(20) NOT NULL COMMENT 作业ID, left_submission_id bigint(20) NOT NULL COMMENT 左侧提交ID, right_submission_id bigint(20) NOT NULL COMMENT 右侧提交ID, similarity decimal(5,2) NOT NULL COMMENT 综合相似度0.00-100.00, algorithm_score json DEFAULT NULL COMMENT 各算法得分详情含片段摘要, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0已生成 1已确认, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_homework_pair (homework_id, left_submission_id, right_submission_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT两两比对结果表;建表时踩过的坑是两个索引策略问题第一联合索引(homework_id, left_submission_id)比单独索引(homework_id)在分页查询时快很多因为老师查看详情的过滤条件永远带着两次作业 ID第二decimal(5,2)存相似度比 float 靠谱float 的精度误差会在排序时让两个相等的数产生随机顺序给老师的报告带去不必要的困惑。2.3 工程结构把查重算法和 Web 层彻底隔离构建工程时我一般建议按这个分包结构走查重算法放进独立的core包不要和 controller、service 混在一起。理由很简单查重算法是纯计算逻辑属于“可能随时替换”的部分今天用余弦相似度明天可能换成 SimHash但 controller 和 service 是稳定层不能因为算法替换而动它们。com.copydetect ├── controller │ └── HomeworkController.java │ └── CompareController.java ├── service │ ├── HomeworkService.java │ ├── CompareTaskService.java ├── core │ ├── detector │ │ ├── SimilarityDetector.java统一接口 │ │ ├── CosineDetector.java │ │ ├── SimHashDetector.java │ │ └── LevenshteinDetector.java │ ├── tokenizer │ │ └── CodeTokenizer.java代码分词器按语言去注释去字符串 │ ├── parser │ │ └── MatchSegmentParser.java匹配片段解析用于报告高亮 └── mapper ├── SubmissionMapper.java └── CompareResultMapper.java统一接口长这样所有算法实现都返回一个CompareResult对象包含相似度分数和匹配片段列表。这样 controller 层只依赖接口不关心底下跑的是什么算法将来加新算法也不需要动调用方代码。public interface SimilarityDetector { CompareResult detect(String sourceCode1, String sourceCode2); }这个设计把“算法实现”和“业务编排”变成了两个互不干扰的模块。我见过很多查重系统把算法直接写在 service 里最后加一个特征就开始牵一发动全身非常痛苦。3. 三套相似度算法怎么选余弦、SimHash、Levenshtein 的适用边界与组合策略3.1 代码先标准化不分词、去注释、剥离字符串字面量算法才有意义任何相似度算法输入若不做预处理结果都是噪声。代码文本比自然语言更规则但也更需要针对性的清洗。查重前必须做的标准化有三步去掉注释包括块注释和行注释、去掉字符串字面量内容、按词法边界做 token 切分。为什么要去字符串因为两个学生都可能写System.out.println(请输入一个整数);这句话本身一模一样但不是抄袭证据去掉之后只剩下System.out.println( )这个调用结构。同理注释里的内容更不能参与比对否则“// 这是贪心算法”这种教科书抄来的注释会把相似度虚增好几个点。下面这段 Java 做的是“去注释 按 token 切分”的核心逻辑用正则完成后我会再执行一次按 token 的过滤public String normalize(String source) { // 1. 去掉单行注释// 开头到行尾 String noLineComments source.replaceAll(//[^\\n]*, ); // 2. 去掉块注释/* ... */ 非贪婪匹配 String noBlockComments noLineComments.replaceAll(/\\*(.|[\\r\\n])*?\\*/, ); // 3. 去掉字符串字面量双引号包裹保留引号占位 String noStrings noBlockComments.replaceAll(\([^\\\\\]|\\\\.)*\, \\); // 4. 按 Java 标识符和符号边界切分去掉空格 String[] tokens noStrings.split([\\s\\p{Punct}]); return String.join( , tokens); }参数说明第二步的正则用了(|[\\r\\n])*?这种写法而不是.是因为 Java 正则默认.不匹配换行符如果不处理换行多行注释永远去不干净——这是很多人做文本清洗时最容易翻车的地方。第四步的\\p{Punct}匹配所有标点符号把;、{、}都切掉只保留标识符和关键字序列这是为了后面算余弦时词袋更干净。这一步做完两份功能相同但变量名不同的作业其相似度会自然回落到一个合理区间。变量名不同但结构相同这才是查重系统要抓的核心特征。3.2 三种算法原理对比与适用边界我把三种算法放在一张表里对比这样你在选型时可以少走弯路。算法核心原理优势劣势适用场景余弦相似度把文本转成词频向量计算两向量夹角余弦实现简单、解释性强、支持高频词权重调整不关心 token 顺序调换代码块顺序会误判偏低中等长度的完整文件比对SimHash为每个 token 生成 64 位哈希指纹加权累加后降维成比特向量用海明距离算相似计算极快适合海量两两比对线性复杂度对短文本少于 200 token敏感容易误判先粗筛一轮排除大部分无关对比对Levenshtein 编辑距离计算两字符串之间最少增删改次数除以最大长度得到相似度能抓到局部拷贝、插入死代码的细节复杂度 O(n*m)长文本会慢到令人绝望长度相近的短方法体、函数级别的片段比对这个表格的关键结论是单靠一个算法做代码查重是伪命题。Levenshtein 对文本过长直接失去工程可行性SimHash 对短代码块完全没有区分度余弦相似度丢失顺序信息后会有系统性的偏差。这就是为什么我在中间层的CompareTaskService里用三段式组合SimHash 粗筛只对粗筛通过的组合跑余弦余弦结果显示高度相似或高度不相似时再对局部片段跑 Levenshtein 找证据。组合后的判定逻辑if (simHashDistance 12) { return new CompareResult(0.0, Collections.emptyList()); // 海明距离大于12直接判为无关 } double cosineScore cosineDetector.detect(normalizedCode1, normalizedCode2).getScore(); if (cosineScore 0.85 || cosineScore 0.3) { // 极端情况下用 Levenshtein 精确复核 double levenshteinScore levenshteinDetector.detect(normalizedCode1, normalizedCode2).getScore(); return new CompareResult(combineScore(cosineScore, levenshteinScore), collectSegments(cosineDetector.getSegments())); } return new CompareResult(cosineScore, cosineDetector.getSegments());参数说明simHashDistance 12这个阈值来自经验值——64 位 SimHash 中海明距离小于等于 3 一般认为高度相似3 到 12 是可能有相似大于 12 基本无关。这个阈值会随文本长度产生漂移后续会讲到怎么根据作业平均长度动态调整。3.3 余弦相似度在代码场景里的实现细节TF 不能只用原始词频代码查重里直接凭词频算余弦会有个严重偏差几乎所有 Java 作业都会出现public、static、void、int、return、new这些词它们出现频率高但不携带“谁抄了谁”的信息。处理方法是给这些高频词降权。轻量做法是准备一份 Java 关键字表把这些词从词袋中剔除后再算余弦。严格做法是引入 TF-IDF 权重但代码查重场景里文档集只有 200 份作业时 IDF 计算不充分效果不稳定。我实际落地用的是“黑名单过滤 词频归一化”public MapString, Double buildVector(String normalizedCode) { MapString, Double vector new HashMap(); String[] tokens normalizedCode.split( ); for (String token : tokens) { if (STOP_WORDS.contains(token)) { continue; // STOP_WORDS 包含 Java 关键字和常见 API 名 } vector.put(token, vector.getOrDefault(token, 0.0) 1.0); } // 归一化处理除以向量长度保证不同长度的文件可比较 double norm Math.sqrt(vector.values().stream().mapToDouble(v - v * v).sum()); vector.replaceAll((k, v) - v / norm); return vector; }参数说明normalizeCode之后我直接按空格切分是因为标准化的最后一步把 token 用空格 join 了STOP_WORDS集合里至少要包含public、static、class、void、int、return、new、if、else、for、while这些 Java 关键字。不做这一步两张完全不同的作业相似度也能到 0.35——全是关键字贡献的。做了之后真正的“用户逻辑代码”才开始在向量里体现差别。这份停用词表本身也是可以慢慢调优的资源老师用一段时间后会反馈哪些固定套路代码还应当被忽略。4. MyBatis Plus 数据层实战批量比对任务的分页、状态流转与写入策略4.1 比对任务编排为什么必须异步以及线程池参数怎么设查重的耗时大头全在算法计算上。200 份作业两两对比 19900 对最慢的组合要 10 到 20 秒才能跑完如果放在 HTTP 请求线程里同步执行老师点一次“开始比对”浏览器要空转 15 分钟一定会以为系统坏了。常见做法是接口只负责创建一条“比对任务”记录立刻返回任务 ID后台用线程池异步执行全部对比对每完成一批就更新进度。线程池参数是重点我给出一个适合 8 核 16G 云主机的配置实测不会打满 CPU 也不会排队过久Bean(compareExecutor) public ThreadPoolTaskExecutor compareExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(4); // 核心线程数不建议超过CPU核数的一半 executor.setMaxPoolSize(8); // 最大线程数留给峰值 executor.setQueueCapacity(2000); // 队列容量比对任务是短跑的没必要太大 executor.setThreadNamePrefix(compare-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }参数说明CorePoolSize设 4 是因为算法是 CPU 密集型的比 IO 密集型的线程数要少设CallerRunsPolicy是拒绝策略里最安全的一个——队列满了就让提交任务的线程自己跑虽然会拖慢接口但不会丢任务。这点在查重的场景里非常重要作业提交高峰时任务丢弃是系统性事故拖慢一点可以接受。异步任务里最容易被忽略的是状态流转。提交记录表里有一个status字段0 待比对、1 比对中、2 已完成、3 失败。任务开始前把所有相关提交记录从 0 改成 1完成后逐条改 2。但这里有个并发问题如果多个老师同时触发比对会重复执行同一对数据。解决办法是在 MyBatis Plus 的更新语句里加条件status 0只有抢到更新的线程才继续执行public boolean markSubmissionsProcessing(Long homeworkId) { // 限定 status 0 才更新防止并发重复触发 LambdaUpdateWrapperSubmission wrapper new LambdaUpdateWrapper(); wrapper.eq(Submission::getHomeworkId, homeworkId) .eq(Submission::getStatus, 0) .set(Submission::getStatus, 1); return submissionMapper.update(null, wrapper) 0; }这段代码的巧妙之处在于update返回受影响的行数如果多线程同时进来只有一个线程能拿到大于 0 的结果其余线程可以直接跳过——这是比分布式锁轻量得多的方案单机部署完全够用。4.2 批量写入的边界saveBatch不是所有场景都最优需要手动分片比对结果写入时最容易踩的性能坑是把 19900 条结果一次性saveBatch。MyBatis Plus 的saveBatch底层是拼一条巨大的 SQL默认每批只处理 1000 条。但在比对场景里一条compare_result的 json 字段可能有好几 KB1000 条拼出来的 SQL 会超过 MySQL 的max_allowed_packet阈值默认 64MB直接爆掉。更稳妥的写法是自己在代码里做一次分片比如每 200 条为一批public void batchSaveResults(ListCompareResult results) { // 每 200 条一批防止单条 SQL 过大 int batchSize 200; for (int i 0; i results.size(); i batchSize) { int end Math.min(i batchSize, results.size()); ListCompareResult subList results.subList(i, end); compareResultMapper.insertBatchSomeColumn(subList); } }参数说明batchSize定 200 而不是 1000是因为 json 字段体积不可控。如果比对片段很长一条记录可能就有 5KB200 条是 1MB对 MySQL 来说非常安全。如果你们的场景里 json 被限制在 1KB 以内可以调到 500。这一层也要做幂等控制比对任务在失败重跑时重复写入会积累脏数据。常见做法是在写入前先按比对对查一次库存在就更新相似度而不是插入。用 MyBatis Plus 的exist判断或者直接在表上加唯一索引(homework_id, left_submission_id, right_submission_id)然后配合ON DUPLICATE KEY UPDATE处理。更建议建表时直接加唯一索引从根上防止重复——这也是上面建表 SQL 里为什么没加唯一索引的原因实际要补上这个约束。4.3 分页查询与排序覆盖老师的三种典型筛选老师查看查重报告时操作路径非常固定选作业按“相似度从高到低”看结果点进去查看“交叉匹配片段”。MyBatis Plus 的分页插件对这类场景支持得已经很完善但有几个细节需要注意。第一个细节分页查询和聚合查询最好不要走同一个“查询对象”。分页查的是明细聚合查的是“每对提交的相似度”虽然数据源一样但查询条件不同。我用一个CompareQueryDTO接前端参数再转换成 MyBatis Plus 的分页条件IPageCompareResultVO page new Page(queryDTO.getPageNum(), queryDTO.getPageSize()); LambdaQueryWrapperCompareResult wrapper new LambdaQueryWrapper(); wrapper.eq(CompareResult::getHomeworkId, queryDTO.getHomeworkId()) .orderByDesc(CompareResult::getSimilarity) .orderByAsc(CompareResult::getCreateTime);第二个细节相似度按降序排列时需要用orderByDesc配合orderByAsc(createTime)这样能保证多次比对同一对数据时时间更早的那条记录排在前面。不然 MySQL 的排序不稳定翻页时会看到之前排在第二页的数据跳到第一页来——这个情况我用分页插件配合orderBy踩过最后只有把排序字段补全才消除。第三个细节是不要在分页查询里 count 大表的全部记录。200 人的作业会产生近两万条比对记录分页 count 对 MySQL 来说还能扛住但原型阶段就把这个字段从SELECT count(*)优化成SELECT count(id)是值得的InnoDB 在 count 大字段时性能差别可以到 2 倍以上。5. 文件上传与路径解析避坑三四条经验换来少加班5.1 作业文件名后缀不统一导致文件解析失败进入查重前最头疼的问题是“文件读取失败”。作业平台允许学生提交.java、.cpp、.py之外还有.txt、.docx甚至无后缀文件。很多查重系统在这儿直接炸掉最常见的错误是读取.docx时用new String(Files.readAllBytes())出来的全是乱码。我统一做的处理是文件上传后先做后缀校验白名单解析阶段再按后缀选择解析器。.docx不是纯文本不能直接读文件字节需要用 Apache POI 的XWPFDocument解析段落.txt和.java则直接按 UTF-8 读取。后缀不对或无法解析的文件直接标记为失败并通知学生重新提交。这个校验要在上传接口就做而不是等到查重阶段才发现——不然后面排错时才看到文件编码不对就很被动了。5.2 文件和数据库记录的孤儿问题先落库还是先落盘上传接口的常见顺序是先存文件到磁盘再生产提交记录。这个顺序有个隐患——如果文件存完了但数据库插入失败磁盘上会出现一个没有数据库记录的孤儿文件累积多了占空间且很难清理。我的顺序刚好反过来先落盘再落库public Long submit(Homework homework, MultipartFile file) { // 1. 先落盘文件名带学号和时间戳避免覆盖 String storedName studentNo _ System.currentTimeMillis() _ FilenameUtils.getName(file.getOriginalFilename()); // 2. 存数据库记录 file_path 为相对路径 Submission submission new Submission(); submission.setHomeworkId(homework.getId()); submission.setStudentNo(studentNo); submission.setFilePath(/uploads/ homework.getId() / storedName); submissionMapper.insert(submission); // 3. 如果数据库插入失败删除磁盘文件 try { file.transferTo(new File(rootDir submission.getFilePath())); } catch (IOException e) { submissionMapper.deleteById(submission.getId()); throw new BusinessException(文件保存失败请重试); } }注意了这里有个顺序问题数据库插入失败时删磁盘文件是安全的但磁盘保存失败时删数据库记录也必须同时删除已存在的文件。我写这段代码时留了一个口子如果file.transferTo抛异常数据库记录删了但此时磁盘文件可能已经写了部分内容——需要同步把磁盘上可能存在的半截文件也删掉否则会留下残余数据。这个细节在并发上传场景下会反复考验人。5.3 文件存储路径不能是用户可控参数上传接口接收的MultipartFile的原始文件名完全由学生控制。如果有人上传一个文件名是../../../../../etc/passwd的文件路径拼接就会出大事。所以在第 5.2 节的代码里保存文件名时把原始文件名解析后用FilenameUtils.getName()过滤掉目录部分保存目录固定为/uploads/{homeworkId}/绝不允许原始文件名中的路径片段进入。Spring Boot 层面我需要在配置里关掉 multipart 的大小限制默认 1MB 太小代码里限制扩展名但更严格的是路径过滤——不能在 controller 里只做“文件大于某个大小”就放行路径穿越这种攻击是静默执行的等意识到时文件已经写到不该写的位置了。这个坑我见过不少团队中招基础但致命。5.4 上传后不校验文件是否为空、是否损坏这个看起来简单的校验在提交量大的时候特别重要。有些学生传上来的文件是 0 字节的空文件有些是损坏的压缩包。如果不做校验后面查重算法读空文件时要么报ArrayIndexOutOfBoundsException要么算出相似度 0——两个空文件相似度是 100%会让老师看到哭笑不得的结果。处理方式是在上传接口就对文件内容做基础判断文件大小必须大于 0后缀在解析白名单内读取前用Files.probeContentType做一个 MIME 类型的辅助校验只做辅助后缀才是最终依据。这一层校验能挡掉大约 2% 的无效提交但省下来的排查时间远超成本。6. 查重系统常见问题排查误报、漏报与性能瓶颈的定位逻辑6.1 现象两段明显雷同的代码相似度却低于 30%这是排障时最让人恼火的情况学生把max改成findMax把list改成array然后整体相似度就跳水了。原因在于余弦相似度在词法层面不感知“重命名”变量名全换等于 token 序列全换向量夹角瞬间拉开。解决路径有两条。一是加一层“抽象化预处理”把变量名、方法名、类名用正则统一替换成占位符。比如所有小驼峰命名的 token 统一变成VAR这样max和findMax就归一到同一个 token 上。二是调整降权策略让方法名和关键控制结构的权重上升变量名权重下降。具体做法是在 tokenizer 阶段就给 token 分类VAR、METHOD、CONTROL、LITERAL余弦向量计算时按分类加权重控制结构权重设 2.0变量名设 0.8关键字仍然过滤掉。做这一步要小心过度抽象如果把所有 token 都替换成占位符两份功能相同的作业相似度会无限接近 100%误报爆炸。抽象只做一层且只对符合命名模式的 token 生效不匹配的 token 保留原样这样“改了变量名”的能抓出来结构完全不同的不会被动提升相似度。6.2 现象两份完全没有关系的作业相似度却达到 60%疑似误报这种误报的根源几乎都是“模板代码”污染。很多课程从实验指导书里统一给出头文件、类框架、输入输出骨架学生只需要填空。这些统一模板占了整份代码可能的三分之一即便我们把 Java 关键字过滤掉模板里的自定义类名、变量定义仍然原样存在相当于两份作业从出生起就自带 30% 的相似度。处理办法是引入“模板代码黑名单”机制。在查重预处理阶段系统把全班提交做一次“交集提取”——凡是超过 60% 学生都出现的完全一样的代码片段自动应用降权或剔除不参与相似度计算。这个交集的提取用 SimHash 聚类即可轻松完成代价很低却能系统性压低误报基线。调这块的经验是阈值定在 60% 还是 75%需要看班级规模。20 人的小班35% 的重复可以算抄200 人的大班模板重复率天然高阈值要上调。这个参数建议做成每门课的配置项而不是系统级写死——同一套系统被不同老师用曲线是完全不同的。6.3 现象比对任务跑了一个小时还没结束CPU 已经满载查重系统的性能瓶颈几乎永远在 Levenshtein 算法上。一段 500 行的 Java 代码约 3000 个 tokenLevenshtein 要跑 900 万次操作如果这种长代码有几百对要对比必然拖垮整批任务。定位方法先看日志确认慢在哪一步——如果是余弦和 SimHash 阶段就已经很慢那就是预处理环节的正则没写好有灾难性回溯如果是 Levenshtein 慢直接砍掉它对长文本的启用条件。我的策略是给 Levenshtein 加上长度阈值两段文本 token 数都超过 500 时直接用余弦结果不再跑编辑距离只有 token 数低于 500 时才对疑似片段做 Levenshtein 复算用于生成报告证据。另外一个工程侧优化是把“比对任务”按作业粒度拆分并做去重同一份作业在多个线程里重复读文件、解析、分词浪费非常严重。每个文件的标准化结果token 序列最好在比对前算好并缓存到内存 Map 中key 是submissionIdvalue 是ListStringtokens。200 份作业只做 200 次预处理而不是 19900 次预处理阶段的耗时直接从几十分钟降到几秒钟。7. 调参陷阱与验证技巧一组可靠的默认参数比什么花哨设计都重要7.1 三个最关键的阈值参数以及它们怎么联动查重系统里真正决定“老师信不信”的参数是以下三个simHashDistanceSimHash 粗筛阈值、similarityThreshold相似度判重阈值、segmentLengthMin匹配片段最小长度用于报告展示。这三个参数不能独立调它们是一个链条SimHash 放过多少对比对决定余弦要跑多少余弦输出多少决定超过多少会被老师看到匹配片段最短多少展示决定报告能不能“让老师看几眼就确信”。给一组实践经验值作为起点SimHash 距离阈值设 8相似度阈值设 50%最小匹配片段长度设 10 个 token。为什么是 864 位 SimHash海明距离 3 以内是“几乎拷贝”3 到 8 是“有明显相似”8 到 12 是“可能局部相似”。设 8 意味着允许粗筛阶段漏一点但换余弦阶段的计算量降低了一半以上。相似度阈值 50% 是一个“拿到手里还能复核”的初始值你可以先按 50% 给老师看三天再根据反馈决定放宽还是收紧。7.2 验证方法用已知答案的测试集校准参数而不是人工目测人工目测论文级别的查重结果不靠谱查重系统的效果必须用“有标准答案的测试集”来验证。做法是准备 5 组作业其中 2 组为“真雷同”、1 组为“故意改写”变量重命名、代码块调换顺序、2 组为“题目相同但独立完成”。跑完后检查结果——真雷同组的相似度应该超过 70%故意改写组应该在 55%~70% 之间视为疑似独立完成组应该低于 40%。如果真雷同组没超过 70%优先调“抽象化预处理”和停用词表如果独立完成组超过 40%优先调“模板代码交集剔除”的阈值如果故意改写组的相似度过低低于 40%说明重命名检测的抽象力度不够需要增加变量名归一化的范围。按照这个顺序调参每次只改一个参数用测试集重跑效率高且不会把参数调到过拟合。7.3 报告要有“证据”否则 50% 的相似度没有说服力在报告展示时不要只给一个数字而是给“相似片段位置列表”。这个列表是在算法内部被收集的余弦计算时记录下高权重匹配的 token 片段Levenshtein 复算时记录下最小编辑操作的公共子串最后把公共子串按原文件行号映射回去前端就能做类似论文查重的高低亮红。这个“证据链”还有一个用途老师可以在页面上人工确认“这不是抄的这是模板”然后把这对结果标记为误报。标记事件本身可以反馈到算法配置里比如某段代码被超过 10 位老师标记为模板就会自动加进模板黑名单下一轮查重自动剔除。这个闭环是查重系统最有价值的地方——算法越用越准老师的判断变成算法的观察数据。最后说一个我自己的习惯每次调完参数我都会把测试集结果截图存档并且写上“这次为什么调、调完效果是什么”。两周后回头看几乎每次都能发现当初某个“直觉调参”其实是过度拟合了特定测试用例而存档帮我快速定位并回退。查重这个系统的调参充满玄学但保持测试集、一次只改一个变量的纪律会让玄学收敛得足够快。希望这套思路和参数起点能帮你在自己的作业查重系统上少走一段弯路。本文还有配套的精品资源点击获取 Spring Boot + MyBatis Plus 代码作业查重系统：三种相似度算法选型与调参实战
简介采用Spring Boot和MyBatis Plus构建的代码作业查重系统源码面向计算机专业学生、教师及后台开发人员解决作业提交、原创性检测与评分管理等问题。系统覆盖学生、教师、管理员三种角色支持代码与PDF作业的提交集成JWT安全认证、Redis缓存、Swagger接口文档查重模块基于开源JPlag可有效检测作业相似度便于快速部署与二次开发。压缩包共168个文件以95个Java后端业务类、21个Vue前端页面、16个XML配置和11个SQL数据库脚本为主另含JPlag查重工具jar、YAML环境配置与Markdown说明整体仅2.36MB目录划分清晰适合课程设计、毕业设计或小型作业管理平台参考。已有127人学习资源附带初始化SQL脚本与完整源码可帮助读者理解多角色权限控制、作业流程状态设计及查重服务集成方式减少重复造轮子直接用于功能演示或项目改造。1. 代码作业查重系统学生提交一版老师收一沓“疑似雷同”的判据代码作业查重系统和论文查重完全是两个物种。论文查重看连续字符串匹配代码里一行return ans;能被全校 200 人写得一模一样要是照搬论文那套老师邮箱会被误报通知塞爆。这个基于 Spring Boot 和 MyBatis Plus 的查重系统要解决的核心问题只有一个在“共性允许、抄法隐蔽”的代码作业里把真正雷同的学生挑出来并且让老师拿到能复核的证据。它做的事情不复杂——收作业、存源码、算相似度、出报告但难点全藏在相似度怎么算、算完怎么解释这两件事上。这套系统适合谁两类人最需要。一类是被期末 200 份实验报告逼到凌晨两点的老师另一类是想把“查重”做成毕业设计或小型商业工具的开发者。前者能直接获得可复现的查重报告后者能从这套源码里拆出 Spring Boot 的完整工程结构、MyBatis Plus 的分页与批量写入实践以及纯 Java 实现的文本相似度算法——不需要调外部 API不花钱离线就能跑。下面这份笔记是我按一个可运行方案的思路拆解的从工程骨架、数据表设计到三套相似度算法怎么选、怎么组合再到文件上传的坑和误报调优。我会把关键代码贴出来并解释参数含义最后收在几个能直接救命的进阶技巧上。先说明一点查重系统永远解决不了“判定”它只负责给老师提供“足够解释力”的证据链。2. Spring Boot MyBatis Plus 工程骨架为什么选这套组合以及建表的第一原则2.1 选型理由不是 Spring Boot 多优秀而是查重系统需要的它都有查重系统本质上是一个“文件上传 文本比较 结果展示”的 CRUD 应用但有几个特殊要求上传的源码文件可能同时有几百份、比对任务要排队跑、比对结果要分页查并且要能按相似度排序。这三个需求直接把技术选型框死了。Spring Boot 负责的是“胶水层”文件上传接口、异步任务调度、REST API。MyBatis Plus 负责的是数据层作业表、提交记录表、比对结果表的增删改查它的分页插件和saveBatch批量插入在这种“一次性写入大量比对结果”的场景里比手写 MyBatis XML 少掉一半样板代码。为什么不用 JPA因为查重结果的查询模式高度固定——按作业 ID 查、按相似度倒序、按学生分组MyBatis Plus 的 LambdaQueryWrapper 写起来比 JPA 的 Specification 直观得多而且 SQL 是透明可控的真到了要调索引的时候不至于抓瞎。这跟当年我在一个老项目里用 JPA 调多表关联查询的体验完全不同JPA 在复杂查询下生成 SQL 像黑匣子查重系统这种“老师随时可能按任意维度筛选”的业务SQL 能力透明比建模优雅重要得多。2.2 核心数据表设计五张表三张是必须两张是进阶查重系统的表结构核心就三张作业表、提交表、比对结果表。作业表存“哪门课的哪次作业”提交表存“谁交了哪份文件、文件存哪儿”比对结果表存“A 学生的作业和 B 学生的作业相似度多少、算法用的哪种”。下面是提交表和比对结果表的核心字段建表时第一原则是比对结果表不能存多余数据但必须留 json 字段。为什么因为查重的“判据”需要解释力A 和 B 相似度 78% 只是结果老师真正要看的是一段段高亮匹配的代码片段——这个片段列表就是存进 json 字段的。CREATE TABLE submission ( id bigint(20) NOT NULL AUTO_INCREMENT, homework_id bigint(20) NOT NULL COMMENT 作业ID, student_no varchar(32) NOT NULL COMMENT 学号, file_path varchar(255) NOT NULL COMMENT 源码文件存储路径, file_hash varchar(64) DEFAULT NULL COMMENT 文件MD5用于绝对重复检测, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待比对 1比对中 2已完成 3失败, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_homework_student (homework_id, student_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT作业提交表;file_hash这个字段很多人会忽略但它是最廉价的一层查重两份文件如果 MD5 完全相同相似度直接就是 100%根本不需要跑算法。等会儿在批量比对的时候先按 hash 分组能省掉一大半无效计算。比对结果表在设计时重点考虑的是“怎么让 200 人两两比对的结果不要爆炸式增长”。200 人两两对比是 19900 对每对存一条记录是能接受的但如果每对再存一份完整匹配片段 json表的体积会膨胀到几十 GB。做的时候要注意json 里只存相似度超过阈值的片段每对最多存 20 条片段摘要超过的只存条数。CREATE TABLE compare_result ( id bigint(20) NOT NULL AUTO_INCREMENT, homework_id bigint(20) NOT NULL COMMENT 作业ID, left_submission_id bigint(20) NOT NULL COMMENT 左侧提交ID, right_submission_id bigint(20) NOT NULL COMMENT 右侧提交ID, similarity decimal(5,2) NOT NULL COMMENT 综合相似度0.00-100.00, algorithm_score json DEFAULT NULL COMMENT 各算法得分详情含片段摘要, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0已生成 1已确认, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_homework_pair (homework_id, left_submission_id, right_submission_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT两两比对结果表;建表时踩过的坑是两个索引策略问题第一联合索引(homework_id, left_submission_id)比单独索引(homework_id)在分页查询时快很多因为老师查看详情的过滤条件永远带着两次作业 ID第二decimal(5,2)存相似度比 float 靠谱float 的精度误差会在排序时让两个相等的数产生随机顺序给老师的报告带去不必要的困惑。2.3 工程结构把查重算法和 Web 层彻底隔离构建工程时我一般建议按这个分包结构走查重算法放进独立的core包不要和 controller、service 混在一起。理由很简单查重算法是纯计算逻辑属于“可能随时替换”的部分今天用余弦相似度明天可能换成 SimHash但 controller 和 service 是稳定层不能因为算法替换而动它们。com.copydetect ├── controller │ └── HomeworkController.java │ └── CompareController.java ├── service │ ├── HomeworkService.java │ ├── CompareTaskService.java ├── core │ ├── detector │ │ ├── SimilarityDetector.java统一接口 │ │ ├── CosineDetector.java │ │ ├── SimHashDetector.java │ │ └── LevenshteinDetector.java │ ├── tokenizer │ │ └── CodeTokenizer.java代码分词器按语言去注释去字符串 │ ├── parser │ │ └── MatchSegmentParser.java匹配片段解析用于报告高亮 └── mapper ├── SubmissionMapper.java └── CompareResultMapper.java统一接口长这样所有算法实现都返回一个CompareResult对象包含相似度分数和匹配片段列表。这样 controller 层只依赖接口不关心底下跑的是什么算法将来加新算法也不需要动调用方代码。public interface SimilarityDetector { CompareResult detect(String sourceCode1, String sourceCode2); }这个设计把“算法实现”和“业务编排”变成了两个互不干扰的模块。我见过很多查重系统把算法直接写在 service 里最后加一个特征就开始牵一发动全身非常痛苦。3. 三套相似度算法怎么选余弦、SimHash、Levenshtein 的适用边界与组合策略3.1 代码先标准化不分词、去注释、剥离字符串字面量算法才有意义任何相似度算法输入若不做预处理结果都是噪声。代码文本比自然语言更规则但也更需要针对性的清洗。查重前必须做的标准化有三步去掉注释包括块注释和行注释、去掉字符串字面量内容、按词法边界做 token 切分。为什么要去字符串因为两个学生都可能写System.out.println(请输入一个整数);这句话本身一模一样但不是抄袭证据去掉之后只剩下System.out.println( )这个调用结构。同理注释里的内容更不能参与比对否则“// 这是贪心算法”这种教科书抄来的注释会把相似度虚增好几个点。下面这段 Java 做的是“去注释 按 token 切分”的核心逻辑用正则完成后我会再执行一次按 token 的过滤public String normalize(String source) { // 1. 去掉单行注释// 开头到行尾 String noLineComments source.replaceAll(//[^\\n]*, ); // 2. 去掉块注释/* ... */ 非贪婪匹配 String noBlockComments noLineComments.replaceAll(/\\*(.|[\\r\\n])*?\\*/, ); // 3. 去掉字符串字面量双引号包裹保留引号占位 String noStrings noBlockComments.replaceAll(\([^\\\\\]|\\\\.)*\, \\); // 4. 按 Java 标识符和符号边界切分去掉空格 String[] tokens noStrings.split([\\s\\p{Punct}]); return String.join( , tokens); }参数说明第二步的正则用了(|[\\r\\n])*?这种写法而不是.是因为 Java 正则默认.不匹配换行符如果不处理换行多行注释永远去不干净——这是很多人做文本清洗时最容易翻车的地方。第四步的\\p{Punct}匹配所有标点符号把;、{、}都切掉只保留标识符和关键字序列这是为了后面算余弦时词袋更干净。这一步做完两份功能相同但变量名不同的作业其相似度会自然回落到一个合理区间。变量名不同但结构相同这才是查重系统要抓的核心特征。3.2 三种算法原理对比与适用边界我把三种算法放在一张表里对比这样你在选型时可以少走弯路。算法核心原理优势劣势适用场景余弦相似度把文本转成词频向量计算两向量夹角余弦实现简单、解释性强、支持高频词权重调整不关心 token 顺序调换代码块顺序会误判偏低中等长度的完整文件比对SimHash为每个 token 生成 64 位哈希指纹加权累加后降维成比特向量用海明距离算相似计算极快适合海量两两比对线性复杂度对短文本少于 200 token敏感容易误判先粗筛一轮排除大部分无关对比对Levenshtein 编辑距离计算两字符串之间最少增删改次数除以最大长度得到相似度能抓到局部拷贝、插入死代码的细节复杂度 O(n*m)长文本会慢到令人绝望长度相近的短方法体、函数级别的片段比对这个表格的关键结论是单靠一个算法做代码查重是伪命题。Levenshtein 对文本过长直接失去工程可行性SimHash 对短代码块完全没有区分度余弦相似度丢失顺序信息后会有系统性的偏差。这就是为什么我在中间层的CompareTaskService里用三段式组合SimHash 粗筛只对粗筛通过的组合跑余弦余弦结果显示高度相似或高度不相似时再对局部片段跑 Levenshtein 找证据。组合后的判定逻辑if (simHashDistance 12) { return new CompareResult(0.0, Collections.emptyList()); // 海明距离大于12直接判为无关 } double cosineScore cosineDetector.detect(normalizedCode1, normalizedCode2).getScore(); if (cosineScore 0.85 || cosineScore 0.3) { // 极端情况下用 Levenshtein 精确复核 double levenshteinScore levenshteinDetector.detect(normalizedCode1, normalizedCode2).getScore(); return new CompareResult(combineScore(cosineScore, levenshteinScore), collectSegments(cosineDetector.getSegments())); } return new CompareResult(cosineScore, cosineDetector.getSegments());参数说明simHashDistance 12这个阈值来自经验值——64 位 SimHash 中海明距离小于等于 3 一般认为高度相似3 到 12 是可能有相似大于 12 基本无关。这个阈值会随文本长度产生漂移后续会讲到怎么根据作业平均长度动态调整。3.3 余弦相似度在代码场景里的实现细节TF 不能只用原始词频代码查重里直接凭词频算余弦会有个严重偏差几乎所有 Java 作业都会出现public、static、void、int、return、new这些词它们出现频率高但不携带“谁抄了谁”的信息。处理方法是给这些高频词降权。轻量做法是准备一份 Java 关键字表把这些词从词袋中剔除后再算余弦。严格做法是引入 TF-IDF 权重但代码查重场景里文档集只有 200 份作业时 IDF 计算不充分效果不稳定。我实际落地用的是“黑名单过滤 词频归一化”public MapString, Double buildVector(String normalizedCode) { MapString, Double vector new HashMap(); String[] tokens normalizedCode.split( ); for (String token : tokens) { if (STOP_WORDS.contains(token)) { continue; // STOP_WORDS 包含 Java 关键字和常见 API 名 } vector.put(token, vector.getOrDefault(token, 0.0) 1.0); } // 归一化处理除以向量长度保证不同长度的文件可比较 double norm Math.sqrt(vector.values().stream().mapToDouble(v - v * v).sum()); vector.replaceAll((k, v) - v / norm); return vector; }参数说明normalizeCode之后我直接按空格切分是因为标准化的最后一步把 token 用空格 join 了STOP_WORDS集合里至少要包含public、static、class、void、int、return、new、if、else、for、while这些 Java 关键字。不做这一步两张完全不同的作业相似度也能到 0.35——全是关键字贡献的。做了之后真正的“用户逻辑代码”才开始在向量里体现差别。这份停用词表本身也是可以慢慢调优的资源老师用一段时间后会反馈哪些固定套路代码还应当被忽略。4. MyBatis Plus 数据层实战批量比对任务的分页、状态流转与写入策略4.1 比对任务编排为什么必须异步以及线程池参数怎么设查重的耗时大头全在算法计算上。200 份作业两两对比 19900 对最慢的组合要 10 到 20 秒才能跑完如果放在 HTTP 请求线程里同步执行老师点一次“开始比对”浏览器要空转 15 分钟一定会以为系统坏了。常见做法是接口只负责创建一条“比对任务”记录立刻返回任务 ID后台用线程池异步执行全部对比对每完成一批就更新进度。线程池参数是重点我给出一个适合 8 核 16G 云主机的配置实测不会打满 CPU 也不会排队过久Bean(compareExecutor) public ThreadPoolTaskExecutor compareExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(4); // 核心线程数不建议超过CPU核数的一半 executor.setMaxPoolSize(8); // 最大线程数留给峰值 executor.setQueueCapacity(2000); // 队列容量比对任务是短跑的没必要太大 executor.setThreadNamePrefix(compare-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }参数说明CorePoolSize设 4 是因为算法是 CPU 密集型的比 IO 密集型的线程数要少设CallerRunsPolicy是拒绝策略里最安全的一个——队列满了就让提交任务的线程自己跑虽然会拖慢接口但不会丢任务。这点在查重的场景里非常重要作业提交高峰时任务丢弃是系统性事故拖慢一点可以接受。异步任务里最容易被忽略的是状态流转。提交记录表里有一个status字段0 待比对、1 比对中、2 已完成、3 失败。任务开始前把所有相关提交记录从 0 改成 1完成后逐条改 2。但这里有个并发问题如果多个老师同时触发比对会重复执行同一对数据。解决办法是在 MyBatis Plus 的更新语句里加条件status 0只有抢到更新的线程才继续执行public boolean markSubmissionsProcessing(Long homeworkId) { // 限定 status 0 才更新防止并发重复触发 LambdaUpdateWrapperSubmission wrapper new LambdaUpdateWrapper(); wrapper.eq(Submission::getHomeworkId, homeworkId) .eq(Submission::getStatus, 0) .set(Submission::getStatus, 1); return submissionMapper.update(null, wrapper) 0; }这段代码的巧妙之处在于update返回受影响的行数如果多线程同时进来只有一个线程能拿到大于 0 的结果其余线程可以直接跳过——这是比分布式锁轻量得多的方案单机部署完全够用。4.2 批量写入的边界saveBatch不是所有场景都最优需要手动分片比对结果写入时最容易踩的性能坑是把 19900 条结果一次性saveBatch。MyBatis Plus 的saveBatch底层是拼一条巨大的 SQL默认每批只处理 1000 条。但在比对场景里一条compare_result的 json 字段可能有好几 KB1000 条拼出来的 SQL 会超过 MySQL 的max_allowed_packet阈值默认 64MB直接爆掉。更稳妥的写法是自己在代码里做一次分片比如每 200 条为一批public void batchSaveResults(ListCompareResult results) { // 每 200 条一批防止单条 SQL 过大 int batchSize 200; for (int i 0; i results.size(); i batchSize) { int end Math.min(i batchSize, results.size()); ListCompareResult subList results.subList(i, end); compareResultMapper.insertBatchSomeColumn(subList); } }参数说明batchSize定 200 而不是 1000是因为 json 字段体积不可控。如果比对片段很长一条记录可能就有 5KB200 条是 1MB对 MySQL 来说非常安全。如果你们的场景里 json 被限制在 1KB 以内可以调到 500。这一层也要做幂等控制比对任务在失败重跑时重复写入会积累脏数据。常见做法是在写入前先按比对对查一次库存在就更新相似度而不是插入。用 MyBatis Plus 的exist判断或者直接在表上加唯一索引(homework_id, left_submission_id, right_submission_id)然后配合ON DUPLICATE KEY UPDATE处理。更建议建表时直接加唯一索引从根上防止重复——这也是上面建表 SQL 里为什么没加唯一索引的原因实际要补上这个约束。4.3 分页查询与排序覆盖老师的三种典型筛选老师查看查重报告时操作路径非常固定选作业按“相似度从高到低”看结果点进去查看“交叉匹配片段”。MyBatis Plus 的分页插件对这类场景支持得已经很完善但有几个细节需要注意。第一个细节分页查询和聚合查询最好不要走同一个“查询对象”。分页查的是明细聚合查的是“每对提交的相似度”虽然数据源一样但查询条件不同。我用一个CompareQueryDTO接前端参数再转换成 MyBatis Plus 的分页条件IPageCompareResultVO page new Page(queryDTO.getPageNum(), queryDTO.getPageSize()); LambdaQueryWrapperCompareResult wrapper new LambdaQueryWrapper(); wrapper.eq(CompareResult::getHomeworkId, queryDTO.getHomeworkId()) .orderByDesc(CompareResult::getSimilarity) .orderByAsc(CompareResult::getCreateTime);第二个细节相似度按降序排列时需要用orderByDesc配合orderByAsc(createTime)这样能保证多次比对同一对数据时时间更早的那条记录排在前面。不然 MySQL 的排序不稳定翻页时会看到之前排在第二页的数据跳到第一页来——这个情况我用分页插件配合orderBy踩过最后只有把排序字段补全才消除。第三个细节是不要在分页查询里 count 大表的全部记录。200 人的作业会产生近两万条比对记录分页 count 对 MySQL 来说还能扛住但原型阶段就把这个字段从SELECT count(*)优化成SELECT count(id)是值得的InnoDB 在 count 大字段时性能差别可以到 2 倍以上。5. 文件上传与路径解析避坑三四条经验换来少加班5.1 作业文件名后缀不统一导致文件解析失败进入查重前最头疼的问题是“文件读取失败”。作业平台允许学生提交.java、.cpp、.py之外还有.txt、.docx甚至无后缀文件。很多查重系统在这儿直接炸掉最常见的错误是读取.docx时用new String(Files.readAllBytes())出来的全是乱码。我统一做的处理是文件上传后先做后缀校验白名单解析阶段再按后缀选择解析器。.docx不是纯文本不能直接读文件字节需要用 Apache POI 的XWPFDocument解析段落.txt和.java则直接按 UTF-8 读取。后缀不对或无法解析的文件直接标记为失败并通知学生重新提交。这个校验要在上传接口就做而不是等到查重阶段才发现——不然后面排错时才看到文件编码不对就很被动了。5.2 文件和数据库记录的孤儿问题先落库还是先落盘上传接口的常见顺序是先存文件到磁盘再生产提交记录。这个顺序有个隐患——如果文件存完了但数据库插入失败磁盘上会出现一个没有数据库记录的孤儿文件累积多了占空间且很难清理。我的顺序刚好反过来先落盘再落库public Long submit(Homework homework, MultipartFile file) { // 1. 先落盘文件名带学号和时间戳避免覆盖 String storedName studentNo _ System.currentTimeMillis() _ FilenameUtils.getName(file.getOriginalFilename()); // 2. 存数据库记录 file_path 为相对路径 Submission submission new Submission(); submission.setHomeworkId(homework.getId()); submission.setStudentNo(studentNo); submission.setFilePath(/uploads/ homework.getId() / storedName); submissionMapper.insert(submission); // 3. 如果数据库插入失败删除磁盘文件 try { file.transferTo(new File(rootDir submission.getFilePath())); } catch (IOException e) { submissionMapper.deleteById(submission.getId()); throw new BusinessException(文件保存失败请重试); } }注意了这里有个顺序问题数据库插入失败时删磁盘文件是安全的但磁盘保存失败时删数据库记录也必须同时删除已存在的文件。我写这段代码时留了一个口子如果file.transferTo抛异常数据库记录删了但此时磁盘文件可能已经写了部分内容——需要同步把磁盘上可能存在的半截文件也删掉否则会留下残余数据。这个细节在并发上传场景下会反复考验人。5.3 文件存储路径不能是用户可控参数上传接口接收的MultipartFile的原始文件名完全由学生控制。如果有人上传一个文件名是../../../../../etc/passwd的文件路径拼接就会出大事。所以在第 5.2 节的代码里保存文件名时把原始文件名解析后用FilenameUtils.getName()过滤掉目录部分保存目录固定为/uploads/{homeworkId}/绝不允许原始文件名中的路径片段进入。Spring Boot 层面我需要在配置里关掉 multipart 的大小限制默认 1MB 太小代码里限制扩展名但更严格的是路径过滤——不能在 controller 里只做“文件大于某个大小”就放行路径穿越这种攻击是静默执行的等意识到时文件已经写到不该写的位置了。这个坑我见过不少团队中招基础但致命。5.4 上传后不校验文件是否为空、是否损坏这个看起来简单的校验在提交量大的时候特别重要。有些学生传上来的文件是 0 字节的空文件有些是损坏的压缩包。如果不做校验后面查重算法读空文件时要么报ArrayIndexOutOfBoundsException要么算出相似度 0——两个空文件相似度是 100%会让老师看到哭笑不得的结果。处理方式是在上传接口就对文件内容做基础判断文件大小必须大于 0后缀在解析白名单内读取前用Files.probeContentType做一个 MIME 类型的辅助校验只做辅助后缀才是最终依据。这一层校验能挡掉大约 2% 的无效提交但省下来的排查时间远超成本。6. 查重系统常见问题排查误报、漏报与性能瓶颈的定位逻辑6.1 现象两段明显雷同的代码相似度却低于 30%这是排障时最让人恼火的情况学生把max改成findMax把list改成array然后整体相似度就跳水了。原因在于余弦相似度在词法层面不感知“重命名”变量名全换等于 token 序列全换向量夹角瞬间拉开。解决路径有两条。一是加一层“抽象化预处理”把变量名、方法名、类名用正则统一替换成占位符。比如所有小驼峰命名的 token 统一变成VAR这样max和findMax就归一到同一个 token 上。二是调整降权策略让方法名和关键控制结构的权重上升变量名权重下降。具体做法是在 tokenizer 阶段就给 token 分类VAR、METHOD、CONTROL、LITERAL余弦向量计算时按分类加权重控制结构权重设 2.0变量名设 0.8关键字仍然过滤掉。做这一步要小心过度抽象如果把所有 token 都替换成占位符两份功能相同的作业相似度会无限接近 100%误报爆炸。抽象只做一层且只对符合命名模式的 token 生效不匹配的 token 保留原样这样“改了变量名”的能抓出来结构完全不同的不会被动提升相似度。6.2 现象两份完全没有关系的作业相似度却达到 60%疑似误报这种误报的根源几乎都是“模板代码”污染。很多课程从实验指导书里统一给出头文件、类框架、输入输出骨架学生只需要填空。这些统一模板占了整份代码可能的三分之一即便我们把 Java 关键字过滤掉模板里的自定义类名、变量定义仍然原样存在相当于两份作业从出生起就自带 30% 的相似度。处理办法是引入“模板代码黑名单”机制。在查重预处理阶段系统把全班提交做一次“交集提取”——凡是超过 60% 学生都出现的完全一样的代码片段自动应用降权或剔除不参与相似度计算。这个交集的提取用 SimHash 聚类即可轻松完成代价很低却能系统性压低误报基线。调这块的经验是阈值定在 60% 还是 75%需要看班级规模。20 人的小班35% 的重复可以算抄200 人的大班模板重复率天然高阈值要上调。这个参数建议做成每门课的配置项而不是系统级写死——同一套系统被不同老师用曲线是完全不同的。6.3 现象比对任务跑了一个小时还没结束CPU 已经满载查重系统的性能瓶颈几乎永远在 Levenshtein 算法上。一段 500 行的 Java 代码约 3000 个 tokenLevenshtein 要跑 900 万次操作如果这种长代码有几百对要对比必然拖垮整批任务。定位方法先看日志确认慢在哪一步——如果是余弦和 SimHash 阶段就已经很慢那就是预处理环节的正则没写好有灾难性回溯如果是 Levenshtein 慢直接砍掉它对长文本的启用条件。我的策略是给 Levenshtein 加上长度阈值两段文本 token 数都超过 500 时直接用余弦结果不再跑编辑距离只有 token 数低于 500 时才对疑似片段做 Levenshtein 复算用于生成报告证据。另外一个工程侧优化是把“比对任务”按作业粒度拆分并做去重同一份作业在多个线程里重复读文件、解析、分词浪费非常严重。每个文件的标准化结果token 序列最好在比对前算好并缓存到内存 Map 中key 是submissionIdvalue 是ListStringtokens。200 份作业只做 200 次预处理而不是 19900 次预处理阶段的耗时直接从几十分钟降到几秒钟。7. 调参陷阱与验证技巧一组可靠的默认参数比什么花哨设计都重要7.1 三个最关键的阈值参数以及它们怎么联动查重系统里真正决定“老师信不信”的参数是以下三个simHashDistanceSimHash 粗筛阈值、similarityThreshold相似度判重阈值、segmentLengthMin匹配片段最小长度用于报告展示。这三个参数不能独立调它们是一个链条SimHash 放过多少对比对决定余弦要跑多少余弦输出多少决定超过多少会被老师看到匹配片段最短多少展示决定报告能不能“让老师看几眼就确信”。给一组实践经验值作为起点SimHash 距离阈值设 8相似度阈值设 50%最小匹配片段长度设 10 个 token。为什么是 864 位 SimHash海明距离 3 以内是“几乎拷贝”3 到 8 是“有明显相似”8 到 12 是“可能局部相似”。设 8 意味着允许粗筛阶段漏一点但换余弦阶段的计算量降低了一半以上。相似度阈值 50% 是一个“拿到手里还能复核”的初始值你可以先按 50% 给老师看三天再根据反馈决定放宽还是收紧。7.2 验证方法用已知答案的测试集校准参数而不是人工目测人工目测论文级别的查重结果不靠谱查重系统的效果必须用“有标准答案的测试集”来验证。做法是准备 5 组作业其中 2 组为“真雷同”、1 组为“故意改写”变量重命名、代码块调换顺序、2 组为“题目相同但独立完成”。跑完后检查结果——真雷同组的相似度应该超过 70%故意改写组应该在 55%~70% 之间视为疑似独立完成组应该低于 40%。如果真雷同组没超过 70%优先调“抽象化预处理”和停用词表如果独立完成组超过 40%优先调“模板代码交集剔除”的阈值如果故意改写组的相似度过低低于 40%说明重命名检测的抽象力度不够需要增加变量名归一化的范围。按照这个顺序调参每次只改一个参数用测试集重跑效率高且不会把参数调到过拟合。7.3 报告要有“证据”否则 50% 的相似度没有说服力在报告展示时不要只给一个数字而是给“相似片段位置列表”。这个列表是在算法内部被收集的余弦计算时记录下高权重匹配的 token 片段Levenshtein 复算时记录下最小编辑操作的公共子串最后把公共子串按原文件行号映射回去前端就能做类似论文查重的高低亮红。这个“证据链”还有一个用途老师可以在页面上人工确认“这不是抄的这是模板”然后把这对结果标记为误报。标记事件本身可以反馈到算法配置里比如某段代码被超过 10 位老师标记为模板就会自动加进模板黑名单下一轮查重自动剔除。这个闭环是查重系统最有价值的地方——算法越用越准老师的判断变成算法的观察数据。最后说一个我自己的习惯每次调完参数我都会把测试集结果截图存档并且写上“这次为什么调、调完效果是什么”。两周后回头看几乎每次都能发现当初某个“直觉调参”其实是过度拟合了特定测试用例而存档帮我快速定位并回退。查重这个系统的调参充满玄学但保持测试集、一次只改一个变量的纪律会让玄学收敛得足够快。希望这套思路和参数起点能帮你在自己的作业查重系统上少走一段弯路。本文还有配套的精品资源点击获取