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

这种问题我一年能被问几十次——明明是道基础计算题，样例在本地跑得好好的，一提交就卡在 分，上不去。很多人第一反应是“判题系统是不是有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结果要会看“潜台词”

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