第 2 / 9 篇
整理于 · 8 分钟
导入流程怎样逐步变得可靠
一次上传如何支撑多次补录、历史录入与防错审查
贯穿项目的约定 本篇涉及 2 条
在教务工作中，成绩导入是使用频次最高、也是最容易出错的环节。最初的设想往往十分单纯：用户选择一个 Excel 文件点击上传，系统后端解析表格并存入数据库。但在真实的教学运转中，这种粗粒度的模式很快就会遇到各种边界问题：
- 一场期中考试可能由不同学科组在不同时间分批提交；
- 教师可能补录上学期的历史考试，也可能需要修改某几位学生的录入错误；
- 表格中可能包含多个工作表（Sheet），部分是草稿，部分才是正式成绩；
- 同一个文件可能被不同人重复上传。
为了应对这些现实挑战，SCORE 的成绩导入流程经历了一系列从粗放到严谨的模型演进。
1. 一次上传是否等同于一场考试？
在系统最初的设计讨论中，曾出现过两种极端的模型假设：
- 简单模型：一次文件上传就直接对应生成一条考试记录。这种方式操作路径最短，但无法应对“语数英分三次上传到同一场期中考”的现实情况。
- 严格批次模型：要求教务人员必须先在系统里建立一个“考试批次”，定义好考试名称、涵盖学科、年级和满分，随后各科教师只能往该批次下追加数据。
严格批次模型便于统一管理，但需求讨论还要考虑周测、随堂小测和单学科考试。如果每次上传都必须先建立批次，轻量录入也会多出一段准备流程。模型选择因此需要同时照顾单次上传与分批归集。
最终，系统采取了**“默认新建，显式追加”**的务实方案：
- 默认情况下，每次上传独立成绩表均作为一次新的考试记录处理；
- 若需要对既有考试补充学科或缺漏学生，教师可以在操作界面中显式选择“进入补录模式”，并指定目标考试；
- 若需要修订已有考试中的错误分数，则进入专门的“成绩更正模式”。
新建、补录与更正分别对应不同的写入范围，教师可以按录入目的选择流程；分批成绩也有了明确的归集目标。
2. 考试时间与上传时间：双时间轴的引入
在录入历史学年或补录既往成绩时，常常会出现一个容易被忽视的问题：数据是什么时候录入系统的，并不等于这场考试发生在什么时候。
如果系统仅使用当前上传时间戳作为时间轴：
- 今天录入的上一学年期末考，会被错误地画在今日学情趋势图的最右侧，彻底破坏历史波动的真实趋势；
- 录入旧成绩时，若直接套用学生当前的所在班级（如学生现已升入高三），会导致高一时的考试被错误归属到高三班级下，导致历史班级比对失真。
为此，系统确立了清晰的双时间轴与班级快照机制：
- 考试时间（Exam Date）：记录考试实际发生的日期，用于全局时间排序、跨考试学情趋势、历年同期对比与归档归类；
- 上传时间（Upload Timestamp）：记录文件被提交入库的操作时刻，仅用于系统审计与操作留痕；
- 历史班级快照：成绩记录中永久固化考试发生时学生所在的班级，学生档案中的“当前班级”变化不会回溯篡改历史成绩的班级归属。
3. 导入管道：可阻断、可预览、可审查的多阶段流程
将 Excel 文件安全转化为数据库记录，不能依赖一次黑盒式的提交。SCORE 将导入拆解为清晰的链式管道：
- 多 Sheet 识别与灵活选择：许多教师习惯在一个工作簿中保留“总表”、“原始分”、“赋分后”、“草稿”等多个 Sheet。系统允许用户逐页预览，自由选择仅导入某一张、跳过某些 Sheet 或提交全部校验通过的 Sheet。
- 结构识别与异常阻断：自动识别学科列、满分行与异常值（如超出满分范围、非法字符等）。一旦发现阻断性错误（如关键列缺失、学号冲突），必须在预览阶段明确标红并拦截提交，杜绝脏数据入库。
- 差异比对与写回审查：特别是在更正或补录模式下，系统在提交前必须展示“变更对照表”——清晰标明“学生张三，数学原分数 85，本次修改为 92”。操作者核对无误后方可落库，确保每一次修改都心中有数。
4. 补录与更正的边界
补录与更正在底层数据语义上有着本质区别，系统对二者施加了不同的约束：
| 模式 | 面向的场景 | 允许的操作范围 | 严格受限的行为 |
|---|---|---|---|
| 补录模式（Append） | 既有考试中缺少某些学生或某些学科明细 | 向目标考试中追加新学生、新学科成绩 | 不允许静默覆盖既有学生的已有学科分数 |
| 更正模式（Correction） | 既有考试中某些学生的分数录入有误 | 仅修改目标考试中已存在学生的目标学科分数 | 不允许顺带新增学生档案或扩充新学科；异常分值严格阻断 |
此外，对于已归档的历史考试，系统实行只读保护：若需修改，必须先由具备权限的管理人员将其恢复为可编辑状态，再通过更正流程修改，防止日常操作无意污染历史归档数据。
5. 反馈可见性：从工程细节到用户信任
在系统演进过程中，曾暴露出一个交互缺陷：导入提交成功后，前端立即卸载预览区域并重置表单，成功提示也随预览组件一同消失。写入已经完成，操作者却可能看不到结果，从而误以为上传未生效。记录确认的是提示的生命周期问题，没有记录由此造成的重复数据规模。
修复把提交反馈移出临时表单和预览容器，使预览关闭后结果仍然可见。前端还在请求处理中禁用重复提交，收到结果后再恢复操作。这是页面层的在途保护，不能据此认为服务端已经具备跨页面、跨客户端的幂等保证。
这轮调整分别处理了考试归属、写入范围和结果反馈：历史数据按考试时间进入分析，补录与更正有各自的限制，提交结果不再依赖预览是否打开。后续页面与统计设计，才能在这些明确的数据口径上继续展开。