洛谷图论刷题实战：最小环、反向建图与01BFS全解析

1. 整体选题思路与题目规划

3月18号这天我照例打开洛谷，本来只是想随便刷两道热题保持手感，结果一坐进去就是四个多小时。趁着记忆还热乎，把这次刷题的过程、踩过的坑、以及几道值得反复琢磨的题目整理出来。这篇东西适合正在备战算法竞赛的学生、准备机试的求职者，以及平时拿洛谷当“算法健身房”的自学党——不管你是刚开始接触图论，还是已经能稳定切绿题蓝题，这篇里应该都能找到点有用的东西。

先说说3.18这天我的选题策略。我给自己定的原则是：不盲目追新题，而是把几类常考、常出现、但每次做都容易出细节问题的题型串起来。具体选了三道主线题和一道附加题：P6175（最小环问题）、“寻找道路”（NOIP原题）、P11230（一道近期新增的综合图论题），外加一道Switch the Lamp On（双端队列BFS经典题）。为什么选这几道？因为它们的核心考点刚好覆盖了图论里最常被面试和竞赛翻牌子的四个方向：Floyd算法变体、反向建图与条件筛选、最短路与状态维护、01BFS。

很多人在洛谷刷题有个误区，上来就按难度从低到高挨着做，结果刷了几百道水题，遇到稍微综合一点的题还是不会。我的习惯是按题型模块刷，一个月集中攻一个方向，这个月我主攻图论，所以3.18的题目基本都是围绕最短路、最小环、01BFS展开。这样集中刷的好处很明显——同一个套路在不同题目里反复出现，你对它的理解会从“背模板”变成“真正懂它为什么这么写”。

除了选题，我还给自己定了一条硬性要求：每道题做出来之后，必须用至少两种方式实现一遍。比如P6175，我先是按常规思路用邻接矩阵的Floyd写法过了一遍，然后用Java又写了一遍，顺便测了测洛谷上Java和C++在时空限制下的表现差异。这也是为什么搜“洛谷如何切换编程语言”的人一直不少——语言差异在刷题里是真的会影响策略的。

2. 核心题目解析与实操细节

2.1 P6175 最小环问题：Floyd的隐藏用法

先聊P6175。这道题的核心是无向图最小环，也就是找出一条环，使得环上所有边的权值之和最小。很多人第一次看到这道题会想：直接枚举所有三元组判断能否构成三角形不就行了？但题目里的图不一定是完全图，边数也可以很大，枚举三元组是O(n³)但前提是你得有边能连，而且很多情况下图里根本没有三角形环，存在的是四环、五环甚至更长环，所以必须换思路。

P6175的正解是Floyd算法的一个经典变体。常规Floyd是求任意两点之间的最短路，但它的主循环其实暗藏了一个信息：当最外层循环枚举到第k个节点时，dp[i][j]存的是只经过编号不超过k-1的中间节点时，i到j的最短路径长度。利用这个性质，我们可以在更新dp[i][j]之前，先检查一下i、j、k三者能不能构成一个环。

具体来说，在Floyd最外层循环到k时，先枚举所有i < k和j < k且i不等于j的点对，此时mp[i][k]和mp[k][j]是直连边的权值，dp[i][j]是i到j经过k之前节点的最短路。那么mp[i][k] + dp[i][j] + mp[k][j]就可能是经过k点的一个环的权值。为什么？因为mp[i][k]是i到k的直连边，mp[k][j]是k到j的直连边，中间dp[i][j]是在k之前的节点里绕路，三者连起来就构成一个从i出发、经过k、然后回到i的闭环。每次取最小值，最后就是整个图的最小环。

我在实现时遇到一个坑：如果图存在重边，必须保留最小权值的边，否则dp更新会出错。另一个坑是初始化——dp数组对角线要置0，其他位置要置成INF，而且INF不能设成int的最大值，否则加法会溢出。我用的是0x3f3f3f3f，这个值在洛谷的题目里基本够用，两个0x3f3f3f3f加起来大约21亿，还没有溢出int上限。如果你用Java，这里更要小心，Java的int最大值是2147483647，两个接近最大值的数相加会溢出成负数，排查起来非常隐蔽。

2.2 寻找道路：反向建图的思想

再聊“寻找道路”。这道题是NOIP2014提高组的原题，题目要求从起点到终点找一条最短路，但有个限制条件：路径上每个点的所有出边指向的点，都必须能到达终点。换句话说，你要经过一个点，从它连出去的所有点都得“有路可走”，不能走到死胡同。

很多人第一次看到这个条件会懵，正面处理非常麻烦，因为你得边走边检查每个邻居能不能到终点。正确姿势是先反向建图，从终点出发做一次遍历，标记出所有能到达终点的点。然后原图中那些“出边指向了不可达点”的点，就要从候选路径里删掉。最后在剩下点组成的子图里跑最短路。

这个“反向建图”的思路很有代表性，洛谷上大量图论题都会用到。3.18这天我特意把反向建图相关的题目集中整理了一遍，发现其实核心就一句话：正向图走不通或者不好判断条件时，想想从终点往起点看会怎样。比如判断一个点能不能到终点，正向跑要n次DFS，反向从终点跑一次BFS就全解决了。这个思想在P8675这类树上问题里也有变体，树的遍历方向反过来往往会让状态转移简单很多。

实操上我建议用链式前向星而不是vector存图，尤其是点数在10万级别的题目。链式前向星在遍历所有出边时，缓存访问比vector连续性好，实测能快20%到30%。虽然写起来稍微麻烦点，但图论题刷多了之后，链式前向星应该是你默认的存图方式，vector只用来做备份或者特殊处理。

2.3 Switch the Lamp On：01BFS的思维转换

Switch the Lamp On是道很有意思的题，它考察的是01BFS——边权只有0和1的最短路问题。题目是这样的：有一个由斜线组成的网格，每条斜线可以看作一堵墙或者一扇门，你可以旋转它让门打开（代价1），也可以不旋转就通过（代价0）。问从左上角到右下角最少需要旋转多少次。

乍一看这题像是搜索迷宫，但关键的思维转换是：把旋转操作看成走一条权值为1的边，把直接通过看成走一条权值为0的边。这样问题就变成了01BFS，用双端队列deque来维护——权值为0的节点从队头入队，权值为1的从队尾入队，保证每个节点第一次出队时距离一定是最小的。这比Dijkstra快，因为不需要优先队列的log n复杂度，整体就是O(V+E)。

这里有个很经典的坑：在01BFS中，visited数组标记的时机不是入队时，而是出队时。如果入队就标记，后面可能有一条边权为0的路径到达同一个点，但你因为已经标记过而错过了更优解。我第一次写的时候就踩了这个坑，样例过了但提交全WA，排查了好久才发现是标记时机不对。

这类题在洛谷上有个特点，就是题目描述经常包装得很“花哨”，但剥开外壳后核心算法很朴素。所以刷题时别被题目故事吓到，先把约束条件提取出来，问自己三个问题：节点是什么？边是什么？边权怎么定义？ 想清楚这三个问题，再套合适的算法模板，基本就稳了。

2.4 P11230与P8675：新题带来的思路冲击

P11230是近期洛谷新增的一道综合题，题号里的“23”说明是2023年的新题。这类新题的特点是不会只考单一算法，经常是把图论和数据结构揉在一起。我做P11230的时候发现它其实是“最短路 + 线段树优化建图”的组合，这种题在你没接触过优化建图的时候会觉得无从下手，但一旦理解了“把每个区间抽象成虚拟节点、区间内所有点连向虚拟点、然后给虚拟点之间连边”的技巧，就会发现很多看似复杂的图论题本质都是同一套路。

P8675我最初拿到时以为是树的直径问题，后来仔细读题才发现涉及的是树上点对路径的统计，需要用到DFS序加树状数组。这类题目对思维深度的要求比纯模板题高得多，但也正是刷题最有价值的部分——把旧知识在新场景下组合起来，才是真正的能力提升。我的建议是遇到这种综合题时，不要急着看题解，给自己至少一个小时的独立思考时间，哪怕最后没做出来，中间的过程也值回票价。

3. 洛谷平台实操技巧与语言切换

3.1 如何切换编程语言：新手最容易忽略的设置

洛谷刷题时，很多人会在代码提交上栽跟头，尤其是语言选择这块。我见过不少人在题目页面直接点“提交答案”，结果语言默认是C++98，而代码里用了C++17的特性（比如结构化绑定、if带初始化），编译直接报错。在洛谷提交代码前，一定要确认页面右上角的语言下拉框已经选对版本。

具体操作是：进入题目页面，点击右上角的“提交”，在代码编辑器上方会有一个“语言”选项，点开下拉菜单就能看到C++98、C++11、C++14、C++17、Java8、Java11、Python3等选项。如果你是刷算法题，建议无脑选C++17，因为洛谷大部分题解、模板、数据结构的实现都是以C++为主，而且C++17的语法更现代，写起来舒服不少。如果你非要用Java，我建议选Java11以上版本，配套的JVM启动速度比Java8快，对时间限制紧的题目会友好一些。

我在3.18这天专门做了一组对比测试：同一道题，C++17提交耗时120ms，Java11提交耗时360ms，内存占用也差了一倍多。所以如果你是算法竞赛路线，C++是你的主语言没得跑；如果你是为了准备面试刷题，Java或Python都行，但要意识到同样的算法复杂度，不同语言的常数因子差距是实打实的，遇到时间限制卡得很死的题目，要么优化常数，要么换语言。

3.2 Java刷题的超时困境与对策

搜“java洛谷”的人很多，说明用Java刷洛谷的同学不在少数。我自己主力语言是Java和C++，这里分享几个Java刷题实战心得。首先是输入输出一定要用BufferedReader代替Scanner。Scanner虽然方便，但在数据量大的题目里常驻超时元凶。我见过太多Java代码算法没问题、就因为用了Scanner而被卡时间，换成BufferedReader之后直接AC。

其次是Java的栈帧开销比C++大，如果递归深度超过10万层，建议改成显式栈模拟，否则很容易爆栈。这个在“寻找道路”这类需要DFS的题里特别明显，我3.18做这题时第一次用递归DFS，小样例都过了，大样例直接StackOverflowError，后来改成BFS加队列才解决。

还有一个Java的隐藏坑是List的自动装箱。如果你用ArrayList存图，每次add和get都是Integer对象的装箱拆箱操作，在大数据量下会有明显的性能损耗。更极端的做法是用int[]数组加手动栈模拟邻接表，但那样写起来太痛苦，日常刷题用ArrayList就行，顶多在明显要超时的时候再优化。

3.3 洛谷团队系统与C++刷题的协作方式

洛谷的团队系统其实是个被很多人忽略的宝藏功能，尤其适合和同学、队友一起准备比赛。搜“洛谷团队系统c++”这个词条的人，估计是想知道怎么在团队里布置C++题目作业。创建团队的方式很简单：登录后点击页面顶部的“团队”入口，创建一个团队，然后把队友拉进去。团队主页上可以布置homework，这个功能在备赛阶段特别好用——你可以按知识点分布置题目，比如这周围绕“图论最短路”出5道题，下周换成“动态规划”，每道题队友提交后你能直接看到通过率和用时排名。

我自己用团队系统最大的感触是它可以量化每个人的刷题习惯。比如我发现自己每天晚上8点到10点的AC率明显高于凌晨，说明那个时候精神状态最好，所以后来就把难度高的题都留到这个时段刷。团队里另一个有用的功能是“题单”，你可以在题单里收录一系列题目并附上简短的说明，比零散地发给队友链接高效得多。如果你在准备区域赛或者校赛，强烈建议建一个团队，一个人刷题容易懈怠，有队友催着写题、互相对拍，效率完全不一样。

3.4 搜索用户与找题解的正确姿势

“洛谷搜索用户”这个热搜词很有意思，估计是有人想找特定大佬的账号看他们刷了什么题、代码怎么写。在洛谷首页顶部的搜索框里输入用户名，就能进入他的个人主页，能看到他的刷题记录、通过题数、最近的提交状态，甚至还能看到他在团队里的排名。这个功能用来“偷师”特别好用：你找一个水平比你高两档的大佬，看他近期过了哪些题，把这些题归入自己的题单，按他的节奏刷，比自己瞎刷效率高不少。

不过我看题解有个原则：至少独立思考半小时，才允许看题解。而且看题解不能只抄代码，要看它的状态定义、转移方程、边界条件，看完之后必须自己关掉题解，从头写一遍。这一步的核心是让你真正掌握思路而不是背代码。我3.18做P8675的时候就是这么干的，思考了40分钟没思路，看了题解的“DFS序 + 树状数组”提示之后恍然大悟，合上题解自己写，写了30分钟一次AC，那种成就感比直接抄答案爽太多了。

4. 动手实操：3.18刷题全流程复盘

4.1 刷题前的环境准备与节奏安排

刷题不是打开网页就开写，准备工作做得好，效率能提升一大截。我3.18的流程是这样的：早上先把洛谷的每日一题做了（一般是一道绿题难度），算是热身。然后上午10点开始正式刷P6175，中午休息前完成第一版代码。下午集中精力攻克“寻找道路”和P11230，晚上最后用Switch the Lamp On收尾。这样安排的核心原则是把最难的题放在自己精力最好的时段，而不是随缘打开什么刷什么。

环境上我用的是本地的VS Code加一个洛谷的提交插件，写完代码直接在插件里提交，不用复制粘贴到网页，整体流程顺很多。不过用什么编辑器其实无所谓，关键在于形成稳定的代码模板。我自己有个头文件模板，包含了常用的头文件、快读快写函数的封装、链式前向星的建图模板、并查集模板等等，每道题从这个模板开始写，能省不少重复劳动。模板不是让你直接无脑套用，而是减少键盘敲击的机械时间，让你把注意力放在算法本身上。

4.2 P6175完整代码实现与细节注释

直接上P6175的核心代码（C++17），我把容易踩坑的地方都加了注释：

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

const int MAXN = 105;
const int INF = 0x3f3f3f3f;

int mp[MAXN][MAXN];   // 存图，直接边权
int dp[MAXN][MAXN];   // Floyd最短路
int n, m;

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

    cin >> n >> m;
    memset(mp, 0x3f, sizeof(mp));
    memset(dp, 0x3f, sizeof(dp));

    for (int i = 1; i <= n; i++) {
        mp[i][i] = 0;
        dp[i][i] = 0;
    }

    for (int i = 0; i < m; i++) {
        int u, v, w;
        cin >> u >> v >> w;
        // 坑点：必须取最小值，因为可能存在重边
        mp[u][v] = min(mp[u][v], w);
        mp[v][u] = min(mp[v][u], w);
        dp[u][v] = min(dp[u][v], w);
        dp[v][u] = min(dp[v][u], w);
    }

    int ans = INF;

    // Floyd外层循环枚举中间点k
    for (int k = 1; k <= n; k++) {
        // 先尝试用k更新最小环
        // 此时dp[i][j]只经过编号 < k 的节点
        for (int i = 1; i < k; i++) {
            for (int j = i + 1; j < k; j++) {
                // i->k直接边 + k->j直接边 + i->j经过<k的最短路
                // 注意这里不能用dp[i][k]代替mp[i][k]，
                // 因为dp[i][k]可能已经被更新为非直接边
                if (mp[i][k] != INF && mp[k][j] != INF && dp[i][j] != INF) {
                    ans = min(ans, mp[i][k] + mp[k][j] + dp[i][j]);
                }
            }
        }

        // 正常的Floyd更新
        for (int i = 1; i <= n; i++) {
            if (dp[i][k] == INF) continue;
            for (int j = 1; j <= n; j++) {
                if (dp[k][j] == INF) continue;
                dp[i][j] = min(dp[i][j], dp[i][k] + dp[k][j]);
            }
        }
    }

    if (ans == INF)
        cout << "No solution." << endl;
    else
        cout << ans << endl;

    return 0;
}

这里最关键的注释点是：更新最小环时一定要用mp[i][k]和mp[k][j]，而不是dp[i][k]和dp[k][j]。因为dp[i][k]可能已经不是直连边了，它已经被前面若干轮Floyd更新成了经过其他中间点的最短路径，如果用它来构成环，路径会出现重复访问节点的情况，算出来的“环”不合法。这个坑是我之前刷最小环时反复WA才深刻体会到的，这次特意写进代码注释里。

4.3 “寻找道路”的建图与搜索实现细节

“寻找道路”这题的实现，我按三步走，完整流程分享出来：

第一步，读入图，同时存正向图和反向图两份邻接表。正向图用于最后跑最短路，反向图用于从终点反向遍历。这里我用了链式前向星，head数组和edge结构体各两份。

第二步，从终点出发，在反向图上BFS，标记出所有能到达终点的点。这个BFS就是标准的visited染色，复杂度O(n+m)。得到ok数组后，对每个点u做检查——遍历u的所有出边，如果有一条出边指向的v不ok，说明u不合法（因为从u走到v之后就再也到不了终点，题目不允许你经过这样的u）。标记为bad。

第三步，在原正向图上，把所有bad的点和终点做特殊处理，跑最短路（BFS即可，因为边权都是1，题目保证边权为1）。跑BFS时，如果一个点的邻居是bad，直接跳过，不加进队列。最终dist[终点]就是答案。

有一个细节需要单独说明：bad的点本身不能作为路径中间点，但如果你起点就是bad，其实直接输出-1就好了。还有，终点本身不算bad，因为它是可到达终点的（终点到终点距离为0）。这个边界条件要考虑清楚，不然最后BFS的时候把终点也排除了，结果一直输出-1。

4.4 01BFS实现与双端队列的选择

Switch the Lamp On的01BFS，我用deque实现，这里把核心思路展开一下。由于每个格子有四条边四个方向，我建图的时候把每个格子的四个角当成节点，边权由格子的斜线方向决定。如果旋转代价为0（斜线方向和行进方向一致），就把这条边权标0，否则标1。

代码结构上，我维护一个deque<pair<int,int>>，起点入队时距离置0。每次从队头弹出节点，遍历四个方向，如果通过边权为0，距离不变，从队头压入；如果边权为1，距离加1，从队尾压入。距离存一个dist二维数组，初始化为INF。第一次从队头弹出某节点时，dist就是它的最短路，此时可以continue掉后续重复访问。

这里我特别想强调一个问题：很多人会同时维护dist数组和visited数组，其实01BFS里只要有dist数组就够了，访问到节点时如果当前距离大于等于dist[u]，直接跳过。如果加了visited数组并且入队时标记，就可能错失更优的0权路径。这是我之前做题踩过的坑，写在这里给大家提个醒。

4.5 一次提交失败的定位与修复过程

3.18这天我也有翻车的时候。做P11230的时候，我第一版提交直接WA了一半。当时看到“答案错误”的第一反应不是看测试数据提示，而是回去重新读题，发现题目里有一个要求被我忽略了：图上某些点必须经过，且经过顺序有约束。我最初的思路只考虑了最短路，没有处理点必须经过的约束，所以错了。

定位到这个原因后，我把状态从dist[u]改成了dist[u][mask]，其中mask是经过点的二进制集合，成了一个状态压缩最短路问题。复杂度从O(V log V)变成了O(2^k * V log V)，k是必须经过的点数，这题k只有3，所以还是能过的。改完之后重新提交，一次AC。

这个过程的收获是：提交失败时不要急着看题解，先回头读题。WA的原因往往不是代码细节写错了，而是题意理解有偏差。如果确认题意理解无误，再检查边界条件、数据范围、初始化这些点位。我有个习惯，每次WA就先花5分钟读题，再花5分钟检查边界，最后才去看测试数据，这个流程帮我省下了大量无效时间。

5. 常见问题与排查技巧实录

5.1 洛谷刷题高频问题速查表

这一节把我在洛谷刷题过程中反复遇到的问题整理成一张速查表，按频率从高到低排列：

这张表是我3.18刷完题当天整理的，每一条都是真实踩过的坑，不是网上抄来的经验。尤其是Java的Scanner问题，我见过太多萌新在洛谷上被这个坑反复折磨，其实换BufferedReader就三行代码的事，但很多题解里根本不会提这个。

5.2 一道题反复提交不过的排查路径

如果你提交一个题目反复不过，我建议按下面的路径排查，而不是盲目改代码：

1. 先确认是不是题意读错了。洛谷很多题目的故事背景写得又臭又长，真正条件就藏在输入输出格式里。3.18我做寻找道路时一开始忽略了“所有出边指向的点都必须能到达终点”中的“所有”两个字，导致错误理解成“至少有一条出边指向可达点”，排查了半天才发现是这里的理解偏差。

2. 检查边界情况。n=1、m=0、图不连通、起终点相同这些极端case往往是你WA的根源。写代码前先在草稿纸上手动模拟一遍n=1的情况，很多问题当场就暴露了。

3. 换一组数据自测。如果小样例过了但提交WA，自己构造几个边界数据来测。我在P6175上就构造了一个只有两个点一条边的图，结果发现我的代码会输出错误路径而不是“No solution.”，问题出在初始化时mp[1][1]=0导致自环误判。

4. 对比测试。如果实在找不到问题，可以找一个这题AC的代码，把你的代码和它的代码对拍。洛谷题解区里每一题都有多份代码，构造随机数据、跑对拍器，一般几万组数据跑完就能定位到出错的case。

这个排查路径看起来没什么技术含量，但实际刷题时非常管用。与其盲目提交被罚次数，不如静下心来把每个环节都检查一遍。毕竟洛谷是有提交次数限制和罚时的，反复提交失败会影响你在团队里的排名和信心。

5.3 内存超限的几种隐蔽原因

内存超限（MLE）也是洛谷刷题的高频问题，表现很隐蔽。第一种是开数组时INF初始化误用了memset。memset按字节填充，如果你对int数组memset(dp, 0x3f, sizeof(dp))，会把每个int填成0x3f3f3f3f这没问题，但如果你用0x7f，每个int会变成0x7f7f7f7f，两者都能用，但0x7f7f7f7f更大，加法溢出风险更高。所以INF的选择不仅影响正确性，也影响你是否敢加大数组。

第二种是Java的HashMap使用过度。如果你在算法里频繁使用HashMap存储键值对，而且键是long型的组合值，那内存消耗是惊人的。3.18我做P11230时第一版用HashMap存状态，结果runtime memory飙到500MB，后来改成int数组下标映射，内存直接降到80MB。洛谷的内存限制一般是128MB或256MB，如果你的算法需要大量键值对，优先考虑用数组加离散化，而不是Hash容器。

第三种是递归栈空间。C++默认的栈空间在Linux上是8MB，如果递归深度超过几十万层，会导致栈溢出，这不算MLE但表现很像。很多图论题的点数达到10^5级别，DFS深度也达到10^5，这时候要么加栈空间指令（某些OJ支持），要么改成迭代式。

5.4 对拍器：自己动手做数据验证

对拍是刷题到进阶阶段必须掌握的技巧，尤其适合在洛谷这种OJ上练习时使用。原理很简单：你有两份代码，一份是暴力解法（保证正确但可能慢），一份是优化解法（可能是你的正解），然后用随机数据生成器跑多组数据，比对两份代码的输出是否一致。如果不一致，就说明优化解法有bug，而那组随机数据就是导致bug的样例。

对拍器写起来不复杂，就是三个脚本：数据生成器（随机生成符合题意的输入）、暴力程序（用最朴素的方式实现正确逻辑）、你的正解程序。3.18晚上我刷完四道主菜之后，又用对拍器验证了一遍P6175的正解和暴力枚举最小环的代码，跑了5000组随机数据，全通过，这才放心把最终版提交上去。这个过程虽然费时，但对训练算法严谨性帮助极大——毕竟竞赛里WA一次罚时20分钟，因为一个边界条件没处理而罚时是最亏的。

6. 感受与下一步计划

3.18这一天的洛谷刷题让我重新确认了几件事。第一，图论刷题不要贪多，一天四道题足够了，但每道题要真正吃透，而不是AC完就扔。我现在每道题AC之后还会想一个问题：如果把题目的某个条件改一下，解法会怎么变？这个问题往往比题目本身更有价值。比如P6175如果改成有向图最小环，Floyd的更新顺序就需要调整；寻找道路如果允许多次经过同一点，那就要换成分层图最短路来做。这种“一题多问”的训练方式，是提升算法思维最扎实的路径。

第二，平台工具用得好，刷题效率能翻倍。洛谷的团队系统、题单功能、用户搜索，都是帮你更高效刷题的工具，但前提是你要真的有计划地使用它们，而不是拿它们当作刷社交动态的替代品。3.18我建了一个“图论专题”题单，接下来一周都会往里加题，预计把最小环、割点、桥、拓扑排序、差分约束这些图论子专题全部覆盖一遍。

第三，编程语言的选择要结合实际目标。如果你还在读高中、目标是信息学竞赛，C++是唯一选择，不用犹豫。如果你已经上大学、目标是找开发岗，用Java或Python刷题完全可以，但一定要清楚自己语言的常数劣势，提前做好输入输出优化。我自己的习惯是双修——正式比赛用C++，面试刷题用Java，两者互相印证，对算法本身的理解反而更深刻。

最后想分享一个关于刷题时长的建议。我见过很多人每天在洛谷“打卡”五六个小时，但实际上有效学习时间可能不到两小时，中间全在刷手机发呆。我自己的节奏是：每天保证两小时高质量刷题，其中至少一小时是完全专注地思考题目，不看题解、不聊天、不切网页。状态好的时候可以延长到三小时，但超过三小时之后效率陡降，再做新题反而会打击信心。这3.18这天的四小时算一个例外，因为遇到P11230这种特别有挑战性的题，整个人处于心流状态，感觉不到累，但我不建议把这当成日常节奏。

下次我准备开一个新专题，专门整理洛谷上那些“题面花哨但内核经典”的题目，有兴趣的同学可以关注我洛谷账号，互相学习交流。