简介杭州电子科技大学OJ题库是一套面向计算机专业学生与编程爱好者的算法训练资源压缩包共收录5743个HTML格式的题目网页快照整体大小为53.36MB。这些HTML文件对应OJ系统中的具体题目编号涵盖排序、搜索、图论、动态规划等经典算法与数据结构题目文件内包含题目描述、输入输出格式、样例测试用例及解题要求方便用户离线查阅和反复研读。目前已有2123人浏览学习适合日常刷题、备赛ACM/ICPC、考研机试或系统提升编程解题能力。资源以ZIP压缩包发布解压后可按编号快速定位目标题目借助这些网页快照读者可以按需检索题目在本地整理思路、推演解法再结合自身的代码实现进行验证从而强化算法理解、调试技巧和竞赛应变能力。1. 杭州电子科技大学 OJ 题库为什么老刷题的人还在回头看它如果你在搜索引擎里敲下“oj题库”大概率会看到一堆挂着大厂名字的刷题平台但真正做过 ACM 校队训练的人几乎都绕不开杭州电子科技大学的 OJ 系统。HDU OJ 是很多高校 ACM 集训队默认的入门题库题量大、覆盖广题目编号从 1000 开始一路排到几千早期的经典题到现在仍是面试手撕代码的底子。它解决的问题很具体让你在真实判题环境下学会处理输入输出边界、时间复杂度和数据范围而不是只在 IDE 里跑通样例就觉得自己会了。适合刚接触算法竞赛的程序员、准备校招笔试的学生以及想系统补算法基础的自学者。要说它和现在那些带论坛、带题解社区的平台比界面确实朴素但恰恰是这种朴素把“提交、报错、改、再交”的循环打磨得无比直接。2. 从注册到提交第一份代码HDU OJ 的基本操作与判题规则2.1 注册、语言选择与题目编号规则HDU OJ 的入口是主页的 User Login注册只需要用户名、邮箱和密码没有复杂的手机验证。登录后你会看到 Problem Set 页面题目按编号递增排列每道题有标题、通过率AC / Submit 比例和分类标签。这里有个很实在的经验不要从 1000 题往后一道一道刷因为前几十道是给新手熟悉判题流程的后面的题目难度曲线并不平滑1000 到 2000 之间混着大量数学推导和复杂模拟直接顺序刷很容易劝退。题号本身是有规律的。三位数的题目多是早期经典题比如 1000 是 AB1001 是简单递推1003 是最大子段和这些题在后来很多 OJ 上都能看到变体。四位数之后难度开始按专题聚集比如 2xxx 区间有大量动态规划和图论3xxx 区间有不少字符串处理。刚开始不要追求题号高先把 1000 到 1050 范围内的题吃透这里面包括输入输出基础、简单递推、贪心、排序足够你熟悉判题环境的脾气。2.2 最小可提交的 C 模板与输入输出套路HDU OJ 支持 C、C、Java、Python 等多种语言但 C 的通过率和响应速度在多数题目上仍然是最稳的选择。一个最小可提交的模板长这样#include cstdio int main() { int a, b; while (scanf(%d%d, a, b) ! EOF) { printf(%d\n, a b); } return 0; }这段代码对应 1000 题的核心逻辑。注意scanf的返回值它返回成功读取的参数个数到达文件末尾时返回EOF。HDU OJ 的输入默认是多组数据直到文件结束所以while (scanf(...) ! EOF)是几乎所有题目必须掌握的骨架。如果你用while (cin a b)效果是一样的但cin默认关联stdio会拖慢速度在数据量大时可能造成 TLE超时。我一般会加一句ios::sync_with_stdio(false);来解除这种关联如果题目要求更快直接回到scanf/printf。这里有个新手最常见的误解认为判题只跑你给的那几个样例。实际上 OJ 会在后台用多组测试数据跑你的程序你的代码必须能处理任意多组直到文件结束而不是只处理一组。所以“我的程序在 IDE 里输出了一个正确结果”不算数你得按判题机的输入方式去写。2.3 判题结果状态码的含义AC、WA、TLE 到底在说什么提交后会看到一串状态码我把最常见的几种拆开讲。ACAccepted通过。注意“通过”意味着你的程序在判题机的所有测试数据上都输出了正确结果但有些题会有内存和时间限制AC 里也有快慢之分只看 AC 不看耗时是刷题中的一种浪费。WAWrong Answer答案错误。可能是算法逻辑不对也可能是输出格式差了空格、换行、大小写甚至Case 1:的冒号后面多了一个空格。TLETime Limit Exceeded超时。程序没有在限定时间内跑完。你不一定要把代码优化到极致但至少得选择复杂度正确的算法。RERuntime Error运行时错误通常是数组越界、除零、空指针访问在 HDU 的旧题目里很常见的原因是数组开小了。MLEMemory Limit Exceeded内存超限多半是数组开得过大或者递归层数太深导致栈溢出。PEPresentation Error输出格式错误。和答案只差几个空格或换行OJ 认为是格式问题而不是逻辑问题。PE 本质上是 WA 的近亲但比 WA 好受一点——至少逻辑对了。状态码是判题机给你的最直接反馈。我的习惯是TLE 先想复杂度RE 先查数组大小WA 先检查格式PE 就把输出原样和标准输出用 diff 比对。另外要留意 HDU OJ 的题目界面里通常会给出 Memory Limit 和 Time Limit比如 1000 题是 2000 ms / 32 MB。32 MB 意味着你不能开一个 int[10^7] 的全局数组那是 40 MB直接 MLE。数据范围题目里会写但很多老题只给一个模糊的“huge input”这就要靠经验估算。到这里你已经能在 HDU OJ 上提交并看懂判题结果了。但“能提交”和“会刷题”之间还有一大段路下一章我把训练路径和题目筛选讲清楚这部分是很多人坚持不下来的分水岭。3. 刷题要刷到什么程度按层级筛选题目与训练路径3.1 用题号和通过率筛选从哪里找“水题”和经典题打开 Problem Set 时列表里每一行都有 AC 数和 Submit 数通过率就是 AC/Submit。这个数字有两个用法一是找水题通过率超过 50% 的题目大多思路直白适合热身二是找经典难题通过率低于 10% 的题目往往有隐蔽的边界条件等你水平上来之后再去啃。我更常用的是题号区间加通过率组合的筛选方式拿 1000 到 1100 这 100 道题来说通过率高的先做通过率极低的先跳过。这个过程不需要脚本页面右上角可以翻页眼睛扫过去就能记住哪些题号眼熟。等刷到 200 题左右你会形成自己的“舒适区”和“恐惧区”清单这是非常个人化的东西但正是清单让你后续选题效率更高。另一个隐藏入口是 HDU OJ 的“Contest”区。很多暑期集训的题目会挂到 Contest 里比赛的题面通常有分类提示比裸做 Problem Set 里的题多一层引导。如果你发现某道题在 Problem Set 里死活看不懂题意可以去搜索一下有没有对应的比赛题解但只看题意说明不要直接抄代码。3.2 按专题刷从模拟、贪心到动态规划的推进顺序不要按题号顺序刷按专题刷才是持续提升的关键。我在 HDU OJ 上的推荐顺序是模拟与枚举比如 1006、1012、1021 这类题直接翻译题意把过程写清楚训练的是编码准确度。排序与查找实现sort的变体、二分查找的下界与上界这部分会反复用到后面的题目里。贪心区间调度、哈夫曼、最小生成树的贪心思想HDU 1050、1051 都是经典。动态规划从最长递增子序列、背包问题到状态压缩HDU 1159、2602 是必刷。图论最短路径、最小生成树、拓扑排序HDU 1874、1863。数论与计算几何放在靠后的位置因为数学推导和浮点数精度需要额外积累。每个专题里我一般会按“简单 3 道、中等 3 道、困难 1 道”的配比来刷。简单的题训练手熟中等的题训练思路困难的题用来突破。如果你卡在某个专题超过两天先放掉回头再看往往会有新感受。3.3 时间与复杂度预算先估再写避免 TLEHDU OJ 的老题时间限制大多在 1 秒到 3 秒之间但判题机的速度不能直接用你本机的运行时间换算。我通常的做法是读题后先估算数据规模再确定算法复杂度最后才动笔。举个例子如果题目里说n 100000这意味 O(n²) 的算法在最坏情况下会有 10^10 次运算稳稳超时你要么优化成 O(n log n)要么用 O(n) 的扫描。把这个估算写在草稿纸上比写完再跑一遍随机数据靠谱得多。HDU OJ 的题目没有官方的复杂度标签但从数据范围倒推复杂度是每个刷题者必须掌握的技能。我个人的阈值是1 秒内大约能跑 10^8 次简单整数操作。保守一点把你的算法运算次数除以 10^8如果大于 2 就该怀疑会不会 TLE。这个经验值在 HDU OJ 的旧机器上偏乐观实际上 2×10^7 就可能超时所以能低就低。当你按专题刷到 150 题以上回看最初的 1000 题会感觉格外简单这就是进步的直观证据。但这阶段最大的敌人往往不是算法而是输入输出——下一章讲 HDU OJ 最容易让人翻车的几个细节。4. 实战HDU OJ 上最容易翻车的输入输出处理4.1 多组输入与 EOF 结束while(cinn) 的陷阱HDU OJ 的题目描述里只要出现“Input”这个词就默认是多组测试数据直到 EOF。最典型的写法是#include iostream using namespace std; int main() { int n; while (cin n) { // 处理 n } return 0; }这里cin n在读取到文件末尾时会返回false循环自然结束。问题在于有些人会在循环外面再写一个for (int i 0; i n; i)把多组输入的结束条件搞错。这种错误在本地测试时很难发现因为你手动敲的几组数据敲完就回车了程序并没有读到 EOF看起来一切正常但判题机把整个输入文件一次性灌进来你的循环次数可能多跑或少跑一组。正确做法是每道题先明确“是否需要多组输入”如果题目没有明确说就按多组处理这是 HDU OJ 最通用的规则。另外如果题目要求以某个特定值结束比如0 0表示结束记得在循环里加if (n 0) break;或等价判断不要把结束标记当成业务数据去处理。4.2 输出格式空格、换行、Case 编号的精确匹配输出格式是 HDU OJ 判题严格程度的重灾区。比 WA 更让人崩溃的是 PE你逻辑完全正确但因为多了一个空格被判格式错误。最常见的三个坑每个样例输出之间需要空行还是连续输出题目里会写“blank line between cases”这通常意味着最后一个样例之后不能有多余空行。Case 1:和后面的数字之间用冒号加空格还是冒号不加空格看样例输出它长什么样你就得原样复刻。行尾不要有空格。很多人在最后一组数据的输出末尾也加了一个空格判题机会认为多余字符而报 WA。写代码时我习惯用变量记录当前是第几个测试用例然后统一用这样的结构int caseNo 0; while (cin n) { if (caseNo) cout endl; // 第二个样例开始才输出空行 cout Case caseNo : result endl; }这样能精确控制空行的位置。另一种控制方式是在每次样例结束时输出换行如果题目要求样例间空行就把printf(\n)放在除了第一个样例之外的位置避免最后多一个空行被 PE。4.3 数据范围与类型选择int 不够用的典型场景HDU OJ 的很多题目会用到 32 位整数存不下的结果比如 1001 题计算从 1 加到 nn 最大可取到 10 万直接int sum n * (n 1) / 2;在 n50000 时就已经溢出。正确姿势是提前把一副输入的数据转换成long long#include iostream using namespace std; int main() { long long n; while (cin n) { long long sum n * (n 1) / 2; cout sum \n\n; } return 0; }注意我在读取时就用了long long这样乘法不会先把中间结果存到 int 里再扩容。这类题目在 HDU OJ 上有个特点故意把样例数值给得很大本地测试时你用手算或者普通 int 跑不出来一提交回来一个 WA就是因为你没看题目末尾的 “The input may be very large” 提示。还有一种情况是结果本身在 int 范围内但中间计算过程会溢出。比如算组合数分子分母分别乘的时候就已经爆了 int解法是先约分再乘或者直接全用long long。我的原则是凡是不确定数据范围一律long long起步要用数组时预估需求的 1.5 倍大小开宁可多占内存不要越界。关于输入输出还有个小技巧HDU OJ 的样例输入文件里有时候会有看不见的空白行如果你用scanf读取时被空行干扰可以在格式串里加\n或者用while (scanf(%d, n) ! EOF)配合getchar()处理。这层坑在遇到字符串题时会放得更大但那是进阶内容先把数值题吃透就够了。5. 避坑HDU OJ 判题常见问题与排查清单5.1 本地运行正常一交就 WA现象代码在 Dev-C 或 Visual Studio 里输入题目样例输出完全一致提交到 HDU OJ 返回 WA。原因最常见的是多组输入问题。本地运行时你以为程序只处理一组数据于是用了cin n; for(...)的单次逻辑但判题机把整个测试文件喂进来你的程序只读了第一个测试用例剩下全部没处理。另一种是输入里有看不见的空格或换行你用cin 读取字符时自动跳过了空白但题目要求你处理字符串中的空格这种情况要用getline而不是。解决先确认题目是否包含 “multiple test cases” 或 “EOF” 字样是的话改成while (cin n)或while (scanf(...) ! EOF)。其次把样例复制到记事本里关掉自动换行检查行尾有没有多余空格。最后如果你用了getline混用cin 记得在中间加一个getchar()或者cin.ignore()吸收换行符。5.2 逻辑“对”但 TLE现象自己写了段能出结果的代码数据量小时秒出提交后 TLE。原因算法复杂度太高。比如用冒泡排序处理 10 万条数据或者用递归算斐波那契而不做记忆化。另一个原因是输入输出流太慢cin默认和stdio同步频繁读写会浪费时间。解决先看数据范围写复杂度低于 10^8 的算法。然后加ios::sync_with_stdio(false); cin.tie(nullptr);如果题目数据量极大直接用scanf/printf。如果这两步都做了还是 TLE就要换思路比如把线性扫描改成二分查找或者用前缀和把多次区间求和从 O(n) 降到 O(1)。5.3 莫名 RE可能是数组越界或递归过深现象代码本地跑得好好的提交后进程异常退出报 RE。原因RE 在 HDU OJ 上多是段错误即访问了非法内存。常见两个来源数组开小了题目给出的最大 n 是 100但你只开了int a[10]或者递归函数里没有设置出口栈溢出。解决把数组开到题目最大范围的 1.2 倍以上这个不是玄学是为了防止边界索引。递归过深时把递归改成循环或者去查是不是出现了死循环调用。另一种隐蔽情况是除以零题目没有声明分母不为零时记得在代码里做判断if (b 0) continue;这种防御式写法在 HDU OJ 上很实用。5.4 long long 还是 __int64是个编译器问题现象有的代码在本地用__int64能过提交到 HDU OJ 报编译错误或者反过来用long long在本地 Windows 编译器上报错。原因老旧的编译器对视窗环境的__int64支持各不相同HDU OJ 的判题环境以 Linux 下的 G 为主标准写法是long long输入输出用scanf(%lld, x)或cout。Windows 下 Visual Studio 能识别__int64但在 %lld 上行为不一致容易翻车。解决统一使用 C 标准里的long long输出用printf(%lld\n, sum)或cout sum。如果你在旧代码里看到__int64直接全局替换成long long这是最省心的处理方式。这四条是 HDU OJ 刷题初期的最大障碍每一条我都踩过。尤其是 5.1我在 1000 题上浪费过一下午后来把“先写多组输入骨架”变成肌肉记忆WA 率才降下来。6. 把 HDU OJ 变成自己的训练系统本地测试与补题技巧6.1 用对拍脚本验证代码随机数据生成器与比较脚本刷题到一定阶段你会发现样例过、提交 WA 是最痛苦的循环。为了把这种循环压到最短我强烈建议在本地搭一个“对拍”环境写一个随机数据生成器两个程序分别跑同一份数据比对输出。下面是一个最简单的对拍脚本放在 Linux 或 Windows 的 WSL 里跑# 数据生成器 gen.cpp编译为 gen # 你的题解 sol.cpp编译为 sol # 暴力程序 brute.cpp编译为 brute while true; do ./gen input.txt ./sol input.txt out_sol.txt ./brute input.txt out_brute.txt if diff -q out_sol.txt out_brute.txt /dev/null; then echo AC on this test else echo WA found! break fi done这个脚本的思路是用生成器造出大量小规模随机数据brute程序用最简单的算法保证正确但可能慢sol是你的优化程序两个输出不同就说明sol有 bug。这里要注意生成器本身不能生成超出题目要求的数据范围否则brute也会被拖垮。实际使用中我会先让brute和sol跑 1000 组随机小数据如果全部一致再把数据规模放大只跑sol验证性能。对拍脚本是刷题过程中的后悔药能让你在提交前发现绝大多数 WA比在判题机上反复试错快得多。6.2 补题与错题整理一份可检索的刷题清单我见过太多人刷题只刷不补AC 之后再也不看第二眼。实际上HDU OJ 题库的价值不在于刷了多少题而在于你把自己的错题整理成了什么形状。我个人的做法是维护一个本地表格字段包括题号、题目名、状态、我的错误原因、正确解法类别、是否值得二刷。每周五晚上把这一周的错题重新做一遍做不出来的题标红两周后再次复习。这个表格不需要什么高级工具Markdown 或 Excel 都行重点在于最后三列。如果你发现自己反复在“输出格式”上出错那说明读题时没有把样例输出逐字符对比如果反复在“数组越界”上出错说明你对数据范围的敏感度不够下次开题时先写数组大小。这种归纳比单纯刷题更能指向能力短板。6.3 收尾我的习惯与一句劝告刷 HDU OJ 的过程中我养成了一个最基础的验收标准任何一道题AC 之后我会强迫自己写出“这题考什么 复杂度多少 边界条件是什么”三行笔记。这个习惯帮我养成了对每道题的正确认识而不是只记住题号。有个教训是我至今记得的有一道排序题我用sort能过所有样例但一交 WA后来发现题目要求稳定排序而sort不是稳定的必须用stable_sort。从那时起我每一次读题都会关注题目里有没有“保持原顺序”之类的措辞。这种细节恰恰是 HDU OJ 题库想教给你的——它不提供任何提醒你要自己负全责。希望这些从输入输出到对拍、再到整理错题的经验能帮你在 HDU OJ 上少走一些弯路。刷题是一份长期投入但每次 AC 时那种豁然开朗的感觉值得你为它付出的时间。本文还有配套的精品资源点击获取