OJ基础计算题卡分真相：判题规则边界与隐藏坑排查指南

这几天某刷题群又有人发同样的问题：一道看起来非常基础的计算题，本地样例一下全过，提交上去却卡在xx分，要么是90，要么是98，总之不是满分，后面还跟一句“这题是不是判题规则有问题”。每次看到这种帖子我都忍不住多回复几句，因为“卡分”和“完全过不了”完全是两回事。全错往往意味着思路跑偏，而卡分说明你的代码已经能通过绝大多数测试点，只在某些隐藏在暗处的数据上翻了车。这个场景在在线评测系统（OJ）里太经典了，今天就借这个标题，把“判题规则”背后的逻辑、隐藏的边界条件，以及基础计算题常见的失分原因一次性聊透。

先说结论：大部分情况下判题规则没有针对你，而是你的代码触发了某种评测机不认的写法，或者正好踩中题目描述里没写但数据里存在的边界。你要做的事情不是怀疑评测系统，而是按照评测逻辑反过来推，自己把那个失分点找出来。

1. 判题规则到底“判”了什么？搞清系统怎么给你的代码打分

1.1 “卡分”本质上是因为黑盒测试只认输出

大部分OJ评测，尤其是基础计算题，用的都是黑盒测试。什么是黑盒？就是评测系统根本不在乎你代码内部写得有多优雅、注释写得有多全，它只做三件事：把你的源码编译成可执行文件、跑一组预先准备好的输入数据、把你的输出和标准答案做比对。一样就给这个测试点打对勾，不一样就直接判错。如果你的程序在某个数据上崩溃、超时、或者内存超限，那一样不能得分。

所以你能拿到“xx分”，代表你通过了几乎所有测试点，但至少有一个点出了问题。那个问题测试点往往是数据范围极端的点，比如最大值的点、最小值的点、重复数据、负数的点。正因为你的代码在常规例子里看不出毛病，才容易让人误以为是判题规则有毛病。

这个逻辑特别像考试评分：平时练习题你都会做，考试里面出现了一道你没见过的边界题，你要说卷子有问题，那肯定不对。要冷静下来，一张一张看题目给的数据范围，比反复重交无效代码有用得多。

1.2 在线评测的常见状态都代表什么意思

基础计算题的提交状态一般包括：AC（通过）、WA（答案错误）、RE（运行时错误）、TLE（超时）、MLE（内存超限）、CE（编译错误）。如果你是一个新手，我建议先把这些状态的含义记牢，因为卡分状态不同，排查方向完全不同。

• WA：最常见，你的代码跑完了，但输出和标准答案不一致，说明有可能是思路错，也有可能是某项边界没考虑到。
• RE：一般是数组越界、栈溢出、除零这些问题，也有可能是一个隐藏的大数值输入导致容器越界。
• TLE：代码逻辑本身可能没问题，但你的算法复杂度太高，或者某个循环在数据极端情况下跑不完。
• MLE：内存申请太多，多见于开大数组但没注意限制。
• PE：输出格式不匹配，多数是多了一个空格、少了一个换行这类问题。

你会发现真正“卡分”的现象通常不属于TLE和MLE，更多是WA或PE打到部分点。因为如果超时，基本一大半测试点都过不了，得分会非常难看。而WA则可能只是败在最特殊的那个测试点身上。

2. 基础计算题卡分最常见的6个隐藏坑

2.1 数据范围没看全，int随手一写就溢出

这是基础计算题卡分的头号原因。很多题目描述会写“n <= 10^9”或者“a, b不超过2^31-1”，但代码里仍然用int存储运算结果。int在绝大多数OJ平台上是32位有符号整数，范围是-2147483648到2147483647，大概21亿多。看起来好像很大，可一旦两数相加或相乘，就很容易越过上限。

举一个很典型的例子，题目如果让你计算 1 + 2 + ... + n，n给到10^9，你用int累加一定溢出，因为答案大约是5×10^17级别。这种题你必须用long long（64位整数）才扛得住，更夸张的甚至需要高精度算法。很多人卡在“某些测试点过，某些测试点不过”，就是因为小n都能算对，一旦数据到了最大范围，溢出后结果突然变成负数或乱值，自然被判WA。

我刚学编程时写过一个求阶乘的题，用int存结果，算到13的阶乘附近就开始不对，我还一直以为题目出错了。后来发现是我根本没看数据范围，而是拿自己本地的编译器行为当世界标准了。所以你遇到卡分，第一件事永远是回头把题目输入范围看一遍，然后估算你的变量类型够不够存，不够就换更大类型，或者换算法。

2.2 浮点数在判定时没你想的那么“宽容”

很多计算题会涉及小数，比如求平均值、除法、物理公式。这时候就牵扯到两个常见问题：一是精度不够，二是输出格式不对。

先讲精度。判题机在比对浮点数输出时，通常不是要求完全二进制相等，一般会有特殊判断（Special Judge）允许误差范围，比如误差不超过10^-6就算通过。但是如果你拿单精度的float去算，误差很容易超出允许范围。尤其是多次运算累计误差，会直接导致答案差了那么一点点。所以做浮点计算题，优先使用double，除非题目给了明确的内存限制要求，否则别碰float。

再讲输出格式。有些题要求“保留两位小数”，你如果直接 cout << ans，输出一长串小数，那么无论你算得多准，判题规则都认为你格式错。正确做法是，要么用 printf("%.2lf", ans)，要么用C++的 fixed << setprecision(2)。这个错误通常不会全WA，而是部分测试点通过、部分输出不匹配，看起来就很像“判题规则坑我”。

还有个隐藏小坑是“-0.00”问题。比如计算结果是一个绝对值极小的负数，四舍五入后可能会输出 -0.00，但标准答案可能是 0.00，字符串比对直接失败。解决办法是：如果要输出小数，可以对结果做一个极小量修正，比如 if (fabs(ans) < 1e-9) ans = 0;，再输出，非常管用。

2.3 多组输入的处理方式不对，导致某些数据没读进来

很多基础题会用“多组测试数据”作为输入格式，比如“输入包含多组测试用例，每组一行，每行两个整数，一直读到文件末尾”。这种需求下，你必须在程序里循环读取直到EOF。不少人在这一步写错，常见错误有两种。

第一种是只处理了一组就退出。你判断输入的条件写成了只读一次，样例因为恰好只有一组数据，所以看起来对了，实际测评时第二组数据根本没有被处理。这种代码往往拿不到满分，因为后面的组全被忽略，输出自然对不上。

第二种是不小心在循环里把输入条件写复杂了，比如用 while (!cin.eof()) 配合内部又读一次，最终在读到倒数第二组后多循环了一次，造成多输出一行脏数据。多出来的这行会导致评测结果WA。很多人觉得无法理解“为什么我自己跑不出问题”，因为本地输入文件末尾的结束标记有时候不容易模拟出来。

稳妥的多组写法要看语言而定。C语言用 while (scanf("%d%d", &a, &b) != EOF)，C++用 while (cin >> a >> b)，Python用 for line in sys.stdin: line = line.strip(); if not line: continue，Java用 while (scanner.hasNextInt())。不要自己造轮子判断结束条件，直接依赖这些成熟读法最稳。

2.4 输出格式里藏着的空格与换行也能让你卡分

你以为输出结果正确就完事了，但评测机对输出的比较往往是逐字符比较的。哪怕只是多了一个空格、少了一个换行，它都会认为你和标准答案不一致。

打个比方：标准输出是

code复制1 2

你的输出是

code复制1  2

两个空格夹出两个空格，你看不出来，但字符串比对立刻发现不同。更常见的是每行结尾的空格：很多人在循环里输出元素，为了统一写了 cout << a[i] << " "，结果最后一个数字后面多了个空格。这种格式错误，有些OJ会判PE，有些OJ直接判WA。PE和WA在分数上往往会被算成部分得分，于是你看到“卡分”现象。

处理格式问题没有捷径，只能依照题目描述里的“输出样例”严格对齐。有些题目如果明确说“每个数字间用一个空格分隔”，那你就保证除了行间换行外，不能出现行尾空格。我在落笔时会先看能不能用第一个样例硬对，如果样例尾行有多余空格，就立刻调整打印逻辑。

一个很多人没注意到的细节是：大多数评测系统允许最后一行没有换行符，但也有极少数老系统对末尾换行敏感。保险起见，在程序结束时主动打一个换行 printf("\n")，不会有副作用，还能照顾到那些对末尾换行有要求的题目。

2.5 全局变量、数组大小与递归栈的隐藏问题

如果是一道计算题，理论上不太会开很大数组，但依然有这类坑。比如题目给了最多10^6组输入，你开数组时少看一个0，只开了10^5大小，那么超出部分就会越界写，轻则把别的小变量覆盖，重则运行时错误。这种问题不是每次都触发，只在数据较大的那几组触发，表现出来就是部分正确、部分崩溃。

另外，有些计算题如果你用了递归写法，比如递归求斐波那契数列，n一大就会爆栈或超时。基础计算题其实不只是考你会不会算，还考验你能不能处理边界数据。判题机里运行栈默认大小各平台不同，如果题目测试点规模不小，递归深度又大，就会出现本地运行好好的、提交上去RE的怪现象。所以不要在函数内开超大数组，能放全局的放全局，递归能改循环的尽量改循环。

2.6 别忘了某些环境相关细节：%lld 与 %I64d

还有一类很奇怪的问题，出现在用C/C++的scanf/printf时。比如题目数据范围很大，你用long long存储，在Windows环境装的一套编译器上写 printf("%I64d", ans)，本地测得好好的，但OJ通常在Linux系统上运行，Linux下GCC只认 %lld，不认 %I64d。这样会导致大整数输出直接变成乱码或错值，于是又出现“部分测试点通过、部分错误”的现象。

反过来，有人在Linux上写 %lld，但本地Windows上的旧版编译器可能不支持，就会本地编译失败。解决办法很粗暴：统一用 %lld（新版本都支持），如果是自己的电脑本地编译器比较旧，建议装一个新一点的GCC或直接用在线编译器验证；如果确实需要在Windows下输出64位整数，可以用 cout，流输出一般没有这个历史包袱。

3. 从“xx分”到AC的排查步骤实录

3.1 先从题目描述里找到你忽视的约束条件

卡分之后不要急着改代码，先拿出纸笔把题目重新读一遍，逐字标出这几类信息：

• 输入变量的取值范围是什么？
• 是否有多组输入？怎么结束？
• 输出要求保留几位小数？
• 是否存在特殊约定，比如输入可能为0、可能为负数、可能相同？

把这些信息写下来之后，再对照你的代码检查一遍。比如题目写“n是正整数且不超过10^9”，你用int存n，可能没问题，但你要算的和如果超过int范围，那就是坑。又比如题目没有说n是正整数，只说了整数，那你必须考虑负数、0这些数据，别人可能因此用 n*(n+1)/2 公式时把0或负数带入也没问题，但如果你用了循环累加且循环初值有问题就会漏。

这一步是我处理自己代码问题的固定起点。因为绝大多数基础计算题卡分，都不是“高级算法”问题，而是出题人故意埋的边界地雷。你把这些约束对照着变量类型、输出格式逐一核查，通常很快能找到怀疑对象。

3.2 本地制造“极端数据”现场复现失分点

如果你已经确定了怀疑点，下一步就是构造可复现的输入来验证。比如你怀疑题目需要处理10^9级别的数字，那本地就直接生成一个最大的输入，跑一次看输出有没有变成负数、乱码、或者超时。

假设题目是“多组输入，每组两个整数a和b，输出a+b”，数据范围写的是“0 <= a, b <= 2^31-1”。你用int会怎样？我写一段代码演示：

cpp复制#include <cstdio>
int main() {
    int a, b;
    while (scanf("%d%d", &a, &b) != EOF) {
        printf("%d\n", a + b);
    }
    return 0;
}

本地测试时给一组输入：

code复制2147483647 1

在大多数机器上，输出会是 -2147483648，因为发生了整数溢出。但如果你看样例输出只写了 3 5 这类小数据，你的程序跑出来的结果是8，和样例一致，于是你以为没问题。其实这道题合起来最大可达4294967294，远超int范围。修正方案非常简单，换成64位整数：

cpp复制#include <cstdio>
int main() {
    long long a, b;
    while (scanf("%lld%lld", &a, &b) != EOF) {
        printf("%lld\n", a + b);
    }
    return 0;
}

再跑一次极端输入，输出正确，这个失分点就补上了。如果把每一组极端情况都本地跑过一遍，你的“xx分”大概率能变成满分。

3.3 用小规模数据加对拍，定位逻辑或格式问题

如果是涉及逻辑陷阱的题，比如“判断闰年”“求最大公约数”这类，极端数据未必能一下暴露问题，但用“对拍”可以。所谓对拍，就是写一个暴力解法或另一个独立实现，把同一组随机输入分别丢给两个程序跑，看输出是否一致。只要生成了足够多的随机小数据，基本能发现代码里暗藏的错误。

举个例子，你写了一个看似聪明的数学公式，但不确定正负号处理是否正确，就可以写一段普通的循环暴力代码作为基准。然后用Python或shell生成几千组随机数据，分别喂给两个程序，比较输出：

bash复制for i in $(seq 1 1000); do
  echo "$RANDOM $RANDOM" > input.txt
  ./your_program < input.txt > out1.txt
  ./brute_program < input.txt > out2.txt
  if ! diff -q out1.txt out2.txt > /dev/null; then
    echo "difference found!"
    cat input.txt
    break
  fi
done

这段脚本在Linux或macOS上可以直接跑。如果中途发现不同，输入文件里那组数据就是你的“罪证”。拿到它，再进一步判断是程序逻辑还是输出格式的问题。别小看这个笨办法，我很多卡到半夜的题都是用对拍救回来的。

3.4 根据失分点类型选择针对性修复方案

不同失分点对应不同修法。若是整数溢出，最简单的是把所有参与计算、可能变大的变量都改成long long，但如果题目极端到大数相加，long long都不够用，那时你就得引入高精度加法：用数组或字符串模拟逐位计算。如果是浮点数卡精度，修法是把float改成double，并对最终输出做误差修正。如果是多组输入读入不对，就改成前面提到的标准EOF读法。如果是输出格式问题，则按样例严格对照修正。

这里有个非常实际的心得：不要去猜评测机里到底有哪些数据，而要在代码里对所有约束做兼容。与其说“判题规则太严”，不如说“自己的代码鲁棒性不够”。评判系统只认最终结果，它不知道你写了多少个小时的代码，也不会因为你的程序思路清奇就额外加分。

4. 常见问题速查：判题规则与“基础计算题卡分”对应表

为了方便你以后排查类似问题，我把常见现象、可能的评测状态、背后原因和处理方案整理成一张表：

你再回看网上各种求助帖里的“一道基础计算题卡在 分”，九成以上都能在上面这张表里找到对应项。那些真正需要高深算法才能AC的题，反而不会有人单纯用“基础计算题”来描述。

做题时还有一个特别容易忽略的观察点：看OJ返回的“通过测试点个数”信息。有些OJ在WA时会告诉你“通过了N个测试点，错误在M号点”，如果M是最后一个或比较大的编号，那大概率是边界数据；如果M是中间的某个点，那也许是特殊规则数据，比如输入出现零、出现负数、出现很大或很小的数。有了这个信息，排查范围会进一步缩小。

5. 踩坑之后我养成的几个好习惯

最后一次次被卡分教训之后，我现在每写一道基础计算题，都会养成几个固定的习惯。第一个习惯是动手写代码之前先把题目的数据范围抄在注释里。别嫌麻烦，因为写代码写到一半，最容易忘了最初看到的范围限制，尤其是“a和b均为整数”这种容易被忽略的描述。抄下来后，选类型时就会自然而然地想到要不要long long。

第二个习惯是每次写完核心逻辑，立刻跑去构造三组极值数据来测：最小值、最大值和某个中间值。如果有负数输入，就把最小负数和零也测一遍。这套“打表测试”花不了几分钟，却能挡住大量本可以避免的WA。真到提交时，心里踏实很多。

第三个习惯是输出格式永远先看样例的最后一行。我会特别注意行尾有没有空格、最后一组数据之后有没有换行，而不是想当然地用循环里统一加分隔符的写法。如果是输出一组数组，通常我会用“判断是不是最后一个元素”来决定是否打印空格，而不是每个元素后都跟一个空格。

第四个习惯是遇到“卡在小分数”时，绝不连续反复提交同一份代码更不着急发帖抱怨。我会把本地测试和代码逐段审查当成必做流程，先看完错误信息，再确定最可疑的位置。如果连续排查两小时都没头绪，再考虑把题目背景、代码片段和已经尝试过的方法整理成帖子去求助。带着完整信息求助，别人帮你定位的速度会快很多，而不是甩一句“这题判题规则是不是有问题”等着别人来猜。

说回开头那个求助问题。其实很多所谓“判题规则问题”，最终查下来都是代码实力和细心程度的体现。判题系统本身是死板的，但也正因为死板，它给出的分数非常诚实：通过了多少测试点，就拿多少分，不会冤枉你，也不会偏袒你。保持这个心态去面对卡分，你的水平反而会在一次次找bug的过程中提升得很快。