CSP 复赛考前 72 小时：六大隐性失分点排查指南

距离第二轮上机考试只剩最后三天。每年带队复盘时，最令人惋惜的从来不是难题不会做，而是走出考场时信心满满——“大样例全过了”，成绩公布却断崖式失分。原因往往并不复杂：官方大样例侧重基础逻辑覆盖，极少包含极限数值、多组测试的极端分布以及精心构造的边界数据。平时在本地环境能顺利跑通的代码，一旦放到正式评测机的严格编译选项与极限数据下，那些潜伏已久的问题便会集中爆发。

考前最后三天，不建议再硬啃新算法。花一个晚上系统排查以下六类代码隐患与交卷规范，性价比远高于盲目刷题。

一、长整型溢出的两个隐蔽变体

看到数据范围达到 10^18，多数选手会记得声明 long long，但真正的陷阱往往藏在计算细节里。

中间截断溢出。 若 a 和 b 都是 int 类型，书写 ans = a * b; 时，编译器会先在 32 位整型寄存器中完成乘法，溢出截断之后才将结果赋给 ans。此时 ans 声明得再宽也无济于事。正确做法是显式提升运算类型：

ans = 1LL * a * b;   // 先将 a 提升为 long long，乘法在 64 位下进行

负数取模漏修正。 在包含减法的模运算中，直接写 (ans - x) % MOD 极易产生负值。C++ 的取模运算遵循”向零截断”规则，负数的取模结果仍为负。标准写法应当补正：

ans = ((ans - x) % MOD + MOD) % MOD;

这一行看似啰嗦，却是避免答案差之毫厘、谬以千里的关键。

二、多组测试数据中的清空退化

多组测试数据题目中，切忌在每组循环开头无脑写：

memset(head, 0, sizeof(head));

若题目给出 T ≤ 100000，且各组数据的 N 之和 ≤ 200000，单次清空是 O(N)。出题人若刻意构造大量小数据，全量重置会让总耗时退化为 O(T × N)，瞬间从满分变为超时零分。

正确做法是按当前测试点实际用到的长度 n，用循环按需重置：

for (int i = 1; i <= n; i++) head[i] = -1;

同时注意，清空范围要覆盖所有被修改过的辅助数组，避免上一组数据的残留污染下一组结果。

三、未初始化变量与非 void 函数缺返回值

本地环境与评测机在底层内存分配机制上存在本质差异，这一点在考前必须反复强调。

局部变量脏数据。 全局变量默认置零，而函数内部局部变量未赋初值时，在本地环境可能”凑巧”为 0，在评测机上却必定读取随机内存脏数据，导致答案错乱。养成声明即初始化的习惯，是最廉价的保险。

函数漏写 return。 非 void 函数在部分分支漏写 return，在评测机的严格编译模式下会触发未定义行为或运行时错误。考试时建议开启 -Wall 选项自查，编译器会逐行提示所有”控制流到达函数末尾”的警告。

四、数组越界与栈空间保护

下标越界。 从 1 开始计数的数组，若常量仅声明 const int N = 100000;，访问 a[N] 即越界。数组上限至少预留 5 至 10 个安全余量：

const int N = 100005;

大数组防爆栈。 函数内栈空间有限，局部定义大数组极易爆栈。凡是超过 1000 规模的数组，一律声明在全局区。这一条在递归深层调用时尤为致命——栈空间被大数组挤占后，递归深度稍大就会崩溃。

五、命名冲突：那些不能用的标识符

在包含 <bits/stdc++.h> 并使用 using namespace std; 时，以下单词严禁用作全局变量名：

• y1：与数学库中的贝塞尔函数冲突
• next：与标准库算法冲突
• hash、time、pipe：均与标准库符号冲突

这类冲突在本地编译时可能只是警告，但在评测机上可能直接导致编译错误或行为异常。命名时不妨加个前缀，如 myNext、curTime，以绝后患。

六、交卷前 15 分钟：强制停笔执行”三删三查”

最后十五分钟不要再改算法，严格执行以下检查清单：

三删：

1. 删除所有调试输出，包括 cout、printf 以及中间变量的打印语句
2. 删除所有注释掉的旧代码和临时测试文件
3. 删除所有本地文件读写操作，确认使用标准输入输出

三查：

1. 查文件名与输入输出格式是否与题目要求完全一致
2. 查数组大小、数据类型、取模修正是否覆盖所有边界
3. 查多组数据的清空逻辑与变量初始化是否完整

这十五分钟的收益，往往比多做一道题更高。

考场上的每一分都来之不易。算法能力决定上限，工程细节决定下限。守住下限，才能让真实水平完整地转化为最终成绩。