想象一间考核车间。学徒们把刚做好的木椅子交到窗口，老师傅老周并不急着动手敲打，而是从抽屉里抽出一张写满验收项的纸条：椅面稳不稳？四腿齐不齐？承重够不够？每一项，打勾或打叉。整个过程没人喊、没人量，全靠一张“验收单”自动流转。这就是代码评测系统的本质——学生提交一段程序，系统自动运行它，逐项检验正确性、效率和代码质量，再把结果反馈给学生。学生看到“4/6 通过”，立刻知道哪里没做对，改完再交一轮。 本文就从这间“考核车间”说起，带你认识这条自动批改流水线的每个环节：考卷怎么出（测试用例设计）、操作间怎么隔离（沙箱执行环境）、工位怎么检查（代码风格检测）、车间怎么调度（评测平台架构）、监控怎么防抄（防作弊机制），以及怎么让整条流水线跑得更快（性能优化）。读完之后，你会对现代在线编程教育背后的“隐形批改老师”有一个完整而直观的认识。

岗位关联

学会代码评测设计，等于掌握了 AI 教育产品中“自动反馈闭环”的核心引擎，是搭建在线编程平台、招聘笔试系统与智能作业批改产品的基础能力。

目录
  1. 可视化演示
  2. 评测系统概览
  3. 测试用例设计
  4. 沙箱执行环境
  5. 代码风格检测
  6. 评测平台架构
  7. 防作弊机制
  8. 评测性能优化
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示代码评测流水线（提交→编译→沙箱执行→验证）、测试用例覆盖矩阵与防抄袭相似度检测，交互切换模式与步骤查看评测各阶段。

本节配有交互动效（进入视口后自动加载，约 3KB）。

评测流水线 提交：源代码接收与预处理 编译：隔离环境编译生成可执行文件 沙箱：受限资源内执行测试用例 评测结果 = AND（测试用例通过状态） 四阶段流水线实现自动化评测

评测系统概览

老周的考核车间门口挂着一块牌子：“只认验收单，不认人情。”学徒小蔡把椅子推进窗口，老周只要把验收单往机器里一塞，几秒后，一份带勾叉的成绩单就掉了出来。这个过程的本质是：接收作品（代码）、按单执行（运行测试）、输出结果（评分反馈）。学生把代码提交到在线编程平台后，评测系统自动完成编译、运行、比对、打分，全程不需要老师参与。

代码评测系统就是这间车间的自动化版本。学生提交代码后，系统先在后台编译，再把一组测试用例喂给它——每个用例包含输入和期望输出，最后比对实际输出与期望输出。这一整套动作，业内叫“评测”，背后的系统常被称为 Online Judge（在线判题系统）。评测通常从三个维度打分：正确性（输出与预期是否一致）、效率（运行时间与内存是否在限定范围内）、代码质量（风格与可维护性）。

许多平台的得分就是通过用例通过比例换算的，公式如下：

小蔡拿到成绩单，看到“测试 3：空值处理失败”，马上回去修；修完再交，错误清零。这种“批改→反馈→修改→再批改”的闭环，正是在线教育能让学生自主刷题、不依赖老师的核心秘密。

Score=NpassNtotal×100\displaystyle Score = \frac{N_{\text{pass}}}{N_{\text{total}}} \times 100
得分等于通过的用例数除以总用例数，再乘 100 换算成百分制。
  1. 统计通过数（N_pass）在所有测试用例中，实际输出与期望输出完全一致的用例个数，它是分子。
    Npass=∑i=1Ntotal1[outputi=expectedi]\displaystyle N_{\text{pass}} = \sum_{i=1}^{N_{\text{total}}} \mathbf{1}[\text{output}_i = \text{expected}_i]
  2. 总用例数（N_total）本次评测计划执行的全部测试用例数量，它是分母，代表考卷的总题数。
    Ntotal=∣test set∣\displaystyle N_{\text{total}} = |\text{test set}|
  3. 求通过比例用通过数除以总数，得到 0 到 1 之间的小数。
    NpassNtotal\displaystyle \frac{N_{\text{pass}}}{N_{\text{total}}}
  4. 换算百分制乘以 100 并取整，得到 0 到 100 的整数得分，方便学生理解。
    Score=NpassNtotal×100\displaystyle Score = \frac{N_{\text{pass}}}{N_{\text{total}}} \times 100

测试用例设计

老周出考卷很有讲究：每个学徒都得测，但考题不能太多，要测在点子上。一把椅子，要测“正常人坐”（普通场景）、“小孩蹦跳”（边界场景）、“胖子压”（极端场景），而不是让一百个普通人轮流坐一遍。测试用例设计就是这间车间的“出题方法论”。

最核心的两招是等价类划分和边界值分析。等价类划分把无穷无尽的输入空间分成若干组，每组只挑一个代表输入来测——比如排序函数的输入按长度分：空数组、单元素、多元素，各取一个代表即可。边界值分析专门盯临界点：最大值、最小值、刚好越界的那一位。程序最容易在“差一点点”的地方出错，就像椅子在承重极限附近突然散架。

除了正确性，还要看测试覆盖得全不全。覆盖度指标衡量的是代码被执行的程度：

老周最得意的一招是“隐藏考题”——学徒永远不知道老师傅口袋里还有最后一题。评测系统里的“隐藏用例”同理：公开样例给学生练习用，隐藏用例则悄悄夹在真实评测中，防止学生针对公开样例“背答案”。

Coverage=NcoveredNtotal×100%\displaystyle \text{Coverage} = \frac{N_{\text{covered}}}{N_{\text{total}}} \times 100\%
覆盖度是“被测试执行到的语句数”占“总语句数”的比例，用来评估测试是否漏掉了代码的某些角落。
  1. 已覆盖语句数（N_covered）运行测试用例时至少被执行过一次的代码语句数量。
    Ncovered=∣{s∈statements:s executed}∣\displaystyle N_{\text{covered}} = |\{s \in \text{statements} : s \text{ executed}\}|
  2. 总语句数（N_total）被测程序的全部语句数量。
    Ntotal=∣statements∣\displaystyle N_{\text{total}} = |\text{statements}|
  3. 求覆盖比例两者相除，得到的百分比就是覆盖率；覆盖率越高，说明测试用例越“全面”。
    NcoveredNtotal×100%\displaystyle \frac{N_{\text{covered}}}{N_{\text{total}}} \times 100\%

沙箱执行环境

老周的车间里有一排“隔音操作间”：四面厚墙、单向观察窗、限时操作。学徒在里面干活，就算把工具摔了也伤不到外面的人；操作超时，铃一响就强制收工。这个操作间在代码评测里叫作“沙箱”（Sandbox）。

为什么需要沙箱？因为学生提交的代码可能包含死循环、疯狂申请内存，甚至是恶意命令。评测系统必须把代码关进独立空间再运行，否则一段 while(1){} 就能让整个评测平台瘫痪。沙箱的关键机制包括：隔离机制——用容器或虚拟机把代码与宿主机隔开；资源限制——限制 CPU 时间、内存大小、进程数量；安全策略——禁止网络访问、禁止读写宿主机文件系统；超时处理——超时直接判失败并终止进程。

一个典型的受限判分模型可以写成：

老周的车间外面，学徒们排着队，透过窗口能看到里面的人“砰”的一声被秒表叫停——这就是超时处理。它让每一个学徒都被公平对待，也让车间永远不会被一个人拖垮。

S=Scode×1[Texec≤Tlimit∧Mexec≤Mlimit]\displaystyle S = S_{\text{code}} \times \mathbf{1}[T_{\text{exec}} \le T_{\text{limit}} \land M_{\text{exec}} \le M_{\text{limit}}]
只有运行时间和内存都达标，代码才能拿到基础分；任何一项超限，这题直接判零分。
  1. 运行时间（T_exec）代码实际消耗的 CPU 时间，单位通常为秒。
    Texec=tend−tstart\displaystyle T_{\text{exec}} = t_{\text{end}} - t_{\text{start}}
  2. 内存占用（M_exec）代码运行期间峰值内存，单位通常为 MB。
    Mexec=max⁡tmemory(t)\displaystyle M_{\text{exec}} = \max_{t} \text{memory}(t)
  3. 指示函数（1[条件]）条件成立时取 1，不成立时取 0，像开关一样。
    1[true]=1,1[false]=0\displaystyle \mathbf{1}[\text{true}] = 1,\quad \mathbf{1}[\text{false}] = 0
  4. 整体乘积只有当两项条件都满足时，指示函数才为 1，代码获得满分；否则得到 0 分。
    S=Scode×1=Scode\displaystyle S = S_{\text{code}} \times 1 = S_{\text{code}}

代码风格检测

老周不只验收成品，还检查“工位”：工具是否归位、木屑有没有扫干净。一个把工具乱丢的学徒，做的椅子再好看也要被扣分——因为明天他可能找不到凿子，团队协作全靠规矩。代码风格检测就是程序界的“工位检查”。

这类检查有一个特点：不需要运行代码，所以叫静态检查。常用的工具如 ESLint、Pylint 会扫描源码，检查三类问题：风格规范——变量命名是否有意义、缩进是否统一、行长度是否超标；圈复杂度——代码里 if/else、循环、分支嵌套得越深，逻辑越绕，越难维护；重复代码检测——两段一模一样或高度相似的代码块会被标记，提示应该提炼成公共函数。

圈复杂度是衡量代码“绕不绕”的核心指标，公式如下：

老周管这叫“从业习惯打分”。代码风格检测虽然不像正确性那样一刀切，但它是团队协作的润滑剂——今天你留的整洁工位，是明天队友能顺利开工的保障。

M=E−N+2P\displaystyle M = E - N + 2P
圈复杂度通过控制流图的边数、节点数和连通分量数，量化代码里独立路径的多少。
  1. 边数（E）控制流图中程序跳转的连线数量。
    E=#edges in control flow graph\displaystyle E = \#\text{edges in control flow graph}
  2. 节点数（N）控制流图中语句块和判断分支的数量。
    N=#nodes in control flow graph\displaystyle N = \#\text{nodes in control flow graph}
  3. 连通分量数（P）通常一个独立函数取 1。
    P=1\displaystyle P = 1
  4. 组合计算边数减节点数加两倍的连通分量数，得出独立路径条数；数值越大，代码越复杂。
    M=E−N+2×1\displaystyle M = E - N + 2 \times 1

评测平台架构

车间规模变大后，老周忙不过来了。他建了一间调度室：所有学徒的作品先塞进“工单箱”排队，调度员按顺序取出，分派给不同的工作台同时开工，干完再把结果贴回公告栏。在线评测系统（OJ）的架构，就是这间调度室的数字化版本。

最关键的组件是提交队列——它用消息队列（如 Redis、RabbitMQ）缓冲海量提交请求，防止考试瞬间的流量高峰把服务器压垮。评测调度器从队列里取任务，分发给空闲的 Worker 进程执行，并管理超时与重试。评测框架（如 JUnit、pytest）负责真正运行测试用例、收集结果。最终，结果存储模块把分数、运行日志和提交历史写进数据库，方便学生查看、教师复盘。

引入并行工作台后，整体提速效果可以用加速比来描述：

调度室让老周从“亲自逐个验收”变成“组织一群人同时验收”，车间吞吐量大增。对学生来说，最直观的感受就是：提交后不用再等半小时，几十秒就能拿到反馈。

Speedup=TserialTparallel\displaystyle Speedup = \frac{T_{\text{serial}}}{T_{\text{parallel}}}
加速比是串行所需时间除以并行所需时间，衡量“多开工作台”带来的收益。
  1. 串行时间（T_serial）只有一个工作台时，完成全部评测所需的总时间。
    Tserial=tfinish−tstart\displaystyle T_{\text{serial}} = t_{\text{finish}} - t_{\text{start}}
  2. 并行时间（T_parallel）多个 Worker 同时工作时的完成时间。
    Tparallel=Tserial/p+Toverhead\displaystyle T_{\text{parallel}} = T_{\text{serial}} / p + T_{\text{overhead}}
  3. 求比值串行时间除以并行时间，得到加速倍数；理想情况下接近 Worker 数量 p。
    Speedup=TserialTserial/p+Toverhead\displaystyle Speedup = \frac{T_{\text{serial}}}{T_{\text{serial}} / p + T_{\text{overhead}}}

防作弊机制

老周发现两个学徒交的椅子长得一模一样，连表面的木纹都像。他拿出两把椅子仔细端详，又翻了翻学徒的打卡记录——谁的进度可疑，一目了然。代码评测的防作弊机制，就是车间的“监考摄像头”和“作品鉴定仪”。

首先是相似度检测：把两份代码两两比对，计算相似程度。但朴素的“逐字比对”很容易被绕过——学生只要全局替换变量名、删除注释，文本就完全不一样了。于是有了特征比对：先把代码解析成抽象语法树（AST），再去掉变量名和注释，只看结构骨架；MOSS 等经典查重工具就是基于这类思路。更进一步的提交记录分析会观察行为特征：提交间隔、修改频率、粘贴痕迹。考场监控则负责浏览器锁定、切屏警告、摄像头抓拍。

两份代码的相似程度常用 Jaccard 相似度来度量：

老周不会被“换了个名字”骗过——AST 特征比对就像看骨架，换皮不换骨照样识破。当然，查重系统给的是“疑似度”，最终判定还需要老师复核，就像老周不会只凭相似就开除学徒。

J(A,B)=∣A∩B∣∣A∪B∣\displaystyle J(A,B) = \frac{|A \cap B|}{|A \cup B|}
Jaccard 相似度等于两份代码共同特征的数量，除以它们总共拥有的特征数量。
  1. 交集（A∩B）两份代码共有的特征数量，比如相同的语法树子树。
    ∣A∩B∣=#shared features\displaystyle |A \cap B| = \#\text{shared features}
  2. 并集（A∪B）两份代码各自特征的总和（重复只算一次）。
    ∣A∪B∣=∣A∣+∣B∣−∣A∩B∣\displaystyle |A \cup B| = |A| + |B| - |A \cap B|
  3. 求比值交集除以并集，结果从 0（完全不同）到 1（完全一样）。
    J(A,B)∈[0,1]\displaystyle J(A,B) \in [0, 1]

评测性能优化

老周发现“切削”步骤每个学徒都要重新做一遍，太浪费。他干脆把半成品提前准备好，谁来了直接组装；同时让几个操作间一起开工。这套经验正是评测性能优化的核心思路。

常见的优化手段有四种：缓存加速——相同代码不重复编译，预编译结果直接复用；相同测试用例的输出结果也可以缓存，命中后秒出成绩。并行评测——横向扩容 Worker 进程，配合消息队列削峰。分级评测——先跑快速的小用例，通过者再进入大用例和压力测试，连基础题都过不了的代码直接提前淘汰，节省算力。反馈提速——流式输出中间结果、优先展示第一个失败用例，让学生少等。

缓存效果可以用命中率来度量：

优化后的车间，学徒排队时间从一小时缩短到三分钟。孩子学手艺的劲头也更足了——反馈越快，练习密度越高，技能的成长曲线就越陡。

HitRate=NhitNtotal\displaystyle HitRate = \frac{N_{\text{hit}}}{N_{\text{total}}}
缓存命中率是“直接命中缓存的请求数”占“总请求数”的比例，命中率越高，重复劳动越少。
  1. 命中次数（N_hit）提交的代码在缓存中直接找到编译结果或评测结果的次数。
    Nhit=#cache hits\displaystyle N_{\text{hit}} = \#\text{cache hits}
  2. 总请求数（N_total）评测系统收到的全部评测请求数。
    Ntotal=#all requests\displaystyle N_{\text{total}} = \#\text{all requests}
  3. 求比例命中次数除以总请求数，得到 0 到 1 之间的命中率。
    HitRate=NhitNtotal\displaystyle HitRate = \frac{N_{\text{hit}}}{N_{\text{total}}}

AI 应用场景

在线编程学习平台的自动批改

阶段：自动评测与即时反馈

解决的问题：传统教学里，一个班几十份程序作业，教师需要逐份运行、比对、写评语，动辄占用半天时间，学生拿到反馈时往往已经忘了自己当初的思路。AI 评测系统把“提交→运行→比对→反馈”压缩到几秒，让练习密度大幅提升。

具体案例：在 CodeGym 类的编程学习平台上，学生完成一道算法题后点击提交，评测平台自动用公开用例加隐藏用例跑一遍，返回“通过 5/8，第 3 个用例超时”。学生立刻知道是效率问题还是逻辑问题，改完再提交，形成高频练习闭环，学习积极性明显高于等待老师批改的模式。

企业远程笔试的防作弊评测

阶段：行为分析与人机识别

解决的问题：远程编程笔试无法让考官盯着每个人的屏幕，传统线下笔试的监考手段在线上几乎失效。评测平台通过沙箱隔离 + 相似度检测 + 行为记录，把“考场纪律”数字化。

具体案例：某招聘平台在校招笔试中，候选人提交代码后在沙箱中运行，系统同时记录切屏次数、粘贴来源和提交间隔。笔试结束后，查重模块对全部候选人的代码做 AST 相似度比对，标记出相似度超过 80% 的代码组，由算法工程师二次复核，有效遏制了“复制粘贴”型作弊。

高校程序作业的学习分析

阶段：评测数据挖掘与学情诊断

解决的问题：教师想知道全班卡在哪个知识点，但传统批改只给分数，看不到班级的共性错误。评测系统收集每次提交的通过率、错误类型和尝试次数，帮助教师精准定位教学重点。

具体案例：某大学 Java 课程使用评测平台布置作业，后台统计显示本周 60% 的学生在“数组越界”用例上失败，平均尝试 4 次才通过。教师据此在下一节课专门讲边界检查，并向平台提交了一组新的边界用例，评测覆盖度提升到 95%。

Python 演示

python39 行
# mini online judge in one classimport time  class CodeJudge:    def __init__(self, test_cases, limit=1.0):        self.test_cases = test_cases        # list of (args, expected)        self.limit = limit                  # time limit in seconds        self.pass_count = 0                 # how many cases passed     def run(self, student_func):        logs = []        for args, expected in self.test_cases:            started = time.time()            try:                output = student_func(*args)                ok = (output == expected) and (time.time() - started) <= self.limit            except Exception:                ok = False            logs.append(ok)            if ok:                self.pass_count += 1        return logs     def summary(self):        return self.pass_count, len(self.test_cases)  def add(a, b):    return a + b  if __name__ == "__main__":    cases = [((1, 2), 3), ((-1, 1), 0), ((0, 0), 0), ((2, 2), 5)]    judge = CodeJudge(cases, limit=0.5)    logs = judge.run(add)    passed, total = judge.summary()    print("logs:", logs)    print("score: %d/%d" % (passed, total))
目的：实现一个迷你代码评测器，用一组测试用例自动检验学生函数的正确性，并统计得分。
  1. def __init__(self, test_cases, limit=1.0)构造评测器时把“考卷”（测试用例）和时间上限存好，就像老周的验收单。
  2. self.test_cases = test_cases测试用例列表中的每个元素是 (参数元组, 期望输出)，定义了输入和答案。
  3. for args, expected in self.test_cases:逐个取出用例，相当于老周逐项核对验收单。
  4. output = student_func(*args)把参数解包后真正运行学生代码，这是“实操”环节。
  5. ok = (output == expected) and (time.time() - started) <= self.limit比对输出是否一致，同时检查是否超时，两个条件缺一不可。
  6. except Exception:学生代码抛异常也算失败，捕获后不让整个评测器崩溃。
  7. self.pass_count += 1通过一个用例就累计一分，对应公式里的 N_pass。
  8. if __name__ == "__main__":独立运行时执行演示，模拟一次完整的评测流程。

常见误区

误区我只要堆上几千个随机测试用例，覆盖度肯定高，评测质量自然就有保证。多总比少强。

正解数量不等于质量，真正决定质量的是覆盖度和代表性。用等价类划分几千个“正常的加法”，不如加一个“最大整数相加”的边界用例更能暴露溢出问题。就像老周考椅子，让同一个人反复坐十次，不如让一个胖子压一次更能发现问题。评测设计的第一课：挑代表性用例，死盯边界。

为何常见：直觉上觉得“测得多等于测得全”，忽略了边界和分支往往藏在少数刁钻输入里，而大量重复用例只是在浪费算力。

误区学生代码都在沙箱里跑，所以随便怎么恶意都无所谓，反正出不了事。

正解沙箱只是“大幅降低风险”，而不是“彻底消除风险”。容器隔离依赖内核能力，历史上出现过沙箱逃逸漏洞。所以安全策略必须层层设防：禁用网络、只读文件系统、限制系统调用、最小权限启动。老周的操作间门确实加固了，但火种和尖锐工具照样会被收走。

为何常见：把“隔离”理解成“保险箱”，忽略了隔离机制本身也是被攻击的对象，安全防御永远是纵深工程。

误区程序能跑就行，风格扣分多此一举，反正考试只看输出对不对。

正解在企业与开源项目里，代码要被很多人反复阅读和修改。无意义的命名、过深的嵌套会让维护成本爆炸。风格检测管不到“对错”，但能管“手尾”——就像老周检查工具归位，因为明天还要用。圈复杂度超过阈值的函数应当被拆分，这是代码质量的基本盘。

为何常见：独自完成作业的经历容易让人误以为软件都是一次写完、一眼看懂的，忽略了真实软件的协作属性。

误区为了公平，每个学生的代码都必须跑完所有测试用例，否则评分就不严谨。

正解分级评测是行业常见做法：先跑快速小用例，通过者再进深度压力测试，连基础用例都过不了的代码直接判失败。这不是走捷径，而是淘汰赛逻辑——基础不达标的代码，跑深度测试只会浪费算力。公平体现在“同一套规则”，而不是“同一种时延”。

为何常见：把“充分评测”和“全量执行”混为一谈，忽略了平台资源终究有限，效率与公平需要平衡。

误区代码查重就是把两份代码逐字逐句比对，看起来不一样就说明没抄。

正解学生只要全局替换变量名、删除注释，逐字比对立刻失效。真正常用的是先把代码解析成抽象语法树（AST），再比较结构相似度；MOSS 等工具还结合了指纹与最长公共子序列。好比老周不看木纹颜色，直接看榫卯结构——换皮不换骨照样识破。

为何常见：停留在文本层面的直观理解，缺少编译原理中“结构即语义”的视角。

面试题

Q1. 在代码评测中，用于检验程序输出对错的依据是？

单选题 · easy

  • A.标准测试用例集← 正确答案
  • B.项目代码风格指南
  • C.完整系统运行日志
  • D.沙箱安全资源配置

答案：A。标准测试用例集包含输入和期望输出，评测系统把程序实际输出与期望输出比对，从而判断正确性。风格指南管不了对错，运行日志只是过程记录，沙箱配置与答案无关。

Q2. 等价类划分的核心思想是？

单选题 · easy

  • A.用全部输入逐一测试
  • B.随机生成海量输入数据
  • C.把输入分组取代表测试← 正确答案
  • D.只测一个正常输入值

答案：C。等价类划分把无穷输入空间分成若干等价类，每类挑一个代表即可覆盖该类行为，效率和代表性兼得。逐一测试不现实，随机数据缺乏针对性，只测正常值会漏掉边界。

Q3. 隐藏用例在评测中的作用是？

单选题 · easy

  • A.帮助教师手动批改作业
  • B.防止学生针对样例背答案← 正确答案
  • C.用于替代所有公开用例
  • D.增加服务器运行负担

答案：B。公开样例方便学生练习，但如果评测只用公开用例，就可以“背答案”式地硬编码输出。隐藏用例在学生看不见的地方检验真实逻辑，是保证评测公平性的关键设计。

Q4. 沙箱环境最核心的职责是？

单选题 · mid

  • A.加快学生代码的运行速度
  • B.自动修复代码中的语法错误
  • C.替代教师检查作业正确性
  • D.隔离运行避免破坏宿主机← 正确答案

答案：D。沙箱把不可信代码关进独立隔离空间，限制资源与权限，防止死循环、恶意命令影响宿主机，相当于考核车间的隔音操作间。加速、改错、判分都不是沙箱的职责。

Q5. 评测平台加入消息队列的主要原因是？

单选题 · mid

  • A.让测试用例数量可以无限大
  • B.削峰填谷保护评测服务稳定← 正确答案
  • C.直接提高单次评测的速度
  • D.自动生成学生的测试用例

答案：B。考试开始瞬间会产生大量提交请求，消息队列先缓冲再按速度分发，避免系统被峰值流量压垮，类似调度室的工单箱。它不改变单次评测速度，也不负责生成用例。

Q6. 圈复杂度数值越高，说明代码？

单选题 · mid

  • A.逻辑分支越多越难维护← 正确答案
  • B.运行速度越快性能越好
  • C.变量命名越规范清晰
  • D.注释越详细文档更全

答案：A。圈复杂度衡量控制流图中独立路径的数量，数值越高代表 if/else、循环等分支越多，代码越绕，阅读和维护成本越高。它和运行速度、命名规范、注释数量没有直接关系。

Q7. 学生全局替换变量名后提交，最可能失效的检测是？

单选题 · hard

  • A.基于语法树的特征比对
  • B.提交记录的行为分析
  • C.基于文本的相似度比对← 正确答案
  • D.运行时内存峰值监控

答案：C。逐字文本比对遇到变量名全局替换就会失效，因为改完的文本看起来完全不同。而语法树比较忽略变量名只看结构骨架，行为分析看提交习惯，内存监控与抄袭无关，所以失效的是文本相似度比对。

Q8. 下列哪些做法能提升评测平台吞吐量？

多选题 · hard

  • A.使用缓存复用相同代码编译结果← 正确答案
  • B.牺牲沙箱隔离换取更多计算资源
  • C.减少测试用例只测一个样例
  • D.扩增 Workerr 并行处理提交队列← 正确答案

答案：AD。缓存能避免重复编译、直接复用结果，扩增 Worker 能并行处理队列里的提交，二者都是正规的提速手段。牺牲沙箱会带来安全风险，减少用例会降低评测质量，都不能接受。

Q9. 沙箱超时机制主要解决什么问题？

单选题 · mid

  • A.学生代码输出结果格式不一致
  • B.测试用例期望输出设计不合理
  • C.死循环耗尽 CPU 拖垮整个平台← 正确答案
  • D.代码风格检查误报率过高

答案：C。死循环代码若不限制时间，会无限占用 CPU，甚至拖垮整个评测平台。超时机制像操作间里的强制收工铃，到点立即终止并判失败，让单个提交无法影响其他学生。

Q10. 关于代码查重技术的说法，正确的有？

多选题 · extreme

  • A.语法树比较能抵御变量名替换← 正确答案
  • B.最长公共子序列可度量相似度← 正确答案
  • C.相似度检测能完全杜绝抄袭
  • D.文本比对容易被改名绕过← 正确答案

答案：ABD。AST 比较关注结构而非名字，能抵御改名；最长公共子序列（LCS）是经典相似度度量方法；文本比对只看表面字符，确实容易被改名绕过。但任何查重手段都只是辅助，无法完全杜绝抄袭，最终还要人工复核。