1. 从“围观”到“提交”：我的Codeforces初体验心路
说实话，在点下“Register”按钮之前，我已经在Codeforces（简称CF）的题目列表和排行榜里“潜水”了好几年。看着那些动辄2000+、3000+的Rating，总觉得那是另一个世界的事情，自己那点刷LeetCode的“三脚猫功夫”实在拿不出手。这种心态，我相信很多和我一样的普通开发者都有——把CF视为算法竞赛的“圣地”，只敢远观，不敢亵玩。促使我迈出第一步的，其实是一次偶然看到的Codeforces Round 946 (Div. 3)的题目。Div.3是CF专门为新手和低分段选手设计的比赛，我看到Problem B的标题“The King and the Thief”，一个关于国王和小偷的博弈故事，描述竟然意外地有趣，不像想象中全是干巴巴的数学公式。那一刻我意识到，或许它并没有那么遥不可及。于是，在一个普通的周末晚上，我清空了桌面所有干扰，像准备一场重要考试一样，注册了我的第一场CF比赛——Round 946 (Div. 3)。这篇文章，就是记录下我从赛前焦虑到第一次成功提交（甚至AC）的全过程，包括那些新手必然会踩的坑，比如折磨无数人的“人机验证”问题，以及如何真正读懂一道CF题。
2. 赛前准备：远不止于打开浏览器
很多人以为参加一场线上编程比赛，就是到点打开网站开始做题。但我的实际体验告诉我，充分的赛前准备至少占了一半的成功率。这里的“准备”，不仅仅是心理建设，更是一系列具体、琐碎却至关重要的技术环节。
2.1 环境搭建与模板准备
CF的比赛环境是纯在线的，你只有一个内置的代码编辑器和一个提交按钮。但这不意味着你可以“裸奔”上场。我提前一个小时做的第一件事，就是准备好我的“代码模板”。这个模板包括：
- 常用头文件与宏定义：在C++中，
#include <bits/stdc++.h>（万能头文件）和using namespace std;是标配。我还预定义了ll作为long long的别名，因为CF的题目数据范围经常需要处理大整数，用int很容易溢出导致WA（错误答案）。 - 输入输出优化：对于C++，在需要读入大量数据时，
cin/cout可能会成为性能瓶颈。我的模板里加入了ios::sync_with_stdio(false); cin.tie(nullptr);这两行来关闭同步流，提升速度。虽然Div.3的数据量通常不大，但养成好习惯很重要。 - 调试打印宏：在本地调试时非常有用。我定义了一个
#ifdef LOCAL的宏，当在本地编译时，会启用debug(...)宏来打印变量；而在CF的在线环境（非LOCAL）下，这个宏则什么都不做，避免不必要的输出导致错误。
#include <bits/stdc++.h> using namespace std; typedef long long ll; #define debug(x) cerr << #x << " = " << (x) << endl int main() { ios::sync_with_stdio(false); cin.tie(nullptr); // 你的代码逻辑从这里开始 }把这些模板提前敲好并保存在一个顺手的地方（比如本地的一个文本文件），比赛开始时直接粘贴，能节省宝贵的几分钟，更重要的是减少因紧张而敲错基础代码的概率。
2.2 理解比赛规则与界面
CF的比赛通常持续2到2.5小时，包含5到8道题目，难度从A题最简单递增。Div.3的题目，A、B题通常比较直接，考察基本编程能力和思维；C题开始需要一些简单的算法（如贪心、二分）；D、E题可能涉及更典型的数据结构或算法。规则是“积分制”，每道题的首个正确提交时间决定了你的得分（罚时），提交错误会有20分钟的罚时。这意味着，盲目提交是大忌，必须尽量在本地或仔细思考确保逻辑正确后再提交。
我花了些时间熟悉界面：题目区域、提交区域、个人状态、排行榜。特别要注意的是“样例”（Sample Tests）。CF的题目都会提供样例输入和输出，这是你验证思路的第一道关卡。但千万要记住：样例过了不代表你的程序就对了，它只是最基本的情况。很多陷阱隐藏在样例之外，需要自己设计更多的边界用例（比如最小输入、最大输入、特殊值）进行测试。
3. 首战实录：与Problem B的搏斗
比赛开始后，我按照策略，先快速浏览所有题目的标题和大概意思。A题通常是个热身题，我决定先跳过，直接寻找我赛前有点印象的B题——“The King and the Thief”。
3.1 读题：一半的战役在理解题意
CF的题目描述往往是英文的，夹杂着一些故事背景。我的经验是，必须剥离故事外壳，抽象出数学模型。B题的故事大概是：国王和小偷在一条坐标轴上，国王可以移动，小偷也可以移动，有特定的规则问小偷是否总能逃脱。乍一看很复杂。
我静下心来，用笔在纸上画了一条数轴，把题目中的关键条件列出来：
- 初始位置：国王在
xK，小偷在xT。 - 移动规则：国王每次移动可以
+a,-a,+b,-b（a和b是给定的正整数）。小偷每次移动只能+d或-d。 - 目标：判断是否存在一种策略，使得小偷无论国王如何移动，都能永远不被国王抓到（即位置不重合）。
读到这里，我意识到这不是一个模拟题（去一步步模拟移动），而是一个数论/博弈题，核心是判断状态空间。我需要找到问题的本质。经过反复咀嚼“无论国王如何移动”这个条件，我猜想这可能和**最大公约数（GCD）**有关。因为国王和小偷的移动步长都是固定的，他们能到达的位置集合其实是初始位置加上步长整数倍的集合。如果小偷能到达的某个“安全集合”是国王永远无法到达的，那么小偷就安全了。
这个思考过程大约花了10分钟。对于新手来说，这10分钟可能毫无头绪甚至想放弃。我的心得是：不要死磕一句看不懂的英文。先抓主干（输入、输出、规则），忽略修饰性语句。如果5分钟内没有清晰思路，可以暂时标记，去看看A题或者C题的开头，换换脑子。很多时候，解决一道更简单的题目带来的信心，会帮助你回过头来理解难题。
3.2 构思与验证：从猜想到证明
基于GCD的猜想，我进行了更深入的分析。设国王的移动步长集合是{a, b}，小偷的步长是d。一个经典结论是：如果d不能被gcd(a, b)整除，那么小偷可能存在于一个与国王不同的“剩余类”中。但题目还有初始位置。我构造了几个小例子在纸上演算：
- 例1：a=2, b=4, d=3。gcd(2,4)=2。3不能被2整除。假设初始位置相差1。我发现无论国王怎么走，他的位置奇偶性总是和初始位置一致（因为步长都是偶数），而小偷走3步会改变奇偶性。似乎有戏。
- 例2：尝试更小的例子，手动模拟几步。
这里是一个关键技巧：对于博弈/数学题，如果无法直接证明，就尝试构造极端情况和反例。我试图构造一个国王一定能抓到小偷的情况。我发现，如果国王和小偷初始位置的差是gcd(a, b, d)的倍数，并且国王的步长集合能“覆盖”小偷的步长，那么国王似乎总能调整位置去逼近。
最终，我形成了一个尚不严谨但感觉可行的算法思路：计算g = gcd(a, b)。检查abs(xK - xT) % gcd(g, d) == 0是否成立？如果成立，则国王有可能抓到（输出某种结果），否则小偷永远安全。我需要根据题目要求的输出格式来定。
3.3 编码与本地测试
将思路转化为代码。我小心翼翼地实现gcd函数（C++有内置的__gcd，但我为了清晰自己写了一个）。核心逻辑只有几行：
int g = gcd(a, b); int diff = abs(xK - xT); if (diff % gcd(g, d) == 0) { cout << "YES\n"; // 假设输出YES表示国王能赢 } else { cout << "NO\n"; }然后就是至关重要的本地测试。我不仅测试了题目给的样例，还自己设计了多组测试数据：
- 边界情况：
a=1,b=1,d=1，初始位置相同或差1。 - 大数情况：用一些较大的质数。
- 随机生成一些数据，用一段暴力模拟的小程序（双循环枚举若干步）来验证我的算法结果是否与暴力结果一致。对于不确定的题目，写一个暴力枚举的“对拍器”是黄金法则，虽然它效率低不能提交，但能快速在小数据范围内验证你的逻辑是否正确。
经过约20分钟的调试和测试，我比较有信心了。于是，我准备提交人生中第一道CF题目。
4. 那些新手专属的“坑”：从提交到崩溃
就在我满怀信心地点开提交页面时，我遇到了传说中让无数新手崩溃的“人机验证”问题。这也是近期热搜词“codeforces人机验证一直过不了怎么”所反映的普遍困境。
4.1 人机验证（CAPTCHA）的终极解法
CF为了防止机器人滥用，提交代码时需要完成一个图形验证码。问题在于，这个验证码系统（特别是Cloudflare提供的）有时非常“反人类”：图片加载不出来、识别框点选不准、甚至无限循环要求验证。我当时的遭遇是：第一次验证，我明明按要求点选了红绿灯、自行车，却提示失败。刷新后，验证码图片直接无法加载，一片空白。
我的解决经过如下，这几乎是一个标准流程：
- 不要狂点刷新：这可能导致你的IP被暂时限制。
- 检查网络环境：这是最可能的原因。CF网站在国内访问有时不稳定。我尝试切换了网络连接（从WiFi切换到手机热点），情况立刻改善。如果你有稳定的、延迟较低的网络代理（注意：此处仅指优化网络路由的合法服务，用于提升访问速度与稳定性，完全符合相关规定），这会是一个好选择。
- 清除浏览器缓存和Cookie：特别是Cloudflare相关的Cookie。在浏览器设置中清除最近的历史记录。
- 使用浏览器无痕/隐私模式：这可以避免很多扩展插件和缓存的影响。
- 终极备用方案：如果比赛时间紧迫，上述方法都无效，可以尝试使用Codeforces官方的手机App进行提交。移动端有时验证流程不同，可能更顺畅。
我最终通过切换网络解决了问题。这个过程浪费了我将近5分钟，期间心跳加速，生怕比赛时间就此流逝。给新手的忠告：务必提前10-15分钟登录比赛页面，触发并完成一次人机验证，确保提交功能畅通。把这当作赛前检查清单的一项。
4.2 首次提交与等待判决
验证通过后，我选择了语言（GNU C++17），粘贴代码，屏住呼吸点击了“Submit”。页面跳转到“My Submissions”，状态显示为“In queue”。CF的评测是排队进行的，高峰期可能需要等待一两分钟。这几分钟是最煎熬的。你会不断刷新页面，脑子里反复回放代码，怀疑自己哪里有没有写long long，有没有处理负号。
终于，状态更新了——“Accepted”！
那个绿色的“AC”标志出现的那一刻，一种难以言喻的成就感涌了上来。虽然只是一道Div.3的B题，虽然Rating可能只加个位数，但那种跨越了从“观众”到“参与者”鸿沟的感觉，无比真实。我看了看时间，从读题到AC，用了约35分钟。在Div.3的节奏里，这不算快，但对我自己而言，是一个完美的开始。
5. 赛后复盘：比AC更重要的事
比赛结束后，我并没有立刻离开。复盘是进步的关键，尤其是对于新手。
5.1 阅读题解与学习更优解
我立刻去看了Problem B的官方题解（Editorial）以及其他高分选手的代码（在Status里筛选“Accepted”并按执行时间或代码长度排序）。我发现，我的思路基本正确，但官方题解给出了更简洁的数学表述：小偷安全的条件是abs(xK - xT) % gcd(a, b, d) != 0。我之前的gcd(g, d)其实等价于gcd(a, b, d)。学习这种简洁的数学表达能提升未来解题的速度。
更重要的是，我看到一些选手用更短的代码实现了相同逻辑，或者用了不同的判断方法。对比学习能开阔思路。
5.2 分析比赛数据与总结策略
我通过比赛页面的“Standings”查看自己的排名。虽然只做出一题，但在全球上万名参赛者中，我排在了前60%左右。这说明有很多人一题都没做出来，或者提交了多次错误答案导致罚时很高。我的“一次AC”策略在初期是有效的。
我也浏览了A、C题的题解。A题果然是个简单的语法题，我因为策略选择跳过了它，但实际上它应该是用来稳定心态和赚取保底分数的。新手策略建议：无论如何，先花5-10分钟尝试A题。快速拿到第一个AC能极大缓解紧张情绪。
5.3 建立个人的“错题本”
我将Problem B的题目链接、我的代码、官方题解链接以及我自己的解题思路（包括最初的错误猜想）记录到了一个笔记中。我特别标记了“核心模型：多维步长下的可达性与最大公约数”。这样，未来遇到类似“两个物体在数轴上按固定步长移动”的问题，我就能快速联想到这个模型。
6. 给未来新手参赛者的实用指南
基于我的第一次体验，我想给所有想尝试但还未敢尝试Codeforces的朋友一些具体建议：
6.1 赛前
- 心理建设：目标不是做出所有题，而是“做出至少一道题”或“比上次多做一个题”。把CF当作一个高质量的编程练习场，而不是考场。
- 技术准备：
- 固定你的编程语言和模板：不要临场换语言。C++是主流，Python在Div.3中也足够快。
- 熟悉在线IDE：CF自带编辑器功能有限。可以提前适应，或者准备好本地环境并练习快速复制粘贴。
- 解决网络问题：赛前测试登录、加载题目和提交功能，确保人机验证能通过。
- 知识储备：不必掌握所有高级算法。Div.3的A、B题通常只需要循环、判断、数组和基本数学（最大公约数、模运算）。掌握C题水平的贪心、二分查找、简单动态规划就能取得不错成绩。
6.2 赛中
- 时间分配：前10分钟通读所有题目，对难度有个排序。遵循“先易后难”原则，但也要敢于暂时跳过卡住的题。
- 调试技巧：
- 充分使用样例：但不止于样例。
- 自己构造小数据：特别是边界情况（最小值、最大值、相等、奇偶、正负）。
- 输出中间变量：在代码里加一些
cerr输出（用之前提到的调试宏），在本地运行时查看逻辑流。
- 提交策略：除非有绝对把握，否则不要在比赛最后几分钟狂交代码赚“侥幸分”。错误的提交会带来罚时，可能让你排名下降。一次深思熟虑的提交胜过五次盲目尝试。
6.3 赛后
- 无论结果如何，都看题解：这是学习最快的方式。理解每道题的标准解法，思考自己为何没想到。
- 参与社区讨论：在CF的题目评论区（“Comments”），经常有高手分享更巧妙的思路或指出题目的陷阱。
- 定期参与：不用每场都打，但可以定个小目标，比如每月参加一场Div.3。稳定性比突击更重要。
第一次参加Codeforces，就像第一次离开新手村进入一个广阔而真实的冒险地图。你会遭遇理解题意的障碍、思维上的瓶颈、工具上的麻烦（比如人机验证），也会收获独立解决问题的喜悦、看到绿色“AC”时的激动，以及意识到自己还有巨大进步空间的那种清醒。它不仅仅是一场比赛，更是一面镜子，清晰地照出你在解决问题、严谨编码、压力管理方面的真实水平。我的Rating起点很低，但这完全不重要。重要的是，我跨出了那一步，并且已经计划好了下一场。如果你也在犹豫，我的建议是：注册下一场Div.3，把它当作一次有趣的挑战。最坏的结果，无非是看到一堆“Wrong answer”，而这，正是我们学习旅程的起点。
