Spring Boot新生报到系统实战：状态机、扫码报到与并发控制全解析

每年到毕业季，计算机相关专业选题里，管理信息系统这类“业务型系统”永远是刚需，而高校新生报到系统几乎可以算作经典中的经典。我之前做过一个类似的Spring Boot项目——面向某师范类高校的新生入学报到系统，从需求分析到部署演示跑完整套流程。今天就把这个项目的设计思路、核心代码逻辑和踩过的坑一起梳理出来。

如果你正在准备毕设，或者在学校信息化部门需要做一个迎新报名工具，这篇内容会比较对口。它不只是一堆CRUD，里面会涉及状态机流转、批量录取数据导入、二维码报到确认、实时统计看板、并发状态控制和权限设计等真实业务问题。把这些点讲清楚，无论答辩还是真正上线，都会更有底气。

1. 选题与整体架构：为什么新生报到系统是经典MIS选题

1.1 传统迎新场景存在的真实痛点

很多没有接触过学校业务的人，容易把新生报到想象成“登记一下姓名和电话”那么简单，但实际上高校迎新是一个典型的跨部门协作流程。新生到了学校之后，要完成身份核验、打印报到单、缴纳学费或办理绿色通道、分配宿舍、领取校园卡、确认院系班级信息、提交档案材料等多个环节。传统方式下，这些工作分散在体育馆、行政楼、各学院报到处，新生和家长拖着行李在各个窗口排队，工作人员则在纸质名单上找到该学生姓名后打勾确认。

这个模式的问题非常明显：

• 纸质名单无法实时汇总，学校领导想看“今天实际到了多少人”，只能等各学院人工上报，既慢又不准确。
• 新生信息分散在不同部门，招生办有录取数据，财务处有缴费数据，后勤有宿舍数据，但彼此割裂。报到现场工作人员无法快速判断“这个学生学费交了没有、宿舍分到哪一栋”。
• 数据重复录入严重，新生填一张纸质信息表，学院录入一次，宿舍登记又录入一次，既浪费时间又容易出错。
• 缺乏留存记录，报到完成后纸质单据归档困难，后续查证、退学处理、晚到报到都缺少系统支撑。

新生报到系统要解决的核心问题，就是把“身份确认—信息采集—资格审核—办理确认”这条链路搬上线，让各角色在统一平台上协同处理。作为毕业设计，它业务边界清晰、角色分明、功能可扩展，也符合Spring Boot这类企业级框架的应用场景，所以常年是MIS类毕设的热门选题。

1.2 技术选型：为什么是Spring Boot而不是其他方案

技术选型是毕设答辩中最常见的问题，导师大概率会问“你为什么用Spring Boot，而不是SSH或者Python Flask”。这个问题一定要能答得清楚。

Spring Boot的优势不在于它“新”，而在于它把Spring家族的配置复杂度降下来了，让开发者能快速搭建一个可运行的高校级Web应用。起步依赖机制让你只需要在pom.xml里声明需要的starter，框架自动装配好内嵌Tomcat、数据源、日志等组件。YAML配置替代了大量XML，对于一个以业务逻辑为主的系统，开发效率提升非常明显。

前后端方案上，我建议使用前后端分离：后端Spring Boot提供RESTful API，前端使用Vue 3 + Element Plus。这套组合在校园网环境里很成熟，组件丰富，界面做出来也不丑。相比之下，如果使用Thymeleaf服务端渲染模板，页面开发速度会慢一些，而且毕设作品展示时，前后端分离的结构明显更有说服力。

数据访问层我用的是MyBatis Plus。它保留了SQL的灵活性，同时内置了BaseMapper，单表CRUD基本不用写SQL，对于报到记录查询、按状态统计这类操作非常顺手。选型理由往深一层说：新生报到系统的数据模型虽然不算复杂，却存在大量条件组合查询（按学院、按专业、按状态、按时间），MyBatis Plus的Wrapper机制能用Java代码组合查询条件，比手写一堆动态SQL干净得多。

认证与权限方面，可以选Sa-Token或者JWT。我实际用的是Sa-Token，它对多角色登录（新生端、学院端、管理端）的支持比较友好，登录状态管理和权限注解开箱即用。如果毕设要求不那么高，JWT + 拦截器手写一套也可行，核心逻辑就是把token解析后放入ThreadLocal，再配合自定义注解做权限校验。Spring Security能做，但配置成本偏高，对于这个项目有点杀鸡用牛刀。

1.3 系统角色划分与功能模块拆解

做这种多角色系统，第一步不是写代码，而是把角色和用例理清楚。新生报到系统的角色通常分成四类：

• 新生：查看录取信息、在线预报到、提交到校信息、查看报到进度和宿舍分配结果。
• 院系辅导员：负责审核新生预报到信息、现场扫码确认报到、查看本院系报到进度。
• 学院管理员：管理本院专业、班级、带班辅导员，统计本院数据。
• 校级管理员：导入招生录取数据、配置报到批次、分配宿舍资源、查看全校报到大屏、处理绿色通道申请。

功能模块围绕“报到前—报到中—报到后”三段展开。

报到前核心是录取数据导入和预报到。通过Excel模板批量导入招生办提供的录取名单，系统为每位新生生成账号和初始密码。新生登录后在线填写健康状况、到校方式、到校时间、生源地贷款情况等，辅导员审核后形成预报到记录。

报到中核心是现场报到业务。工作人员扫新生出示的报到二维码，系统校验身份、缴费状态、宿舍分配情况，确认后流转为“已报到”状态。

报到后核心是数据汇总查询和统计看板，按学院、专业、时间段多维度展示报到率，同时支持补报到、晚到登记、退学等异常业务。

模块划分清楚之后，再去做数据库设计和接口设计，思路会顺很多。很多同学一上来就建一堆表，结果业务边界模糊，做到后面自己都理不清。

2. 数据库设计与状态流转：报到系统的核心在“状态”

2.1 核心数据表设计与字段规划

新建生报到系统，最重要的不是用户表，而是“报到业务”相关的几张表。我按模块把全项目表结构分成四组：系统基础表（用户、角色、菜单）、录取与新生信息表、报到业务流转表、资源分配与审核表。

下面这几张核心表是必须的，字段设计也直接决定后续代码好不好写。

学生基本信息表里的admission_no（录取编号）和id_card_no（身份证号），都必须加唯一约束。一对多关系上，一个学生对一条报到记录，所以在report_flow表给student_id建唯一索引，保证同一名新生不会重复产生两条主报到记录。

关于“逻辑删除”这个细节，我一般会用del_flag字段而不是直接物理删除。新生报到场景里，学生数据一旦被删除，后续的宿舍分配记录、缴费记录就全都关联不上了，审计也会出问题。所有核心业务表统一保留del_flag、create_time、update_time三个基础字段，虽然看起来多写几行代码，但后面排查问题会轻松很多。

2.2 报到状态机的设计思路

报到系统的业务复杂度，核心体现在状态变化上，而不是数据结构上。一个新生从录取名单导入开始，到最终完成所有报到流程，至少要经历以下状态。

• 未报到：录取数据已导入，新生尚未登录系统。
• 预报到完成：新生已登录，填写了到校信息和健康信息，且院系已审核。
• 已缴费/待缴费：缴费记录同步或线上填写，区分是否完成缴费；家庭困难学生可以走绿色通道。
• 已分宿舍：宿舍管理员完成床位分配，或者新生线上自选宿舍后确认。
• 现场报到完成：现场工作人员扫码确认，状态终态。
• 异常状态：缓报到、退学、保留入学资格。

这些状态不能用一个字符串随意写死，我会用数字字典或者Java枚举统一维护，否则统计时报“已报道”“以报到”“yi baodao”这种乱七八糟的值，真的会很崩溃。

public enum ReportStatus { NOT_REPORTED(0, "未报到"), PRE_REPORTED(1, "预报到完成"), APPROVED(2, "院系审核通过"), PAID(3, "已缴费"), DORMITORY_ASSIGNED(4, "已分配宿舍"), REPORTED(5, "现场报到完成"), DELAYED(6, "缓报到"), WITHDRAWN(7, "退学/保留资格"); }

为什么状态要独立成枚举而不是直接存在student_info表里？因为同一批新生在迎新过程中，不同学院进度不同，有的学院要求先缴费再报到，有的支持先报到后补缴。状态独立成report_flow表的字段，后续调整流程只改状态流转逻辑，不碰基础信息表，扩展性好很多。

2.3 防止状态回跳和并发更新问题

状态机的核心规则只有一条：已流转的状态不能逆流，除非有明确的撤销操作。比如“现场报到完成”之后，不能因为修改了一条信息就自动变回“未报到”。这个我在代码里通过Service层的状态校验方法实现。

public boolean canTransit(Integer currentStatus, Integer targetStatus) { Map<Integer, List<Integer>> allowedMap = new HashMap<>(); allowedMap.put(ReportStatus.NOT_REPORTED.getCode(), Arrays.asList(ReportStatus.PRE_REPORTED.getCode(), ReportStatus.WITHDRAWN.getCode())); allowedMap.put(ReportStatus.PRE_REPORTED.getCode(), Arrays.asList(ReportStatus.APPROVED.getCode(), ReportStatus.DELAYED.getCode())); allowedMap.put(ReportStatus.APPROVED.getCode(), Arrays.asList(ReportStatus.PAID.getCode(), ReportStatus.DORMITORY_ASSIGNED.getCode(), ReportStatus.DELAYED.getCode())); allowedMap.put(ReportStatus.PAID.getCode(), Arrays.asList(ReportStatus.DORMITORY_ASSIGNED.getCode(), ReportStatus.REPORTED.getCode())); allowedMap.put(ReportStatus.DORMITORY_ASSIGNED.getCode(), Collections.singletonList(ReportStatus.REPORTED.getCode())); allowedMap.put(ReportStatus.DELAYED.getCode(), Arrays.asList(ReportStatus.REPORTED.getCode(), ReportStatus.WITHDRAWN.getCode())); return currentStatus.equals(targetStatus) || allowedMap.getOrDefault(currentStatus, Collections.emptyList()).contains(targetStatus); }

现场报到期间，多个窗口同时确认报到是常见情况。如果两个操作员同时扫同一个二维码，数据库层面就可能出现两次update，覆盖先前的记录。解决思路有两条：

• 数据库乐观锁，在report_flow表加version字段，更新时比对version。
• 报到确认接口使用update ... where report_status = 旧状态 的条件更新，如果影响行数为0，说明状态已被其他人修改。

boolean updated = reportFlowService.lambdaUpdate() .eq(ReportFlow::getStudentId, studentId) .eq(ReportFlow::getReportStatus, ReportStatus.APPROVED.getCode()) .set(ReportFlow::getReportStatus, ReportStatus.REPORTED.getCode()) .set(ReportFlow::getOnsiteReportTime, LocalDateTime.now()) .update(); if (!updated) { throw new BizException("该新生报到状态已变更，请刷新后重试"); }

条件更新虽然简单，但非常实用，推荐在答辩时重点讲，这比“用了Redis锁”更能体现对业务并发的理解。

3. 核心功能实操实现：从0到1跑通报到流程

3.1 项目初始化与依赖配置

后端工程建议直接用Spring Initializr生成，Java版本选JDK 8或JDK 17都可以。新生报到系统的代码量不算大，JDK 8完全够用；如果选JDK 17，要注意MyBatis Plus和Sa-Token等依赖的版本兼容性。

pom.xml中核心依赖大概长这样：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>cn.dev33</groupId> <artifactId>sa-token-spring-boot-starter</artifactId> <version>1.36.0</version> </dependency> <dependency> <groupId>com.github.binarywang</groupId> <artifactId>weixin-java-miniapp</artifactId> <version>4.5.0</version> </dependency>

微信小程序不是必须的，如果只是做Web端，删掉最后一个依赖即可。MyBatis Plus的版本选择上有个经验：别盲目用最新版，我曾经因为MyBatis Plus 3.5.3和Spring Boot 3.x搭配，遇到JDK 17下无法启动的问题，后面改回3.4.x才解决。毕设绑定的版本宁稳勿新。

3.2 录取数据批量导入功能的实现

录取数据导入是所有流程的源头。输入是学校招生办提供的Excel录取名单，字段至少包含：录取编号、姓名、身份证号、性别、学院、专业、班级、考生号。如果学院、专业这些字典表的记录还没建立，导入前必须先维护基础数据。

导入的代码结构建议分三步：

• 上传Excel文件，使用EasyExcel读取数据。
• 逐行校验：录取编号是否重复、身份证号格式是否正确、学院/专业是否在字典表中存在。
• 校验通过后批量插入数据库，如果中途有N条失败，记录失败原因并生成错误报告供下载。

public ImportResult importAdmissionData(MultipartFile file) { List<AdmissionRow> rows = easyExcel.read(file.getInputStream()) .head(AdmissionRow.class) .sheet() .doReadSync(); List<StudentInfo> validStudents = new ArrayList<>(); List<ImportError> errors = new ArrayList<>(); for (int i = 0; i < rows.size(); i++) { AdmissionRow row = rows.get(i); try { validateRow(row, i + 1); validStudents.add(buildStudentInfo(row)); } catch (BizException e) { errors.add(new ImportError(i + 2, e.getMessage())); } } if (!validStudents.isEmpty()) { studentInfoService.saveBatch(validStudents); } return new ImportResult(validStudents.size(), errors); }

导入完成之后，用定时任务或者一个批量方法给每个新生生成默认账号，初始密码可以是身份证后六位，标记“首次登录需修改密码”。如果不做这一步，新生拿到系统地址却登不进去，整个流程就断掉了。

3.3 预报到信息采集与审核功能

预报到环节要采集的信息，我分成必填项和选填项。

必填项：到校日期、到校时间段、到校交通方式、是否需接站、紧急联系人电话。 选填项：生源地贷款信息、家庭困难说明、军训服尺码、到站车次。

预报到表不一定要和student_info合并，独立成pre_report_info表更方便，因为一个学生如果缓报到，预报到信息可以延后填写。院系辅导员在列表中审核新生预报到信息，审核通过后，新生端状态从“预报到完成”变为“院系审核通过”。

这里有一个小坑：到校日期和到校时间段的数据类型。尽量用字符串保存时间段（如“上午8:00-10:00”），不要用时间戳，因为这不是一个业务时间点，只是描述性信息。采集到的接站信息可以汇总成报表，给校车调度人员做参考。

3.4 报到二维码生成与现场扫码确认

现场报到是整个系统最有辨识度的功能。传统模式是排长队找名字打勾，这里变成新生出示二维码、工作人员扫码确认。二维码内容怎么设计才安全合理？

我的做法是：二维码里放一个随机UUID，同时把studentId作为前缀拼接，比如REQ_NO=20250001&TOKEN=UUID字符串。这个TOKEN在预报到的学生首次打开报到码时动态生成，存储到Redis或者数据库字段中。为什么不用studentId直接作为二维码内容？因为studentId本身有规律，容易被猜到或伪造，现场工作人员扫码之后，如果只凭一个ID就直接改状态，安全性太差。

扫码确认接口的完整逻辑是：

• 后端解析出studentId和token。
• 校验token是否匹配且未过期。
• 查询该生当前报到状态。
• 做状态流转校验（例如当前状态至少是“院系审核通过”）。
• 校验是否已完成缴费或者已走完绿色通道。
• 更新状态为“现场报到完成”，记录时间、操作人员。

二维码生成我用的Hutool工具类，一行代码就能生成Base64图片：

public String generateQrCode(String content) { QrConfig config = new QrConfig(300, 300); // 传入业务内容字符串 return Base64.getEncoder().encodeToString( QrCodeUtil.generatePng(content, config)); }

前端拿到这个Base64字符串直接渲染成图片，新生在报到现场展示给工作人员扫。

3.5 缴费、绿色通道与宿舍分配联动

缴费状态和报到状态是联动关系。现实中不是所有学生都在线上完成缴费，有的学生家里办理了生源地贷款，有的到了现场才去财务窗口排队缴费。所以在系统中，缴费状态我设计了四种：未缴费、已缴费、免缴（奖学金覆盖）、贷款待确认。

现场报到扫码时，判断逻辑是：如果status=PAID或status=绿色通道审核通过，则允许正常报到，否则提示“未完成缴费确认，请前往财务窗口或绿色通道办理”。这个判断不需要太复杂的规则引擎，一个接口里几行条件判断就够，但必须在答辩时讲清楚“哪些状态是报到前置条件”。

宿舍分配采用“管理员分配+新生查询”模式，管理员在宿舍分配页面选择楼栋、楼层和床位，系统自动过滤已被占用的床位。分配完成之后，新生端能立刻看到住宿信息。如果你想让项目更有亮点，可以做成新生在线自选宿舍。核心逻辑是事务操作：先锁定床位，再更新宿舍空余数，然后写入分配记录。这里特别要注意并发，默认SQL的update都有行锁，把“占用床位的更新”放在最前面执行，然后利用影响行数判断是否抢到。

@Transactional(rollbackFor = Exception.class) public DormitoryAssign assignDormitory(Long studentId, Long roomId) { boolean locked = dormitoryBedService.lambdaUpdate() .eq(DormitoryBed::getRoomId, roomId) .eq(DormitoryBed::getStudentId, null) .eq(DormitoryBed::getStatus, 0) .set(DormitoryBed::getStatus, 1) .set(DormitoryBed::getStudentId, studentId) .update(); if (!locked) { throw new BizException("该床位已被选定，请选择其他床位"); } DormitoryAssign assign = new DormitoryAssign(); assign.setStudentId(studentId); // 查询并回填房间信息 return assign; }

3.6 数据统计看板与导出报表

新生报到系统如果不做统计大屏，就少了一半的实用价值。学校领导最关心的就是报到率，统计口径要按“已报到人数 / 应报到人数”。应报到人数是Excel导入的录取人数，已报到人数是状态为“现场报到完成”的人数。

日报统计可以用一条分组SQL：

SELECT college_id, SUM(CASE WHEN report_status = 5 THEN 1 ELSE 0 END) AS reported_count, COUNT(*) AS total_count FROM student_info WHERE enrollment_year = 2025 AND del_flag = 0 GROUP BY college_id;

这个SQL的缺点是student_info表如果已经有几万条数据，统计性能会比较差。应对方案有两种：一是给enrollment_year和report_status建联合索引；二是引入Redis缓存，把各学院已报到人数在每次报到确认时累加写入Redis，看板只读缓存值。

public void refreshStatisticsCache(Integer collegeId) { Long reportedCount = studentInfoService.lambdaQuery() .eq(StudentInfo::getCollegeId, collegeId) .eq(StudentInfo::getReportStatus, ReportStatus.REPORTED.getCode()) .count(); redisTemplate.opsForValue().set("report:college:" + collegeId, reportedCount); }

看板的前端展示用Vue + ECharts，柱状图展示各学院报到率排名，折线图展示报到人数随时间的变化趋势。这块是整个项目最容易出视觉效果的部分，作品演示时一定不要跳过。

4. 常见问题与排查技巧实录

4.1 新生数据导入时报“身份证重复”

招生办给的Excel里，偶尔会出现同一名考生在男生宿舍和女生宿舍名单重复出现的情况，或者是身份证号被Excel的浮点数科学计数法自动转换成奇怪的格式。这是一个很经典的问题。

Excel导入身份证号，一定要在模板里先把这一列的单元格格式设为“文本”，否则15位以上数字会被自动转成科学计数法，读出来变成“1.23456E+17”，后几位全丢。代码侧校验身份证号时，用正则严格匹配：(^\d{15}$)|(^\d{17}[\dXx]$)，校验非法数据直接写入错误报告，不要中断整个导入流程。

身份证号重复的校验逻辑，除了数据库唯一索引兜底，在导入Service里也要先把Excel内所有身份证号收集起来，用Map去重。因为数据库唯一索引报错时，MyBatis Plus批量插入只会告诉你“某一批失败了”，很难定位具体是哪一行，预校验能帮你把错误行号直接返回给用户。

4.2 现场高并发扫码报到时报错或数据错乱

报到日当天，上午9点到11点是高峰期，可能出现几十个工作人员同时扫码确认。如果后端按常规方式读写数据库，MySQL默认连接池配置很快被打满。虽然没有像秒杀系统那么夸张的量，但对一个高校报到场景来说，提前做一些保护是必要的。

• 确认报表接口必须做分页和条件缓存，不能把几万条数据一次性查出来。
• 扫码确认接口前面加一层Redis限流，同一操作员每分钟最多操作600次（每100毫秒一次），防止误操作和接口刷请求。
• 条件更新保证同一学生记录不会被多次更新覆盖。

另外数据库连接池参数可以适当调整：

spring: datasource: hikari: maximum-pool-size: 30 minimum-idle: 10 connection-timeout: 10000

4.3 二维码明明正常但扫码后提示“状态异常”

这种情况我排查过几次，原因基本都是流程状态没满足前置条件。例如新生尚未完成预报到审核，或者缴费状态未确认，系统直接拦截了。解决这个问题，要在扫码后的提示信息里写清楚“当前处于什么状态、还缺什么步骤”，不然现场工作人员完全不知道该怎么处理。

后来我在扫码确认接口里，把提示信息改成了类似“该生当前状态为院系审核通过，缺失缴费信息，请先办理缴费或绿色通道确认”，并把这个判断场景整理成了一个checklist：

• 该生是否存在于本批次报到名单中。
• 该生是否已完成预报到。
• 院系是否已审核。
• 是否已缴费或已通过绿色通道。
• 是否已分配宿舍（如果学院设置为前置条件）。
• 当前是否处于报到批次时间范围内。

4.4 缓报到、退学、数据修改等异常流程怎么处理

信息系统最怕把正常流程做好之后，遇到异常情况不知道往哪放。新生报到也一样，总有少量学生因为生病、签证、家庭原因需要晚到几天，或者决定放弃入学资格。

我的建议是不要在代码里为每种情况写死分支，而是用可配置的处理动作。在report_flow表增加一个operation_log字段，或者单独建一张report_op_log表，记录“谁在什么时间把状态从A改到B，原因是C”。这样即使出现退学、缓报到这类低频业务，系统也能稳定处理，而且答辩时你能拿出来说“我们对异常状态流做了审计设计”，这是很加分的点。

operation_log表大概可以这样设计：

4.5 关于毕设答辩和项目亮点的经验

系统功能做完只是第一步，怎么在答辩时把项目亮点讲出来更重要。同样是新生报到系统，有的同学讲完就是“登录+增加删除改查”，有的同学能讲出状态机、乐观锁、批量导入校验、Redis统计缓存、二维码安全机制。后者明显更符合优秀毕设的要求。

如果你想让这个项目更有竞争力，可以再扩展几个方向。一是增加微信小程序端，让新生直接用微信扫码打开预报到页面，体验比浏览器输入网址好很多。二是接入人脸识别核验，报到现场用摄像头拍照，调用人脸比对接口验证身份。三是做消息通知，报到状态变化时通过短信或微信公众号模板消息通知辅导员和家长。以上每个方向都可以作为论文里的“创新点”章节来写。

另外一个很实际的建议：演示数据一定要准备充分。不要用admin、123456这种数据，至少导入50条模拟新生数据，覆盖不同学院、不同专业、不同报到状态。让评委在系统里看到条形图、饼图都有数据变化。先准备好状态为“未报到”和“已报到”的学生各一批，现场演示时点一下“扫码报到”，看板数字立刻变化，这个效果比讲十分钟PPT都管用。

5. 实际操作中的个人体会

最后分享几点我自己的真实感受。

第一个体会是，这种业务型系统的开发难点从来不是某个技术点，而是流程梳理。你只有把新生报到到底有哪几个环节、每个环节由谁操作、什么条件下流转到下一个状态搞清楚，代码写起来才顺畅。很多同学一上来就去研究Spring Boot的自动配置原理，结果业务模型一团乱，做出来的东西导师一看就是“只有壳没有核”。

第二个体会是，代码里留一些能自圆其说的设计点。比如我前面提到的条件更新、批次时间校验、审核操作日志，都是一两页能讲清楚但不显得浅薄的小设计。答辩时评委最反感的是“我这里用了Redis是因为大家都用Redis”，但如果你能说“这里用条件更新是为了防止多人重复确认导致状态覆盖”，评委的感觉是完全不一样的。

第三个体会比较现实：如果你在毕业设计时间有限的情况下，不要追求把全流程模块做满。新生报到系统里，用户管理、录取导入、预报到、现场报到、统计看板，这五个模块做完已经是一个完整项目了。绿色通道、宿舍自选、消息通知、小程序端，这些属于加分项，有时间再补。把核心链路做到逻辑严谨再加一个亮点模块，远比功能堆砌但每个模块都粗糙要好得多。

如果你正在做或者准备做类似的项目，欢迎参考这套思路落地。把业务状态理清楚，把现场报到这个核心场景做扎实，这套系统在教务和学工场景里的复用价值还是很高的。