简介：这是一份面向蓝桥杯竞赛选手的QDUOJ适配题库资源包，针对青岛大学在线评测系统优化调整，适合正在备赛、希望利用在线评测环境进行实战演练的读者。压缩包一共2个文件，整体约70.24MB。old_data.json 以结构化格式保存了历届蓝桥杯赛题信息，包含题目描述、输入输出格式、时间与内存限制等参数，使用者可以直接解析并了解每道题的考察要点；test_case.zip 则提供配套的输入输出测试样例，解压后导入QDUOJ，即可模拟真实比赛环境，提交代码并获取运行时间和内存消耗的即时反馈。目前已有1363人学习下载。对于希望熟悉蓝桥杯题型节奏、在正式比赛前进行高强度训练的选手而言，这份题库省去了自行搜索整理题目与样例的环节，能够直接聚焦算法实现和调试，有效提升代码正确率与解题速度。无论是初次接触竞赛的新手，还是需要查漏补缺的老手，这套题库都具备较高的实用价值。
1. 蓝桥杯题库 for QDUOJ（修改版）到底改了什么：直接可导入才是核心卖点
自建 OJ 的人都懂，真正劝退你的往往不是部署，而是“没有题”。蓝桥杯历年真题恰好是需求量最大的一类题目来源，但直接去蓝桥杯官方或其它竞赛站点扒题，导进 QDUOJ 大概率翻车：测试数据配不上、格式不认、答案文件缺失，或者题目描述里还混着官方在线系统的特判逻辑。这个「蓝桥杯题库 for QDUOJ（修改版）」解决的就是最后一公里——把蓝桥杯真题按 QDUOJ 能识别的方式重新打包，让你不用从零解析官方数据格式，后台直接导入就能开始训练。它的核心价值不是“题目多”，而是“改过之后能直接跑”，适合三类人：给自己实验室搭 OJ 的管理员、带竞赛队的教练，以及想在本地环境里刷蓝桥杯真题的选手。下面我会按 QDUOJ 的题目包结构、导入流程、踩坑排查和二次使用这条线展开，讲清楚这份修改版题库该怎么用，以及哪些地方你不能无条件信任。
2. 搞清楚 QDUOJ 的题目包格式再导入：JSON、TestData 与 Special Judge 的关系
2.1 QDUOJ 的“题目”到底是一个文件还是一个目录：zip 包里的三种内容
QDUOJ 的题目不是单个文件，而是一个有固定结构的 zip 压缩包。后台“导入题目”时，系统会解压这个包，读取里面的元信息并注册测试数据。理解这个结构，是你判断修改版题库有没有问题的前提。
一个标准导入包里通常有三部分内容，我整理成表格方便对照：
| 目录/文件 | 作用 | 是否必需 |
|---|---|---|
problem.json | 题目描述、输入输出说明、样例、时间/内存限制、题目类型等元信息 | 必需 |
testdata/ | 测试数据文件，按测试点组织，如1.in、1.out | 必需 |
spj/ | 特判程序（Special Judge），用于答案不唯一的题目 | 可选，依赖题目 |
problem.json是整个包的核心。QDUOJ 后台创建题目时填写的字段，在导入模式下几乎都能映射到这个文件里。常见的字段包括title、description、input_description、output_description、samples、test_case_score、memory_limit、time_limit。其中test_case_score定义了每个测试点的分值，QDUOJ 评测时会按这个结构逐点给分；memory_limit的单位是 MB，time_limit的单位是 ms，这两个单位特别容易在搬运题目时被搞错。
testdata目录是判题机真正读取的数据。QDUOJ 约定一个测试点由同名的输入文件和输出文件组成，例如1.in对应1.out，2.in对应2.out。系统在评测时会扫描testdata目录，按文件名将输入输出配对，然后依次运行选手程序做比对。这个配对逻辑意味着：如果你的 zip 里只有.in没有.out，导入能成功，但选手提交后拿不到分数；如果文件名大小写不一致，比如1.In和1.out，系统会跳过或匹配失败，表现出的现象就是“全 WA”。
spj目录是很多搬运题库最容易出错的地方。蓝桥杯有些题目不是简单地比对输出文件，而是检测某些数值在容差范围内，或者要求输出格式灵活（比如多解、顺序无关的集合）。这类题就需要特判程序。QDUOJ 的spj目录在旧版本中接受的是编译好的可执行文件，新版本则有些支持放源码自动编译，具体行为取决于你的部署版本。你拿到修改版题库后，最省事的验证方式是把spj相关的题单独挑出来，用一份已知能 AC 的代码在后台提交一次，确认特判逻辑真的生效了再批量启用。
弄完这一层你再看“修改版”三个字，就知道它到底在做什么了：把一个原本散落在官方系统里、格式不统一的题目库，重新整理成上述标准结构。所以拿到手先别急着解压看题面，先按这个目录结构核对一遍，比什么都管用。
2.2 “修改版”通常改在哪：答案修正、数据补全与格式对齐
很多人看到“修改版”会疑惑：题库不就是题目吗，有什么好改的？实际上，蓝桥杯历年真题从官方平台迁移到 QDUOJ，中间隔着好几层格式障碍。
第一层是评测方式不同。蓝桥杯竞赛系统有自己的一套评测内核，有些题目的判题基于特殊规则：比如输出结果可能不唯一、需要对浮点数做精度判断、或者按 JSON 结构抽取关键字段比较。这些题直接放进 QDUOJ 的默认文本比对模式下，选手代码即使逻辑正确也会被判 WA。修改版最常见的一项工作，就是给这类题目补上合适的 SPJ，或者改写输出样例，让 QDUOJ 的评测逻辑和原题意图对齐。
第二层是测试数据不完整。官方系统提供的数据可能包含多组样例、大数据点、边界数据，但搬运者在导出过程中难免丢文件。常见的“修改版”会在testdata里补齐这些缺失的输出文件，修正某些测试点的标准答案。判断补没补齐有个笨办法：解压后数一下1.in到N.in和对应.out的个数是否一致，不一致就说明数据有缺口。
第三层是元信息和题目描述。problem.json里的time_limit和memory_limit必须按 QDUOJ 的单位填写。蓝桥杯官方题目说明里的时间通常是“1 秒”，内存是“256MB”，到 QDUOJ 的 JSON 里就得写成1000和256。别小看这个换算，我把单位写反过一次，结果整道题的判题全部 TLE，怎么看代码都没问题，最后发现是限制被建成了1ms。
“修改版题库”的价值就在于帮你绕开这三层坑。但反过来说，你也必须对“改了什么”保持敏感：修改者是基于哪一年、哪些组别的题目做的整理？是全部题都带 SPJ，还是只修了数据？这些问题在导入之前不搞清楚，导入之后排查问题的成本会高出很多。我的习惯是，拿到任何修改版题库先做小批量验证——导入五道题，覆盖一道纯文本比对题、一道浮点题、一道大输入题，全部提交通过后再考虑全量导入。这在没有官方更新日志的情况下，是最可靠的质量判断方式。
3. 分两步把题库装进 QDUOJ：数据校验与导入命令
3.1 第一步：导入前校验题目包，缺什么一目了然
我不想一上来就教你怎么点后台按钮。因为“修改版”题库的质量参差不齐，如果你手里这个包在打包时就缺了文件，后台导入不会有任何报错，问题会一直潜伏到你开始交作业那一步。所以我在导入前会先写一个小脚本，把 zip 包的结构跑一遍，确认三件事：有没有problem.json，testdata里输入输出是否成对，以及time_limit、memory_limit是不是落在合理区间。
下面这个脚本是我常用的校验工具，直接放在题目包同目录下运行：
import json import os import sys import zipfile def check_problem_zip(zip_path: str) -> None: """检查 QDUOJ 题目包结构是否完整，输出缺失项。 参数: zip_path: 题目包文件路径，形如 ./problem_1001.zip """ with zipfile.ZipFile(zip_path, "r") as zf: names = zf.namelist() # 清理目录前缀，避免顶层文件夹名称干扰判断 normalized = [n.rstrip("/") for n in names] # 1. 必须是 problem.json 结尾的配置存在 has_problem_json = any(n.endswith("problem.json") for n in normalized) print(f"[check] problem.json: {'OK' if has_problem_json else 'MISSING'}") # 2. 收集 testdata 下的 .in / .out 文件，核对配对关系 in_files, out_files = [], [] for n in normalized: if n.startswith("testdata/") or "/testdata/" in n: if n.endswith(".in"): in_files.append(n) elif n.endswith(".out"): out_files.append(n) in_base = {os.path.basename(f) for f in in_files} out_base = {os.path.basename(f) for f in out_files} missing_out = sorted(in_base - out_base)[:5] missing_in = sorted(out_base - in_base)[:5] print(f"[check] testdata 输入文件: {len(in_files)} 个, 输出文件: {len(out_files)} 个") if missing_out: print(f"[check] 有输入但缺对应输出: {missing_out}") if missing_in: print(f"[check] 有输出但缺对应输入: {missing_in}") # 3. 读取 problem.json，检查关键限制参数 json_name = next((n for n in normalized if n.endswith("problem.json")), None) if json_name: with zf.open(json_name, "r") as f: data = json.load(f) tl = data.get("time_limit", 0) ml = data.get("memory_limit", 0) print(f"[check] time_limit: {tl} ms, memory_limit: {ml} MB") if tl < 100: print("[check] 警告: time_limit 小于 100ms，大概率单位或数值异常") if ml < 16: print("[check] 警告: memory_limit 小于 16MB，请确认是否合理") spj = data.get("spj", False) has_spj_dir = any(n.startswith("spj/") for n in normalized) print(f"[check] spj 标记: {spj}, spj 目录: {'存在' if has_spj_dir else '不存在'}") if spj and not has_spj_dir: print("[check] 警告: 题目声明 SPJ，但 zip 里没有 spj 目录") if __name__ == "__main__": check_problem_zip(sys.argv[1])这段脚本做的三件事对应我刚才说的三个检查维度。第一段用namelist()拿压缩包内部路径，目的是排除不同打包工具带来的差异——有些包多套了一层蓝桥杯/2023/...目录，直接按文件名判断会误报。第二段对testdata做配对统计，把.in和.out的文件名各取一遍做差集，能快速暴露“有输入没输出”的残缺测试点。第三段解析 JSON 后打印关键评测参数，time_limit小于 100ms 时基本可以断定单位写错或数值异常，因为任何真实可评测的题目都不可能给 1ms 限时。
运行方式是python check_problem_zip.py ./xxx.zip。如果输出里没有任何MISSING和警告，说明这个包结构上没问题，可以进后台导入；如果报缺文件，不要强行导入，回去找题的原始来源补全。注意脚本里的in_base - out_base只会帮你找到“多出”或“缺少”的文件名，不会判断.in和.out内容是否匹配——内容匹配只能靠评测验证，这是结构校验代替不了的。
3.2 第二步：后台导入、题型配置与评测回归
结构校验通过后，进入真正的导入环节。常见做法是先用“创建题目 → 导入文件”的方式，把 zip 包上传，QDUOJ 会自动读取problem.json并注册测试数据。这一步有个细节：不是所有 QDUOJ 版本都支持 zip 全量导入，旧版本可能只能手动创建题目后逐个上传数据文件。如果你的后台在导入时没有 zip 选项，就需要先手动建题再传testdata。我用的是导入 zip 的方式，按下面的步骤走最稳妥：
- 进入后台管理界面，找到“题目管理”或“导入题目”入口。
- 选择下载好的修改版 zip 包，保持默认的压缩格式，不要二次改后缀名。
- 上传后系统会解析
problem.json，这时检查题目列表里是否出现了对应标题。 - 打开刚导入的题目，逐个字段核对：
time_limit、memory_limit、标签、难度、题面里的样例。看到明显不符的直接在后台改。 - 先随机挑一道题提交一个能跑的代码模板，确认评测行为正常，再批量导入剩余题目。
第 5 步的“评测回归”绝对不能省。我的标准做法是导入后立刻用一段最朴素的 Python 代码做冒烟测试：对样例输入做print(input())之类的原样输出，再写一道只输出固定字符串的题验证 WA 分支是否正常。如果这道水题能 AC，说明评测链路通了；如果直接 CE 或 500 错误，多半是包的文件权限或目录层级有问题，后台导入并没有真正把测试数据落到判题机的数据目录。
这里必须说明一个 QDUOJ 的使用习惯：导入和真正“上线”是两件事。后台导入成功后，题目对普通用户是否可见，取决于你是否设置了题目状态和公开范围。你如果是给自己团队搭的 OJ，建议先把题导入到一个“练习”分类下，配好标签再开放。批量导入所有题目到公开区，一旦某道题数据有问题，影响的是所有人的做题信心。
4. “修改版”不等于完全可用：导入后常见的 5 个翻车点与排查
4.1 所有提交都是 WA：先别怀疑改错了，检查 testdata 配对
现象：题目导入成功，样例能过，但所有人提交任何正确代码都是 WA，且分数为 0。这不是代码问题，是评测数据问题。
原因：最常见的是testdata文件名不匹配。比如修改版在整理时，把输出文件命名成了1.out，但输入文件叫01.in，QDUOJ 按文件名逐一配对时找不到对应关系，导致每个测试点都拿不到正确输出。另一种可能是.out文件里带着 BOM 头、结尾多了换行符以外的字符，这些细节在文本比对模式下都会变成 WA。
解决：先用上一章的结构校验脚本看配对情况。如果配对没问题，单独解压一对in/out，人工核对输出内容是否合理。确认是文件缺失还是内容格式问题，再决定是补文件还是修正输出数据。修补之后重新打包导入，不要在原题上直接改数据，因为 QDUOJ 后台没有“单独替换测试点输出”的快捷入口，重导一次反而安全。
4.2 一提交就 RE / CE：SPJ 编译与格式问题
现象：普通题目一切正常，凡是需要特判的题目，选手提交后状态直接是 Runtime Error 或 Compile Error，而且不是个别选手，是所有人都这样。
原因：spj目录里的特判程序没有正常工作。修改版题库在重新打包时，如果 spj 是 C++ 源码，而你的 OJ 判题机没有安装对应编译器；或者 spj 是二进制文件，但和你判题机的架构不一致（比如在 x86 机器上编译完放到 ARM 机器上），评测进程拉起来就崩溃。还有个常见情况：spj 的退出码约定和 QDUOJ 版本不一致。
解决：确认你的判题机环境里有没有g++，查看 spj 文件是用什么语言写的。大多数 QDUOJ 部署文档明确要求 spj 以可执行文件形式存在，建议在你的判题环境里单独编译一次，把编译产物替换回 zip 包。如果没有把握，就直接放弃这类题的特判，改写题目描述，把输出要求改成“输出一个符合条件的结果”，配合文本比对也能训练，只是评判严格度低一点。
4.3 直接提示找不到题目文件：zip 顶层目录与大小写
现象：导入后台时提示成功，但用户一打开题目，页面报错或测试数据为空。
原因：zip 包在打包时多套了一层外层目录。比如你的包结构是蓝桥杯题库/某个题目/problem.json，导入后后台能读到 JSON，但testdata的相对路径全错。另外部分打包工具会把目录名大小写改写，比如TestData变成testdata，这在 Linux 服务器上是两个完全不同的路径。
解决：导入前打开 zip 确认testdata是否在压缩包根目录下直接出现。如果不是，就用压缩软件“解压到当前目录”再重新打成problem.json在根层的包，不要双击打开直接改，避免中间目录残留。重新打包后跑一遍校验脚本，脚本里已经处理了“清理目录前缀”，但你要看的是原始输出里的路径，确保它真的以testdata/开头。
4.4 时间限制和内存限制对不上：蓝桥杯时间维度 vs QDUOJ 单位
现象：某道题自己本地运行 0.8 秒能过，提交到 QDUOJ 直接 TLE；或者本地程序占用 300MB 内存，题目限制显示只有 32MB。
原因：单位换算错误。蓝桥杯题目描述里的时间通常是秒，QDUOJ 是毫秒；内存通常是 MB，但也有题目会写成 KB 或 GB。修改版题库出现这个问题的原因，多半是制作时把其他 OJ 平台的导出数据直接塞进 QDUOJ，没做字段映射。
解决：在后台打开题目，看到time_limit小于 100 的，十有八九就是把秒当毫秒填了。按原题官方限制重新设置：1 秒对应1000，内存在 QDUOJ 里填256。改完后做一次真实提交验证，别只看样例。这一步也是我为什么坚持导入后随机抽题跑一遍的原因——静态校验看不出这种逻辑错位。
4.5 题面乱了、中文变问号：编码问题
现象：导入后题目描述在网页上显示正常，但提交记录里的中文内容变成乱码，或者题面出现\uXXXX这样的转义字符。
原因：problem.json文件保存时用了 GBK 编码，而 QDUOJ 后台用 UTF-8 解析。大部分修改版题库能正常显示，是因为制作人已经转码了；但如果你自己二次修改过 JSON 文件，用 Windows 记事本另存为时很容易悄悄改成 GBK。
解决：用utf-8显式读写 JSON 并重新保存。在 Python 里打开文件加encoding="utf-8"，关闭用ensure_ascii=False写出，这是最不容易翻车的做法。改完后重新导入，不要在后台里复制粘贴修正，因为后台保存时会再次走转码流程，可能二次破坏数据。
5. 把这套题库用出价值：基于它自建“训练场”的进阶习惯
题库导入成功只是开始。蓝桥杯题目的价值在于历史真题的年份和组别差异，QDUOJ 的标签体系可以帮你把这个题库组织成真正好用的训练场。我会在导入后给每道题打三个维度的标签：年份（如2023）、组别（如省赛B组）、题型（如DP、贪心）。这样选手刷题时能按“先刷 2021 年省赛简单题”来过滤，而不是面对几百道题毫无头绪。
如果你要对题目做二次修改，记住一个原则：每次修改后都重新走一遍导入流程，而不是在后台改完就完事。后台修改只影响数据库记录，不会同步回 zip 包；你下次换个环境部署 OJ，所有修改都丢了。正确的做法是把修改内容维护在problem.json源文件里，后台只是验证结果。我自己的习惯是维护一个CHANGELOG.md，记录了每道题改过什么、为什么改。别小看这种笨功夫，过两周你就忘了某道题的 SPJ 是原版自带还是自己补的，到时候排查问题全靠这份记录。
还有个验证习惯值得提一下：定期抽查题目质量。我一般每个月随机抽 5 道题，不看题面，直接提交一份暴力解和一份最优解，对比两者的得分差异。如果暴力解得了满分，说明这道题的测试数据太弱，不适合作为竞赛训练题；如果最优解都拿不到满分，说明 SPJ 或数据还有问题。这种“对抗性回归”虽然费点时间，但能帮你把题库里潜在的地雷一个个排掉。
最后说一个我自己的教训：刚搭好 OJ 时，我把整个修改版题库一次性全量导入，结果有一道题的数据文件和另一道题重名，后台导入后覆盖了前面的测试数据，导致两道题共用一份数据，前后排查了两天才定位到。从此以后，所有批量导入我都坚持“小批试、中批验、全量上”三步走。这套题库值得投入，但前提是你把它当成需要持续运维的资产，而不是装完就完事的插件。希望这个思路和操作流程能帮到你，让你在 QDUOJ 上刷题、带队的体验顺一点。
本文还有配套的精品资源，点击获取
