在线评测系统判题规则全解析：基础计算题为什么总卡分？

这种问题我一年能被问几十次——明明是道基础计算题，样例在本地跑得好好的，一提交就卡在 分，上不去。很多人第一反应是“判题系统是不是有bug”“判题规则是不是太离谱了”。但根据我的经验，90%的情况不是规则离谱，而是我们的程序和判题规则之间，隔着一层看不见的信息差。

大家口中的“判题规则”，大白话讲就是在线评测系统（OJ）拿到你的代码之后，严格按照一套固定流程去编译、运行、比对结果。它不是一个会欣赏你思路的批改老师，而是一个铁面无私、只会做机械比对的质检员。你写了“请输入两个数”，它不会觉得友好，只会觉得“多出来的内容不是预期输出”。你算了 float，它拿 long double 的精度去比对，结果就是差之毫厘、判你错误。

这篇文章想把这件事彻底讲透，正好写给那些被基础计算题卡分的人。内容包括判题系统内部的工作逻辑、基础计算题最常踩的几类规则坑、一个80分案例的完整复盘，以及我多年排查这类问题沉淀下来的自查清单。不管你是刚刷OJ的新手，还是带学生做作业的老师，都建议把这篇看完，能省下不少“怀疑人生”的时间。

1. 先把判题规则的底牌翻出来：在线评测系统到底怎么跑你的代码

1.1 从提交到出结果，中间这一步一步都可能出问题

很多新手对判题系统的认知是“我点提交，过几秒它告诉我对错”。这个理解没错，但太粗了。判题系统的处理流程可以拆成四段：

第一段是编译。你的代码提交上去后，系统会调用后台的编译器或解释器来构建可执行文件。这里最容易被忽略的是环境差异：你本地用的是自己装的编译器或IDE，自带某些头文件、默认开启某些扩展，但评测机上是一个干净得多的环境。常见的问题包括用到了非标准头文件、依赖了本机才有的库、C++代码里用了 VLA（变长数组）但评测机没开扩展，等等。这时候最常见的结果是编译错误（CE），运气好点编译器也过了，但运行行为可能不同。

第二段是运行。评测机会把准备好的输入数据喂给你的程序，程序读的是标准输入，输出写到标准输出。你的程序被扔在一个资源受限的沙箱里：CPU 时间有限、内存有限、输出大小有限，也不允许读写额外文件。很多人在本地跑得飞快，一交就超时（TLE），往往不是死循环，而是把该用O(nlogn)的题写成了O(n²)，评测机用大数据一测就原形毕露。

第三段是捕获输出。评测系统并不关心你的程序在屏幕上打印了什么漂亮的提示，它只会把你往标准输出写的内容整体拿走，形成一份“选手输出”。

第四段是比对结果。评测机会把选手输出和标准答案做比对。比对方式有严格文本比对和特判（Special Judge）两种。严格比对简单粗暴，输出文件逐字节（或者忽略行尾空白后逐行）对比；特判则是一个额外的小程序，按题目约束来判断你的输出是否符合要求，比如浮点数输出只要误差在1e-6以内就算对。

理解了这几步，很多“为什么本地对、交上去错”的困惑就能化解了：因为你本地的“对”，是在你手动输入样例、肉眼观察输出的情况下得到的；而评测机的“对”，是在一堆你没见过的边界数据上、用程序化的方式逐字符比对出来的。这两者的标准根本不一样。

1.2 判题结果类型：AC不是唯一重点，非AC结果要会看“潜台词”

我整理了一张结果类型对照表，这是判题规则最基础的知识，每次排查卡分问题都用得上。

不少 OJ 会把输出格式的问题直接并进 WA，不单独设 PE。所以如果你收到的反馈只有“答案错误”，别急着认定是计算逻辑问题，先想想输出格式是不是和题面要求的不一致。这也是很多人卡在分数上不去、反复提交却一直没进展的重要原因——你以为它让你改算法，其实判题规则只是让你的输出文件跟标准答案长得一模一样。

基础计算题里，RE 和 TLE 出现频率相对低，WA 才是绝对大头。而 WA 的背后，又有相当一部分是“没有按照判题规则说话”导致的。

2. 基础计算题卡分的四大判题规则陷阱

2.1 浮点精度和保留位数：看着没问题，比对就是不相等

基础计算题不等于全是整数加减，温度转换、圆的面积、平均分这类问题都会涉及浮点数。一旦涉及浮点，判题规则就分成两派：一派要求严格按格式输出，比如“保留两位小数”；另一派只说“误差不超过1e-6即可”。这两派对应的处理方式完全不同。

先说保留位数。很多题目会明确写“输出格式：每个结果占一行，保留2位小数”，这时候你必须用固定的格式化方式，C/C++ 里是 printf("%.2lf", ans)，C++ 的 iostream 是 cout << fixed << setprecision(2) << ans。新手最容易犯的错误是直接 printf("%lf", ans)，默认输出 6 位小数，和题目要求的 2 位对不上。还有人用了 printf("%.0lf") 把小数全舍掉了，更是错得离谱。

再说误差容忍。这种题通常会配 Special Judge，判题程序会读取你的输出和标准答案，计算两者的绝对误差或相对误差，小于题目给的阈值就算对。但要注意，即便有特判，你也不能乱输出额外内容，也不该把中间过程的调试信息带进来。有人会在答案后面补一个“正确答案是xxx”，特判程序按数字解析的时候直接失败，一样 WA。

我给一个实用建议：凡是浮点题，先按“保留足够多的小数位”来输出，比如 printf("%.10lf", ans)，提交一次看看能不能过。如果能过，说明题目走的是误差判定的特判路线；如果 WA，再把输出格式改成题目要求的样子。这一步能快速帮你摸清这道题的判题规则。

2.2 多余输出和空格换行：Presentation Error 不是救命稻草

卡分的基础计算题里，有一类非常隐蔽的问题：你的答案核心数字完全正确，但多打印了提示文本、行尾多了空格、或者行末少了换行。这类错误在部分 OJ 上会报 PE，但在更多 OJ 上直接被记成 WA。

我自己带过的学生里，出现过很多类似情况：

• 代码里写了 printf("请输入a和b: ")，提交前忘了删；
• 为了调试，在循环里打印了 printf("a=%d,b=%d\n", a, b)，这种调试输出在本地跑的时候“看起来正常”，但评测机把所有输出都收走比对，直接判错；
• 每一行输出后面多打了一个空格，或者整个输出最后缺一个换行。

为什么会这样？因为评测机比对的是“整个输出文件”，不是“你肉眼看到的那几个数字”。它收到一堆带着调试信息的文本，和标准答案逐字符比较，任何一个多余字符都会导致不匹配。

我的建议是：提交前养成两个习惯。第一，全局搜索代码里的 printf、cout、print，确认每一句输出都是题目要求的一部分。第二，把输出格式跟题面逐字核对，题目说“每组输出占一行”，你就老老实实每组输出后换行，行尾不要有空格。不要心存侥幸，觉得 PE 也算对，很多规则里 PE 不算通过，即使算，你也不知道评测机什么时候会收紧规则。

2.3 数据范围与类型选择：sum爆int，答案是负数，谁也想不到

基础计算题最简单的形态是 a+b，但 a+b 恰恰是最容易踩数据范围坑的地方。题面写“输入两个整数 a 和 b，输出它们的和”，很多人瞄一眼就写了 int a, b; scanf("%d%d", &a, &b); printf("%d\n", a + b);。自信满满地交上去，结果 WA。

问题出在哪？数据范围。如果题面写的是 0 <= a, b <= 10^9，那么 a + b 最大是 2 * 10^9，已经超过 32 位有符号整数的上限 2147483647。程序算出来的结果溢出变成了负数，评测机拿它和正确答案比对，当然不匹配。你可能觉得这不算“规则”问题，但在判题规则里，这就是典型的“你的程序在评测数据下运算结果不正确”。

处理办法很简单：看到整数题先看数据范围。只要范围可能超过 2^31 - 1，就用 long long；如果范围可能超过 9 * 10^18，就用更高精度的方案，比如 Java 的 BigInteger、Python 原生大整数，或者 C++ 里自己实现高精度。

还有一个相关但更隐蔽的坑：浮点数比较不要用 ==。题目让你计算一些值，然后判断是否等于某个结果，比如判断三点是否共线、判断两数相除是否整除。如果你直接用 a / b == c / d 这种写法，浮点运算的舍入误差会害了你。正确姿势是计算差值，用 fabs(x - y) < 1e-9 这样的误差范围判断。这和判题系统的浮点特判逻辑是一致的：计算机里的浮点数本来就不是精确值，比较必须留出容差。

2.4 输入方式的“隐藏规矩”：多组数据、EOF、逗号分隔，一个不对全盘皆输

基础计算题的输入约定，看起来差别不大，实际处理方式完全不同。判题规则里，输入读取这一步就是一道坎。常见的输入模式有三种，每一种都要用对应的代码结构。

第一种是“固定组数”：第一行给你一个数字 n，告诉你后面有 n 组测试数据。C 语言可以这样写：

c复制int n, a, b;
scanf("%d", &n);
while (n--) {
    scanf("%d%d", &a, &b);
    printf("%d\n", a + b);
}

第二种是“读到EOF为止”：题目没有说有多少组，只说“输入包含多组测试数据，每组占一行，处理到文件结束”。这时必须这样写：

c复制int a, b;
while (scanf("%d%d", &a, &b) != EOF) {
    printf("%d\n", a + b);
}

或者 C++ 的：

cpp复制int a, b;
while (cin >> a >> b) {
    cout << (a + b) << endl;
}

如果题目是这种模式，你却只处理了一组数据就结束程序，那么评测机给的第二组、第三组测试数据会被你的程序无视。结果就是：第一个测试点可能过了，后面的全 WA，分数卡在一个尴尬的位置上不去。我推测，这就是很多人“基础计算题卡分”的直接原因之一。

第三种是“行内多个数据需要解析”：输入可能是 a,b 或者 a;b 这种带分隔符的格式，甚至每行可能有多个数字但中间混着逗号。这时候你要么用 scanf 的格式串直接匹配，要么把整行读进来再手动解析。直接 cin >> a >> b 是处理不了逗号的。很多题目的输入示例看起来“理所当然”，但你真的去读的时候，才会发现里面写的是 1,2，不是 1 2。

输出方面同样有隐藏规矩。有些题目要求“对每个测试用例，输出 Case #x: sum”，你如果只输出数字，即使计算正确，也会因输出格式不匹配被判 WA。有些题目要求输出 YES 或 NO，你写成 Yes 或 yes，同样不对，因为字符串比对是大小写敏感的。

3. 一个80分案例的完整复盘：从“本地能跑”到“满屏WA”

这一节我模拟一个非常典型的求助案例，它的结构和标题里描述的场景一模一样：一道基础计算题卡在 分，求助判题规则问题。

3.1 题面、初始实现和表面症状

题目描述是这样的：输入包含多组测试数据，每组一行，包含两个整数 a 和 b（范围在 -10^9 到 10^9），以 EOF 结束。对于每组数据，输出 a+b 的值，每个结果占一行。

拿到这个题，绝大多数新手会写出类似这样的代码：

cpp复制#include <cstdio>

int main() {
    int a, b;
    while (scanf("%d%d", &a, &b) != EOF) {
        printf("%d\n", a + b);
    }
    return 0;
}

本地测试的时候，手动输入：

code复制1 2
3 4
-1 5

输出：

code复制3
7
4

“完全正确啊！”于是提交。结果出来一个刺眼的 分，可能有几个测试点过了，但后面的全 WA。

表面症状就是典型的“会做的题过不了”，这种时候，人会下意识开始怀疑判题系统。但实际上，我们不妨冷静下来，把代码和题面逐字对照一下。

3.2 两次排查思路，找到角落里的真凶

第一次排查：先看数据范围。题面明明写着 a 和 b 的范围是 -10^9 到 10^9，a+b 的范围是 -2*10^9 到 2*10^9。int 的取值范围在绝大多数平台上最大是 2147483647，也就是大约 2.147*10^9。那么 1,000,000,000 + 1,000,000,000 就等于 2,000,000,000，还勉强在范围内，但 1,500,000,000 + 1,500,000,000，或者干脆 2*10^9 + 1 呢？直接溢出成负数。评测机的数据覆盖了数据范围的端点，你的程序在边界处全部算错，卡分就说得通了。

解决办法是换成 long long：

cpp复制#include <cstdio>

int main() {
    long long a, b;
    while (scanf("%lld%lld", &a, &b) != EOF) {
        printf("%lld\n", a + b);
    }
    return 0;
}

第二次排查：如果已经用了 long long 还是卡分，那就该怀疑输入输出格式了。注意题面说“输入包含多组数据，每组占一行”。你的 scanf 在读到 EOF 之前会一直循环，这个没问题。但有些同学会习惯性在 printf 里加一个“提示词”：

cpp复制printf("结果是: %lld\n", a + b);

本地看很友好，提交后多余文本直接造成 WA。还有一种做法是行末多打一个空格，或者末尾没有换行，都会在严格比对时被立刻识别出来。

我在实际排查中还会做一步“对拍验证”：写一个完全不依赖任何算法的小程序、或者直接用 Python 算标准答案，然后随机生成大量测试数据，把你的程序和标准程序跑一遍，逐个对比输出。只要有一个输出不一致，那个用例就是定位问题的钥匙。这种做法在复杂题里是神器，基础计算题里同样适用，能在两分钟内验证你的输出格式是否稳定。

3.3 很多时候，漏看题面里的“隐藏限定”才是元凶

复盘这个案例之后你会发现，卡分的原因往往不复杂，但容易被忽视。题面里的每一句话都可能是判题规则的一部分。有些人只看输入样例和输出样例，觉得“长得差不多”就够了，结果忽略了文字中关于数据范围、输出格式、多组输入的关键描述。

样例只是让你理解题意用的“抽样展示”，不是完整规范。比如样例输出可能是：

code复制3
7
4

并没有显示“每个结果后必须换行”这句规则，但题面文字写了。如果你用空格分隔输出，样例也可能人眼看不出来，评测机却能一眼发现。所以在做任何基础题的时候，我建议把题面文字当成代码规格说明书来读：输入部分圈出变量个数、数据范围、结束条件；输出部分圈出每一行的内容、是否需要 Case 前缀、是否保留小数、行尾是否有额外空格要求。读完之后再动笔写代码，比一遍遍试提交高效得多。

4. 判题规则实操排查清单与避坑手册

4.1 从WA到AC的七个检查点

下面这张表是我每次帮人排查基础计算题卡分问题时，都会拿出来过一遍的清单。按顺序走完，绝大多数问题都能暴露。

每次卡分不要急着“瞎改”。先拿着这个表逐项核对，比盲目提交十次都有用。尤其是第 4 和第 5 点，我敢说，基础计算题的卡分案例里，至少有一半是栽在这上面的。

4.2 能救命的两个调试技术：输出重定向和对拍脚本

先说输出重定向。本地调试时，不要老是一组一组手动输入数据，把测试数据写进文件，用重定向方式运行你的程序，方便又高效。Windows 命令行或 macOS/Linux 终端里都是这样：

bash复制./my_program < data.in > data.out

然后打开 data.out 查看结果。如果题目给了多个样例，就把每个样例保存成 sample1.in、sample2.in，批量跑一遍，避免重复敲键盘。

在此基础上，推荐做对拍。对拍的核心思路是“用一个简单程序生成随机数据，同时喂给两个程序——一个是你写的可能有问题的那份，一个是基本不依赖算法、逻辑上一定正确的暴力解或标准解——然后逐个对比输出”。我常用的脚本长这样：

bash复制#!/bin/bash
for i in $(seq 1 1000); do
  python3 gen.py > data.in
  ./my_program < data.in > my.out
  python3 bf.py < data.in > bf.out
  if ! diff -b data.in my.out bf.out > /dev/null; then
    echo "Found mismatch at test $i"
    break
  fi
  echo "Test $i passed"
done

gen.py 负责随机生成符合题目范围的数据，bf.py 是暴力标准答案。只要找到一个不一致的用例，你就拿到了定位 bug 的关键线索。

4.3 想少被扣分，记住四条铁律

这些规则听起来简单，但每一条都是我见过无数“血泪案例”后总结出来的，说多了都是泪。

第一条，永远不要把样例当完整测试数据。样例只是示意，真正的评测数据里会包含边界值、极限值、空值、重复值，只有你的程序在这些数据上都输出正确，才能拿到满分。

第二条，拿到任何题先看数据范围再写代码。很多基础题卡分就是因为 int 和 long long 的差距，这个一眼就能避免的问题，不值得浪费一次提交机会。

第三条，提交前一定全局搜索调试输出。在代码里写 printf("debug: %d\n", x) 是常见的调试手段，但提交前必须删掉。只要忘了删，哪怕你的计算过程完美，评测系统也会判你答案错误。

第四条，WA 之后先看题面，再看代码，最后才看评测状态。很多人一上来就怀疑 OJ 故意卡人，但绝大多数 OJ 的判题规则是公开且一致的。先把题面里每一个字都读到心里去，再带着问题去检查自己的代码，你会发现很多“灵异事件”其实是自己埋下的伏笔。

我被“基础计算题卡分”类的问题问过太多次，也帮着排查过数不清的提交记录。说实话，真没遇到过几次是评测系统本身的问题。更多时候，是程序里藏着一个不起眼的细节：类型溢出、调试输出没删、多组输入没读完、浮点格式不对、大小写不一致。判题规则其实是一种很朴素的契约：你按题面规范交程序，它按统一标准给结果。只要读懂了这种契约，基础计算题拿满分就是水到渠成的事。

如果你现在也正卡在 分上，别急着怀疑规则不合理。把题面读三遍，把边界数据测一遍，把输出格式抠一遍，再按上面那套清单走一遍。我敢打赌，真凶就藏在某个角落，而且大概率就在这篇文章列出的某个坑里。