简介：面向K12阶段学生与教师的教材资源查询下载工具，适配Windows 10及以上系统。软件围绕国家中小学智慧教育平台设计，支持按学科、年级、出版社等条件筛选定位教材，并将所需课程资料批量保存至本地，有效缓解网络不稳定时在线浏览的困扰，便于教师统一整理备课素材、学生自主开展课前预习与课后复习。压缩包为7z格式，共73个文件，以58个pak界面与语言资源文件为主，辅以6个dll运行库、2个exe主程序、2个bin数据文件及asar、json、html等配置模块，整体约68.96MB，结构符合Electron应用打包特征；压缩包内含「课本下载器.exe」主程序及完整运行组件，解压后即可启动使用。目前已有2267人学习下载，为需要系统收集国家平台课件、习题和视频课程，并希望在离线环境下可持续使用的师生，提供便捷的本地化获取与归档方案。

1. 教材查询下载器v3.1.0在win10上到底解决什么：从“只能在线翻页”到“离线PDF”

大家都去过国家中小学智慧教育平台找教材，网页做得挺流畅，但想存一份PDF却找不到下载按钮，只能一页页截图。这不是平台缺功能，而是它把教材拆成了“按需加载的在线资源”，你有网就能看，没网就抓瞎。教材查询下载器v3.1.0就是在这个背景下被做出来的工具：它把官方平台的书目接口拉通，在win10系统上把教材逐页抓下来，再合并成本地PDF。它适合三类人：准备课件的老师、给学生打印资料的家长、以及需要批量归档教材的教育信息化管理员。下面我把这套东西的原理、参数和坑一次讲完。

2. 搞清楚它的工作方式：官方教材数据流与win10运行环境

2.1 官方平台的教材不是一堆PDF文件，而是一个动态书库接口

你在浏览器里看到教材封面、目录、内页，背后其实是前端通过JSON接口向服务端要数据。我拿这类下载器的行为反推过，它做的事情和你在Network面板里能看到的一模一样：

• 先请求“教材列表”接口，传入学科、年级、册次，拿到教材元数据（bookId、教材名称、版本、页数）。
• 再请求“教材详情”接口，拿到每一页的图片地址或PDF分片地址。
• 最后用多线程把图片/分片拉到本地，按页码顺序合并成一本完整的PDF。

这里有个关键点：为什么不能直接下载整本PDF？因为官方平台把整本书按页存储，甚至部分页走的是流式加载，并没有暴露“整本打包”的静态地址。下载器的作用不是破解，而是把网页端公开的逐页资源按顺序串起来，模拟用户逐页浏览而已。所以它要求你先有一个可用的官方平台账号，并且保持登录状态，否则只能拿到封面和几页公开预览。

2.2 win10环境怎么选：py源码跑还是打包exe跑

v3.1.0这个版本号，你会在网上同时看到两个形态：一个是不需要安装Python的绿色exe，另一个是带“py文件”的源码包。我的建议是：能用源码跑就优先源码跑。原因很简单——exe在win10上很容易被杀毒软件误报，而且出问题你根本不知道它内部卡在哪一步；源码虽然要配环境，但每步都能看到日志，排错快得多。

win10系统本身倒不挑版本，Home、专业版、LTSC 2021、22H2我都试过，只要不是那种过度精简的“Ghost版”，下载器都能正常跑。真正影响运行的往往不是Windows大版本，而是两个环境细节：

• Python版本：最低要3.8，因为这类下载器用到了f-string和dataclasses语法，3.7以下会直接SyntaxError。
• VC运行库：如果走exe，右键以管理员运行依然报“找不到VCRUNTIME140.dll”，那就要装一次微软VC++ 2015-2022运行库，这个在win10 LTSC上尤其常见。

提示：win10 22H2（内部版本19045）和LTSC 2021都能用，但LTSC默认没有应用商店，如果你需要登录辅助组件，别老折腾精简版，老老实实装完整版。

3. 在win10上把v3.1.0跑起来：最小命令与参数设置

3.1 准备工作：装Python、配置依赖、导出登录凭证

用源码跑，先确认Python能调用。打开CMD输入：

python --version

输出3.8或更高就继续。接着用pip装依赖，这类下载器的核心依赖其实只有三个：

pip install requests pycryptodome PyMuPDF

逻辑说明：requests负责HTTP请求，pycryptodome用来处理平台偶尔返回的加密参数（某些接口的token做了AES加密），PyMuPDF负责把下载下来的分页图片合并成PDF。这三个库缺一不可，缺了PyMuPDF你只能得到一堆jpg，得不到整本PDF。

然后处理登录。第一次建议用浏览器登录国家中小学智慧教育平台，登录后F12切到Network，找到任意一个接口请求，复制请求头里的Cookie，存成本地cookie.json。也可以直接在下载器里输入账号密码，它内部会走一遍登录流程并缓存token。我一般会选Cookie方案，因为下载器的登录接口如果遇到图形验证码会卡住，而浏览器里已登录的Cookie可以直接绕过。

3.2 最小下载命令：按bookId拉一本

cookie.json准备好了，先试最小命令：

python downloader.py --book-id 9787303234567 --cookie cookie.json --out ./pdfs

逻辑说明：book-id是教材在平台里的唯一标识，可以从网页地址栏的id参数里找到；cookie指定凭证文件；out指定输出目录，这里用相对路径pdfs。跑通后会在pdfs目录下生成一个以教材名命名的PDF文件。这条命令是下载器的“最小可用单元”，参数再复杂，最后都是落到这个基本动作上。

如果你连book-id都不知道，可以先用查询命令：

python downloader.py --list --subject 语文 --grade 1 --cookie cookie.json

逻辑说明：list模式会打印出所有匹配教材的bookId、教材标题和版本号。打印格式一般是：

[1] 9787303234567 统编版 一年级上册 [2] 9787303234568 统编版 一年级下册

用这个列表去对bookId，比去网页翻省事多了。

3.3 批量下载：按学科+年级+册次一次抓全

单本测试通过后，真正解放双手的是批量模式。比如下载小学语文全部册次：

python downloader.py --subject 语文 --grade 小学 1 2 3 4 5 6 --cookie cookie.json --out ./小学语文 --threads 3

参数再解释一遍：subject限定学科名，grade设成“小学”并显式列出1到6年级，下载器会把这些年级的语文学科全部教材列出来，再逐本下载。--threads表示并发线程数，这里设3，具体怎么调在第4章讲。输出目录用中文先回避，后面避坑章节会专门说为什么。

4. 参数怎么调才能又快又完整：线程、重试与合页逻辑

4.1 并发数与限速：不是把threads调大就一定更快

很多第一次用下载器的人，看到--threads第一反应就是设成8、16，结果下了几十页就开始报错或拿到空白图。常见做法是：默认3，最多不要超过5。平台对单IP的并发是有限流行为的，线程越高，越容易触发返回空数据；线程太低又确实慢。版本高一点的下载器通常还会带--sleep参数，用于每个请求之间主动休眠：

python downloader.py --book-id 9787303234567 --threads 3 --sleep 0.5 --cookie cookie.json

sleep的单位是秒，0.5表示每个请求之间停顿0.5秒。配合3线程，实测下载一本120页的教材大约需要3到5分钟，不快，但稳。如果你是办公网络出口，后端是共享IP，请求频率再低一点，--sleep 0.8比较安全。

4.2 重试参数：对图片型教材是保命选项

这个平台的教材内页大部分是扫描图片，偶尔会有某一张图片因为CDN边缘节点缓存不一致而返回404或者损坏的字节流。没有重试机制，下载器就会把这张图记为“成功”然后在合并PDF时留下一张白纸或直接报错退出。所以下载参数的底线是：

python downloader.py --book-id 9787303234567 --retry 5 --retry-interval 2 --cookie cookie.json

--retry 5表示对同一页最多重试5次；2表示两次重试之间间隔2秒。如果连续5次都失败，下载器会把该页的状态标记为failed并且继续下一张，最后在日志里提示。注意这个“继续下一张”的行为，单本下完了你还能手工补；但如果你带着failed标记去合并PDF，那这本教材就是缺页的，所以第6章的校验步骤不能省。

4.3 输出格式与合页顺序：临时文件命名决定PDF是否乱页

下载器在拉取分页时，会在临时目录里生成类似“page_1.jpg”“page_2.jpg”的临时文件。这里有个隐藏参数，--page-prefix，可以控制临时文件名的结构。默认是补零的4位数，也就是“page_0001.jpg”，这样做是为了最后按字典序合并时不会出现第2页排到第10页后面的情况。如果你改成了--page-prefix page_，那第2页和第10页在字符串排序时，page_10会排在page_2前面，最终PDF顺序错乱。

合并这一步用的是PyMuPDF，它的insert_image方法会把每张图片转成一个PDF页，最后统一保存。内存方面要注意：一本300页的教材，如果全部图片先读进内存再合并，占用会超过1GB。这类下载器采用的方式是边插入边保存，你不需要额外调参数，但千万别自己写脚本时把图片一次性Load成列表。

5. win10上跑下载器的5个高频坑：登录失效、杀软误报与中文路径

5.1 登录状态一天就失效，下载到一半报“未授权”

• 现象：批量下载进行到第3本时，日志里开始大量出现HTTP 401或403，强制续期也无效。
• 原因：平台登录token的有效期大约是8小时，如果你在前一天导出cookie后隔天才运行，token很可能已经过期了。另一个容易被忽略的原因是同一账号在浏览器和下载器里同时登录，后者把前者设备挤下线。
• 解决：每次批量任务开始前，先执行一次--check-login参数快速验证登录状态，返回OK再开跑。如果失效，重新在浏览器登录并导出新cookie；同时保证下载器登录期间不要在另一个浏览器里登录同一个账号。

5.2 Windows Defender直接把exe删了，其实不是毒

• 现象：双击绿色exe版下载器没反应，Windows安全中心的通知中心弹出“已隔离威胁”，被删文件是downloader.exe。
• 原因：这个工具用PyInstaller打包，没有数字签名，又带有网络请求和文件写入行为，很容易被Defender启发式扫描判定为“高风险”。这属于误报，但不要因此去关闭整个Defender，风险太大。
• 解决：在“病毒和威胁防护”的排除项里加两个路径：一是exe所在的文件夹，二是你计划的输出目录。更强制的做法是直接用python downloader.py跑源码，不碰exe。杀软误报的问题只会出现在exe形态上，源码形态不涉及。

5.3 输出目录写成中文，合并时频繁编码报错

• 现象：--out ./教材下载后，日志输出正常，但到合页阶段抛UnicodeEncodeError，PDF文件只生成了几页就中断。
• 原因：win10控制台默认编码是GBK，Python的sys.stdout默认也是GBK，当它尝试打印包含中文路径的报错信息时，编码转换炸掉。这不是下载器自身逻辑问题，是Windows环境的典型水土不服。
• 解决：窗口里先执行一行环境变量再运行下载器：

set PYTHONUTF8=1 python downloader.py --out ./shujiao --cookie cookie.json ...

如果不想每次设置，也可以在系统环境变量里新建PYTHONUTF8=1。还有一种根治办法：路径全部用英文，输出之后再用资源管理器重命名，这个最省心。

5.4 多线程下载后PDF页序乱掉，问题出在临时文件排序

• 现象：下载完成后PDF能打开，但第2页和第11页互换，页序看起来像洗过牌。
• 原因：临时文件名没有补零。我遇到过有用户自己改了--page-prefix成不固定长度，或者下载器版本里默认排序算法把字符串当字典序比较。默认配置通常没问题，但如果你合并前有手工清理临时文件的习惯，很容易留下这种坑。
• 解决：用默认的补零名称，合并前在脚本里对文件名进行自然排序（numeric sort），而不是字符串排序。检查方法：临时文件的page_0009和page_0010，ls命令看顺序必须是0009在0010之前，否则就是补零位数不够。

5.5 连续下载3本书后开始拿空白图，不是平台封你IP

• 现象：HTTP状态码都是200，但读取到的图片字节数为0，合并出来的PDF空白页连续出现。
• 原因：单IP请求频率短期过高，平台CDN的限流策略不是直接拒绝，而是给你返回一个空响应体。这比429封禁更恶心，因为它看起来像成功。
• 解决：把线程数降到2，--sleep加到0.8，并且每下载完一本执行一次--sleep-long 20，让平台喘口气。另外，别同时开着抓包或流量转发工具，那会改变请求频率特征，更容易触发限流。

6. 进阶：把下载器用成一个“可验证、可增量”的教材归档工具

6.1 下完不是结束，跑一遍页数校验再入库

下载到本地后，先别急着拷贝。写一个校验脚本，用PyMuPDF读出PDF实际页数，和平台元数据里的页数对比：

import fitz, json with open("meta.json", "r", encoding="utf-8") as fp: meta = json.load(fp) expected = meta["pageCount"] doc = fitz.open(meta["fileName"]) actual = doc.page_count doc.close() print(f"expected {expected}, got {actual}") if expected != actual: print(f"MISSING: {meta['bookName']}") else: print("OK")

逻辑说明：meta.json是下载器在每次任务结束后自动生成的，里面记录bookName、pageCount、fileName。这个脚本把所有教材的meta.json扫一遍，实际页数对不上的就是缺页或漏页，需要重新补下那本教材。这个习惯救过我很多次——有同事用下载器批量拉了200本教材，直接U盘拷贝走了，后来发现有3本因为中途遇到磁盘空间不足而缺页，全队人愣是用了好几周才自查出来。

6.2 增量更新：教材改版后只重下变化的那几页

教材不是一成不变的，统编版教材每年都有微调和页面替换。如果每次改版都整本重下，费时费力。如果下载器带了diff模式，用法是这样：

python downloader.py --book-id 9787303234567 --diff ./pdfs --cookie cookie.json

diff模式的逻辑是：先读取本地PDF的页数和每页图片的哈希值，再和平台线上元数据比对，发现某页哈希不同，就只下载这一页并替换。执行完后会生成一份changed_pages.txt，记录改了哪几页。这个模式特别适合学校教研组统一维护教材档案，线上版本更新后，备份目录自动同步，不用人肉核对。

6.3 定时同步：win10任务计划程序帮你每周自动归档

把整个流程脚本化，然后用“任务计划程序”挂成每周任务。我一般写一个bat：

@echo off cd /d D:\teaching\downloader set PYTHONUTF8=1 python downloader.py --subject 全部教材 --diff ./pdfs --cookie cookie.json --threads 2 --sleep 0.8

在win10里搜索“任务计划程序”，新建任务，触发器选“按周”，指定周一凌晨两点运行，条件里勾选“只有在计算机使用交流电源时才启动”，避免白天电量不稳定时把下载进程杀一半。

最后说一个我自己的教训：最开始用这个下载器时，我只关心能不能下载成功，完全不看校验，结果有一次拿着缺了十几页的PDF去打印课件，课上到一半才发现图不对。从那以后，我给自己定了个规矩：任何通过工具批量生成的教材文件，必须经过页数校验才算“完成”，宁可慢几分钟，也不让坏文件进入自己信任的目录。希望这套参数和避坑经验对你也有用——下载器只是省力工具，但最终对内容负责的还是你自己。希望帮到你。

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