在算法竞赛（OI/ACM/LeetCode 等）中，评测机（Online Judge，简称 OJ）返回的状态码就是它与你沟通的“语言”。每一道题的 AC 背后，往往都垫着无数次的报错。

---

一、评测状态全景总结表

状态简称	英文全称	中文含义	核心原因	严重程度 / 心情
AC	Accepted	答案正确	代码逻辑、时间、空间全部完美契合题目要求。	🟢 完美！通关！
WA	Wrong Answer	答案错误	代码能跑通，但输出的结果跟标准答案对不上。	🔴 逻辑漏洞 / 细节没扣好
TLE	Time Limit Exceeded	运行超时	程序运行的时间超过了题目限制（通常是 1 秒或 2 秒）。	🟡 算法太慢 / 死循环
RE (RTE)	Runtime Error	运行错误	程序在运行过程中直接“崩溃”了（闪退）。	🟣 越界 / 危险操作
CE	Compile Error	编译错误	连翻译成机器码这一关都没过，直接被编译器拒绝。	🟤 语法错误 / 乱码
MLE	Memory Limit Exceeded	内存超限	程序申请的内存空间超过了题目限制（通常是 128MB 或 256MB）。	🟠 数组开得太大

---

二、终极排错与修改指南

当你在评测机上看到那刺眼的非 AC 状态时，请深呼吸，对照以下步骤逐一排查。

1. 遇到 WA (答案错误) 怎么改？

WA 是最折磨人的状态，因为评测机不会告诉你哪里算错了。

• 检查数据类型（十年 OI 一场空，不开 long long 见祖宗）：仔细看题目的数据范围，乘法累加、大数求和是否超出了 int 的上限（约 2 * 10^9）？如果是，果断把相关变量改为 long long。
• 检查多组测试数据清空：如果题目包含多组输入（while(cin >> n) 或 int T; cin >> T;），你的数组、计数器变量每次循环开头是否重新清零了？
• 检查极值与边界：手动测试几个极端情况。比如 N=0、N=1、甚至输入的数组全为负数、全为 0 的情况，看看你的程序有没有输出奇怪的值。
• 处理取模问题：题目如果要求“结果对 998244353 取模”，检查是不是每一步加法和乘法都取模了？减法是否使用了 (A - B + MOD) % MOD 防止出现负数？

2. 遇到 TLE (运行超时) 怎么改？

TLE 意味着你的代码“做得太慢了”，需要降维打击。

• 计算复杂度是否超标：C++ 一秒钟大概能执行 10 for 循环（O(N2) 计算量 10^10），必定超时。必须去想 O(N log N) 甚至 O(N) 的算法（比如前缀和、二分、双指针）。
• 检查死循环：在 while (l < r) 里面，l 和 r 的值是不是在某些情况下没有发生变化，导致永远跳不出循环？
• 解除 I/O 封印：有没有在 main 函数开头加上 ios::sync_with_stdio(false); cin.tie(0);？有没有把所有的 endl 换成 \n？（endl 会强制刷新缓冲区，导致输出极慢）。

3. 遇到 RE (运行错误) 怎么改？

RE 代表程序执行了非法的致命操作，被操作系统强行“击毙”。

• 数组越界（最常见）：你是不是访问了 a[-1]？或者题目 N <= 100000，你的数组只开了 int a[10000];？

规范做法：全局数组大小永远比题目给的最大值多开一点，比如 const int MAXN = 100005; int a[MAXN];。

• 除以零：检查你的代码里有没有 A / B 或 A % B，而此时 B 恰好等于 0 的情况。
• 爆栈（Stack Overflow）：如果你写了递归（DFS），是不是没有写终止条件 if (xxx) return;？导致函数无限嵌套撑爆了内存。

4. 遇到 CE (编译错误) 怎么改？

CE 最容易解决，因为下方一定会提供 Error Log（报错日志）。

• 迷途的字符（stray character）：不小心把全角中文逗号、中文空格或文字混入了代码逻辑区域。删掉重写即可。string>`。

5. 遇到 MLE (内存超限) 怎么改？

• 算算你开了多大数组：一个 int 占 4 字节。如果你开了一个二维数组 int dp[10000][10000]，它将吃掉 400MB 的内存！通常题目只给 128MB 或 256MB。
• 优化策略：使用“滚动数组”技巧降维，或者把不必要的大数组换成动态容器（但需评估时间常数）。

---

心法注释：
别把非 AC 状态当成失败，要把它们当成评测机给你发送的“侦查情报”。收到情报后，像外科医生一样，拿着上面的清单精准排雷。