简介：面向蓝桥杯参赛者与算法训练者的真题题库资源，已针对青岛大学在线评测系统QDUOJ完成适配，便于在真实OJ环境中模拟比赛、提交代码并即时获得评测反馈。压缩包共2个文件，包含JSON格式的题目数据文件与ZIP格式的测试用例包，整体大小约70.24MB；JSON用于存储题目标题、输入输出格式及限制参数，测试用例则提供多组输入输出对，供选手校验程序正确性。目前已有1345人学习下载，热度印证其训练价值。这份“修改版”题库整合了历年蓝桥杯真题及配套数据，参赛者可将题目与用例导入QDUOJ，按比赛规则进行限时训练，熟悉题型分布、时间与内存限制等评测细节。通过反复调试与对比期望输出，能有效提升算法实现和查错能力，为蓝桥杯及类似ACM赛事打下扎实基础。

1. 蓝桥杯刷真题最怕没环境：这份 QDUOJ 题库包解决整卷模拟

蓝桥杯备赛刷题，最烦的不是题难，而是真题散得到处都是。省赛前训练群里传的「XX 年真题 PDF」缺题面、缺数据，想统一练还得自己粘题，光是排版就耗掉半条命。这份「蓝桥杯题库 for QDUOJ（修改版）」把历年真题整理成 QDUOJ 可识别的题目包，导入后本地 OJ 按年份、组别整卷刷题，评测直接给结果，填空题和编程题都能判。适合三类人：冲省一的参赛学生、带队训练的老师、自己搭 OJ 的运维党。没搭过 OJ 也没关系，照着第 3 章的 Docker 流程走，两个小时以内能跑起来。

2. 题库包的核心是 testdata：先看懂 QDUOJ 怎么组织题目再动手

2.1 一道题在 QDUOJ 里由什么组成

判断一个题库包能不能用，先要理解 QDUOJ 的一道题不是「一段题面 + 一个答案」，而是由三块拼起来的：数据库里的一条 Problem 记录、存放在 media/testdata 目录下的测试数据、以及题面里可能引用的图片等静态资源。

关键在test_case_id这个字段。它是一串随机字符串，Problem 表里存一份，media 目录下有一个同名文件夹，两边靠它关联。Judge Server 拿到用户提交后，去media/testdata/{test_case_id}/下面读1.in、1.out、2.in、2.out这些文件做评测，而不是用题面里展示的样例。也就是说，真正决定一道题能不能判对的是 testdata，不是前台那两行示例。

很多人在这一步犯了先入为主的错：以为把题面粘进去、样例能跑通就算导入成功。实际上蓝桥杯编程大题的数据点通常在 10 组左右，包含边界、超限、特殊构造，分散在多个.in/.out文件里。题库包的核心价值就在这里——数据点被手动整理过，而不是你重新去网上找答案反推。

2.2 题库包的 XML 题面：字段对应关系与导入格式

QDUOJ 后台逐题编辑时，你需要填写标题、题面描述、输入说明、输出说明、样例、时限、内存限制等字段。批量题库包则把这些信息统一写进一份 XML 文件，每一题对应一个目录，目录下放着problem.xml和 testdata 数据。

├── 2019_province_c/ │ ├── 01_result_fill/ │ │ ├── problem.xml │ │ └── testdata/ │ │ ├── 1.in │ │ ├── 1.out │ │ └── ... │ └── 10_programming/ │ ├── problem.xml │ └── testdata/

下面是一份典型的problem.xml内容，以蓝桥杯经典真题「龟兔赛跑预测」为例：

<?xml version="1.0" encoding="UTF-8"?> <problem> <!-- 标题，对应 QDUOJ 的 title 字段 --> <title>龟兔赛跑预测</title> <!-- 题面描述，保留蓝桥杯原题的 HTML 结构 --> <description> 话说这个世界上有各种各样的兔子和乌龟，但是研究发现， 所有的兔子和乌龟都有一个共同的特点——喜欢赛跑。 于是它们经常举办赛跑比赛... </description> <!-- 输入说明 --> <input>第一行包含三个整数 L R T，分别表示赛道长度、兔子速度、乌龟速度</input> <!-- 输出说明 --> <output>输出大写字母 T 表示乌龟赢，R 表示兔子赢，D 表示平局</output> <!-- 时限单位毫秒，内存单位 KB --> <time_limit>1000</time_limit> <memory_limit>65536</memory_limit> <!-- 展示用样例，与判题数据分离 --> <samples> <sample> <input>10 5 20</input> <output>D</output> </sample> </samples> <!-- 数据目录标识，导入脚本靠它定位 testdata 文件夹 --> <testdata_dir>testdata/guitu_saipao</testdata_dir> </problem>

各字段和 QDUOJ 后台表单的对应关系很简单：time_limit直接进 Time Limit，单位是毫秒；memory_limit单位是 KB，65536 就是 64MB；samples用于前台展示，用户打开题目看到的输入输出示例来自这里。真正评测用的是testdata_dir指向的目录。

testdata_dir这个标签是题库包的约定写法，QDUOJ 原生没有。它的作用是让导入脚本知道这道题的数据放哪，然后在写入数据库前把整个数据目录复制到media/testdata/{随机生成的 test_case_id}/下。整个导入流程的难点不是读 XML，而是维护这条目录映射关系。

2.3 为什么同一份题包能在 QDUOJ 和 hoj 系 OJ 之间复用

「蓝桥杯 hoj」这个关键词经常和这份题库一起出现，原因在于 hoj 系的评测系统数据组织方式高度同构。HUSTOJ、HDUOJ 这类系统同样是「题面 XML + 编号数据点」的结构，只是目录命名规则不同：QDUOJ 用随机字符串，hoj 系常用纯数字题目编号。

我一般会维护一个适配层，把从题库包解析出来的数据结构先转成中间格式，再按目标 OJ 的字段名输出。QDUOJ 要的是test_case_id，HUSTOJ 要的是problem_id，核心数据点文件完全不用动。这就是为什么这类题库包一发出来，既有人说「QDUOJ 能导」，也有人说「hoj 能用」——数据本身是通用的，适配成本只在一个映射函数。

修改版题库通常改的就是映射层的坑：原包字段名跟 QDUOJ 预期不一致、题面里残留 Markdown 语法、数据点末尾没有换行符。这些改动恰恰是它比「裸真题集」值钱的地方。

3. 导入流程实操：Docker 部署 QDUOJ 到批量写入题目

3.1 用 Docker 拉起一个干净的 QDUOJ 实例

先要有一台能跑 QDUOJ 的机器，推荐 4 核 8G 以上的云主机或本地虚拟机。QDUOJ 依赖 MySQL、Redis、RabbitMQ 三个基础组件，手工装容易在版本兼容上翻车，常见做法是直接用官方仓库里的docker-compose.yml一键起。

git clone https://github.com/QingdaoU/OnlineJudge.git cd OnlineJudge/deploy # 按需修改 compose 里的端口映射，默认 80 端口容易和已有服务冲突 docker compose up -d docker compose ps

起服务后等一分钟，让数据库迁移完成，再打开http://服务器IP，应该能看到 QDUOJ 的首页。默认管理员账号需要到容器里创建：

# 进入 backend 容器，创建管理员账号 docker exec -it oj-backend python manage.py createsuperuser

这里有个参数要留意：docker-compose.yml里的 MySQL、Redis 端口如果和宿主机冲突，建议改容器内部映射，不要改容器间通信的 service 名，否则 backend 连不上数据库。部署阶段就把端口规划好，后面导入题库时少踩很多坑。

提示：如果之前部署过旧版 QDUOJ，先备份数据库再升级，题库导入和版本兼容问题处理起来要冷静得多。

3.2 解压题库包并核对目录结构

拿到题库压缩包后，先别急着导。我习惯先解压到固定目录，做一次完整核对，确认目录结构完整再写导入脚本。

mkdir -p /opt/lanqiao unzip lanqiao_qduoj_fixed.zip -d /opt/lanqiao cd /opt/lanqiao # 查看二级目录结构 find . -maxdepth 2 -type d | head -20 # 检查数据点文件数量，防止某些题目的 testdata 目录是空的 find . -name "*.in" | wc -l find . -name "*.out" | wc -l

核对重点有三个。第一，problem.xml是否每道题都有，缺题面的题目导入后前台直接空白；第二，.in和.out文件数量是否一致，不一致说明有题目数据被截断；第三，有没有assets或images目录，题面里引用的图片需要单独上传到后端媒体目录。

根据我的经验，.in和.out数量不一致是最常见的问题。有些题目的数据点是「多组输入对应一组输出」，目录里会多出几个.in文件，导入脚本需要跳过或手动确认。这一步核对花五分钟，能避免导入后排查一个下午。

3.3 批量导入：写脚本读 XML 写入数据库，再同步 testdata

QDUOJ 管理后台没有批量导入整包题目的功能，常见做法是通过 Django shell 写脚本处理。脚本逻辑分三步：解析 XML 生成题目对象、生成test_case_id并把 testdata 复制到媒体目录、最后保存数据库记录。

# manage.py shell 环境下执行，字段映射见 QDUOJ 的 Problem 模型 import os import random import string import xml.etree.ElementTree as ET from oj.models import Problem BASE_DIR = "/opt/lanqiao" def random_case_id(length=12): """生成随机 test_case_id，与 testdata 目录名保持一致""" return ''.join(random.choices(string.ascii_letters + string.digits, k=length)) def import_problem(problem_dir): """导入单道题：返回 True 表示成功""" xml_path = os.path.join(problem_dir, "problem.xml") tree = ET.parse(xml_path) root = tree.getroot() # 从 XML 抽取字段，统一做 strip 清理空白 title = root.findtext("title", "").strip() if not title: print(f"[跳过] 缺少标题: {problem_dir}") return False # 检查是否已导入过，避免重复写入 if Problem.objects.filter(title=title, source="lanqiao").exists(): print(f"[跳过] 已存在: {title}") return False case_id = random_case_id() testdata_src = os.path.join(problem_dir, root.findtext("testdata_dir", "testdata")) testdata_dst = f"/data/testdata/{case_id}" # 注意 QDUOJ 的媒体目录挂载位置 # 复制数据目录 if not os.path.exists(testdata_src): print(f"[警告] 数据目录不存在: {testdata_src}") else: os.system(f"cp -r {testdata_src} {testdata_dst}") # 写入 Problem 表 Problem.objects.create( title=title, description=root.findtext("description", ""), input_description=root.findtext("input", ""), output_description=root.findtext("output", ""), time_limit=int(root.findtext("time_limit", "1000")), memory_limit=int(root.findtext("memory_limit", "65536")), samples=[{"input": s.findtext("input", ""), "output": s.findtext("output", "")} for s in root.findall("samples/sample")], test_case_id=case_id, source="lanqiao", # 用 source 标记来源，后续模拟赛筛选靠它 visible=True, ) print(f"[成功] {title}") return True

这个脚本有几个关键参数值得说明。source="lanqiao"是我加的分类标记，QDUOJ 的 Problem 模型原生支持 source 字段，用它区分题库来源，后面按年份或组别建模拟赛时直接按 source 过滤。time_limit默认给 1000ms，来自蓝桥杯官方对 C/C++ 组的时限要求；如果题库包在 XML 里写明其他值，以 XML 优先。

复制 testdata 用的os.system("cp -r ...")在生产环境不够优雅，建议换成shutil.copytree，并且先判断目标目录是否已存在，避免重复导入时把旧数据覆盖。正式批量导入前，先挑一道题跑一遍脚本，确认前台能打开、评测能出结果，再放量导入。

# 在 backend 容器内执行 docker exec -it oj-backend python manage.py shell

3.4 导入后自检：验证题面渲染和判题链路

批量导入完成后，不要只看数据库记录数。打开前台题目列表，随机点开三道题，检查题面是否正常渲染、样例是否展示、提交后能否正确评测。

# 通过 API 验证题目是否可见 curl -s http://localhost/api/problem/?offset=0&limit=10 | python -m json.tool | head -50

验证判题链路时，我一般会提交一份「抄样例」的代码。如果样例能过但判题全 WA，说明 testdata 挂载路径有问题；如果连样例都 502，说明 Judge Server 没起来或数据目录权限不对。这一步跑通，题库包才算真正落地。

4. 题目内容盘点：按组别、语言和题型决定刷题顺序

4.1 省赛与国赛真题的典型题型分布

蓝桥杯省赛卷子按「5 道结果填空 + 5 道编程大题」的结构组织，国赛也是这个框架。落到 OJ 上，每种题型的判题方式不一样，这在题库包里有明确体现。

和 PTA 那种散着刷的单题不同，这份题库按完整赛卷组织，每场 10 题之间是同一个时间压力下的难度递进关系。按年份逐套刷，练的是比赛节奏；按题型跨年份刷，练的是薄弱算法。

4.2 C/C++ 与 Java/Python 组的时限差异怎么处理

题库包里大部分题目的时限是按 C/C++ 组设置的，Java 和 Python 组在蓝桥杯官网一般有额外放宽，但 XML 里不会自动区分。导入到 QDUOJ 以后，我通常先把 Python 相关的题目时限手动改到 3 倍，Java 改到 2 倍。

# 批量修正 Python 组的时限，3 倍时间 from oj.models import Problem for p in Problem.objects.filter(title__contains="python组", source="lanqiao"): p.time_limit = p.time_limit * 3 p.save()

这个操作看起来简单，但最容易忽略。蓝桥杯 Python 组近年参赛人数增长很快，很多人拿 C 组的题直接练 Python，结果明明思路对了却超时，然后就怀疑是算法问题，实际是时限没校准。批量修改后再刷，反馈才有参考价值。

4.3 嵌入式、单片机等小众题型：题库不能替代的部分

蓝桥杯的嵌入式和单片机方向考的是现场编程和硬件调试，跟软件赛的纯算法题完全是两回事。很多人搜「蓝桥杯嵌入式第16届省赛题目」，找到的是硬件题，这类内容在这份题库里基本不存在，它覆盖的是软件赛 C/C++、Java、Python 三组的真题。

如果准备嵌入式或单片机方向，这份题库能帮你练的是 C 语言基本功，比如寄存器操作的位运算、状态机设计、定时器逻辑，这些会以普通编程题的形式出现。真要备考嵌入式省赛，还是需要一块开发板，把客观题刷完再配合硬件调试，指望纯 OJ 题库包是不够的。

5. 导入避坑记录：五处容易翻车的地方

5.1 导入后题目打开是空白页

现象：后台能看到题目记录，前台点进去题面区域一片空白。

原因：题面描述里残留了未闭合的 HTML 标签或 Markdown 语法，QDUOJ 的 Markdown 渲染器解析失败直接返回空内容。蓝桥杯真题的原文经常包含数学符号、上下标，整理时没有清理干净。

解决：写脚本遍历所有description字段，用html.parser做一次标签闭合校验，把非法标签直接剥掉。导入前先用safe过滤器预览一遍再入库。

5.2 样例能过，提交全 WA

现象：用题目展示的样例提交，本地跑通了，OJ 判全错。

原因：testdata 目录没有正确复制到media/testdata/{test_case_id}/下，或者挂载路径不对。Judge Server 实际读取的是和数据库test_case_id同名的目录，复制成别的名字，前端样例来自samples字段仍然正常显示，评测环节就全部迷路。

解决：进入容器检查目录：

docker exec -it oj-backend ls /data/testdata/<test_case_id>/

确认.in/.out文件数量是否和.in数量一致，再跑一次判题。从那以后我每次批量导入后都先抽查两道题的 testdata 目录。

5.3 Special Judge 题目没生效

现象：结果填空和部分旧赛制题目需要 SPJ，导入后评测返回 Compile Error 或直接判错。

原因：QDUOJ 的 Problem 模型里有spj布尔字段和spj_code字段，题库包的 XML 通常只标注了need_spj=true，没有附带 SPJ 的代码。导入脚本只读标准字段，spj默认 False，题目就按精确比对判。

解决：在导入脚本里加一段判断：

spj_flag = root.findtext("need_spj", "false").lower() == "true" if spj_flag: spj_code = root.findtext("spj_code", "") Problem.objects.create(..., spj=True, spj_code=spj_code)

SPJ 代码一般是一段 C++ 程序，QDUOJ 会把它编译成可执行文件放在 testdata 目录下。如果导入后发现 SPJ 题目报「Judge Error」，多半是编译环境缺头文件，检查 judge-server 容器里有没有装 g++。

5.4 内存限制 64MB 与实际运行矛盾

现象：某些 Python 解法在本地跑得好好的，OJ 上直接 MLE。

原因：题库包里的memory_limit沿用蓝桥杯 C/C++ 组的 64MB，Python 解释器本身内存开销大，64MB 根本不够。蓝桥杯官方对 Python 组的内存限制本来也有放宽，但题包数据没有改。

解决：批量把 Python 相关的题目内存限制调到 256MB，或者干脆统一放宽到 128MB 起步。这个参数在 QDUOJ 后台可以直接改，批量用脚本更省事。

5.5 重复导入导致题目 ID 错乱

现象：同一个题库包导了两遍，前台出现标题完全相同的题目，统计刷题记录时数据全乱了。

原因：导入脚本没有做幂等检查，跑一次就插一遍。QDUOJ 本身不限制标题唯一，因为不同 OJ 可能出相同题名的题目。

解决：导入前先按source="lanqiao"清空一遍旧数据，或者在脚本里加标题 + 来源的联合判断。我个人更推荐保留旧数据但在导入脚本里加exists()检查，这样中途失败可以安全重跑，不用连数据点一起删。

6. 把题库变成模拟赛：按周挑题与校准难度

题库导进去只是第一步，真正让它产生价值的是定期模拟赛。我一般用 Django shell 按阶段搭配题目：第一轮按年份整卷刷，第二轮按难度跨年份混合出题。

# 按难度和来源创建一场 2 小时的模拟赛 from datetime import datetime, timedelta from oj.models import Problem, Contest problems = (Problem.objects .filter(source="lanqiao", difficulty__lte=3) .order_by("?")[:10]) # 随机抽 10 道中等难度题 contest = Contest.objects.create( title="蓝桥杯中期模拟赛", start_time=datetime.now(), end_time=datetime.now() + timedelta(hours=2), visible=True, ) contest.problems.set(problems)

创建比赛前，我会先手工校准难度系数，把题库默认的难度和蓝桥杯真题实际通过率对齐。比如「龟兔赛跑」这种模拟题标 2 星，贪心和 DP 题标 4 星。校准的依据是后台统计的提交通过率，通过率低于 15% 的题往上调一星。

做完这些，这份题库包才算真正从「一堆 XML 文件」变成了「一个能反复用来训练的比赛环境」。从那以后，我每次拿到新的题库包，都强制自己先过一遍「单题导入 → 前台点开 → 交一发 AC 题」的自检流程，再整包灌进去，就再没翻过车。希望帮到你。

本文还有配套的精品资源，点击获取