ACC-C++组初赛全攻略：考点拆解、备赛清单与赛场实战复盘

ACC编程竞赛的C++组初赛，这周末刚结束。说句实话，我赛前预判偏乐观了，总觉得初赛题目再难也有个度，结果真正坐下来三个小时，才意识到这类比赛考验的不是"会不会做"，而是"在有限时间内能不能稳定做出来"。没准备的选手到第二题就开始卡壳，有准备的选手则能按部就班拿分——差距就是这样拉开的。

这篇文章不搞泛泛的经验之谈，我把ACC-C++组初赛的考点拆解、备赛清单、赛场操作细节和踩坑复盘完整记录下来。不管你是明年打算参赛的新手，还是已经报名、想认真冲一把的选手，应该都能从这里找到有用的东西。

1. 初赛到底在考什么：从赛题倒推考点分布

1.1 初赛的定位：基础扎实度筛选

先给没接触过ACC的朋友介绍一下背景。ACC是一个面向在校学生的算法编程竞赛，按语言分成多个组别，C++组是报名人数最多、竞争也最激烈的一组。初赛是整个赛程的第一道门槛，它的核心任务不是选拔"天才型选手"，而是筛掉基础不牢、代码习惯差、遇事不冷静的参赛者。

这就决定了初赛的命题风格：绝大多数题目都能用C++基础语法和经典算法解决，不会故意出偏题怪题，但在数据范围、边界条件、时间限制上埋了不少"陷阱"。换句话说，题目本身不难，难的是在赛场上那三个小时里，你能不能保持清醒，把每道题该拿的分都稳稳拿到。

我在考场上观察到一个现象：提前交卷的人很少，几乎所有人都坐满了三个小时。这侧面说明初赛的区分度是够的——就算你只差一个细节没考虑周全，也可能卡在某个用例上半天不AC。

1.2 题型结构与分值布局

ACC-C++组初赛的题型一般分为三个部分，总分100分，考试时长180分钟。不同年份可能略有调整，但整体框架比较稳定：

单选题很容易被轻视，但其实它是初赛里性价比最高的部分。C++的语法细节，比如std::vector扩容机制、引用与指针的区别、auto的类型推导规则、运算符优先级，这些都是选择题的常客。这类题不需要你写完整代码，但需要你对C++的语言特性有准确的理解，不能靠"跑一下试试"来蒙。

代码填空题则是把一道经典算法题目挖掉几个关键位置让你补上。比如归并排序的合并段、DFS的递归出口、二分查找的区间收缩逻辑。这种题对"模板熟练度"要求很高，如果你平时习惯了复制粘贴模板而不理解每一行在干什么，题目稍微挖一个不显眼的空，你就露馅了。

编程题是重头戏，总分60分，基本决定了你能不能晋级。题目难度分布通常是：第1题送分（约15分）、第2-3题中等（各15分左右）、第4题压轴（15分左右）。能不能进复赛，往往就看你在中等题上稳定发挥了多少。

1.3 C++语言层面的高频考点

根据我做过的历年真题和我自己参加这届的感受，C++组初赛的语言考点集中在以下几个方向：

第一是STL容器。vector、map、set、unordered_map、stack、queue、priority_queue，这七个容器覆盖了90%以上的使用场景。初赛最常考的是它们的底层机制和适用场景，比如map底层是红黑树、插入和查找都是O(log n)，unordered_map底层是哈希表、平均O(1)但最坏会退化；priority_queue默认是大根堆，想用小根堆需要传greater<T>作为比较器。这些细节不是"背下来就行"，而是要在写题时形成条件反射，看到数据量和操作类型就能立刻判断该用哪个容器。

第二是基础语法细节。这里我踩过一个坑：int和long long的混用。当时一道题的数据范围是n <= 10^5，每个值在10^9量级，求和很容易超出32位整型范围。如果涉及乘法，更是直接溢出。所以只要题面没有明确说"保证在int范围内"，我会直接用long long，养成习惯比事后排查代价小得多。

第三是C++11/14/17的常用特性。初赛不像工程开发那样要求你写出优雅的现代C++代码，但lambda表达式、auto、using别名、std::function等特性，在写排序比较器、递归函数参数时非常省事。判题环境一般支持C++17，所以auto和lambda可以放心用。

1.4 算法层面的高频考点与复杂度估算

算法层面，初赛的考点比复赛要"亲民"很多，但并不意味着不考。我整理了一下这届以及之前几届的考点频率：

• 前缀和与差分：几乎是必考内容。区间求和、区间修改类题目的基础，实现简单但思路很有代表性。
• 二分答案：中等难度题的常客。看到"最大值最小"、"最小值最大"这类表述，第一反应就应该是二分。
• 双指针：合并有序数组、滑动窗口、链表中点，代码量小，但边界条件很容易写错。
• DFS/BFS：图论和树论的基础，迷宫问题、连通块数量、拓扑排序都是高频切入点。
• 简单DP：线性DP和背包问题最常见，状态定义比状态转移更考验能力。
• 栈和队列的应用：括号匹配、表达式求值、单调栈、循环队列。

一个关键能力是复杂度估算。初赛题目的时间限制通常是1秒，判题机每秒大约能执行10^8量级的运算。我常用的判断标准是：

• 如果n <= 10^5，O(n log n)的算法没问题，O(n^2)会超时；
• 如果n <= 10^3，O(n^2)可以接受，O(n^3)需要谨慎。

做题时先估算复杂度，再决定用什么算法，而不是凭感觉直接上手。这一条建议的价值我后面还会反复提到。

2. 备赛冲刺清单：C++组选手的考前准备

2.1 优先级排序：先把送分内容焊死

备赛最怕的是"什么都想学，什么都没学透"。以我自己的经验，初赛晋级只需要做好两件事：第一，把基础算法的模板写到肌肉记忆；第二，把历年真题的选择题和填空题吃透。

按优先级从高到低，我是这样安排的：

1. 输入输出与常用STL容器：cin/cout关同步、scanf/printf混用问题、vector/map/set的基本操作。这是所有题目的地基，优先级最高。
2. 排序与查找：sort的自定义比较器、二分查找的lower_bound/upper_bound的返回值语义、归并排序的分治思想。
3. 前缀和 / 差分 / 双指针：这三板斧能解决初赛中等题的40%以上，而且实现难度低、不容易写错。
4. DFS与BFS：图的存储方式（邻接表）、递归的实现细节、队列模拟BFS的层序逻辑。
5. 基础DP：线性DP和01背包，不需要碰太难的状态压缩和树形DP。
6. 贪心与数学题：排序后按某种策略取最优、最大公约数、快速幂、素数判断。

优先级的核心逻辑是：初赛编程题的第一题几乎都是送分题，必须保证100%拿满；第2-3题是中等难度，需要你用三板斧去拼；压轴题难，但拿一半分就能拉开差距。所以备考时，把精力重点放在前三个优先级上，比死磕压轴题性价比高得多。

2.2 模板沉淀：考前一个月该落笔的代码块

"模板"在这里不是指死记硬背的那些代码段，而是指你对一类问题的标准解法能达到"不假思索就能写出来"的程度。我建议你在考前一个月，把以下模板手写至少五遍，直到不需要停顿就能写完：

快速输入输出模板：

#include <bits/stdc++.h> using namespace std; int main() { ios::sync_with_stdio(false); cin.tie(nullptr); // 正片代码 return 0; }

这里有两个细节要讲清楚。ios::sync_with_stdio(false)的作用是取消C++的iostream与C标准IO的同步，不然cin比scanf慢很多，在数据量大的题里可能导致超时；cin.tie(nullptr)是解除cin和cout的绑定，避免每次输入前都强制刷新输出缓冲区。这两个操作合起来，能让cin/cout速度接近scanf/printf，但又保留了类型安全的优势。

二分查找模板：

int l = 0, r = n - 1; int ans = -1; while (l <= r) { int mid = (l + r) / 2; if (check(mid)) { ans = mid; l = mid + 1; // 查找右边界 } else { r = mid - 1; } }

二分模板必须自己理解边界条件再使用。写错常见的坑是死循环和越界，比如while (l < r)配合mid = (l + r + 1) / 2的上取整写法，如果没有配套使用，很容易在区间长度为2时死循环。

DFS基础模板：

void dfs(int u, int parent) { for (int v : graph[u]) { if (v == parent) continue; dfs(v, u); } }

DFS不要背网上花哨的写法，就写最简单的这个版本：遍历当前节点的所有邻接点，跳过父节点防止走回头路，然后递归处理子节点。初赛的图论题，90%都能用这个模板套。

2.3 本地环境与判题环境的差异：最容易忽略的一环

很多选手在本地编译运行都正常，一交上去就编译错误、运行时错误，问题往往出在环境差异上。

首先，编译器版本不同。本地可能用的新版GCC或MSVC，判题机可能只支持C++14或C++17。我在本地写#include <bits/stdc++.h>没问题，但如果判题环境不支持这个非标准头文件，就可能编译失败。更稳妥的做法是在代码开头老实列出需要的标准头文件：#include <iostream>、#include <vector>、#include <algorithm>等。虽然多写几行，但兼容性最好。

其次，数据输入的方式。判题机通常是从标准输入读取数据，而不是从文件读取。不要在代码里写freopen("input.txt", "r", stdin)这种本地调试语句，如果你真的需要它调试，提交前务必删掉。

最后一个容易被忽视的是内存限制。比如数组定义在函数内部会占用栈空间，一个int a[1000000]的局部数组大小约4MB，在某些判题环境下可能直接导致栈溢出。正确做法是把大型数组定义成全局变量，放在堆区或静态存储区。这个细节我当年就栽过一次，一个一维数组就能让程序在判题机上运行时崩溃。

3. 赛场实战全流程：从读题到AC的操作细节

3.1 开赛前15分钟与整体策略

ACC-C++组初赛一般提前15分钟开放考场，这段时间不是用来发呆的。我的做法是：先检查电脑上的编译环境是否正常，写一个最简单的Hello World程序跑一遍，确认编译器可用、输出无误。然后调好编辑器的显示设置，把字号、缩进、自动补全都调整到舒适状态。这些小事情在比赛开始后再做，纯属浪费宝贵的做题时间。

这一届初赛的编程题一共4道，难度梯度做得非常明显：

• 第1题是一个基础数学题，本质上就是求若干个数的最大值和次大值，属于给所有选手稳稳送分的题目；
• 第2题考了区间内某个目标值的出现次数，明显指向"前缀和+二分"的解法；
• 第3题是一个需要DFS遍历图节点、并统计路径中某个属性值数量的问题，中等偏上难度；
• 第4题是压轴题，考察线性DP加上一些优化技巧。

我的读题习惯是：先把4道题全部读一遍，花10分钟，然后按难度从低到高开始写。不要按题目顺序写。因为第一眼觉得简单的题，往往不一定真的简单，先把送分题解决掉，心理上就有底气，后面做中等题时不会因为着急而犯低级错误。

3.2 时间分配的具体安排

目标分数不一样，时间分配策略就不一样。如果你的目标是晋级复赛，我建议把精力分成几个阶段：

第一阶段（30分钟）：完成选择题和填空题。这部分分值固定、答案客观，做起来很快。选择题虽然每题只有几分的分值，但胜在它能快速进入状态，让你从"考场紧张"切换成"解题模式"。

第二阶段（50分钟）：解决编程题中的第1题和第2题。这两个题目代码实现量不大，只要思路清晰，一般20-30分钟就能AC一题。如果超过20分钟还卡在某一题上，我的原则是：先把这题能写的部分写上，拿到部分分，然后立刻跳到下一题。编程题通常有多个测试点，就算算法不够优，只要暴力解法能得到一部分分数，就先拿住，后面有时间再回头优化。

第三阶段（40分钟）：主攻第3题和第4题。这时耐心一定要足够，我见过很多选手不是不会做，而是写到一半发现样例没过，情绪一崩就全部GG。正确的做法是：每次提交失败后，冷静分析失败原因，是自己审题错了，还是边界条件没处理，还是算法复杂度不够。实在不行，就写暴力版本拿部分分，总比空着强。

留出最后10分钟：从头到尾检查一遍已经提交的题目，确认代码没有因为复制粘贴而留下脏数据，确认变量命名和类型没有低级错误，有条件的话，在本地重新跑一遍样例。

3.3 两道印象深刻的题目复盘

编程题第2题：区间查询问题

题目的大意是：给定一个长度为n的整数序列，有q次询问，每次询问区间[l, r]内某个值的个数。数据范围是n和q都在10^5级别。

这道题的关键在于，n和q都很大，如果每次询问都暴力遍历区间，复杂度是O(nq)，10^10的计算量必然超时。常见的解法是用前缀和，把每个值的位置信息存进多个有序数组，然后通过二分查找快速定位区间内的个数。具体来说，先遍历整个序列，把每个值出现的位置下标push_back到对应的vector里。对于每次询问，只需要在对应的vector里用lower_bound和upper_bound找到l和r之间的下标个数，复杂度降为O(log n)，整体是O((n + q) log n)，完美通过。

这道题让我印象深的地方是，数据范围给了很明显的暗示：n和q各10^5，就是告诉你不能写O(n^2)的暴力。学会了复杂度估算之后，这类题的正确解法几乎是条件反射地出现在脑子里。

编程题第3题：树上的路径统计

题目要求在一棵树上统计满足某种条件的路径数量。树上有n个节点，每个节点有一个属性值，路径的条件与这些属性值相关。

拿到题目先想到的是枚举所有路径，但n个节点的树路径数量是O(n^2)的，10^5个节点根本跑不完。正确思路是在DFS过程中维护一个全局的状态容器，利用回溯来保证路径的连续性。每次进入一个节点时，把当前节点的信息加入状态容器，递归遍历它的所有子节点，递归返回时再把这个节点的信息从容器中移除。这样，每个节点作为路径端点的情况都能被恰好遍历一次，整体复杂度是O(n log n)甚至O(n)。

这类题目的核心是理解"回溯"这个动作在DFS中的作用。我见过不少人写出"只加不减"的版本，结果状态容器里堆积了大量无关节点的信息，答案自然就不对了。画一个简单的三层树，手动模拟一遍DFS的执行流程，比死记代码强得多。

4. 常见问题与排查技巧：一场比赛的完整复盘

4.1 编译错误的三个经典场景

初赛赛场上，编译错误是最让人血压升高的错误类型，因为它的反馈很直接：屏幕上刷出一堆红色报错信息，心态不好的人当场就慌了。根据我多年参加竞赛和平时训练的经验，编译错误主要来自三个场景。

第一个是头文件拼写错误。iostream少了o、algorithm拼成algrithm、vector拼成verctor，这类问题在匆忙中很容易发生。解决的办法很简单：写代码时不要手动拼头文件名，直接用编辑器的自动补全功能，把出错概率降到零。

第二个是using namespace std;缺了分号或放在了函数内部。我在考场上亲眼看到一位选手把using namespace std;写在了main()函数的大括号后面，结果编译错误一片。using声明必须在代码的全局位置，至少在使用标准库函数之前。

第三个是数组长度用了变量，但编译器要求必须是常量表达式。比如int n; cin >> n; int arr[n];在标准C++里是不合法的（变长数组是C99的特性，C++标准不支持）。用vector<int> arr(n);解决，既避免了报错，还不用手动管理内存。

4.2 运行时错误的常见元凶

运行时错误（Runtime Error，简称RE）在判题信息里通常显示为"段错误"或"访问越界"。这种情况在编程题中非常常见，因为判题机的数据范围往往比样例更大。

我遇到过的RE，十有八九是数组越界引起的。比如，题目说节点编号从1到n，你开了vector<int> graph[n + 1]，但某次访问时下标写成了graph[n + 1]，越界了。又比如，二分查找的mid计算溢出：int mid = (l + r) / 2在l和r非常大时可能溢出，更安全的写法是int mid = l + (r - l) / 2。

还有个隐蔽的RE来源是递归深度过大。DFS如果递归调用到10^5层，栈空间不够就会爆栈，判题机显示RE而不是超时。解决办法有二：一是把递归改成显式栈的迭代写法；二是在能确保安全的情况下，用全局变量存储需要的大数组，减小每次函数调用的栈开销。

4.3 超时的排查思路

超时（Time Limit Exceeded，TLE）是我认为最有价值的错误信息，因为它明确告诉你：算法思路可能对了，但实现不够高效。排查超时，我有一套固定的流程：

先看数据范围，确认复杂度估算是否合理。如果题目n最大10^5，你写的是O(n^2)的嵌套循环，那TLE是必然的，无需怀疑是常数问题，直接改算法。

如果复杂度看起来没问题，比如已经是O(n log n)了，但依然超时，这时就要考虑常数优化。排名靠前的优化手段是：把cin/cout换成scanf/printf（或者确实做好IO同步设置）、把endl换成'\n'（因为endl会刷新缓冲区，很慢）、把传值改成传引用、把递归改成迭代、把函数调用内联到循环里。

最容易被忽略的是STL容器的高层操作的复杂度。比如用unordered_map没问题，但如果你在循环里反复调用count()和insert()，实际上每次操作都要计算哈希并可能触发内存分配，而手写一个简单的数组计数可能快很多。竞赛的核心不仅仅是算法正确，还要在限定时间内存活下来。

4.4 编程题常见问题速查表

4.5 赛前30分钟的最后检查清单

每次比赛出发前，我习惯在脑子里过一遍这个清单：

• 证件和竞赛账号信息是否带齐，账号密码是否确认无误；
• 是否已经打开自己常用的代码模板文件；
• 离线数据结构和常用算法模板的笔记是否备份在本地；
• 本地编译器能否正常编译一个测试程序；
• 是否记住了"变量名用英文、不用拼音"这类最基本的代码规范。

这个小清单看着琐碎，但我经历过账号密码记错、本地编译器配置出了问题、到了现场才发现忘了模板文件的情况。提前把这些都确认好，至少能保证你在起跑线上不输。

写在最后

ACC-C++组初赛这趟走下来，我最大的体会是：竞赛考的东西其实很朴素——基础算法熟练度、代码准确度、赛时心态，这三个要素缺一不可。很多人以为竞赛需要天赋异禀，但我看到的事实是，晋级选手大多是那些愿意把基础模板反复练到条件反射、把历年真题刷透、在赛前认真管理自己环境的人。

如果你也在准备明年的初赛，我的建议很直接：先把送分题焊死，再把中等题用三板斧打穿，最后才是压轴题的攻坚。这个过程没有捷径，但每个愿意静下心来反复调试代码的人，都能看到自己的进步。祝你在赛场上稳扎稳打，写出流畅的代码，拿到对得起自己努力的成绩。