1. 为什么需要一个算法全家桶1.1 零散模板的三个老大难问题接触ACM也快六年了从最开始在OJ上刷水题到后来打区域赛、带队伍我花在“找模板”这件事上的时间可能比写代码本身还多。早些年我把模板散落在硬盘各个角落本地文件、博客、GitHub、各类集训队课件里真正需要的时候反而找不到最顺手的那份体验相当糟糕。后来我下决心做了一套“繁凡的ACM算法全家桶”核心目的只有一个把分散的、零乱的、质量参差不齐的代码沉淀成一套统一的、可直接提交、可快速检索的模板体系。零散模板的问题归纳起来其实就三类。第一类是版本混乱。同一个算法比如线段树我手里至少有四种写法指针版、结构体数组版、带lazy标记的区间修改版、还有专门用来处理扫描线的版本。每次比赛前我都在纠结到底带哪个代码文件深怕考场里临时改板子改出bug。第二类是缺少验证。很多模板是从课件或者别人博客里抄过来的看起来天衣无缝但放到真实数据上一跑就崩溢出的溢出、死循环的死循环。第三类是风格不统一。有人喜欢用宏定义有人喜欢用typedef变量命名也是五花八门。平时自己写题还不觉得可一旦要把几个模板拼接起来做综合题这种风格割裂带来的阅读成本就非常高了。所以我在启动全家桶计划的时候给自己立了几个非常明确的目标一是所有核心模板必须经过OJ实测保证能过题二是代码风格统一整个库读起来就像一个人写的三是每个模板自带使用说明和复杂度标注复习的时候不需要重新看一遍算法推导才能想起这是干什么用的。这段话算是我整个项目最核心的出发点后面所有工作都是围绕这三个目标展开的。1.2 全家桶的定位与设计目标这里要先说清楚“全家桶”并不是要把所有算法都塞进去。ACM的考察范围虽然广但真正在赛场上高频使用、值得整理成模板的算法其实是有限的。我给自己定了一个范围数据结构、图论、字符串、数学、动态规划、几何六个大类每类下面收录的都是“写熟了可以直接用”的代码而不是把OI Wiki上的内容全部复制一遍。设计目标上我参考了比较常见的ACM模板库的组织方式比如一些退役选手放出来的“xx爷模板”但针对自己的使用习惯做了一些调整。最重要的一点是“单文件可提交”。也就是说每个模板都是一个完整的C代码文件包含了所有需要的头文件和命名空间声明复制到在线评测系统里就能直接编译运行。这一点看着简单实际操作起来有很多坑——比如有些测评机是旧版本GCC不支持C17的文件流语法再比如有些题目卡了OpenMP或者特殊头文件模板里如果带了这些内容就会直接编译失败。所以我对每个模板统一做了一次“最古老编译器兼容”测试确保拿到大部分OJ上都能过编译。另外整套模板使用了统一的文件头。每份模板在最顶部用三行注释标注了算法的功能描述、时间复杂度和空间复杂度、以及在哪个OJ上验证过。刚开始我觉得写这些注释很麻烦但坚持了几个月后发现收益极大。因为人的记忆是靠不住的三个月前写的拉普拉斯矩阵树定理模板没有注释的话我可能要看十分钟才能想起来它到底解决什么问题而有了标准文件头基本扫一眼就知道该不该用这个模板进场。2. 全家桶的整体架构与代码规范2.1 通用代码框架与输入输出加速把全家桶做成什么样才算好用我第一个想到的就是“通用性”。ACM模板不像工程代码它不需要考虑模块解耦、不需要处理异常它唯一的目标就是在比赛时间里把问题解出来。所以我的模板都有一套非常固定的“骨架”开头若干include、using namespace std、常量定义、变量定义、核心函数、主函数。实际使用的过程中这个骨架里最容易出问题的是输入输出。大部分模板题的数据量都很大动不动就是10的5次方甚至10的6次方级别的输入数据。很多人在初学阶段喜欢用cin/cout然后加一行ios::sync_with_stdio(false) 和 cin.tie(nullptr)。这两行代码确实能缓解性能问题但并不能保证在所有教科书上都有用。比如某些评测系统上scanf/printf和cin/cout混用会导致缓冲区错乱一旦混用结果就不可预期。所以在我的统一模板里输入输出默认使用scanf/printf只有在个别需要读入string类型、且数据规模不太大的题目里我才会切到cin。如果你真的偏爱cin/cout那我建议在模板开头直接加上下面这段#include bits/stdc.h using namespace std; static const auto io_speed_up []() { ios::sync_with_stdio(false); cin.tie(nullptr); return 0; }(); // 快读示例适用于10^6级别数据输入 inline int read() { int x 0, f 1; char c getchar(); while (c 0 || c 9) { if (c -) f -1; c getchar(); } while (c 0 c 9) { x x * 10 (c - 0); c getchar(); } return x * f; }这段代码的形式其实是个lambda表达式通过static变量初始化来提前绑定能避免编译器因为tie操作做多余的flush。我第一次看到这个写法的时候也觉得花里胡哨但实测下来确实比单纯写两行sync语句略快而且它解决了在某类IDE上同步关闭失效的问题。读函数我还额外封装了快读版本因为模数题里读10的6次方个整数的场景太常见了getchar级别的优化虽然不像有些人说的神乎其神但确实能省几十毫秒。2.2 模板分类体系与文件命名规范目录结构上我直接按算法大类建文件夹每个文件夹里再按具体算法拆文件。比如图论文件夹下会有最短路、最小生成树、网络流、二分图匹配等子文件每个文件名都带有动词或功能词比如Dijkstra_Heap.cpp、Dinic_MaxFlow.cpp。这套命名规范听上去很朴素但执行起来最大的阻力来自我自己——因为以前我喜欢用“图论1”“图论2”这种偷懒名字结果就是过了一周自己都分不清哪个是哪个。全家桶计划强制要求文件名要么描述算法思想要么描述问题场景禁止出现数字编号。每个文件内部我也固定了内容顺序注释头、include与常量、数据结构/全局变量、具体的函数实现、main函数中的示例用法。这里的“示例用法”是我非常坚持加的部分。很多网上模板只给一个孤零零的函数不给调用方式也不给输入格式看起来很高端新手根本用不起来。我在自己的模板里尤其是那些需要先建图、再跑算法的模板比如费用流、树链剖分都会在main函数中写一个可以正确运行的最小示例。这样我就等于在每个模板上附带了一个“可运行的测试用例”平时想检查模板还能不能用直接把这个文件编译一遍跑一下就行。2.3 模板之间的互相引用如何处理整理模板库最容易翻车的一个点是处理模板之间的依赖。比如树链剖分要依赖线段树Tarjan缩点之后要重建图跑拓扑DP后缀自动机后面往往还要挂一个基数排序。如果每个模板都写成“从天而降的独立算法”那真正做题的时候就麻烦了因为你永远不知道哪些函数是可以和别的模板共用的。我的处理方式是所有通用数据结构比如线段树、并查集、单调队列都提供不依赖上下文的独立版本并且不定义重名冲突的全局变量。换句话说这个全家桶里的线段树模板不可能依赖某个不确定的全局数组大小而是在结构体内部动态分配或者在类中维护vector。这样可以保证当你把它和树链剖分拼接起来时只需要改名或者把线段树的模板类塞进去就行。这里给个非常典型的例子并查集。看起来是最简单的数据结构模板却最容易写乱。有些人喜欢定义int fa[N]有些人喜欢int pre[N]一旦和别的模板混用就不知道谁是谁。我在全家桶里统一命名为parent并且封装成带路径压缩和按秩合并的类struct DSU { vectorint f, sz; DSU(int n 0) { init(n); } void init(int n) { f.resize(n 1); sz.assign(n 1, 1); iota(f.begin(), f.end(), 0); } int find(int x) { return f[x] x ? x : f[x] find(f[x]); } bool unite(int a, int b) { a find(a), b find(b); if (a b) return false; if (sz[a] sz[b]) swap(a, b); f[b] a; sz[a] sz[b]; return true; } };这样做的好处一方面是不用担心数组开多大——构造时传n就行另一方面是结构体内部隐藏了辅助数组不会和全局变量冲突。我在实际比赛中对这个DSU类非常依赖除了一些强制卡常的题目需要手写数组外日常使用基本都直接用这个类。3. 核心模板模块的拆解与实现细节3.1 数据结构模块线段树的通用写法数据结构是整个ACM算法体系中写模板价值最高的部分因为它代码量大、逻辑容易出错而且在多个题目里会反复出现。线段树是重灾区各种变形版本区间加、区间乘、区间赋值、历史最值数不胜数。我在全家桶里保留的是最经典的“区间加法区间求和区间最大值”三合一版本因为它适用于绝大多数题目的变体。线段树的实现我选择结构体数组而不是指针。理由很简单指针版写起来确实很自然但一旦涉及递归调用不小心访问空指针就原地爆炸而且调试的时候指针变量看着很费劲。结构体数组加上4倍空间是ACM圈的通用做法不需要动态开点代码也更好背。下面是这套模板的骨架struct SegTree { struct Node { long long sum; long long lazy; long long mx; }; int n; vectorNode tr; SegTree(int n) : n(n), tr(4 * n 5) {} void pushUp(int p) { tr[p].sum tr[p 1].sum tr[p 1 | 1].sum; tr[p].mx max(tr[p 1].mx, tr[p 1 | 1].mx); } void pushDown(int p, int lenL, int lenR) { if (tr[p].lazy 0) return; long long v tr[p].lazy; tr[p 1].sum v * lenL; tr[p 1].mx v; tr[p 1].lazy v; tr[p 1 | 1].sum v * lenR; tr[p 1 | 1].mx v; tr[p 1 | 1].lazy v; tr[p].lazy 0; } void build(int p, int l, int r, const vectorlong long a) { if (l r) { tr[p].sum tr[p].mx a[l]; return; } int mid (l r) 1; build(p 1, l, mid, a); build(p 1 | 1, mid 1, r, a); pushUp(p); } void rangeAdd(int p, int l, int r, int ql, int qr, long long v) { if (ql l r qr) { tr[p].sum v * (r - l 1); tr[p].mx v; tr[p].lazy v; return; } int mid (l r) 1; pushDown(p, mid - l 1, r - mid); if (ql mid) rangeAdd(p 1, l, mid, ql, qr, v); if (qr mid) rangeAdd(p 1 | 1, mid 1, r, ql, qr, v); pushUp(p); } };为什么pushDown要传两个长度参数这是很多新手容易忽略的细节。懒标记下推时左右子节点的区间长度不同所以加法标记对sum的影响不同。如果不传长度处理区间求和就会算错。这个坑我在早年写模板时踩过一次后来直接在模板层面固定了规则避免每次做题都重新想一遍。线段树模板最容易出现的另外两个坑一是查询时的分支条件写反导致区间覆盖到了不应该覆盖的位置二是建树时数组下标的边界比如传入的a数组是0-index还是1-index。我在全家桶里统一定义为1-index所有调用方都必须遵守碰到0-index输入就先手动平移。3.2 图论模块最短路与最大流的模板化封装图论模板里最常被“临场手写”的是Dijkstra。不过很多人写的Dijkstra其实不是严格最优的版本至少在堆优化和松弛顺序上都没做到位。我全家桶里的Dijkstra用优先队列实现每次从堆顶取出当前距离最小的节点只有当该节点的dist等于队里存的值时才去松弛邻居这样能有效规避重复入队导致的死循环问题。void dijkstra(int s, vectorlong long dist, const vectorvectorpairint, long long g) { int n (int)g.size(); dist.assign(n, LLONG_MAX); priority_queuepairlong long, int, vectorpairlong long, int, greater pq; dist[s] 0; pq.push({0, s}); while (!pq.empty()) { auto [d, u] pq.top(); pq.pop(); if (d ! dist[u]) continue; for (auto [v, w] : g[u]) { if (dist[v] dist[u] w) { dist[v] dist[u] w; pq.push({dist[v], v}); } } } }这段代码有几个设计选择值得说一嘴。第一我用dist.assign(n, LLONG_MAX)而不是vectorlong long dist(n, INF)是为了适应不同题目给的顶点数量比边数多很多的情况免得到时候忘记resize。第二邻接表我用vectorvectorpairint, long long在给模板做示例时最简单直观但如果题目卡内存再用链式前向星也不迟。第三if (d ! dist[u]) continue这行不能省它能防止那些已经被更新过的旧堆元素再去影响其他点。网络流模板我收录的是Dinic。至于为什么不放ISAP或者HLPP我的理由很简单Dinic在绝大多数竞赛题目里表现足够好代码量少、不容易写错、即使是最坏情况也能通过大部分测试数据。ISAP确实在某些卡常数的大型网络流题里更快但它的实现细节比Dinic复杂不少一旦模板本身有瑕疵比赛时debug的代价极高。Dinic全家桶版本长这样struct Dinic { struct Edge { int to, rev; long long cap; }; vectorvectorEdge g; vectorint level, iter; Dinic(int n) : g(n 1), level(n 1), iter(n 1) {} void addEdge(int u, int v, long long cap) { g[u].push_back({v, (int)g[v].size(), cap}); g[v].push_back({u, (int)g[u].size() - 1, 0}); } bool bfs(int s, int t) { fill(level.begin(), level.end(), -1); queueint q; level[s] 0; q.push(s); while (!q.empty()) { int u q.front(); q.pop(); for (auto e : g[u]) { if (e.cap 0 level[e.to] 0) { level[e.to] level[u] 1; q.push(e.to); } } } return level[t] 0; } long long dfs(int u, int t, long long f) { if (u t) return f; for (int i iter[u]; i (int)g[u].size(); i) { Edge e g[u][i]; if (e.cap 0 level[u] level[e.to]) { long long ret dfs(e.to, t, min(f, e.cap)); if (ret 0) { e.cap - ret; g[e.to][e.rev].cap ret; return ret; } } } return 0; } long long maxFlow(int s, int t) { long long flow 0; const long long INF 1LL 60; while (bfs(s, t)) { fill(iter.begin(), iter.end(), 0); long long f; while ((f dfs(s, t, INF)) 0) { flow f; } } return flow; } };注意这里的addEdge在建反向边时用的rev索引这个写法非常经典也很容易写错。我在写模板时特别留意了g[v].size()-1和g[u].size()-1的区别反复测试过无向图和有向图两种场景。另外dfs里的iter[u]是当前弧优化不能漏掉否则Dinic会退化成多次重复DFS复杂度直接拉满。3.3 字符串模块KMP与模板匹配的工程化整理字符串算法在ACM里属于比较独立的一块KMP、Z函数、Manacher、后缀数组、自动机各成一派。我在全家桶里最先整理的就是KMP因为它在单模式匹配里最有代表性同时也是很多进阶字符串算法的基础。KMP最让我头疼的地方不是算法本身而是next数组的定义——不同资料里next数组可能是“最长公共前后缀长度”也可能是“失效时要跳转到的位置”不统一的话很容易错乱。我采用的约定是pi[i]表示prefix[0..i]这个子串的最长相等前后缀的长度且这个长度严格小于等于i。求next数组的代码几乎是国际通用的但理解时要注意当j失配时j pi[j-1]不是j pi[j]。很多模板里为了省事直接把索引错开一位导致概念混乱。为了彻底避免这个问题我的模板里统一采用“先得到pi数组再在匹配时用while循环回退”的写法。vectorint getPi(const string s) { int n (int)s.size(); vectorint pi(n, 0); for (int i 1; i n; i) { int j pi[i - 1]; while (j 0 s[i] ! s[j]) j pi[j - 1]; if (s[i] s[j]) j; pi[i] j; } return pi; } vectorint kmpMatch(const string text, const string pat) { vectorint pi getPi(pat); vectorint res; int j 0; for (int i 0; i (int)text.size(); i) { while (j 0 text[i] ! pat[j]) j pi[j - 1]; if (text[i] pat[j]) j; if (j (int)pat.size()) { res.push_back(i - (int)pat.size() 1); j pi[j - 1]; } } return res; }这个版本的优点在于pi数组的求法和匹配用的回退逻辑完全一致不容易出现“为什么这里减一那里不减一”的困惑。我把这个模板和其他字符串模板放在一起后明显感觉复习和使用的成本变低了。另外处理多个模式和通配符的AC自动机模板也是基于这个KMP的next思想写出来的所以KMP模板的正确性会直接影响后面一整套字符串库的稳定性。3.4 动态规划与数学模块套路沉淀DP部分我没有去收录那些一眼就能看出来的经典题目而是整理了每个DP范式对应的“转移骨架”。比如背包九讲里01背包和完全背包的两种写法压缩成一维数组以后其实就差一个循环方向。我的模板里会明确标注“体积循环从大到小”和“体积循环从小到大”的差异同时附一句注释解释为什么。这个看起来非常基础但如果长时间不写DP真的容易搞混我就吃过这个亏——一次团队赛里我负责的完全背包部分因为循环方向写反导致样例过不了耽误了二十分钟。数论模块是我花时间最多的。因为数论公式多、板子长而且经常需要多个模板联合使用比如快速幂、扩展欧几里得、欧拉筛、逆元。我的统一模板里把快速幂和扩展欧几里得放在同一个文件里然后带一个求组合数C(n,k)的取模版。这样在做容斥题或者概率题时直接引用一个文件就够了不需要在好几个文件之间来回跳。4. 模板的测试、调试与评测系统适配4.1 造数据与对拍模板可靠性的底线模板写出来如果不测跟没有模板没有区别。我在全家桶计划里给自己定了一条硬规矩任何一个新模板进入正式目录前必须通过至少十个随机测试用例的对拍。对拍的意思很简单——拿一个非常暴力、但是逻辑必然正确的版本和模板版本跑同一份随机输入对比输出是否一致。如果一致才能认为模板大概率没问题。对拍的工程化流程我在项目里形成了一个小脚本用Python脚本生成随机数据分别运行暴力程序和模板程序用文件对比工具比对结果。为了省事我把生成器和对拍器都放在模板库根目录的tools/文件夹下这样后续收录其他模板时就不需要重新写一套工具了。这里有一个很重要的经验随机数据一定要覆盖“极限规模”和“最坏结构”两类情况。比如线段树模板如果只拿小数组测根本测不出pushDown里的懒标记传播错误Dijkstra模板如果只拿无环图测也很容易掩盖堆优化可能出现的重复入队问题。我自己最常踩的坑是随机数生成范围没给对导致生成的输入不合法比如顶点编号从0开始而模板假定从1开始。后来我在生成器脚本里统一增加了参数校验并且生成完数据后先让暴力程序跑一遍确认数据合法后再进入对拍环节。4.2 边界条件检查清单模板进入正式目录前除了对拍我还会单独跑一遍边界测试。这部分相当重要因为很多模板的bug隐藏在最极端的情况里。举几个典型的例子样例行。输入n1或空串很多递归算法在边界上会数组越界尤其是后缀自动机和回文树这类依赖多个辅助数组的结构。最大数据规模。比如n10的6次方看会不会内存溢出或者超时。我的模板通常不刻意调常但如果某个模板在最大规模下超过了同类算法两倍以上的运行时间我会重新审视实现方式。全相同元素。这个对快速排序、KMP这种有规律性的算法特别有效。全相同串会让KMP的next数组全部变成0或者连续增长写错一点就会死循环。单调递增或递减的数据。这种输入能够暴露并查集的按秩合并是否有效也能检验一些依赖单调性的优化是否在特殊数据下退化成低效逻辑。我的习惯是把这些边界测试写成一个Shell脚本每次更新某个模板库以后一键跑完全部测试。可能有人觉得ACM模板不需要这么严谨但我的观点是如果不做这个测试真正比赛时一旦模板出错代价可能是整场比赛的心态崩盘远不是省下的那几十分钟能弥补的。4.3 适配不同评测系统的细节评测机五花八门模板要能适应它们关键在于“保守”。我在模板库里统一用了#include bits/stdc.h这个头文件在大部分主流评测系统上都能用但如果你所在的学校OJ是老旧的GCC版本可能会编译失败。我的建议是全家桶里准备一个cheader.h备用把常用的头文件都显式列出来万一遇到不支持万能头的环境直接全局替换过去。另一个隐藏很深的坑是C版本。现在很多比赛已经支持C17但有些学校机房的评测机还停留在C11甚至C98。我早期的一个Dinic模板里用到了结构化绑定auto [d, u] pq.top()在C17下没问题结果有一次校赛评测机只支持C14全队提交全挂。后来我统一把模板库的代码风格降级到C11尽量不使用需要C17才能编译的特性。如果你确实想用结构化绑定就一定要在文件头注释里注明所需的最小C版本并提前确认比赛环境支持。还有内存限制的问题。某些题目的内存限制只有64MB甚至32MB这类题目你在模板里开vectorvectorint就要非常小心因为邻接表的开销比链式前向新大不少。我的模板库里保留了一版最基础的前向星实现专门用来对付内存极小的场景。虽然在日常刷题时不太用得上但这个备选版本的存在保证了整套模板库在极端情况下依然可用。5. 常见问题与排查技巧实录5.1 模板管理中的经典坑整理全家桶这几个月我踩过的坑比想象中多有些甚至不是算法本身的坑而是管理流程的坑但这个价值其实更大因为算法错误你很快能发现管理混乱却能把你拖入无限内耗。第一个坑是过度追求“精简代码”。模板写得太短省掉了所有注释和可读性结果就是过了一个月连自己也看不懂了。我之前在网上看到过一些作者把Dinic压到40行以内确实很酷但真到现场调用时你根本不敢保证某个变量名的含义更不敢随便改动。后来我把所有模板的注释统一改成“功能说明用法说明”宁可多写几行注释也要让半年后的自己能在30秒内看懂。第二个坑是版本管理靠“复制粘贴”。一开始我的全家桶就放在本地文件夹里每改一次就存一个副本结果文件夹里充满了Dijkstra_final、Dijkstra_final2、Dijkstra_真最终版之类的文件。后来我把整个库托管到了Git仓库每次修改都通过commit留痕这个问题才彻底解决。Git的另一个好处是你可以放心大胆地删除或重构某个模板因为历史版本都留着不需要像以前那样战战兢兢地保留所有旧文件。第三个坑是过分追求大而全。我刚开始列目录清单时恨不得把OI Wiki上每一个算法都收录进来。但后来发现模板库越大维护成本越高而且很多冷门算法你根本用不上反而让查找变得困难。我最后定了“六类核心算法优先”的策略冷门算法只保留一个跳转链接或者笔记摘要不强行塞进模板目录。5.2 常见编译与运行错误排查方向这里整理一个我在全家桶测试中会反复遇到的错误速查表如果你也在整理自己的模板大概率也会碰到类似的问题。错误表现可能原因排查思路线段树查询结果偏大/偏小pushDown时没有传区间长度或查询分支条件写反检查查询和修改中ql/qr与mid的比较逻辑Dijkstra死循环或超时出队时没判断d ! dist[u]导致旧元素重复松弛在堆顶加一行“continue”判断Dinic流量错误反向边的rev索引写错导致反向边指向错误节点检查addEdge中两处rev的设置KMP匹配不到结果next数组定义为“跳转位置”而不是“最长前后缀长度”统一为pi数组失配时用j pi[j-1]快读和scanf混用导致读入错乱缓冲区被两种读入方式同时占用整套模板统一一种读入方式结构体套vector导致MLE每次初始化时重复分配大块内存改成在init中assign并先算好最大规模C版本不兼容用了C17的语法特性但OJ只支持C11全局搜索结构化绑定和if constexpr等语法多组测试数据未重置全局容器模板中使用了全局变量而没有手动清空在main函数开头用init或clear统一重置5.3 如何让模板库长期可用模板库不是一个“建完就完”的东西它需要持续维护和更新。我的习惯是每次训练赛或者正式比赛结束后都会回顾一遍本场用到的模板看看有没有可以优化的地方有没有出现了不好用的细节然后在当天就更新到仓库里。千万不要攒到周末更不要攒到月底人一旦把问题拖久了就会连问题是什么都想不起来。另一个维护策略是给自己加“使用日志”。我每在比赛或训练中使用一次某个模板就会在对应文件头的注释里加一行记录比如“2025-03-15在XX题中用于建图耗时正常”。这个日志最初看着有点多余但坚持半年之后你会发现你对每个模板的信任度有了非常精准的把握。有些模板你在十道题里用了九次都没问题那它大概率是可靠的有些模板你只验证过一次那比赛时就必须多留个心眼。根据我个人这段时间的经验我觉得模板库最理想的状态不是“所有算法的答案”而是“自己写题的助手”。它不能替代你思考但它能帮你把那些已经想清楚的东西以最快、最稳的方式变成代码。我整理全家桶最大的收获其实是养成了“把每次踩坑都沉淀下来”的习惯。如果你也在整理自己的算法模板建议你从一份最常用的Dijkstra开始先跑通整个“写模板—测模板—存模板—用模板”的闭环然后慢慢扩充。等到你的库能够覆盖数据结构、图论、字符串、DP、数学这些大类时你就真正拥有一把自己的“屠龙刀”了。
ACM算法模板全家桶：构建高效可复用的竞赛代码体系
1. 为什么需要一个算法全家桶1.1 零散模板的三个老大难问题接触ACM也快六年了从最开始在OJ上刷水题到后来打区域赛、带队伍我花在“找模板”这件事上的时间可能比写代码本身还多。早些年我把模板散落在硬盘各个角落本地文件、博客、GitHub、各类集训队课件里真正需要的时候反而找不到最顺手的那份体验相当糟糕。后来我下决心做了一套“繁凡的ACM算法全家桶”核心目的只有一个把分散的、零乱的、质量参差不齐的代码沉淀成一套统一的、可直接提交、可快速检索的模板体系。零散模板的问题归纳起来其实就三类。第一类是版本混乱。同一个算法比如线段树我手里至少有四种写法指针版、结构体数组版、带lazy标记的区间修改版、还有专门用来处理扫描线的版本。每次比赛前我都在纠结到底带哪个代码文件深怕考场里临时改板子改出bug。第二类是缺少验证。很多模板是从课件或者别人博客里抄过来的看起来天衣无缝但放到真实数据上一跑就崩溢出的溢出、死循环的死循环。第三类是风格不统一。有人喜欢用宏定义有人喜欢用typedef变量命名也是五花八门。平时自己写题还不觉得可一旦要把几个模板拼接起来做综合题这种风格割裂带来的阅读成本就非常高了。所以我在启动全家桶计划的时候给自己立了几个非常明确的目标一是所有核心模板必须经过OJ实测保证能过题二是代码风格统一整个库读起来就像一个人写的三是每个模板自带使用说明和复杂度标注复习的时候不需要重新看一遍算法推导才能想起这是干什么用的。这段话算是我整个项目最核心的出发点后面所有工作都是围绕这三个目标展开的。1.2 全家桶的定位与设计目标这里要先说清楚“全家桶”并不是要把所有算法都塞进去。ACM的考察范围虽然广但真正在赛场上高频使用、值得整理成模板的算法其实是有限的。我给自己定了一个范围数据结构、图论、字符串、数学、动态规划、几何六个大类每类下面收录的都是“写熟了可以直接用”的代码而不是把OI Wiki上的内容全部复制一遍。设计目标上我参考了比较常见的ACM模板库的组织方式比如一些退役选手放出来的“xx爷模板”但针对自己的使用习惯做了一些调整。最重要的一点是“单文件可提交”。也就是说每个模板都是一个完整的C代码文件包含了所有需要的头文件和命名空间声明复制到在线评测系统里就能直接编译运行。这一点看着简单实际操作起来有很多坑——比如有些测评机是旧版本GCC不支持C17的文件流语法再比如有些题目卡了OpenMP或者特殊头文件模板里如果带了这些内容就会直接编译失败。所以我对每个模板统一做了一次“最古老编译器兼容”测试确保拿到大部分OJ上都能过编译。另外整套模板使用了统一的文件头。每份模板在最顶部用三行注释标注了算法的功能描述、时间复杂度和空间复杂度、以及在哪个OJ上验证过。刚开始我觉得写这些注释很麻烦但坚持了几个月后发现收益极大。因为人的记忆是靠不住的三个月前写的拉普拉斯矩阵树定理模板没有注释的话我可能要看十分钟才能想起来它到底解决什么问题而有了标准文件头基本扫一眼就知道该不该用这个模板进场。2. 全家桶的整体架构与代码规范2.1 通用代码框架与输入输出加速把全家桶做成什么样才算好用我第一个想到的就是“通用性”。ACM模板不像工程代码它不需要考虑模块解耦、不需要处理异常它唯一的目标就是在比赛时间里把问题解出来。所以我的模板都有一套非常固定的“骨架”开头若干include、using namespace std、常量定义、变量定义、核心函数、主函数。实际使用的过程中这个骨架里最容易出问题的是输入输出。大部分模板题的数据量都很大动不动就是10的5次方甚至10的6次方级别的输入数据。很多人在初学阶段喜欢用cin/cout然后加一行ios::sync_with_stdio(false) 和 cin.tie(nullptr)。这两行代码确实能缓解性能问题但并不能保证在所有教科书上都有用。比如某些评测系统上scanf/printf和cin/cout混用会导致缓冲区错乱一旦混用结果就不可预期。所以在我的统一模板里输入输出默认使用scanf/printf只有在个别需要读入string类型、且数据规模不太大的题目里我才会切到cin。如果你真的偏爱cin/cout那我建议在模板开头直接加上下面这段#include bits/stdc.h using namespace std; static const auto io_speed_up []() { ios::sync_with_stdio(false); cin.tie(nullptr); return 0; }(); // 快读示例适用于10^6级别数据输入 inline int read() { int x 0, f 1; char c getchar(); while (c 0 || c 9) { if (c -) f -1; c getchar(); } while (c 0 c 9) { x x * 10 (c - 0); c getchar(); } return x * f; }这段代码的形式其实是个lambda表达式通过static变量初始化来提前绑定能避免编译器因为tie操作做多余的flush。我第一次看到这个写法的时候也觉得花里胡哨但实测下来确实比单纯写两行sync语句略快而且它解决了在某类IDE上同步关闭失效的问题。读函数我还额外封装了快读版本因为模数题里读10的6次方个整数的场景太常见了getchar级别的优化虽然不像有些人说的神乎其神但确实能省几十毫秒。2.2 模板分类体系与文件命名规范目录结构上我直接按算法大类建文件夹每个文件夹里再按具体算法拆文件。比如图论文件夹下会有最短路、最小生成树、网络流、二分图匹配等子文件每个文件名都带有动词或功能词比如Dijkstra_Heap.cpp、Dinic_MaxFlow.cpp。这套命名规范听上去很朴素但执行起来最大的阻力来自我自己——因为以前我喜欢用“图论1”“图论2”这种偷懒名字结果就是过了一周自己都分不清哪个是哪个。全家桶计划强制要求文件名要么描述算法思想要么描述问题场景禁止出现数字编号。每个文件内部我也固定了内容顺序注释头、include与常量、数据结构/全局变量、具体的函数实现、main函数中的示例用法。这里的“示例用法”是我非常坚持加的部分。很多网上模板只给一个孤零零的函数不给调用方式也不给输入格式看起来很高端新手根本用不起来。我在自己的模板里尤其是那些需要先建图、再跑算法的模板比如费用流、树链剖分都会在main函数中写一个可以正确运行的最小示例。这样我就等于在每个模板上附带了一个“可运行的测试用例”平时想检查模板还能不能用直接把这个文件编译一遍跑一下就行。2.3 模板之间的互相引用如何处理整理模板库最容易翻车的一个点是处理模板之间的依赖。比如树链剖分要依赖线段树Tarjan缩点之后要重建图跑拓扑DP后缀自动机后面往往还要挂一个基数排序。如果每个模板都写成“从天而降的独立算法”那真正做题的时候就麻烦了因为你永远不知道哪些函数是可以和别的模板共用的。我的处理方式是所有通用数据结构比如线段树、并查集、单调队列都提供不依赖上下文的独立版本并且不定义重名冲突的全局变量。换句话说这个全家桶里的线段树模板不可能依赖某个不确定的全局数组大小而是在结构体内部动态分配或者在类中维护vector。这样可以保证当你把它和树链剖分拼接起来时只需要改名或者把线段树的模板类塞进去就行。这里给个非常典型的例子并查集。看起来是最简单的数据结构模板却最容易写乱。有些人喜欢定义int fa[N]有些人喜欢int pre[N]一旦和别的模板混用就不知道谁是谁。我在全家桶里统一命名为parent并且封装成带路径压缩和按秩合并的类struct DSU { vectorint f, sz; DSU(int n 0) { init(n); } void init(int n) { f.resize(n 1); sz.assign(n 1, 1); iota(f.begin(), f.end(), 0); } int find(int x) { return f[x] x ? x : f[x] find(f[x]); } bool unite(int a, int b) { a find(a), b find(b); if (a b) return false; if (sz[a] sz[b]) swap(a, b); f[b] a; sz[a] sz[b]; return true; } };这样做的好处一方面是不用担心数组开多大——构造时传n就行另一方面是结构体内部隐藏了辅助数组不会和全局变量冲突。我在实际比赛中对这个DSU类非常依赖除了一些强制卡常的题目需要手写数组外日常使用基本都直接用这个类。3. 核心模板模块的拆解与实现细节3.1 数据结构模块线段树的通用写法数据结构是整个ACM算法体系中写模板价值最高的部分因为它代码量大、逻辑容易出错而且在多个题目里会反复出现。线段树是重灾区各种变形版本区间加、区间乘、区间赋值、历史最值数不胜数。我在全家桶里保留的是最经典的“区间加法区间求和区间最大值”三合一版本因为它适用于绝大多数题目的变体。线段树的实现我选择结构体数组而不是指针。理由很简单指针版写起来确实很自然但一旦涉及递归调用不小心访问空指针就原地爆炸而且调试的时候指针变量看着很费劲。结构体数组加上4倍空间是ACM圈的通用做法不需要动态开点代码也更好背。下面是这套模板的骨架struct SegTree { struct Node { long long sum; long long lazy; long long mx; }; int n; vectorNode tr; SegTree(int n) : n(n), tr(4 * n 5) {} void pushUp(int p) { tr[p].sum tr[p 1].sum tr[p 1 | 1].sum; tr[p].mx max(tr[p 1].mx, tr[p 1 | 1].mx); } void pushDown(int p, int lenL, int lenR) { if (tr[p].lazy 0) return; long long v tr[p].lazy; tr[p 1].sum v * lenL; tr[p 1].mx v; tr[p 1].lazy v; tr[p 1 | 1].sum v * lenR; tr[p 1 | 1].mx v; tr[p 1 | 1].lazy v; tr[p].lazy 0; } void build(int p, int l, int r, const vectorlong long a) { if (l r) { tr[p].sum tr[p].mx a[l]; return; } int mid (l r) 1; build(p 1, l, mid, a); build(p 1 | 1, mid 1, r, a); pushUp(p); } void rangeAdd(int p, int l, int r, int ql, int qr, long long v) { if (ql l r qr) { tr[p].sum v * (r - l 1); tr[p].mx v; tr[p].lazy v; return; } int mid (l r) 1; pushDown(p, mid - l 1, r - mid); if (ql mid) rangeAdd(p 1, l, mid, ql, qr, v); if (qr mid) rangeAdd(p 1 | 1, mid 1, r, ql, qr, v); pushUp(p); } };为什么pushDown要传两个长度参数这是很多新手容易忽略的细节。懒标记下推时左右子节点的区间长度不同所以加法标记对sum的影响不同。如果不传长度处理区间求和就会算错。这个坑我在早年写模板时踩过一次后来直接在模板层面固定了规则避免每次做题都重新想一遍。线段树模板最容易出现的另外两个坑一是查询时的分支条件写反导致区间覆盖到了不应该覆盖的位置二是建树时数组下标的边界比如传入的a数组是0-index还是1-index。我在全家桶里统一定义为1-index所有调用方都必须遵守碰到0-index输入就先手动平移。3.2 图论模块最短路与最大流的模板化封装图论模板里最常被“临场手写”的是Dijkstra。不过很多人写的Dijkstra其实不是严格最优的版本至少在堆优化和松弛顺序上都没做到位。我全家桶里的Dijkstra用优先队列实现每次从堆顶取出当前距离最小的节点只有当该节点的dist等于队里存的值时才去松弛邻居这样能有效规避重复入队导致的死循环问题。void dijkstra(int s, vectorlong long dist, const vectorvectorpairint, long long g) { int n (int)g.size(); dist.assign(n, LLONG_MAX); priority_queuepairlong long, int, vectorpairlong long, int, greater pq; dist[s] 0; pq.push({0, s}); while (!pq.empty()) { auto [d, u] pq.top(); pq.pop(); if (d ! dist[u]) continue; for (auto [v, w] : g[u]) { if (dist[v] dist[u] w) { dist[v] dist[u] w; pq.push({dist[v], v}); } } } }这段代码有几个设计选择值得说一嘴。第一我用dist.assign(n, LLONG_MAX)而不是vectorlong long dist(n, INF)是为了适应不同题目给的顶点数量比边数多很多的情况免得到时候忘记resize。第二邻接表我用vectorvectorpairint, long long在给模板做示例时最简单直观但如果题目卡内存再用链式前向星也不迟。第三if (d ! dist[u]) continue这行不能省它能防止那些已经被更新过的旧堆元素再去影响其他点。网络流模板我收录的是Dinic。至于为什么不放ISAP或者HLPP我的理由很简单Dinic在绝大多数竞赛题目里表现足够好代码量少、不容易写错、即使是最坏情况也能通过大部分测试数据。ISAP确实在某些卡常数的大型网络流题里更快但它的实现细节比Dinic复杂不少一旦模板本身有瑕疵比赛时debug的代价极高。Dinic全家桶版本长这样struct Dinic { struct Edge { int to, rev; long long cap; }; vectorvectorEdge g; vectorint level, iter; Dinic(int n) : g(n 1), level(n 1), iter(n 1) {} void addEdge(int u, int v, long long cap) { g[u].push_back({v, (int)g[v].size(), cap}); g[v].push_back({u, (int)g[u].size() - 1, 0}); } bool bfs(int s, int t) { fill(level.begin(), level.end(), -1); queueint q; level[s] 0; q.push(s); while (!q.empty()) { int u q.front(); q.pop(); for (auto e : g[u]) { if (e.cap 0 level[e.to] 0) { level[e.to] level[u] 1; q.push(e.to); } } } return level[t] 0; } long long dfs(int u, int t, long long f) { if (u t) return f; for (int i iter[u]; i (int)g[u].size(); i) { Edge e g[u][i]; if (e.cap 0 level[u] level[e.to]) { long long ret dfs(e.to, t, min(f, e.cap)); if (ret 0) { e.cap - ret; g[e.to][e.rev].cap ret; return ret; } } } return 0; } long long maxFlow(int s, int t) { long long flow 0; const long long INF 1LL 60; while (bfs(s, t)) { fill(iter.begin(), iter.end(), 0); long long f; while ((f dfs(s, t, INF)) 0) { flow f; } } return flow; } };注意这里的addEdge在建反向边时用的rev索引这个写法非常经典也很容易写错。我在写模板时特别留意了g[v].size()-1和g[u].size()-1的区别反复测试过无向图和有向图两种场景。另外dfs里的iter[u]是当前弧优化不能漏掉否则Dinic会退化成多次重复DFS复杂度直接拉满。3.3 字符串模块KMP与模板匹配的工程化整理字符串算法在ACM里属于比较独立的一块KMP、Z函数、Manacher、后缀数组、自动机各成一派。我在全家桶里最先整理的就是KMP因为它在单模式匹配里最有代表性同时也是很多进阶字符串算法的基础。KMP最让我头疼的地方不是算法本身而是next数组的定义——不同资料里next数组可能是“最长公共前后缀长度”也可能是“失效时要跳转到的位置”不统一的话很容易错乱。我采用的约定是pi[i]表示prefix[0..i]这个子串的最长相等前后缀的长度且这个长度严格小于等于i。求next数组的代码几乎是国际通用的但理解时要注意当j失配时j pi[j-1]不是j pi[j]。很多模板里为了省事直接把索引错开一位导致概念混乱。为了彻底避免这个问题我的模板里统一采用“先得到pi数组再在匹配时用while循环回退”的写法。vectorint getPi(const string s) { int n (int)s.size(); vectorint pi(n, 0); for (int i 1; i n; i) { int j pi[i - 1]; while (j 0 s[i] ! s[j]) j pi[j - 1]; if (s[i] s[j]) j; pi[i] j; } return pi; } vectorint kmpMatch(const string text, const string pat) { vectorint pi getPi(pat); vectorint res; int j 0; for (int i 0; i (int)text.size(); i) { while (j 0 text[i] ! pat[j]) j pi[j - 1]; if (text[i] pat[j]) j; if (j (int)pat.size()) { res.push_back(i - (int)pat.size() 1); j pi[j - 1]; } } return res; }这个版本的优点在于pi数组的求法和匹配用的回退逻辑完全一致不容易出现“为什么这里减一那里不减一”的困惑。我把这个模板和其他字符串模板放在一起后明显感觉复习和使用的成本变低了。另外处理多个模式和通配符的AC自动机模板也是基于这个KMP的next思想写出来的所以KMP模板的正确性会直接影响后面一整套字符串库的稳定性。3.4 动态规划与数学模块套路沉淀DP部分我没有去收录那些一眼就能看出来的经典题目而是整理了每个DP范式对应的“转移骨架”。比如背包九讲里01背包和完全背包的两种写法压缩成一维数组以后其实就差一个循环方向。我的模板里会明确标注“体积循环从大到小”和“体积循环从小到大”的差异同时附一句注释解释为什么。这个看起来非常基础但如果长时间不写DP真的容易搞混我就吃过这个亏——一次团队赛里我负责的完全背包部分因为循环方向写反导致样例过不了耽误了二十分钟。数论模块是我花时间最多的。因为数论公式多、板子长而且经常需要多个模板联合使用比如快速幂、扩展欧几里得、欧拉筛、逆元。我的统一模板里把快速幂和扩展欧几里得放在同一个文件里然后带一个求组合数C(n,k)的取模版。这样在做容斥题或者概率题时直接引用一个文件就够了不需要在好几个文件之间来回跳。4. 模板的测试、调试与评测系统适配4.1 造数据与对拍模板可靠性的底线模板写出来如果不测跟没有模板没有区别。我在全家桶计划里给自己定了一条硬规矩任何一个新模板进入正式目录前必须通过至少十个随机测试用例的对拍。对拍的意思很简单——拿一个非常暴力、但是逻辑必然正确的版本和模板版本跑同一份随机输入对比输出是否一致。如果一致才能认为模板大概率没问题。对拍的工程化流程我在项目里形成了一个小脚本用Python脚本生成随机数据分别运行暴力程序和模板程序用文件对比工具比对结果。为了省事我把生成器和对拍器都放在模板库根目录的tools/文件夹下这样后续收录其他模板时就不需要重新写一套工具了。这里有一个很重要的经验随机数据一定要覆盖“极限规模”和“最坏结构”两类情况。比如线段树模板如果只拿小数组测根本测不出pushDown里的懒标记传播错误Dijkstra模板如果只拿无环图测也很容易掩盖堆优化可能出现的重复入队问题。我自己最常踩的坑是随机数生成范围没给对导致生成的输入不合法比如顶点编号从0开始而模板假定从1开始。后来我在生成器脚本里统一增加了参数校验并且生成完数据后先让暴力程序跑一遍确认数据合法后再进入对拍环节。4.2 边界条件检查清单模板进入正式目录前除了对拍我还会单独跑一遍边界测试。这部分相当重要因为很多模板的bug隐藏在最极端的情况里。举几个典型的例子样例行。输入n1或空串很多递归算法在边界上会数组越界尤其是后缀自动机和回文树这类依赖多个辅助数组的结构。最大数据规模。比如n10的6次方看会不会内存溢出或者超时。我的模板通常不刻意调常但如果某个模板在最大规模下超过了同类算法两倍以上的运行时间我会重新审视实现方式。全相同元素。这个对快速排序、KMP这种有规律性的算法特别有效。全相同串会让KMP的next数组全部变成0或者连续增长写错一点就会死循环。单调递增或递减的数据。这种输入能够暴露并查集的按秩合并是否有效也能检验一些依赖单调性的优化是否在特殊数据下退化成低效逻辑。我的习惯是把这些边界测试写成一个Shell脚本每次更新某个模板库以后一键跑完全部测试。可能有人觉得ACM模板不需要这么严谨但我的观点是如果不做这个测试真正比赛时一旦模板出错代价可能是整场比赛的心态崩盘远不是省下的那几十分钟能弥补的。4.3 适配不同评测系统的细节评测机五花八门模板要能适应它们关键在于“保守”。我在模板库里统一用了#include bits/stdc.h这个头文件在大部分主流评测系统上都能用但如果你所在的学校OJ是老旧的GCC版本可能会编译失败。我的建议是全家桶里准备一个cheader.h备用把常用的头文件都显式列出来万一遇到不支持万能头的环境直接全局替换过去。另一个隐藏很深的坑是C版本。现在很多比赛已经支持C17但有些学校机房的评测机还停留在C11甚至C98。我早期的一个Dinic模板里用到了结构化绑定auto [d, u] pq.top()在C17下没问题结果有一次校赛评测机只支持C14全队提交全挂。后来我统一把模板库的代码风格降级到C11尽量不使用需要C17才能编译的特性。如果你确实想用结构化绑定就一定要在文件头注释里注明所需的最小C版本并提前确认比赛环境支持。还有内存限制的问题。某些题目的内存限制只有64MB甚至32MB这类题目你在模板里开vectorvectorint就要非常小心因为邻接表的开销比链式前向新大不少。我的模板库里保留了一版最基础的前向星实现专门用来对付内存极小的场景。虽然在日常刷题时不太用得上但这个备选版本的存在保证了整套模板库在极端情况下依然可用。5. 常见问题与排查技巧实录5.1 模板管理中的经典坑整理全家桶这几个月我踩过的坑比想象中多有些甚至不是算法本身的坑而是管理流程的坑但这个价值其实更大因为算法错误你很快能发现管理混乱却能把你拖入无限内耗。第一个坑是过度追求“精简代码”。模板写得太短省掉了所有注释和可读性结果就是过了一个月连自己也看不懂了。我之前在网上看到过一些作者把Dinic压到40行以内确实很酷但真到现场调用时你根本不敢保证某个变量名的含义更不敢随便改动。后来我把所有模板的注释统一改成“功能说明用法说明”宁可多写几行注释也要让半年后的自己能在30秒内看懂。第二个坑是版本管理靠“复制粘贴”。一开始我的全家桶就放在本地文件夹里每改一次就存一个副本结果文件夹里充满了Dijkstra_final、Dijkstra_final2、Dijkstra_真最终版之类的文件。后来我把整个库托管到了Git仓库每次修改都通过commit留痕这个问题才彻底解决。Git的另一个好处是你可以放心大胆地删除或重构某个模板因为历史版本都留着不需要像以前那样战战兢兢地保留所有旧文件。第三个坑是过分追求大而全。我刚开始列目录清单时恨不得把OI Wiki上每一个算法都收录进来。但后来发现模板库越大维护成本越高而且很多冷门算法你根本用不上反而让查找变得困难。我最后定了“六类核心算法优先”的策略冷门算法只保留一个跳转链接或者笔记摘要不强行塞进模板目录。5.2 常见编译与运行错误排查方向这里整理一个我在全家桶测试中会反复遇到的错误速查表如果你也在整理自己的模板大概率也会碰到类似的问题。错误表现可能原因排查思路线段树查询结果偏大/偏小pushDown时没有传区间长度或查询分支条件写反检查查询和修改中ql/qr与mid的比较逻辑Dijkstra死循环或超时出队时没判断d ! dist[u]导致旧元素重复松弛在堆顶加一行“continue”判断Dinic流量错误反向边的rev索引写错导致反向边指向错误节点检查addEdge中两处rev的设置KMP匹配不到结果next数组定义为“跳转位置”而不是“最长前后缀长度”统一为pi数组失配时用j pi[j-1]快读和scanf混用导致读入错乱缓冲区被两种读入方式同时占用整套模板统一一种读入方式结构体套vector导致MLE每次初始化时重复分配大块内存改成在init中assign并先算好最大规模C版本不兼容用了C17的语法特性但OJ只支持C11全局搜索结构化绑定和if constexpr等语法多组测试数据未重置全局容器模板中使用了全局变量而没有手动清空在main函数开头用init或clear统一重置5.3 如何让模板库长期可用模板库不是一个“建完就完”的东西它需要持续维护和更新。我的习惯是每次训练赛或者正式比赛结束后都会回顾一遍本场用到的模板看看有没有可以优化的地方有没有出现了不好用的细节然后在当天就更新到仓库里。千万不要攒到周末更不要攒到月底人一旦把问题拖久了就会连问题是什么都想不起来。另一个维护策略是给自己加“使用日志”。我每在比赛或训练中使用一次某个模板就会在对应文件头的注释里加一行记录比如“2025-03-15在XX题中用于建图耗时正常”。这个日志最初看着有点多余但坚持半年之后你会发现你对每个模板的信任度有了非常精准的把握。有些模板你在十道题里用了九次都没问题那它大概率是可靠的有些模板你只验证过一次那比赛时就必须多留个心眼。根据我个人这段时间的经验我觉得模板库最理想的状态不是“所有算法的答案”而是“自己写题的助手”。它不能替代你思考但它能帮你把那些已经想清楚的东西以最快、最稳的方式变成代码。我整理全家桶最大的收获其实是养成了“把每次踩坑都沉淀下来”的习惯。如果你也在整理自己的算法模板建议你从一份最常用的Dijkstra开始先跑通整个“写模板—测模板—存模板—用模板”的闭环然后慢慢扩充。等到你的库能够覆盖数据结构、图论、字符串、DP、数学这些大类时你就真正拥有一把自己的“屠龙刀”了。
