C++ OJ基础题解库：目录组织、对拍验证与训练系统改造

简介面向ACM入门与基础算法练习的北大POJ题解代码合集适合刚接触在线评测系统、正在刷题或准备课程实验与校赛选拔的学习者用于对照题目理解常见思路、输入输出格式和提交细节。压缩包共157个文件以156份cpp源码为主另附1个txt说明文件整体约59KB体积轻便便于按题号查找和本地编译调试。已有2654人学习表明其作为POJ基础题参考代码具有一定使用价值。内容覆盖从1000题段到3000题段的部分题目涉及输入输出处理、模拟枚举、排序查找、简单递推与动态规划等典型题型源码按题号组织方便与POJ原题逐一对应读者可观察变量命名、边界处理和代码结构在卡题时获得可运行的对照方案也可用于整理个人模板、复盘错因和补充基础算法练习题号跨度较大适合作为阶段练习的辅助参考。1. 从一份基础题解集说起谁该把它放进自己的本地仓库凌晨一点屏幕上一道看着不能再简单的多组输入题连续三次给出了 Wrong Answer翻来覆去检查逻辑最后发现只是循环条件写成了读一次就退出。这类基础题本身不难真正消耗人的是没有人告诉你「一份跑得通、能对拍、能手敲复现的参考实现长什么样」。这份资源就是干这个的某高校在线评测平台基础题库里一批入门题的解答代码以 C/C 为主按题号归档覆盖模拟、枚举、数论入门、二分、零一背包、字符串处理和高精度加减每道题配了样例输入输出。它适合三类人刚接触在线评测、还在和输入格式反复纠缠的新手想给自己攒一个本地题解库、以后随时翻查的中级选手以及要给新人做培训模板、需要一套可编译可回滚参考代码的团队。2. 目录与题单结构把散落的 main.cpp 组织成可检索的题库拿到这类题解集第一反应往往是直接打开某个 cpp 文件抄一段走人。但真要在本地长期用下去目录组织比单题代码重要得多因为你要找的是「那道关于二分答案的题」而不是「那个叫 1005.cpp 的文件」。这份资源的目录做了一件很朴素的事把每道题当成一个最小可运行单元而不是当成一个孤立文件。2.1 按题号切片不按算法归类题库的题号是稳定不变的而算法标签会随着你理解加深而变。同一道题新手觉得是模拟做熟了发现是贪心加前缀和等你再回头看它其实是道二分答案。如果目录按算法分类你会陷入无穷无尽的搬迁工作而且每搬一次就得同步改所有引用路径。按题号分段就省事得多四位题号天然有序1000-1099、1100-1199这样切段每段题量控制在几十道靠文件管理器都能秒定位。oj-basic-solutions/ ├── README.md # 总索引题号 - 一句话题意 - 算法标签 ├── tags.json # 算法标签映射供脚本生成分类视图 ├── templates/ │ ├── main.cpp # 带本地调试开关的空白模板 │ └── problem.md # 题面摘要模板 ├── tools/ │ ├── gen_index.py # 扫描目录生成 README 表格 │ ├── stress.sh # 对拍脚本 │ └── build_all.sh # 批量编译检查 ├── 1000-1099/ │ ├── 1001/ │ │ ├── main.cpp # 参考实现文件头有复杂度注释 │ │ ├── note.md # 思路备注踩过的坑写这里 │ │ ├── sample.in # 题面样例输入 │ │ └── sample.out # 题面样例输出 │ └── 1002/ └── 1100-1199/这套结构的核心是「一个题目目录 一个可独立编译验证的工程」。main.cpp负责实现sample.in与sample.out负责最小回归note.md负责记录当时为什么这么写。很多人抄完代码就把思路丢了三个月后回来看自己的代码像看天书加一个 note 文件能省掉大量重新推导的时间。注意templates/和tools/必须和题库目录平级不要塞进1000-1099里面。批量脚本一旦递归遍历题库目录会把模板文件也当成一道题去编译然后报一堆莫名其妙的错。2.2 双轨索引README 速查表加 tags.json 标签文件人读 README脚本读 JSON两者分工明确。README 里维护一张表题号、一句话题意、算法标签、时间复杂度和易错点各占一列滚动浏览时能在几十行内找到目标题型。tags.json 用机器友好的结构存同一份标签信息方便后续生成按算法分类的视图、统计各题型数量或者接进自己的训练计划脚本。题号一句话题意算法标签复杂度易错点1001多组输入求两数之和输入输出O(1)必须读到文件末尾1013判断素数并统计区间内个数数论、筛法O(n log log n)1 不是素数1056求最大的不超过给定值的可行解二分答案O(n log V)上下界含不含端点1088容量固定的背包取最大价值动态规划O(n·V)循环方向写反会变成完全背包tags.json的结构不用复杂一个题号对应一个标签数组就够{ 1001: [io, basic], 1013: [math, sieve], 1056: [binary-search, greedy-check], 1088: [dp, knapsack-01] }这里有个小设计值得学标签用英文短横线命名而不是中文。中文标签在终端里 grep 会因为编码和宽度问题排版错乱而英文标签能直接当命令行过滤参数用比如python tools/gen_index.py --tag dp就能只列出动态规划那批题。后面第 6 章改造成自己的训练系统时这个字段是最容易被复用的。2.3 每题一个可运行单元main.cpp 加样例文件加文件头注释参考实现的文件头值得单独说。这份资源里每份main.cpp开头都有一段固定格式的注释块写明题意、思路、时间复杂度和提交时踩过的坑。看着像形式主义实际用起来能救命尤其是你在考前突击复习或者给新人讲题的时候。// 题号1013 // 题意给定区间 [L, R]统计其中的素数个数多组数据。 // 思路埃氏筛预处理到最大上界前缀和 O(1) 回答每次询问。 // 复杂度预处理 O(MAX log log MAX)单次询问 O(1)。 // 坑点1 要单独标记为非素数上界取所有询问里的最大值不要每个询问重筛。配合sample.in与sample.out每道题都能用重定向做一次零成本的正确性验证不需要连平台。这是本地题解库相对在线提交最大的优势断网也能跑改一行立刻能验不用等判题队列。提示sample.out一定要从题面原样复制不要用自己程序的输出覆盖。用过自己输出当标准的题等于没验证。2.4 编译与本地运行一条 g 命令里的参数取舍跑起来只需要一行命令但参数怎么选有讲究。这份资源默认按 C17 标准编译开二级优化同时打开常用警告。开优化是为了让本地计时接近判题机否则你本地跑 0.9 秒以为稳了交上去 TLE 会很郁闷开警告是为了让「变量未初始化」「有符号无符号比较」这类问题在编译期暴露而不是在提交后变成一个没法复现的 WA。# 进入某道题的目录 cd 1000-1099/1013 # -stdc17 统一语言标准避免本地能过线上编译错误 # -O2 开二级优化让本地耗时更接近判题机 # -Wall -Wextra 打开常见警告提前暴露未初始化、类型比较问题 # -o main 输出可执行文件名 g -stdc17 -O2 -Wall -Wextra -o main main.cpp # 用样例做一次回归diff 无输出即为通过 ./main sample.in my.out diff -w sample.out my.out echo sample passeddiff -w里的-w忽略行尾空白差异这一条能过滤掉大量因为行末多一个空格导致的假报错。但如果题目明确要求严格格式就要去掉-w手查。本地调试时还有个常用技巧在代码里用条件编译控制文件重定向这样不用每次敲 sample.in同时又能保证提交的代码里不带文件读写。#include cstdio int main() { #ifndef ONLINE_JUDGE // 只有本地编译时才生效提交到判题机时 ONLINE_JUDGE 通常已被定义 freopen(sample.in, r, stdin); freopen(my.out, w, stdout); #endif int l, r; while (scanf(%d%d, l, r) 2) { // 这里换成真正的求解逻辑 printf(%d\n, l r); } return 0; }#ifndef ONLINE_JUDGE这一层保护很关键。判题机普遍会在编译时定义ONLINE_JUDGE宏用了这个开关本地写文件、线上读标准输入一份代码两处用不会因为忘删 freopen 而在线上读到空文件直接 WA。没有定义这个宏的平台也不是没办法编译时加-DONLINE_JUDGE手动模拟一次就能验证。3. 核心代码拆解五类基础题的通用骨架基础题的价值不在题目本身而在于它们覆盖了竞赛型输入输出的所有基础骨架。把下面五类代码吃透后面遇到的大多数入门题都只是换个外套。每段代码我都只保留骨架和一个真实可运行的求解函数注释里写清楚哪些地方是「换个条件就能复用」的插槽。3.1 输入层多组输入的三种写法与快速读入多组输入是新手第一个大坑。题目不告诉你多少组数据只告诉你「读到文件末尾」这时候循环条件写while (true)然后break或者只读一次都会挂。标准写法是判断读入函数的返回值。#include cstdio int main() { int a, b; // scanf 返回成功读入的变量个数读到 EOF 返回 -1循环自然结束 while (scanf(%d%d, a, b) 2) { printf(%d\n, a b); } return 0; }scanf的返回值等于成功赋值的变量个数这个特性是判断「输入是否结束」和「格式是否匹配」的统一手段。写成! EOF也能过但 2更严格如果中间混进了非法字符导致只读到一个数! EOF会让你带着未定义的b继续算下去输出一堆垃圾值。数据量大到百万级时scanf也开始吃力可以换成基于fread的读入。#include cstdio static const int BUF 1 16; static char buf[BUF]; static int pos 0, len 0; // 单字符读取缓冲区空了就补一次 inline int gc() { if (pos len) { len (int)fread(buf, 1, BUF, stdin); pos 0; if (len 0) return -1; // 真正的文件末尾 } return buf[pos]; } // 读入一个整数自动跳过非数字字符支持负号 inline int readInt() { int c gc(), x 0, sign 1; while (c ! - (c 0 || c 9)) { if (c -1) return 0; // 没有更多数据 c gc(); } if (c -) { sign -1; c gc(); } while (c 0 c 9) { x x * 10 (c - 0); c gc(); } return x * sign; }参数说明BUF取 2 的幂是为了让底层读取次数落在缓存友好的区间64KB 是常见折中pos和len分别是当前读到的位置和缓冲区有效长度两者相等说明需要补数据。注意readInt在数据耗尽时返回 0如果题目允许出现真实的 0需要额外用-1或布尔返回值区分结束这一点抄代码时最容易漏。3.2 数论层gcd、线性筛与快速幂三件套入门数论题九成落在三个函数上。这三个函数写熟了能省下大量现场推导的时间也避免了每次手写都出点小错的尴尬。#include vector using namespace std; // 辗转相除求最大公约数b 为 0 时 a 即为答案 long long gcd(long long a, long long b) { while (b) { long long t a % b; a b; b t; } return a; } // 线性筛每个合数只被它的最小质因子筛掉一次O(n) // is_comp[i] true 表示 i 是合数primes 按升序存放素数 void linearSieve(int n, vectorint primes, vectorchar is_comp) { is_comp.assign(n 1, 0); primes.clear(); for (int i 2; i n; i) { if (!is_comp[i]) primes.push_back(i); for (int p : primes) { if (1LL * i * p n) break; // 用 long long 防乘法溢出 is_comp[i * p] 1; if (i % p 0) break; // 保证只被最小质因子筛一次 } } } // 快速幂返回 (base^exp) % modmod 取 1 时直接返回 0 long long power(long long base, long long exp, long long mod) { if (mod 1) return 0; long long res 1 % mod; base % mod; while (exp 0) { if (exp 1) res res * base % mod; base base * base % mod; exp 1; } return res; }逻辑说明线性筛的精髓在if (i % p 0) break;这一句它保证了每个合数只在p等于自己最小质因子时被标记一次因此总复杂度是线性的比埃氏筛的O(n log log n)更快代价是多一点常数。参数上n是筛的上界开数组时记得比最大询问大一点边界差一是最常见的 RE 来源。快速幂里res初始化为1 % mod而不是1是为了处理mod 1这个退化情况base * base在模数接近1e9时会溢出int所以参数和中间量全部用long long。3.3 查找层整数二分的两套模板加二分答案二分写错的人比写对的人多原因基本集中在边界收缩的方向和mid的取整方式上。这份资源里统一用了两套模板分别对应「找第一个满足条件的位置」和「找最后一个满足条件的位置」不混用。// 模板一找区间 [lo, hi] 中第一个使 check 为真的位置 // 前提check 在区间上单调即 false...false true...true int lowerBound(int lo, int hi, bool (*check)(int)) { while (lo hi) { int mid lo (hi - lo) / 2; // 防溢出写法等价于 (lohi)/2 if (check(mid)) hi mid; // mid 可行答案在左半含 mid else lo mid 1; // mid 不可行答案在右半 } return lo; // 循环结束时 lo hi } // 模板二求最大可行值用于「答案是一个数值」的题型 // 例把 n 个数分成 k 段使每段和的最大值尽量小 long long minMaxSum(const vectorlong long a, int k) { long long lo 0, hi 0; for (long long x : a) { lo max(lo, x); hi x; } // 下界是单元素最大值 while (lo hi) { long long mid lo (hi - lo) / 2; int cnt 1; long long cur 0; for (long long x : a) { if (cur x mid) { cnt; cur x; } // 超出就切一段 else cur x; } if (cnt k) hi mid; // 段数够用说明上限可以再压 else lo mid 1; // 段数超了上限必须放宽 } return lo; }参数说明lo (hi - lo) / 2这种写法不是炫技lo和hi都接近2e9时lo hi会溢出成负数然后程序进入死循环或者数组越界本地的表现是卡住不动非常难查。二分答案这类题的check必须满足单调性也就是「上限放宽一定更容易切得出来」一旦题目不满足单调性二分出来的结果就是错的而且样例往往测不出来。注意二分的上下界要按题目值域取不要图省事写lo 0, hi 1e18。范围开太大不仅慢还可能让check内部出现乘积溢出把单调性破坏掉。3.4 规划层零一背包的一维滚动写法背包是入门动态规划的分水岭二维写法直观但容易在数据量大时超内存一维滚动是必须掌握的版本。它只有一处细节和二维不同就是内层循环的方向。#include vector #include algorithm using namespace std; // w[i] 为第 i 件物品重量v[i] 为价值cap 为背包容量 // 返回容量 cap 下能取得的最大总价值 int knapsack01(const vectorint w, const vectorint v, int cap) { vectorint dp(cap 1, 0); // dp[j]容量恰为 j 时的最大价值 int n (int)w.size(); for (int i 0; i n; i) { // 必须从大到小遍历保证 dp[j-w[i]] 用的是「上一轮」的状态 for (int j cap; j w[i]; --j) { dp[j] max(dp[j], dp[j - w[i]] v[i]); } } return dp[cap]; }逻辑说明内层倒序是这个算法唯一的玄学点。正序遍历时dp[j - w[i]]可能在本轮已经被更新过相当于同一件物品被拿了多次那就悄悄变成了完全背包答案一般比正确答案大样例小的看不出来数据一大就露馅。参数上dp数组大小是cap 1因为要访问下标cap如果题目要求「恰好装满」初始化要把dp[0]设为 0、其余设为负无穷这一点和「不超过容量」的版本不一样抄模板时务必看清楚题目问的是哪种。3.5 字符串层高精度加法的进位处理超过unsigned long long范围的整数运算在入门题库里通常只考加减和比较。高精度加法的骨架很短但进位和下标的处理稍微不留神就会错位。#include string #include algorithm using namespace std; // 支持非负整数的高精度加法返回结果的字符串形式 string addStrings(const string a, const string b) { string res; int i (int)a.size() - 1, j (int)b.size() - 1, carry 0; while (i 0 || j 0 || carry) { // carry 单独作为条件处理最高位进位 int sum carry; if (i 0) sum a[i--] - 0; if (j 0) sum b[j--] - 0; res.push_back(char(0 sum % 10)); carry sum / 10; } reverse(res.begin(), res.end()); // 结果是从低位往高位生成的 return res; }逻辑说明while条件里带上carry是必须的否则像99 1这种结果位数超过输入位数的用例会丢最高位。每次循环取出当前的数字字符并减0转成数值累加后取模得本位、整除得进位。res是按低位到高位顺序追加的最后统一反转比每次insert到头部要快一个数量级因为insert(begin())是线性移动。参数上没有特殊限制但要注意这个实现只处理非负整数题目要求负数时得先判符号再转成减法逻辑处理。4. 本地自测与对拍把提交结果从难以预测变成可复现在线提交最难受的一点是你看不到测试数据只能靠反馈结果反推问题。本地能把这件事做成闭环自己造数据、自己跑正解、自己比对一次排查就能定位到具体是哪类输入挂的。这一章的三段脚本都不长配好之后受益期很长。4.1 随机数据生成把边界值固定写进脚本造数据的脚本一定要用固定随机种子这样每次复现的都是同一批用例出了问题能重新跑出同样的输入。种子用一个环境变量传进去需要更大覆盖面时换种子批量跑。# gen.py生成一组测试数据用法 python gen.py seed case.in import random, sys seed int(sys.argv[1]) if len(sys.argv) 1 else 1 random.seed(seed) n random.randint(1, 200) # 数据规模随机覆盖小数据和中等数据 print(n) # 一半用例允许负数和小值专门覆盖边界 for _ in range(n): if random.random() 0.5: print(random.randint(-10, 10), end ) else: print(random.randint(-10**9, 10**9), end ) print()参数说明sys.argv[1]是种子不传时默认 1。数据规模上限刻意设成 200 而不是 100000因为对拍的目的不是压性能而是找逻辑错误小数据跑得快能在几秒内对拍上千轮。负数和小值按比例混进去是因为大量 bug 只在0、1、单元素、全负数这些边界上出现纯随机大数反而测不出来。真实使用时建议再加一段固定边界用例单独写死几个「全相同」「已排序」「只有一个元素」的输入文件。4.2 对拍暴力解法与参考实现互相验证对拍的核心思路是先写一个逻辑正确但复杂度很低的暴力解再拿它和你的优化解比对同一批输入。暴力解可以慢十倍百倍只要能覆盖小规模数据就行。#!/bin/bash # stress.sh循环对拍找到不一致就停下并保留现场 # 用法./stress.sh 轮数 ROUNDS${1:-500} for ((i1; iROUNDS; i)); do python3 gen.py $i case.in ./brute case.in out.brute # 暴力解 ./fast case.in out.fast # 待验证的优化解 # -w 忽略行尾空白避免格式差异造成误报 if ! diff -w -q out.brute out.fast /dev/null; then echo mismatch at seed$i cp case.in fail.in # 保留现场便于事后复现 diff -w out.brute out.fast | head -20 exit 1 fi done echo all ${ROUNDS} cases passed逻辑说明循环里把同一个种子喂给生成器先跑暴力解再跑待验证解diff -q静默比较不一致就立刻停下。关键在那句cp case.in fail.in一旦出错输入文件必须保住否则你只知道「有一组数据挂了」却不知道是哪组又得重跑一遍。diff | head -20只打印前二十行差异防止数据量很大时终端被刷屏。实际经验是五轮以内挂掉的通常是明显的边界问题五百轮都不挂的基本可以认为逻辑是对的。4.3 计时与内存本地估一遍会不会超限性能问题不能靠感觉。题面一般会给出时间限制和内存限制本地用系统计时工具跑一遍最大数据留出三到五倍余量再提交能避免大部分「逻辑没问题但过不了」的情况。# 生成一组最大规模数据 python3 gen_big.py big.in # /usr/bin/time 会输出真实耗时和峰值内存单位 KB /usr/bin/time -v ./fast big.in /dev/null 2 time.log grep -E Elapsed|Maximum resident time.log如果没有/usr/bin/time可以在代码里用clock()打点缺点是只能测 CPU 时间测不到内存。参数上Elapsed是墙钟时间判题机一般按这个算Maximum resident set size是峰值常驻内存比较时要把它换算成 MB 和题面限制对齐。留余量的原因很实际判题机通常是多实例并发跑的你的程序在本地独占 CPU 能过线上和别的提交抢核就可能超时。4.4 批量回归一次编译整个题库改动模板或者统一换编译器版本之后最怕的是某几道题悄悄编译不过。写个批量脚本扫一遍比一个个点开快得多。#!/bin/bash # build_all.sh编译题库中所有题目的 main.cpp统计失败数 fail0 for src in $(find . -path ./templates -prune -o -name main.cpp -print); do if ! g -stdc17 -O2 -Wall -o /tmp/a.out $src 2 /tmp/err.log; then echo [FAIL] $src head -5 /tmp/err.log # 只打前几行避免刷屏 fail$((fail1)) fi done echo failed: $fail exit $((fail 0))find里的-path ./templates -prune把模板目录排除掉这就是前面强调模板要平级存放的原因。退出码用失败数量决定好处是能直接挂到持续集成里编译失败时流水线变红而不是静默通过。5. 避坑与常见问题第一次提交就翻车的五个现场下面五条基本覆盖了基础题库里九成以上的非逻辑性错误。它们的共同点是本地看不出来、样例也测不出来只能靠事先知道。5.1 输入输出类本地过、提交 WA 或格式错误现象一样例跑出来一模一样提交却是 Wrong Answer。原因题目是多组输入代码只读了一次。样例文件里可能只有一组数据所以本地看不出问题。 解决把读入改成while (scanf(...) 2)或while (cin n)并且确认每组数据之间需要重置的全局变量计数器、数组标记都清空了。多组题的经典翻车是数组忘了清第二组数据继承了第一组的污染。现象二答案是 Presentation Error 或者直接被判格式错误。原因行末多了一个空格或者最后一组数据后面多打了一个空行。很多题对输出格式要求严格到字符级。 解决把输出写成「第一个元素不加分隔符之后每个元素前加分隔符」的形式不要写完元素再补分隔符。最后一个换行可以有但不要多打空行。// 正确做法先输出第一个后续元素前加分隔符 printf(%d, a[0]); for (int i 1; i n; i) printf( %d, a[i]); printf(\n);5.2 性能与类型类大数据超时、结果莫名变负现象三小数据飞快大数据超时。原因用了cin但没解除与 stdio 的同步或者用了endl频繁刷缓冲。 解决在main开头加两行解除同步的语句同时把endl全换成\n。这一条能带来几倍的差距是最廉价的优化。int main() { // 解除 cin 与 scanf 的同步并解绑让 cin 提速接近 scanf ios::sync_with_stdio(false); cin.tie(nullptr); int n; while (cin n) { cout n \n; // 用 \n 而不是 endl避免每次刷新缓冲 } return 0; }现象四答案在小数据上对大数据上变成负数或者一个离谱的小值。原因中间结果溢出。n * (n - 1) / 2这种组合数在n达到十万级时早就超出int范围了。 解决把参与乘法或求和的变量全部提升到long long并且注意先转型再乘而不是乘完再转。(long long)a * b是对的(long long)(a * b)是错的因为乘法已经在int里溢出过了。5.3 环境与编译类本地能过、线上编译报错现象五本地 GCC 编译通过提交后编译错误。原因用了平台不支持的标准版本或者扩展特性比如结构化绑定、auto推导的某些用法或者引用了没有包含的头文件本地能过是因为别的头文件间接包含进来了。 解决把所有用到的标准库头文件老老实实写全编译时加-stdc17显式指定标准。本地编译加上-Wall -Wextra能提前发现大部分可移植性问题。提示数组开多大按题目给的最大数据量乘二不要卡着开。多组数据的情况下全局数组忘记清空导致的错误极难排查建议统一写在每组数据开头的init()函数里。6. 二次开发把题解集改成自己的训练系统抄完代码就跑这份资源的价值只发挥了十分之一。它真正的用途是当作一个可编程的数据源往上加自己想要的能力。我改过最有用的一层是「按标签生成训练清单」给定一个标签和题目数量从tags.json里挑题生成一份 Markdown 清单并附上对应目录路径复习时直接照着清单过。# tools/make_plan.py按标签生成训练清单 import json, os, sys tag sys.argv[1] if len(sys.argv) 1 else dp limit int(sys.argv[2]) if len(sys.argv) 2 else 5 with open(tags.json, encodingutf-8) as f: tags json.load(f) # 按题号升序挑选保证清单顺序稳定方便对比每次训练的进度 picked [pid for pid, ts in sorted(tags.items()) if tag in ts][:limit] print(f# 训练清单{tag}{len(picked)} 题\n) for pid in picked: path next((p for p in os.listdir(.) if pid in p), .) print(f- [{pid}](./{path}/{pid}/) 见 note.md)参数说明第一个参数是标签名要和tags.json里的一致第二个参数控制清单长度。sorted保证每次生成的顺序不变这一点很重要如果顺序随机你就没法判断某道题是「这次新做的」还是「上次做过的」。做完清单之后再补一层进度记录把「已通过」「待复习」写回tags.json的扩展字段一个最小可用的训练系统就成型了。另一个值得加的改造是编译流水线。把 4.4 节的批量脚本接进版本管理每次提交前自动跑一遍编译加样例回归哪道题被改坏了立刻能发现。我自己还习惯加一条规则任何一道题的main.cpp改动必须同时在note.md里写一句改了什么、为什么改。看起来啰嗦但半年后回头看这两行笔记比代码本身更能帮你回忆当时的推导路径。验证改造是否有效的方法很朴素挑三道你完全确定答案的题用新流程从头跑一遍看生成的清单、编译结果、样例比对是否都符合预期。改造过程中最容易出问题的地方是路径拼接脚本在题库根目录跑得好好的换个工作目录就找不到tags.json所以路径尽量用相对于脚本位置的方式计算而不是相对于当前目录。这套题解集我用了很久最大的教训是不要相信「本地样例过了就没问题」这句话。样例是出题人给的安慰剂真正的验证来自自己造的数据和自己写的对拍。从那以后我每次改完一份参考实现都强制走一遍「造数据、对拍五百轮、跑一遍最大数据看耗时」的流程哪怕改的只是一行printf。这份资源的目录结构就是按这个习惯搭的照着用能省下不少重复劳动。需要的话按仓库根目录的 README 走一遍几分钟就能在本地跑起来。希望帮到你。本文还有配套的精品资源点击获取