不懂OJ判题规则？基础计算题卡分原因全解析

前阵子帮人看一道很基础的计算题，本地运行、样例输出全都没问题，可一提交到OJ，分数就卡在不上不下的地方。不是零分，不是编译错误，也不是超时，就是那种“绝大多数点都对，可偏偏有几个点扣分”的状态。这种问题在初刷OJ的人里太常见了，而且十有八九不是算法不行，是判题规则没踩准。这篇就把我踩过的、帮人排过的“卡分”原因整理一下，重点围绕判题规则本身展开，希望你能少提交几次无效代码。

不管你是刚开始接触程序设计竞赛，还是只在学校OJ上做基础练习，这篇文章都适用。内容不会讲高深算法，只会把“从一个提交到AC之间到底发生了什么”讲清楚，再看几个典型例子，最后给一套可以照着做的排查流程。

1. 先搞懂判题规则：你的分数从哪儿丢的

1.1 判题结果不是“非对即错”

很多新手对OJ的第一印象是：程序跑完，要么对，要么错。实际上大多数OJ并不是这么粗暴。一次提交可能返回的结果有编译错误（CE）、答案错误（WA）、超时（TLE）、内存超限（MLE）、运行时错误（RE）、输出格式错误（PE）、部分正确，以及最终的通过（AC）。其中“部分正确”或者“卡在某个分数”，往往是最让人头疼的状态，因为它不像WA那样容易定位，也不像RE那样会给你报错信息。

你得先建立一个测试点（Test Case）的概念。一个题目文件夹里通常会有多组输入输出数据，每组就是一个小测试点。OJ拿到你的代码后，会逐个测试点运行，所有点都过就是AC，有某个点没过，就只扣那个点对应的分值。所以“卡在XX分”的真实含义通常是：你的程序能跑，结果也大体正确，但就是有些测试点失分，并没有全盘失败。

这就像考试里的判断题，6道题里错1道，卷面不是0分，而是80分、90分。你不能光看“我前面几道都对了”，得去想“错的那道到底错在哪、题目考查的哪个细节我没注意”。

1.2 判题规则到底在“判”什么

不同OJ的判题规则有细节差异，但核心可以归纳为四层：

第一层是正确性。这要求你的程序输出和标准答案一致，或者被允许的误差范围内一致。不少基础计算题会写“如果结果与标准答案误差不超过1e-6，则认为正确”，这就是所谓的误差判题，本质上是把输出当数值来比，而不是当字符串比。

第二层是格式。判题系统通常会把你的输出当成一个文本文件，和标准输出文件做逐字节比对。它不关心你自己打了几张日志，只关心程序最终打印出来的内容。所以行末多一个空格、两个输出之间少一个换行、字母大小写不一样，都会导致这个测试点被判错。哪怕答案数值完全正确。

第三层是资源限制。每个测试点通常有时间限制和内存限制，比如1秒、256MB。程序虽然结果对，但运行太久会TLE，内存申请太多会MLE。基础计算题一般不涉及复杂算法，但仍可能出现输入输出方式太慢导致的超时。

第四层是运行时环境。OJ运行你代码时用的编译器和本地的可能不一样。比如用C++写代码，提交时语言选了GNU C，有些C++语法就会被拒绝；用C语言提交，却用了C++的STL头文件，也会编译失败。这一层经常被忽略，却非常影响得分。

理解这四层之后，再看“求助判题规则”这个问题，其实真正想问的是：题目到底按什么标准给分？我的程序结果看起来没问题，为什么测试点不认？

1.3 基础计算题为什么最容易卡在这三件事上

基础计算题有个共同特征：逻辑简单，不考精巧算法。正因如此，很多人的代码一眼看过去是对的，但提交后的分数就很难看。

结合经验，基础计算题卡分通常集中在三件事上。

第一是“细节过界”。题目明明让你输出每个数用空格隔开，你在行末多写了个空格；题目要求输出两位小数，你用默认的cout把结果变成了6位有效数字。这些都不是“解题思路”层面的错，而是输出规则层面的错。

第二是“数据范围不看”。一道“计算等差数列和”的题，很多人觉得简单，定义个int就上。可如果n给到10^9，n*(n+1)/2早就溢出int了，最后结果看起来是正数，却和标准答案差了十万八千里。这种失分往往集中在大数据测试点上。

第三是“读取方式没覆盖完所有数据”。很多基础题没有告诉你到底有几组数据，输入可能是一行接一行直到文件结束结尾。你要是只读一次、处理一次就退出，前几个小数据也许侥幸能过，后面遇到大数据用例直接出错甚至超时。

下面几个小节，我把这三大类的具体表现、原因和修复方式逐一展开。

2. 卡分四大来源：格式、精度、范围、输入

2.1 输出格式：行末空格和换行都算错

我见过太多基础题卡分是输格式害的。判题系统非常抠细节，你的输出会被当成一个文本序列，多出的空格会改变字符序列，自然影响比对结果。

举个例子：题目要求“按顺序输出1到n，每个数之间用一个空格隔开，末尾不要多余空格”。你写下面的循环：

cpp复制// 问题代码
for (int i = 1; i <= n; i++) {
    printf("%d ", i);   // 每个数后面都带一个空格
}
printf("\n");

当n等于5时，你输出的是：

text复制1 2 3 4 5 

注意5后面那个空格。从终端看基本无感，但和标准输出“1 2 3 4 5”做字节比对时，它就是多余的。如果题目恰好有不止一个输出数字的测试点，这几组就容易被判错，分数自然扣掉。

换行同理。有些题目要求每组输出占一行，你却在每组之间多打了一个空行，或者最后少了一个换行，都可能卡分。常规的解决办法是严格控制输出逻辑：

cpp复制for (int i = 1; i <= n; i++) {
    if (i > 1) {
        printf(" ");
    }
    printf("%d", i);
}
printf("\n");

这样既保证数之间有空格，又不会在末尾多一个空格。这个细节在输出数组、数列、矩阵时尤其重要。

另一个常见格式问题是精度不对。C++里用cout输出double时，默认只显示6位有效数字，不是6位小数。比如3.1415926535，直接cout会输出3.14159；而题目如果要求“输出两位小数”，那3.14才是对的。用printf可以精确控制格式：

cpp复制printf("%.2f\n", value);

尽量用printf/scanf这类格式化函数配合输入输出，能在很多基础题里少踩格式坑。

还有一类问题无关空格和换行，而是字符大小写。输出“Case 1: yes”，你写成了“Case 1: Yes”，在判题规则里就是完全不同的字符串。碰到这类要求，建议直接复制题面上的单词，别凭记忆敲。

2.2 浮点精度：基础题里的隐形误差判题

基础计算题里有一大部分会涉及浮点数，比如求三角形面积、求平均数、解一元二次方程、计算圆面积等等。浮点数在计算机里本身就不是精确的，如果题目使用误差判题，系统会允许你与标准答案存在一个小误差。但前提是，你的输出精度必须达到题目要求的范围。

先看一个很常见的写法：

cpp复制double a = 1.0 / 3.0;
printf("%.2f\n", a);   // 输出 0.33

如果题目要求“误差不超过1e-6”，那么0.33离真实结果0.333333差太远，即使你逻辑完全正确，还是会被判错。这时候需要输出更多小数位，至少输出到题目要求的误差量级，通常建议多输出几位更保险。

cpp复制printf("%.6f\n", a);   // 输出 0.333333

很多新手以为“保留两位小数”就是所有题都要保留两位，这是误解。基础计算题常有两类要求：一类是明确“四舍五入保留n位小数”，另一类是“与标准答案绝对误差或相对误差不超过某个阈值”。后者往往要求你输出足够多的小数位，比如1e-6就输出小数点后6位以上。

浮点数还有一个特别坑的地方：你计算过程中如果用了float而不是double，精度很容易不够。float只有大约7位有效十进制数字，double大约15位。题目数据较大时，float的误差会放大到超过判题阈值。建议浮点计算一律用double起步，除非题目能确认精度毫无压力。

如果你在程序里要判断两个浮点数是否相等，千万别用a == b。由于浮点舍入，很多数学上相等的式子算出来并不完全一致。正确做法是设一个极小量，比如：

cpp复制const double EPS = 1e-8;
if (fabs(a - b) < EPS) {
    // 认为相等
}

计算过程中也尽量少做可能会放大误差的操作，比如连续的sqrt、除法、减法抵消。以海伦公式求三角形面积为例，三条边长可能是很大的数，如果先算半周长p，再用p*(p-a)(p-b)(p-c)直接做浮点乘法，通常double还扛得住；但如果你用float，面积就可能偏差明显。遇到这类题，用double并且按题目要求输出足够精度，是最稳的。

还有一点很隐蔽：题目要求“结果保留一位小数”，如果答案是整数3，标准输出可能是3.0，也可能直接是3，具体要看题目描述和输出样例。以样例为准，不要跟自己的习惯较劲。

2.3 整数溢出：中间结果比你想的大得多

基础计算题看久了会发现一个规律：题面越简单，数据范围越可能“暗藏杀机”。比如a+b这种题，如果数据范围写到0 <= a, b <= 2^31 - 1，那用32位int算加法很容易溢出。

来看等差数列求和的问题，公式是 n * (n + 1) / 2。当n = 10^9，n * (n + 1) 大约是1e18，远远超过int的21亿上限。如果你写：

cpp复制int n;
scanf("%d", &n);
int sum = n * (n + 1) / 2;   // 溢出，可能变成负数或错误结果
printf("%d\n", sum);

结果大概率会错。即使最终正确答案n*(n+1)/2在某个范围内小于2^31，也不代表中间乘法的每一步都不越界。这道题的“中间量n + 1和n”乘积就已经爆了。

解决办法很简单：涉及可能变大的计算，直接用long long：

cpp复制long long n;
scanf("%lld", &n);
long long sum = n * (n + 1) / 2;
printf("%lld\n", sum);

printf记得用%lld，不要漏成%d。一些老平台可能要求%I64d，所以提交前确认一下OJ常见格式，毕竟格式错了输出解读就不对。

还有一种溢出属于“单个取值不大，但运算后变大”。比如求数组连续子段乘积，虽然每个数不超过1000，但n一大，乘积可能指数增长。基础计算题里常出现的是排列组合、阶乘累加。遇到这类题，估算最坏情况下的中间值，宁可多分配几位也不要冒险。在OJ上，常规做法是：题目没给明确范围就当大数据处理；给范围就算一下上限，看int存不存得下。

整数类型够大之后，还要注意除法和取模。比如 n * (n + 1) / 2，先做乘法再除以2，可以保证中间量的精度。如果先除以2，遇到n是偶数时没问题，n是奇数时会丢精度。这种顺序问题不是判题规则的问题，是数学计算本身的要求。

2.4 多组数据：题目没说“一组”就当多组处理

基础计算题还有一个高频丢分点：输入到底有几组数据。这也是判题规则非常核心的一部分。

有些题会在第一行给一个T，表示后面有T组测试数据。这种最简单，循环T次即可。比如：

cpp复制int T;
scanf("%d", &T);
while (T--) {
    // 处理一组
}

但很多基础题，尤其早期练习，不会给T，而是不断读取输入，直到文件结束为止。比如“对每一对输入的a和b，输出它们的和”，输入可能是很多行，你根本不知道有多少组。如果你只处理一组就return，前面样例也许过了，后面所有组压根没运行，结果自然错。

处理这种“多组直到EOF”的输入，C写法是：

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

C++里用cin判断流状态：

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

有些OJ还会在输入中包含空行，scanf和cin通常情况下能自动跳过空白符，因此不推荐用gets或getline去读数字，容易把换行符也吃进来，造成解析错位。

判断是不是多组输入的技巧是：仔细看题目描述里有没有“每组输入占一行”“多组测试数据”“直到文件结束”这类短语。一旦不确定，就按多组数据处理。只处理一次不会比判断EOF更省事，反而会损失大量测试点。

输入方式同样关系到超时。数据量很大时，cin和cout如果不同时关闭同步，往往会比scanf/printf慢。你可以尽早写：

cpp复制ios::sync_with_stdio(false);
cin.tie(0);

否则遇到几十万行输入，代码可能因为IO太慢而TLE。对基础计算题来讲，这个知识点在后续刷题中一定会用上。

3. 从“卡分”到“满分”的排查实操流程

3.1 提交前先做“环境三连查”

卡分之后别急着怀疑评测机，先从最简单的三件事查起。

第一，查提交语言。你本地用C++17写代码，提交时却选了“C语言”，那大概率编译失败，或者某些C++语法不被旧编译器支持。一定要看准目标OJ支持的语言列表，再选对应项。

第二，查代码里是否有本地痕迹。比如Windows下调试常见的system("pause")、调用本地文件路径、freopen重定向，这些代码在自己的电脑上没问题，但在OJ上要么运行到最后被卡住等不到结束，要么因为权限问题报错。尤其是freopen，OJ会把输入重定向到测试文件，你在代码里自己open一个不存在的路径，整个程序就会停滞。

第三，查主函数定义。C/C++主函数应该是int main，结尾return 0。有人长期写void main，本地某些编译器能容忍，到OJ上就CE。看似离谱，实际每年都有人因此丢分。

环境问题排查完，再进入逻辑层面。如果IDE有警告提示，记得看：整型溢出、未初始化的变量、double转float丢精度，这些警告往往正是卡分元凶。

3.2 构造一套边界用例，本地先自测

很多人的自测方法是用题目样例，测完没问题就提交，这是远远不够的。判题系统看不见你的自信，它只关心极端测试下你稳不稳。所以你要学会自己造边界用例。

以基础计算题来说，至少准备以下几类测试数据：

造用例最怕凭感觉，要依据题目数据范围推算上限和下限。比如题目写“n不超过10^9”，那就必须测一次10^9；题目写“结果四舍五入保留一位小数”，就找一个会触发进位的小数测试四舍五入逻辑。

手工测试可以配合脚本。本地把每个用例存成input.txt，程序读入后把输出记录到output.txt，再和期望结果比对。你可以在Linux下用diff命令，Windows下用fc命令。肉眼容易放过空格，diff不会。

3.3 用样例对比工具找出格式差异

我排查卡分时做过一件很笨但是很有效的事：程序输出和标准答案存成文本，再逐字节对比，肉眼看不出来的差异就全浮出来了。

拿一套最简单的a+b题来说，样例标准输出是：

text复制3
5

你的程序输出可能是：

text复制3
5

看起来一样，但如果你是Windows环境写的文件，行尾会有\r\n，而OJ上的标准输出通常只是\n。这类差异一般OJ会统一处理，但如果你用文件重定向在本地跑，diff对Linux格式和Windows格式会报差异。用diff -u查看时，行尾会显示^M，说明有回车混进去。虽然不少OJ对行尾不敏感，但有部分平台要求严格，小心为上。

文本对比还有一个用处，就是排查“最后一行没换行”。有些选手最后一行不输出换行也能AC，因为标准答案同样没有换行；但有些题标准答案末尾有换行，你少写一个就会被判PE或者WA。最保险的做法是每组数据输出完后主动printf("\n")，不要依赖程序末尾自动补。

文件读写只用于本地对拍，提交时记得删掉或注释掉自己加的freopen。比较常见的是保留freopen导致OJ直接TLE或WA，这是一个非常容易被忽略的环境问题。

3.4 通过测试点分值反推漏掉的数据类型

如果OJ能显示“部分通过”，但没有说明哪个测试点挂了，你可以通过题目给的测试点描述来反推。很多题面会把测试点分成若干档：如第1个测试点n=1，第2个测试点n<=1000，第3个测试点n<=10^9。你发现提交总分少了一个点，而自己的代码在n=1和n<=1000都安全，那就要重点排查大数据档。

怎么排查？把n设成10^9，本地跑一遍，观察结果是否明显异常。如果输出突然变成负数，大概率是int溢出。如果迟迟不结束，可能是你的算法写成了O(n)，而题目数据范围不允许线性遍历。此时不要纠结判题规则，先优化算法复杂度。

还有一类基础计算题会故意加几个特殊测试点，比如“答案对1e9+7取模”“三角形三边可能不合法”。这些特殊点通常会单独占一道，分值不一定高，但如果你没有处理，总分会少一点。我习惯在做题前先把题目中的“约定”整理成两列：一列是数据范围，一列是特殊情况，然后在代码里逐条注释对照，能明显降低漏考虑的概率。

4. 常见问题速查表与避坑实录

4.1 高频坑位速查表

下面这个表是根据实际卡分问题总结出来的，几乎每一条我都亲眼见过。可以直接截图收藏，下次提交前对一遍。

4.2 三个很典型的“卡分”案例复盘

案例一：平均分计算保留小数。

有朋友写过这样的代码：

cpp复制int sum = 10;
int n = 3;
double avg = sum / n;    // 整型除法，结果是3，不是3.333
printf("%.2f\n", avg);   // 输出3.00

题目的标准答案是3.33，他卡在某个测试点上。这就是先做了整数除法再赋给double导致的。该题要求输出浮点数，计算时至少需要保持一边是浮点：

cpp复制double avg = (double)sum / n;
printf("%.2f\n", avg);

还有另一个极端：题目要求输出整数，比如“计算BMI并取整数部分”，你偏偏printf("%.1f")，即使数学结果正确，输出格式也会和标准不一样。输出类型必须紧跟题目要求。

案例二：三角形面积边界不合法。

某道题说输入三角形的三条边，计算面积。表面上用海伦公式就行。但有些测试点故意给1 2 3，这组数构不成三角形。题目如果没说保证输入合法，那你就得自己判断：先检查是否满足任意两边之和大于第三边。很多卡在90分的人就是没判断，错误测试点扣1分。这种分丢得最可惜，逻辑确实写了，只是少写了一个“游戏规则”。

案例三：a+b的大数据版本。

一个最简单的“读两个整数，输出和”的题，数据范围不声明或声明得很宽。用int的后果是前几个测试点全过，到了大整数那个点就爆。把int改成long long，printf对应%lld，立刻AC。这类问题其实只需要从IO格式和变量类型上做调整，跟算法无关，但非常考验对判题规则的理解。

4.3 把判题规则变成自己的自检清单

解决卡分问题最有效的方法，不是每次卡了再翻博客，而是形成固定的自检习惯。我现在每写一道题都会过一遍下面这六个问题：

• 输入是固定一组，还是多组直到EOF？如果题目没说只有一行，我就按多组处理。
• 数据范围的最大值是多少？int够不够？需不需要long long？中间量会不会溢出？
• 输出涉及浮点吗？题目要求保留几位小数，还是允许误差？我有没有用到double？
• 输出格式和样例是否完全一致？末尾有没有多余空格？每组之间有没有多余空行？
• 代码里有没有freopen、system("pause")、注释里的中文路径等OJ不允许的内容？
• 提交语言和代码实际用到的语法是否一致？

每次提交前过一遍这六问，基本可以把“判题规则导致的非算法问题”压到最低。等你慢慢养成习惯，会发现卡分的概率大幅下降，因为大多数坑都是可以提前堵上的。

5. 写在最后：从踩坑到稳定拿分的一点体会

说到底，OJ的判题规则并不复杂，它在多数时候就是“输出是否与标准一致”这几个字。但正是因为人的眼睛会忽略行末的空格、会低估输入数据的规模，这些细节才反复变成扣分点。卡分不是命运弄人，多数情况是你还没有把题面里的规则，完完整整翻译成代码里的判断和输出控制。

我个人遇到这类问题，最想强调的不是某一行代码怎么写，而是“别急着反复提交”。每提交一次浪费的不仅是时间，还会让自己在同一个坑里打转。正确做法是回到题面，把输入范围、输出格式、特殊约定这三栏读出声来，逐一对照自己的程序。如果还是找不到问题，再用小规模边界用例去逼出bug，而不是盲目改逻辑碰运气。养成这套流程之后，你的AC率会明显变好看。希望这篇能帮正在被“基础计算题卡分”折磨的人早点跳出来，把时间花在真正值得研究的题目上。