企业官网建设流程全解析

简介：采用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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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 三种算法原理对比与适用边界

我把三种算法放在一张表里对比，这样你在选型时可以少走弯路。

这个表格的关键结论是：单靠一个算法做代码查重是伪命题。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 Map<String, Double> buildVector(String normalizedCode) { Map<String, 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 才更新，防止并发重复触发 LambdaUpdateWrapper<Submission> 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 字段可能有好几 KB，1000 条拼出来的 SQL 会超过 MySQL 的max_allowed_packet阈值（默认 64MB），直接爆掉。

更稳妥的写法是自己在代码里做一次分片，比如每 200 条为一批：

public void batchSaveResults(List<CompareResult> results) { // 每 200 条一批，防止单条 SQL 过大 int batchSize = 200; for (int i = 0; i < results.size(); i += batchSize) { int end = Math.min(i + batchSize, results.size()); List<CompareResult> subList = results.subList(i, end); compareResultMapper.insertBatchSomeColumn(subList); } }

参数说明：batchSize定 200 而不是 1000，是因为 json 字段体积不可控。如果比对片段很长，一条记录可能就有 5KB，200 条是 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 的分页条件：

IPage<CompareResultVO> page = new Page<>(queryDTO.getPageNum(), queryDTO.getPageSize()); LambdaQueryWrapper<CompareResult> 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 个 token，Levenshtein 要跑 900 万次操作，如果这种长代码有几百对要对比，必然拖垮整批任务。

定位方法：先看日志确认慢在哪一步——如果是余弦和 SimHash 阶段就已经很慢，那就是预处理环节的正则没写好，有灾难性回溯；如果是 Levenshtein 慢，直接砍掉它对长文本的启用条件。我的策略是给 Levenshtein 加上长度阈值：两段文本 token 数都超过 500 时，直接用余弦结果，不再跑编辑距离；只有 token 数低于 500 时，才对疑似片段做 Levenshtein 复算，用于生成报告证据。

另外一个工程侧优化是把“比对任务”按作业粒度拆分并做去重：同一份作业在多个线程里重复读文件、解析、分词，浪费非常严重。每个文件的标准化结果（token 序列）最好在比对前算好并缓存到内存 Map 中，key 是submissionId，value 是List<String>tokens。200 份作业只做 200 次预处理，而不是 19900 次，预处理阶段的耗时直接从几十分钟降到几秒钟。

7. 调参陷阱与验证技巧：一组可靠的默认参数，比什么花哨设计都重要

7.1 三个最关键的阈值参数，以及它们怎么联动

查重系统里真正决定“老师信不信”的参数，是以下三个：simHashDistance（SimHash 粗筛阈值）、similarityThreshold（相似度判重阈值）、segmentLengthMin（匹配片段最小长度，用于报告展示）。这三个参数不能独立调，它们是一个链条：SimHash 放过多少对比对，决定余弦要跑多少；余弦输出多少，决定超过多少会被老师看到；匹配片段最短多少展示，决定报告能不能“让老师看几眼就确信”。

给一组实践经验值作为起点：SimHash 距离阈值设 8，相似度阈值设 50%，最小匹配片段长度设 10 个 token。为什么是 8？64 位 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 位老师标记为模板，就会自动加进模板黑名单，下一轮查重自动剔除。这个闭环是查重系统最有价值的地方——算法越用越准，老师的判断变成算法的观察数据。

最后说一个我自己的习惯：每次调完参数，我都会把测试集结果截图存档，并且写上“这次为什么调、调完效果是什么”。两周后回头看，几乎每次都能发现当初某个“直觉调参”其实是过度拟合了特定测试用例，而存档帮我快速定位并回退。查重这个系统的调参充满玄学，但保持测试集、一次只改一个变量的纪律，会让玄学收敛得足够快。希望这套思路和参数起点能帮你在自己的作业查重系统上少走一段弯路。

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