CSP第一题“重复局面”解题全解：哈希计数与字符串处理

说实话，看到“第30次CSP第一题——重复局面”这个标题，我第一反应是：这题又是来送分的。CSP认证的惯例大家都懂，第一题基本就是给全考场的人建立信心的，考察的东西翻来覆去就是字符串处理、哈希计数、简单模拟这几板斧。“重复局面”这个题名一听就透着一股“我很好拿分”的气息。

但我还是要泼一盆冷水：CSP第一题虽然简单，每年照样有人丢分。丢分的原因往往不是不会做，而是审题不细、边界没想清楚、代码实现里埋了雷。有些选手考完对答案觉得自己AC了，结果成绩出来只有70分、80分，回头一查，全是细节问题。

我这次就借着“重复局面”这道题，把CSP第一题这一类题目的解题思路完整拆一遍。从题面理解、核心考点的底层逻辑，到三种语言的工程实现对比，再到考场上的失分点和大坑，最后落到CSP整个“第一题命题套路”的总结上。不管是准备CSP认证的在校生，还是刚接触算法竞赛、想拿个证的初学者，这篇文章应该都能让你在遇到同类题目时心里更有底。

1. “重复局面”：题目到底在问什么

1.1 题面拆解：一个关于“局面”的计数问题

“重复局面”这题的基本场景是：在一个棋盘类游戏中（通常是8×8的国际象棋棋盘），每走一步之后会产生一个当前局面。给出若干步之后的所有局面记录，要求你统计每个局面在历史上出现过多少次，并按输入顺序输出每个局面到当前时刻为止的出现次数。

按CSP第一题的惯用数据范围，局面数量一般设到100组左右，每组局面是一个8×8的棋盘，棋盘上的字符集合比较有限（比如用字母表示棋子，用点表示空位）。输入形式是：先给一个整数n，表示总共有n个局面，然后依次输入n个8×8的棋盘状态，每个棋盘由8行字符串组成。

输出要求则很直接：对于每个局面，输出它从第1个局面到当前局面为止累计出现的次数。换句话说，第1个局面肯定输出1，第2个局面如果和第1个相同，输出2，否则输出1，以此类推。

这个题意听起来简单到不需要动脑子，但它的核心其实藏在一个很多人没仔细想的地方：局面如何判定重复。两个局面是否相同，不取决于你怎么走到的，也不取决于现在是第几步，只取决于当前棋盘上所有棋子的位置是否完全一致。这一点是整道题的题眼，也是后续所有解法的出发点。

1.2 为什么“当前状态”才是重复判定的唯一依据

CSP的题目描述里往往会把“重复局面”放到一个棋类对弈的大背景下。比如描述说“国际象棋每一步都产生一个局面，如果某个局面在此前已经出现过，则说明棋手可能正在重复走子”。但真正重要的不是棋类规则，而是对“重复”的定义：两个局面只要棋盘状态相同，就视为同一个局面。

这个“只看当前、不看历史”的判定逻辑，决定了本题的数据结构和算法方向。因为你不需要关心局面之间的转移关系、不需要记录路径、不需要构建状态图，只需要把每个局面当作一个独立对象，统计它在序列中的出现频率。这实际上是一个纯粹的“键值计数”问题。

很多初学者在读完题后会被“棋类”“局面”“重复”这些词误导，以为要用到搜索、递归、博弈树之类的东西。但CSP第一题永远不会那么复杂。只要你看穿了这层窗户纸，这道题就只剩下一个问题：怎么把一个8×8的棋盘编码成一个可以放进哈希表、字典里的键。

2. 核心考点拆解：为什么它配得上“第一题”的位置

2.1 棋盘序列化是隐藏的关键一步

C++里判断两个字符串相不相等，可以直接用==运算符，也可以用map来自动去重。Python里更简单，字典的键可以是一个字符串、一个元组，甚至一个不可变的自定义对象。所以在“重复局面”这道题里，最核心的工程技术其实就是棋盘序列化——把一个二维矩阵变成一维的、可哈希的键。

最直白的做法是把8行字符串逐行拼接成一个长度为64的字符串。比如一个局面拼出来形如"RNBQKBNRPPPPPPPP................................pppppppprnbqkbnr"，然后把这个字符串作为字典的键。这种方法简洁、直观、无歧义，两两不同局面不可能产生相同的拼接串。

另一种做法是把8个字符串组成一个元组（Python里的tuple），或者把字符数组直接作为键对象。元组的优势是保留了结构化信息，但比较起来未必比字符串更快。实际上在绝大多数情况下，64字符的字符串比较成本非常低，直接拼串完全够用。

这里还要提醒一点：有些同学会想到把棋盘内容做哈希映射，比如把每个字符映射成数字，然后算一个64位整数作为键。这在小范围局面下可行，但引入了哈希冲突的隐患。如果两个不同的局面恰好算出了相同的哈希值，你的答案就会错。虽然64位哈希冲突概率很低，但CSP这种题考的是100%正确，没必要为了所谓“效率”去承担这种理论风险。字符串直接当键，虽然内存开销稍大，但100%正确。

2.2 哈希表/字典的计数逻辑

序列化之后，题目的骨架就浮出水面了：

1. 读入n。
2. 初始化一个空的哈希表/字典，键是局面字符串，值是int计数。
3. 依次读入每个局面，序列化为键：
   • 如果键不存在，则计数置1。
   • 如果键已存在，则计数加1。
   • 输出当前计数。

整个流程不需要排序、不需要去重、不需要二分查找，一个哈希表就搞定了一切。时间复杂度是O(n × 64)，即每个局面都需要拼接一次字符串，然后做一次哈希查找和更新。n如果不超过100，那总操作量就是个位数千级别，几乎瞬间完成。

为什么CSP第一题特别偏爱这种“哈希计数”模式？因为哈希表是算法竞赛中最基础也最常用的数据结构之一，但很多人对它只是“会用”，并不理解它为什么快。哈希表通过一个哈希函数把键映射到数组下标，平均情况下查找和插入都是O(1)。这意味着无论局面总数是10个还是10000个，处理每个局面的成本都只和单个局面的规模有关，和数据总量基本无关。这个特性就是哈希表能在“重复局面”这类题目中发挥威力的根本原因。

2.3 复杂度分析：为什么这种做法是“最优”的

从理论上看，这道题的输入规模决定了几乎所有合理的解法都能通过。但理解复杂度分析的价值在于，它能帮你判断自己的解法是否安全，也能让你在答案解释和赛后复盘时有理论依据。

设局面数量为n，每个棋盘有8×8=64个格子，那么：

• 时间复杂度：序列化每个局面需要遍历所有64个格子，拼接字符串；哈希表插入/查询均摊O(1)。总复杂度O(n×64)。
• 空间复杂度：哈希表中最多存储n个键，每个键长度为64，总空间为O(n×64)。

这里的n在CSP真题里通常也就是100左右，复杂度完全不是瓶颈。换成更极限的数据规模，比如n=10000，仍然可以轻松跑过。所以这道题真正考察的并不是“你能不能优化到极致”，而是“你能否一眼识别出这是哈希计数问题，并用最简单可靠的方式实现出来”。

3. 三种主流解法的工程实现对比

3.1 Python版：字典是天然王牌

Python写这种题几乎是降维打击，因为字典原生支持字符串键，根本不需要额外设计。

python复制n = int(input())
count = {}
for _ in range(n):
    board = [input().strip() for _ in range(8)]
    key = ''.join(board)
    count[key] = count.get(key, 0) + 1
    print(count[key])

这里有几个小细节值得说一下。

第一，input().strip()的作用是去掉行尾的换行符，避免把\n也拼进键里。有些平台读入时行尾带有回车，不处理的话，同一个局面在不同行可能会因为末尾空白不同被判为不同键。虽然比赛数据通常比较规整，但自己在本地测试时很容易遇到这类问题。

第二，''.join(board)比循环里逐个字符追加要快，这是Python字符串拼接的经典优化点。如果写成key = ''; for row in board: key += row，在Python里会反复创建新字符串，虽然数据量小影响不大，但养成用join的习惯总没有坏处。

第三，count.get(key, 0)这个方法比if key in count再分支要简洁得多，而且在键不存在时直接返回默认值0，语义清晰。

Python版代码量最少，可读性最好，适合在CSP认证中追求快速、稳妥的选手。缺点是Python在大规模输入时比C++慢，但第一题根本遇不到这种压力，所以完全不用担心。

3.2 C++版：map与unordered_map的选择

C++写这题，核心选择在于用std::map还是std::unordered_map。这个选择是很多C++选手纠结的地方。

cpp复制#include <bits/stdc++.h>
using namespace std;

int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);

    int n;
    cin >> n;

    map<string, int> cnt;
    while (n--) {
        string board = "";
        for (int i = 0; i < 8; i++) {
            string row;
            cin >> row;
            board += row;
        }
        cnt[board]++;
        cout << cnt[board] << "\n";
    }
    return 0;
}

如果上面的代码用unordered_map<string, int>替代map，效果如何？

map底层是红黑树，键是按字典序排列的，插入和查询复杂度是O(log n)。unordered_map底层是哈希表，均摊O(1)。在n=100的规模下，两者的差距微乎其微，选哪个都能过。但如果从工程稳妥角度出发，我更推荐map。原因很实际：unordered_map的哈希函数需要保证稳定，C++标准库给string提供的哈希实现虽然没问题，但在极端情况下可能被哈希碰撞拖慢。而map的复杂度是有上限保证的，对竞赛这种“一定要求AC”的场景来说，确定性优先。

另外注意代码里的ios::sync_with_stdio(false); cin.tie(nullptr);。C++的iostream默认会和C标准IO同步，这导致输入输出偏慢。在CSP这种单点输入规模不算特别大的场景下，不写这两行也能过，但写上可以让IO性能提升一个档次，同时也有利于你在更严苛的数据规模下保持优势。

3.3 Java版：HashMap与字符串拼接的中庸路线

Java选手的思路和C++类似，选择HashMap<String, Integer>作为核心容器。

java复制import java.util.*;

public class Main {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int n = sc.nextInt();
        Map<String, Integer> cnt = new HashMap<>();
        for (int k = 0; k < n; k++) {
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i < 8; i++) {
                String row = sc.next();
                sb.append(row);
            }
            String key = sb.toString();
            cnt.put(key, cnt.getOrDefault(key, 0) + 1);
            System.out.println(cnt.get(key));
        }
        sc.close();
    }
}

Java这里最值得注意的点是StringBuilder的使用。很多人刚开始写Java字符串拼接时会直接用str += row，这在Java里会反复创建新对象，效率极低。虽然本题数据量小，但好的习惯是任何时候都用StringBuilder。此外，getOrDefault在Java 8之后才可用，CSP评测环境一般支持，安全起见也可以写成：

java复制int cur = cnt.containsKey(key) ? cnt.get(key) : 0;
cnt.put(key, cur + 1);

4. 考场中容易失分的细节与应对策略

4.1 棋盘读入的换行陷阱

这个问题在实际机考中非常常见：题目描述说的是“输入包含n行，每行由棋盘组成”，但棋盘本身是8×8的字符矩阵，你读入时如果用了cin >> row或input()，默认会跳过空白字符，所以换行符不会混入字符串。这倒是没什么问题。

容易出问题的是另一种场景：有些选手先读n，再用getline读行。getline在读完整数后，会把换行符留在缓冲区，导致第一行棋盘直接被读成空串。这个问题在C++里尤其危险。

我处理的方法是：要么老老实实用cin >> row这种直接跳过空白的读法，要么在getline之前手动消费掉残留的换行符。无论如何，不要在关键读入环节心存侥幸。

4.2 字符集与空位的处理

棋盘中的空格位在真实对局中可能用.表示，也可能用-表示，甚至有题目用空字符串占位。读入时一定要看清楚题目给定的字符集，别把空格和.搞混。

如果棋盘行字符串中包含空格（理论上8×8棋盘不会这样，但保不齐题目改格式），用input()读入会丢失空格后的内容。这时得用更底层的读法。不过按CSP惯例，棋盘行一般没有空格，这个问题出现的概率很低。

4.3 计数输出时机的选择

题目要求“按输入顺序输出每个局面的出现次数”，这要求你是边读边处理，还是读完后统一处理？

从逻辑上讲，两种都可以：你可以把所有局面存下来，先统一建立哈希表，再按顺序逐个查询输出；也可以边读入边统计边输出。但边读边处理明显更省内存，也避免了一次遍历的额外开销。更重要的是，它的代码结构和题目表述完全一致，不容易在输出顺序上出错。我推荐边读边处理。

4.4 自测用例的正确构造方式

考场时间有限，很多人写完代码不测就直接交，这是大忌。对于“重复局面”这种题，至少要构造三个自测用例：

• 全部局面都相同的极端情况（比如n=3，三个局面一模一样），预期输出是1、2、3。
• 全部局面都不同的极端情况（n=3，三个局面互不相同），预期输出是1、1、1。
• 相同局面不相邻的情况（比如局面A、B、A），预期输出是1、1、2。

这三个用例覆盖了计数的递增逻辑、重复判定的客观性、以及哈希表的累积效果。跑完这三个用例，代码的正确性基本就有保障了。

5. 从“重复局面”看CSP第一题的通用解法模式

5.1 近几次CSP第一题的命题套路归纳

如果你做过近几年的CSP真题，会发现第一题几乎都是“伪难题真水题”。

比如某次考的是“数组去重统计”，某次考的是“矩阵旋转后的坐标映射”，某次考的是“字符串按规则切分”。核心套路非常一致：

• 题目背景包装得很花哨，但真正的要求往往只有一句话。
• 需要你掌握某个基础数据结构（哈希表、数组、字符串处理）。
• 数据范围永远小到暴力都能过，但用正确的数据结构能让你写得更优雅。
• 难点不在算法，在于把题目描述“翻译”成代码。

拿“重复局面”来说，棋盘、棋类对弈、重复走子这些词汇的包装，迷惑性并不强，但它确实会让一部分新手分心，去想“是不是要记录棋子的状态机”“是不是要用搜索判断循环”。如果你能快速剥离背景，识别出“就是给字符串计数”，你就已经赢了大多数考生。

5.2 如何系统训练这类题

如果你是为了CSP认证准备第一题，我的建议是不要盲目刷难题。

第一题的难度天花板很低，它的价值在于帮助你熟悉比赛环境和基础语法。你可以这样练：

第一，把近五年的CSP真题第一题全部找出来，用三种语言各写一遍。写的过程中重点体会“输入格式”“字符串处理”“哈希表使用”这三板斧在不同语言里的实现差异。

第二，把每道题都尝试用尽可能多的解法解一遍。比如“重复局面”除了哈希表，还可以用排序后二分查找，或者用数组加布尔标记暴力统计。这些方法虽然不如哈希表优雅，但能帮你理解不同数据结构的适用场景。

第三，刻意练习“题面翻译”能力。拿到一道题，先用一句话概括它要求你做什么，再思考用什么数据结构，最后才是动手写代码。这个习惯一旦养成，CSP第一题对你来说就是纯送分。

5.3 一题多解的价值，远不止这道题本身

在“重复局面”里，我们用了哈希表。但如果我不用哈希表，把局面字符串放在一个动态数组里，每次出现新局面就遍历之前所有局面比较是否相同，这种暴力解法在n=100的规模下也能过，不过时间复杂度是O(n²×64)，也就是大约60万次操作。这让我不禁想到：很多时候，暴力解的代码量更小，容错率反而更高。

不过，理解哈希解法的意义不在这一道题，而在于它是一种心智模型。当你以后遇到更复杂的状态去重问题——比如搜索题里判断某个状态是否访问过，动态规划里的状态压缩，字符串处理里的模式匹配——你会发现，把“状态”序列化成“键”的思路是通用的。能把这个思路用到滚瓜烂熟，比死记硬背几十道题更有价值。

6. 代码之外：CSP考场上比AC更重要的几件事

讲到这里，很多人以为这篇文章要结束了。但作为一个参加过多次CSP认证的老选手，我非常清楚，真正的战场从来不只是在代码里。

6.1 先读全题，再写代码

CSP第一题虽然简单，但题目描述里偶尔会有一两句看似无关紧要的限定，比如“棋盘中的字符区分大小写”“输入中的空行不计入棋盘行数”。这些细节一旦忽略，轻则某个用例出错，重则整道题白写。我习惯的做法是：拿到题目后先花一分钟通读全题，把输入输出格式和边界条件画出来，再动手。第一题的题目通常不超过300字，这一分钟花得非常值。

6.2 提交之前，强制做一个“边界自检”

上考场时我有个强迫症：每道题写完，都会在提交前强行构造一个最大规模数据和一个小规模极端数据，测试一下程序是否正常运行。对于“重复局面”，最大规模就是n=100、局面全相同，验证输出是1到100的递推序列；最小规模就是n=1，验证输出是1。这种测试最多花两分钟，但能拦下一大半低级错误。

6.3 不要“恋战”第一题

CSP认证总共5道题，考试时间3个多小时。很多新手容易犯的毛病是在第一题上反复优化、反复纠结，总觉得自己还能写得更快更漂亮。其实第一题只要AC了，就果断往下一题走。你的目标不是把第一题写成艺术品，而是在有限时间内拿尽可能高的总分。把时间留给第二题、第三题，回报率要高得多。

说到底，“重复局面”真正教给我们的是：算法竞赛里最值钱的不是做难题的能力，而是稳定拿分的能力。把会做的题做到滴水不漏，把不会做的题留到有思路时再啃，这才是CSP认证的生存之道。