脑袋被门夹得好痛前几天有个朋友甩给我一张截图，问：一道基础计算题卡在 分，本地试了十组数据全对，交上去就是上不去，判题规则是不是有问题？我看了眼他的提交记录，第一反应就是——这又来了。这个问题我在各个刷题群里见了不下几十次，每次都要从头解释一遍评测机的工作原理。今天干脆把这类"卡分"问题的排查思路完整写一篇，从判题规则的基本逻辑讲起，到具体怎么定位丢分原因，再到我自己的踩坑复盘。不管你是刚接触 OJ 的新手，还是被某道题卡到怀疑人生想骂评测系统的老刷题人，这篇都能给你一个相对完整的排查框架。
先给结论：判题规则本身出 bug 的概率极低，你卡在某个分数上，几乎一定是你的程序在某些测试点上没过，而不是评测机"看你不顺眼"。但这个结论背后的逻辑链挺长的，我们一点点拆。
1. 卡分的第一反应：大多数人都把"判题规则"当成了替罪羊
1.1 评测机的打分本质：不是"大体对"，而是"每个测试点都对"
很多人对在线评测的理解停留在"对就是对，错就是错"，这种二分思维在一些交互题或简单平台上成立，但在绝大多数 OJ 上，更准确的说法是：你的程序必须在评测机预设的若干个测试点上全部输出正确结果，才能拿到满分。
举个例子：一道题总分 100 分，评测数据分成 10 个测试点，每个测试点 10 分。你提交后如果只过了前 3 个点，得分就是 30 分。你本地随便造了几组数据跑一遍，全对，于是你觉得"程序没问题，是判题规则有问题"——但问题在于，你造的那几组数据，大概率覆盖的只是第 1 个或第 2 个测试点能覆盖的场景。
样例全过只能说明你拿到了"送分点"，后面那些测试点里的边界情况、大数据量、特殊输入，才是真正决定你能不能 AC 的关键。所以第一个要建立的认知是：评测机不会因为你"思路大体正确"就给你分，它只看每个测试点的输出是否与标准答案完全一致。
1.2 部分分的真正来源：数据点加权、子任务结算与 Special Judge
那"部分分"到底从哪来的？主要有三种机制。
第一种是数据点加权。每个测试点分值可能不同，简单的样例点可能只占 5 分或者 10 分，坑爹的数据点可能值 20 分甚至 30 分。你卡在某个分数，可能就是其中一个分值较高的测试点挂了。
第二种是子任务结算。这种在竞赛类平台非常常见：数据按数据范围分成几档，比如 1~3 号测试点 n ≤ 100，暴力就能过；4~6 号测试点 n ≤ 10^5，需要优化算法；7~10 号测试点 n ≤ 10^9，必须用数学公式 O(1) 出答案。你如果只写了暴力版本，那么恭喜你，你就是那个"卡在三十分"的人。这是基础计算题卡分最常见的原因之一，不是判题规则搞你，是题目设计者故意把数据分档，考察你能否根据数据范围选对做法。
第三种是 Special Judge。这类题型的判题规则比较特殊，不要求输出与标准答案逐字符一致，而是由一个特判程序检查你的输出是否在误差范围内。比如答案允许误差 1e-6，你的程序输出 3.1415926，标答是 3.1415927，也算对。但要注意，SPJ 通常只出现在浮点数精度题、构造题或方案验证题里，一道普通整数计算题大概率不会启用 SPJ，所以别指望它能救你。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 基础计算题里的隐藏杀手：越简单的题目，边界越要命
2.1 数据范围不是写着玩的：int 溢出、长整型与取模时机
我见过太多人死在"看起来很简单"的计算题上，原因不是算法不会，而是从头到尾没把数据范围当回事。
比如一道题告诉你 a 和 b 的范围都是 [-10^9, 10^9]，让你输出 a + b。你信心满满写了：
cpp复制#include <iostream>
using n