GitHub Classroom关停后怎么导出：别只备份代码仓库

GitHub Classroom 已于 2026 年 8 月 28 日停用，网站、API 和相关服务均已关闭。因此，依赖 Classroom API 的官方导出脚本现在不能重新拉取课堂数据；GitHub 的停用公告 同时明确，相关 GitHub 用户账户、代码仓库和组织不受影响，但课堂及作业名称、仓库外定义的测试、LTI 集成名册等 Classroom 专属数据会按数据保留政策永久删除。

现在可行的处理方式是：先查找关停前生成的导出目录，验收其中的 JSON、CSV 和成绩记录，再单独备份仍可访问的作业仓库。只有仓库副本，无法完整恢复课堂、作业、学生身份与成绩之间的对应关系；如果从未导出过 Classroom 元数据，则不能通过官方脚本事后补取。

先盘点现有数据，不要把仓库当成完整备份

首先在教师电脑、院系服务器、备份盘和自动化任务产物中搜索名称以 classroom-export- 开头的目录，以及 classrooms.json、accepted-assignments.json 和 grades.csv。同时列出仍可访问的课程组织和作业仓库，把两类资产分开登记。

Git 仓库可以保留代码、提交历史及仓库内的协作记录，却不等于 Classroom 数据仍然完整。课堂与作业的对应关系、学生接受作业的记录、名册标识和汇总成绩属于另一层数据；如果只找到仓库而没有导出文件，应将现状标记为“仓库可恢复，Classroom 元数据缺失”，不要根据仓库名称反推正式成绩或学生身份。

官方脚本原本需要什么，命令如何使用

GitHub 中文导出说明 给出的流程是设置 GitHub CLI、安装 GitHub Classroom 扩展、下载 Classroom Export Utility，并确认课堂数据已保存为本地 JSON 或 CSV。由于 Classroom API 已停用，这套步骤现在主要用于核对旧操作日志、脚本副本和已有导出包，不能作为在线恢复通道。

脚本运行环境包括 GitHub CLI、Classroom CLI 扩展和 jq，还需要有效的 GitHub CLI 身份验证。旧环境或执行记录可依次用 gh --version、gh extension list、jq --version 和 gh auth status 检查；安装扩展与认证所用命令分别是 gh extension install github/gh-classroom 和 gh auth login。

Classroom Export Utility 的 README 列出了原始用法：首次运行前执行 chmod +x export-classrooms.sh；用 ./export-classrooms.sh 导出全部可管理课堂；先以 gh classroom list 查询课堂 ID，再用 ./export-classrooms.sh -c 12345 导出单个课堂；指定目录则使用 ./export-classrooms.sh -o ./my-export。这些命令适合写入归档说明，但现在执行时无法绕过已关闭的 Classroom API。

完整导出包应该包含哪些文件

官方工具生成的是按课堂 ID 和作业 ID 分层的元数据目录，而不是一批克隆下来的 Git 仓库。默认顶层目录名称带有导出时间戳；如果曾使用 -o 参数，则目录名可能由执行者自行指定，不能只按默认名称搜索。

• 顶层的 classrooms.json：记录课堂 ID、名称、归档状态、URL 和组织信息。
• classroom-<ID> 目录中的 classroom.json 与 assignments.json：分别保存单个课堂详情及该课堂的作业列表。
• assignment-<ID> 目录中的 assignment.json：保存单项作业详情。
• 同一作业目录中的 accepted-assignments.json：保存学生或小组的接受记录、提交状态、提交次数、成绩、学生信息和仓库 URL。
• 同一作业目录中的 grades.csv：保存作业名称、GitHub 用户名、名册标识、仓库、提交时间以及已得分数和可得分数。

因此，“别只备份代码仓库”不是泛泛提醒：仓库能够证明代码如何变化，却不能单独重建账号与名册成员的对应关系、接受作业的状态以及导出时的成绩字段。

逐项验收 JSON、CSV 和目录关联

验收目标不是确认文件“能够双击打开”，而是确认结构完整、内容可解析、ID 能关联、缺口有记录。先保留一份只读原件，在工作副本上检查，并将异常文件名、检查命令和处理结果写入单独的验收记录。

1. 检查目录层级。确认顶层存在 classrooms.json，每个预期课堂有对应的 ID 目录，每个作业目录包含作业详情、接受记录和成绩文件。零字节文件、缺失目录和无法读取的文件应单独列出。
2. 验证 JSON 语法。对每个 JSON 文件执行 jq empty 文件名；命令无报错只能证明语法可解析，还应以 jq 'length' classrooms.json 等命令查看记录数，识别合法但异常为空的数组。
3. 核对 ID 关联。抽查 classrooms.json 中的课堂 ID 能否对应 classroom-<ID> 目录，作业列表中的 ID 能否对应相应作业目录；接受记录中的仓库 URL 应与仍存在的 GitHub 仓库相符。
4. 检查 CSV。确认 grades.csv 的表头、分隔符、换行和 UTF-8 字符没有被电子表格软件改写，并抽查含逗号或非 ASCII 字符的名册标识是否发生错列。
5. 做范围对账。按课堂统计作业，再按作业比较接受记录数、成绩行数和实际仓库数。三者不必相等，例如未接受、未提交或未评分都可能造成差异，但每项差异都应能解释并记录。

验收后可为只读原件生成 SHA-256 校验清单。以后复制、解压或迁移时重新计算并比较校验值，可以发现文件被改写、遗漏或损坏；通过标准应是文件可解析、关键 ID 可关联且所有缺口均有记录，而不是强求各类记录数量完全相同。

学生标识和成绩必须受控保管

accepted-assignments.json 和 grades.csv 可能同时包含学生信息、GitHub 用户名、名册标识、仓库地址、提交时间与成绩。这些文件不应提交到公开仓库，也不宜放入任何获得链接即可访问的共享目录。

保管上，建议留存一份加密、只读的原件，仅向课程负责人和获授权的迁移人员开放；分析或格式转换使用受控副本，在不需要身份映射时删除或替换名册标识。具体保留期限、删除审批和访问记录应遵循学校的数据治理制度，不能因为载体是 JSON 或 CSV 就按普通技术文件处理。

迁移时分开处理仓库与课堂元数据

迁移到新教学平台或自建流程时，应拆成两条轨道：一条处理 GitHub 仓库及其权限，另一条映射课堂、作业、学生和成绩字段。可先建立“旧课堂 ID—新课程 ID”和“旧作业 ID—新任务 ID”的对照，再转换成绩文件，避免同名课程或重复作业被错误归属。

如果没有关停前的 JSON、CSV，只能从仍存在的账户、组织和仓库中恢复可验证内容，并从学校 LMS、成绩系统或合规备份补齐名册与成绩。不要用仓库命名规则作为学生身份的唯一证据，也不要补造无法追溯的记录；如果已有完整导出包，则应先完成验收并封存原件，再针对目标平台制作转换副本。