企业官网建设流程全解析

简介：面向计算机与软件工程专业毕业设计阶段的学籍管理系统论文与配套源码合集，适合正在准备教育信息化选题、需要完整软件工程流程范例的高校学生参考。压缩包共24个文件、约323KB，以Java源文件（6个）和编译后的class文件（7个）为主体，覆盖学生信息、成绩、学籍变动等模块的增删改查实现；另含mdb数据库文件与ldb锁文件用于数据存储，2份doc文档分别为毕业论文与程序设计报告，6个bak文件是各模块修改前的代码备份，便于对比演进过程。已有346人学习下载。读者可从中获取需求分析、数据库表结构设计、功能模块划分到系统测试与部署的完整写作框架，并对照Java图形界面代码理解学生管理、查询、删除等功能的实现方式，为论文撰写与系统复现提供可借鉴的样本。

1. 学籍管理系统毕业论文：从「能答辩」倒推需求

学籍管理系统毕业论文最常翻车的地方不在代码跑不跑得起来，而在答辩时被追问一句「你这个系统和一个共享表格有什么区别」就卡住了。我见过不少同学把力气全花在页面上，增删改查做了几十个，结果讲不清一条学籍从入学到毕业是怎么流转的。

所以我一般建议倒着做：先想清楚「学籍管理」四个字的业务内核是一条状态流水——在籍、休学、复学、转专业、退学、毕业，每一次变化都要留痕、可追溯、能被人审核。围绕这条主线去组织需求、表结构和代码，论文的章节自然就有了骨架。

下面这套方案按需求边界、总体架构与数据模型、核心模块实现、避坑排查、验收答辩五段推进，适合正在做毕业设计或课程设计的学生直接照着搭，也适合需要交付一套教务辅助模块的开发者改成自己的版本。

2. 需求边界与角色权限：四类角色、六类业务动作的职责划分

学籍管理系统的需求文档最容易写成功能清单：学生管理、班级管理、成绩管理、用户管理，一条一条列下去，看着很全，实际上评审老师一句「这些功能各自服务于谁」就能问出空心。我的做法是先切角色，再切动作，最后才落到功能菜单上。角色决定数据范围，动作决定状态变化，功能只是这两者的界面投影。

2.1 角色与用例：谁录入、谁审核、谁只能看

任何一套学籍管理系统，实际使用者通常收敛成四类：学生本人、辅导员或班主任、教务管理员、系统管理员。有的学校还会加一类院系负责人只看统计报表，但本质上是教务管理员的只读子集，论文里可以合并描述，不必单独建角色表。

学生的诉求最窄也最硬：查自己的学籍状态、查历年成绩、提交异动申请（休学、复学、转专业）、看申请进度。这里有个容易被忽略的细节——学生提交申请之后，系统不能允许他随意撤回再改，因为异动申请一旦进入审核流程，撤回会打乱审核人的队列。我通常的做法是给申请记录加一个可撤回窗口：状态还是「待初审」时允许撤回，一旦辅导员点了通过，就只能走驳回流程。

辅导员的职责是核对与初审。他要能看到本班学生的基本信息、家庭联系方式是否缺失、学籍状态是否异常，对学生的异动申请做第一道把关。这里的关键约束是数据范围——辅导员只能看自己带的班，不能看别的院系。

教务管理员是整个系统的重心：学籍注册、异动终审、毕业资格审核、报表导出。他拥有最全的数据可见范围，但也承担最大的责任，所以系统里凡是他做的写操作，都必须留操作日志：谁、什么时间、把哪个学生的哪条记录从什么改成了什么。这条需求不是锦上添花，答辩时被问到「数据出错怎么追责」，有没有这张日志表是分水岭。

系统管理员只管账号、角色、菜单，原则上不碰业务数据。很多同学把系统管理员和教务管理员合成一个超级管理员，图省事，结果论文里的权限设计一章就没什么可写的了。

把这四类角色和典型动作对齐，就是一张用例表：

2.2 权限矩阵：菜单级权限为什么挡不住越权

大部分做得比较仓促的学籍管理系统，权限只做到菜单级：学生登录进来只显示「我的学籍」「我的成绩」，教务管理员登录显示全部菜单。看起来没问题，但只要把浏览器地址栏里的参数改一下，/student/detail?id=1001改成id=1002，就能看到别人的信息。这是答辩现场最常见的追问之一：你前端把按钮藏了，后端怎么保证数据不被越权访问？

我的做法是在后端做两层校验。第一层是功能权限，也就是这个角色有没有资格调用这个接口，通常用注解加拦截器实现；第二层是数据权限，接口拿到参数之后，必须按当前登录人的身份再过滤一次。学生查详情，id参数只能等于他自己绑定的学生 ID，不等就直接抛异常；辅导员查列表，SQL 里强制拼上班级条件，而不是信任前端传来的classId。

// 数据权限拦截：在 Service 层入口校验，而不是在 Controller 里做 if public StudentVO getDetail(Long studentId, LoginUser user) { // 学生角色：只能看自己 if (user.hasRole("STUDENT") && !studentId.equals(user.getBindStudentId())) { throw new BizException("无权查看他人学籍信息"); } // 辅导员角色：只能看本班 if (user.hasRole("COUNSELOR")) { Student s = studentMapper.selectById(studentId); if (s == null || !s.getClassId().equals(user.getBindClassId())) { throw new BizException("超出可管理班级范围"); } } return studentMapper.selectDetail(studentId); }

这段代码的关键点不在于写了几个 if，而在于把校验放在 Service 层：任何 Controller、任何定时任务、任何内部调用最终都会经过这里，不会因为新增了一个接口就漏掉校验。LoginUser里的bindStudentId和bindClassId建议在登录时一次性查出来塞进会话，而不是每次请求再查一遍数据库。

另外提醒一点，权限校验失败不要返回「该学生不存在」。不存在和没权限返回同样的提示，可以避免有人靠遍历 ID 探测数据是否存在，这算是个成本很低但很加分的细节。

2.3 需求取舍：哪些进论文主线，哪些放后续工作

学籍管理系统这个题目，边界其实很模糊。往大了做，排课、选课、教材、收费、宿舍都能算进来，一个本科毕设根本做不完，硬塞进去的结果是每个模块都只有一层皮。

我一般会划一条线：围绕「学生身份状态」和「成绩归属」的功能进主线，围绕教学运行的功能不进。具体来说，学生基本信息、班级专业院系三级组织、学籍异动、成绩录入与查询、毕业资格审核、报表导出，这六块是主线，因为它们共享同一份学生主数据，任何一块改了都会影响其他块。排课和选课只和学生有关，但不改变学籍状态，可以作为「后续工作」写在论文最后一章的展望里，反而显得作者对系统边界有清醒认识。

这个取舍还有个好处：主线模块之间是有耦合的，比如转专业之后，学生的班级、专业、培养方案全都要跟着变，历史成绩的归属还要重新判定。这种耦合正好是论文里「难点与解决方案」一节的素材，比写十个互不相干的增删改查有分量得多。

3. 总体架构与数据模型：三层结构与十一张核心表的职责边界

结构和表设计是这类系统真正的分水岭。功能长得差不多的两套系统，一套改个需求就要动三四个地方，另一套加个字段十分钟搞定，差别全在设计阶段定下来了。这一章讲两件事：代码怎么分层，数据怎么建表。

3.1 分层职责：Controller 只管参数，Service 管规则，Mapper 管数据

后端用 Spring Boot 加 MyBatis-Plus，前端用 Vue 加 Element UI，这是目前毕业设计里最稳的组合，资料多、报错好查、答辩老师也熟悉。技术选型本身没什么可纠结的，真正值得写进论文的是分层职责怎么划。

Controller 层只做三件事：接收参数、做基础格式校验、把结果包装成统一响应体。不要在这里写业务判断，更不要直接调 Mapper。我见过把事务写在 Controller 上的代码，一个请求里调了三个 Service，事务边界乱成一团，出问题根本查不出来。

Service 层是业务规则的唯一归属地。状态能不能流转、成绩怎么算有效、批量导入失败怎么回滚，全部放在这里。事务注解也加在这一层，一个业务动作一个方法，方法的粒度就是事务的粒度。

Mapper 层只做数据访问，不写业务判断。像「查询某个学生当前有效的成绩列表」这种带业务含义的查询，SQL 可以写在 Mapper 里，但调用它的判断逻辑必须在 Service。这条规矩听着教条，实际好处是当你需要把「有效」的定义从「未作废」改成「未作废且学期在籍」时，只改一处。

实体类建议分三套：跟数据库表一一对应的DO，面向前端返回的VO，接收请求参数的DTO。很多同学图省事一套实体打天下，结果学生表里的身份证号、家庭住址直接返回给了前端列表接口，答辩时被问到数据脱敏就答不上来。VO 里只放页面需要的字段，身份证号做掩码处理，这个习惯早养早好。

3.2 学籍主表与异动流水表：一对多关系怎么落

整个系统有十一张核心表，按职责可以分成三组。

组织与账号组：sys_user（账号）、sys_role（角色）、sys_user_role（关联）、dept（院系）、major（专业）、class（班级）。这六张表是基础数据，变动很少，初始化时灌一批测试数据就够用。

学籍主数据组：student（学籍主表）、student_status_change（异动流水表）。这两张表是整个系统的核心，也是论文里最该展开写的部分。

教学数据组：course（课程）、score（成绩）、graduation_audit（毕业审核记录）。这三张表围绕学生展开，通过学号或学生 ID 关联。

重点说主表和流水表的关系。student表存学生当前的状态快照：学号、姓名、性别、身份证号、院系、专业、班级、入学日期、当前学籍状态、状态版本号。student_status_change表存每一次状态变化的流水：学生 ID、变更类型（休学/复学/转专业/退学/毕业）、变更前状态、变更后状态、生效日期、申请原因、审核人、审核时间、审核意见。

-- 学籍主表：只存当前快照，状态字段随异动更新 CREATE TABLE student ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', student_no VARCHAR(20) NOT NULL COMMENT '学号，全局唯一', name VARCHAR(50) NOT NULL COMMENT '姓名', id_card VARCHAR(32) NOT NULL COMMENT '身份证号，展示时脱敏', dept_id BIGINT NOT NULL COMMENT '院系ID', major_id BIGINT NOT NULL COMMENT '专业ID', class_id BIGINT NOT NULL COMMENT '班级ID', enroll_date DATE NOT NULL COMMENT '入学日期', status VARCHAR(20) NOT NULL DEFAULT 'ENROLLED' COMMENT '当前学籍状态', status_ver INT NOT NULL DEFAULT 0 COMMENT '状态版本号，乐观锁用', deleted TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除标记', PRIMARY KEY (id), UNIQUE KEY uk_student_no (student_no), KEY idx_class_status (class_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学籍主表'; -- 异动流水表：只增不改，每次状态变化追加一条 CREATE TABLE student_status_change ( id BIGINT NOT NULL AUTO_INCREMENT, student_id BIGINT NOT NULL COMMENT '学生ID', change_type VARCHAR(20) NOT NULL COMMENT 'ENROLL/SUSPEND/RESUME/TRANSFER/QUIT/GRADUATE', from_status VARCHAR(20) NOT NULL COMMENT '变更前状态', to_status VARCHAR(20) NOT NULL COMMENT '变更后状态', effect_date DATE NOT NULL COMMENT '生效日期', reason VARCHAR(255) COMMENT '申请原因', audit_user_id BIGINT COMMENT '审核人ID', audit_time DATETIME COMMENT '审核时间', audit_remark VARCHAR(255) COMMENT '审核意见', PRIMARY KEY (id), KEY idx_student_effect (student_id, effect_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学籍异动流水';

这个设计里有两个决定值得单独讲。第一，主表存当前状态，流水表存历史，不做「每次查询都去流水表里取最新一条」的实时计算。原因很实际：学生列表分页查询时，如果每行都要子查询取最新异动记录，数据量上到几万条就会明显变慢，而且「最新一条」在同一个生效日期存在多条记录时排序结果不稳定。用冗余字段换查询性能，在这个场景下是划算的。

第二，status_ver这个版本号字段。异动审核是并发场景：辅导员和教务管理员可能同时点通过，如果两个人拿到的都是「在籍」这个旧状态，各自算一遍都合法，最后就会写出两条互相矛盾的流水。加乐观锁之后，后提交的那次更新会因为版本号不匹配而失败，系统提示「该学生状态已变更，请刷新后重试」。这是论文里可以实打实写一段的并发处理设计。

3.3 索引与冗余字段：学期编码、学号唯一性、逻辑删除

索引这块，student_no建唯一索引是底线，它同时承担了业务约束和数据约束两个角色。很多人喜欢在代码里select count(*) where student_no = ?判断学号是否重复，再插入。单线程下没问题，并发导入时必翻车。正确做法是把唯一性交给数据库，代码只负责捕获唯一键冲突异常并转成友好提示。

idx_class_status这个联合索引是为「查某个班级里所有休学学生」这类高频查询准备的。学生列表页默认按班级筛，状态筛选也常用，两个字段的联合索引能覆盖大部分查询。注意索引列顺序：等值条件在前，范围条件在后，class_id放前面是因为它是必填筛选条件。

逻辑删除用deleted字段而不是直接物理删除。这一点在学籍系统里不是可选项：学生退学之后，他的成绩记录、异动记录还要保留，物理删除主表会连带出一堆孤儿数据。MyBatis-Plus 有现成的逻辑删除配置，加个注解就能全局生效，别忘了在统计类 SQL 里手动加上deleted = 0，自动拼接和手写 SQL 混用是常见的坑。

还有一个细节值得提前定规矩：学期字段怎么存。用「2024-2025-1」这种字符串最省事，但排序会出问题，因为字符串比较下「2024-2025-10」排在「2024-2025-2」前面。我一般存两个字段：term_code存有序编码（比如 202401、202402，规则是学年起始年加学期序号），term_name存给人看的字符串。排序用 code，展示用 name，两边都不别扭。

4. 核心模块实现：学籍异动状态机与成绩有效性校验

前面两章把边界和结构定下来了，这一章落到最容易被评审追问的两块：状态怎么流转，成绩怎么算数。这两块写扎实了，论文的技术含量就立住了。

4.1 异动状态机：六种状态与允许流转表

学籍状态一共六种：在籍（ENROLLED）、休学（SUSPENDED）、转专业中（TRANSFERRING）、退学（QUIT）、毕业（GRADUATED）、保留学籍（RETAINED）。状态之间不是任意跳转的，比如「退学」之后再「复学」在业务上是非法操作，休学必须经过复学才能回到在籍。

如果代码里到处散落if (status.equals("SUSPENDED"))，业务规则会越写越乱。我的做法是把允许的流转关系定义成一张静态映射表，所有流转判断只查这一处：

// 学籍状态流转规则：key 为当前状态，value 为允许流转到的目标状态集合 private static final Map<StudentStatus, Set<StudentStatus>> TRANSITION_RULES = new HashMap<StudentStatus, Set<StudentStatus>>() {{ put(ENROLLED, EnumSet.of(SUSPENDED, TRANSFERRING, QUIT, GRADUATED, RETAINED)); put(SUSPENDED, EnumSet.of(ENROLLED, QUIT)); // 休学只能复学或退学 put(RETAINED, EnumSet.of(ENROLLED, QUIT)); put(TRANSFERRING, EnumSet.of(ENROLLED, QUIT)); // 转专业完成后回到在籍 put(QUIT, EnumSet.noneOf(StudentStatus.class)); // 终态 put(GRADUATED, EnumSet.noneOf(StudentStatus.class)); // 终态 }}; // 校验方法：业务层每一次异动都必须先过这里 public void assertTransition(StudentStatus from, StudentStatus to) { if (!TRANSITION_RULES.getOrDefault(from, Collections.emptySet()).contains(to)) { throw new BizException("当前状态[" + from.getDesc() + "]不允许变更为[" + to.getDesc() + "]"); } }

把规则集中到一张表里，好处不只是代码干净。论文里可以直接把这张流转表画出来，说明「系统对非法流转有强约束」，比写十句「系统具有良好的健壮性」有说服力。新增一种状态时也只需要改这一处，不会漏掉某个分支。

顺带说个业务细节：转专业实际上是个两段式流程，学生申请、转出专业同意、转入专业同意、教务终审，中间状态用「转专业中」表示，全部通过之后才回到在籍并更新专业和班级。这个设计在答辩时讲出来很加分，因为它体现的是「状态机不是二元开关，而是有中间态」的建模意识。

4.2 一次异动申请的事务实现

异动审核通过时要做三件事：写一条流水、更新主表状态、更新可能受影响的关联数据（比如转专业要改专业和班级）。这三步必须在一个事务里，任何一步失败就整体回滚，否则会出现「流水写了但主表没改」这种对不上账的数据。

@Transactional(rollbackFor = Exception.class) public void audit(Long changeId, boolean pass, Long auditUserId, String remark) { StudentStatusChange change = changeMapper.selectById(changeId); if (change == null || !"PENDING".equals(change.getAuditState())) { throw new BizException("该申请不存在或已处理"); } if (!pass) { changeMapper.updateState(changeId, "REJECTED", auditUserId, remark); return; } Student student = studentMapper.selectById(change.getStudentId()); // 1. 复核状态：申请提交后学生状态可能已被其他操作改变 assertTransition(student.getStatus(), change.getToStatus()); // 2. 更新主表，带版本号防止并发覆盖 int rows = studentMapper.updateStatusWithVersion( student.getId(), change.getToStatus(), student.getStatusVer()); if (rows == 0) { throw new BizException("该学生状态已变更，请刷新后重试"); } // 3. 转专业场景：同步更新专业、班级 if ("TRANSFER".equals(change.getChangeType())) { studentMapper.updateMajorAndClass(student.getId(), change.getTargetMajorId(), change.getTargetClassId()); } // 4. 写流水，审核信息一并落库 changeMapper.finish(changeId, auditUserId, remark); }

这段代码里有几个点值得说明。@Transactional指定了rollbackFor = Exception.class，是因为 Spring 默认只对运行时异常回滚，业务里抛的受检异常不会触发回滚，这个坑踩过的人都懂。

审核时重新查一次学生状态并再校验一遍流转规则，看起来和提交时的校验重复了，其实不是。申请提交到审核通过之间可能隔了好几天，这期间学生状态可能已经变了，提交时的校验结果不能信任。这种「关键节点二次校验」的思路，答辩时讲出来是有分量的。

更新主表用updateStatusWithVersion而不是直接 update，返回的影响行数为 0 就说明版本号不匹配，有并发操作插队了。注意这里必须在事务里执行，否则乐观锁失败后的回滚不彻底。

4.3 成绩归属校验与批量导入的落库策略

成绩模块最容易被忽略的问题是：转专业之后，学生之前修的成绩还算不算数。如果成绩表只存了学生 ID 和课程 ID，查询时按学生当前的专业去关联培养方案，那么转专业的学生历史成绩会突然「消失」或者被判为无效，这是真实业务里会引发投诉的问题。

我的处理原则是成绩跟着修读记录走，不跟着当前身份走。score表里除了student_id、course_id，还要存term_code（修读学期）、course_type（课程性质：必修/选修/通识）、credit（学分快照）。学分和课程性质在录入时就从课程表里复制一份存下来，而不是查询时再关联。理由很实在：课程学分过几年可能会调整，如果实时关联，学生毕业审核时按新学分算，和当年修读时的口径就对不上了。这种「关键业务字段做快照」的做法，在财务、订单类系统里很常见，学籍系统里同样适用。

批量导入是另一个高频翻车点。教务每年新生入学要一次性导入几千条学籍，用 POI 一把梭全读进内存，文件大一点就 OOM；用逐条 insert，几千条要跑好几分钟。我的做法是分三步：先全量解析做格式校验并缓存到临时列表，再按 500 条一批批量插入，最后把失败行号和原因回写给前端。

// 分批插入：每批 500 条，批内失败整体回滚，批间互不影响 public ImportResult importStudents(MultipartFile file) { List<StudentExcelRow> rows = excelReader.read(file, StudentExcelRow.class); List<String> errors = validateAll(rows); // 先做全量校验，收集所有格式错误 if (!errors.isEmpty()) { return ImportResult.fail(errors); // 有格式错误直接返回，不写库 } int success = 0; for (List<StudentExcelRow> batch : Lists.partition(rows, 500)) { try { studentMapper.batchInsert(convert(batch)); success += batch.size(); } catch (DuplicateKeyException e) { // 学号冲突由唯一索引兜底，记录批次范围便于人工核对 errors.add("第 " + (success + 1) + " 至 " + (success + batch.size()) + " 行存在重复学号"); break; } } return ImportResult.of(success, errors); }

这里的关键决策是先校验后写库。很多人边读边写，读到第五十行发现格式错误，前四十九行已经进库了，用户还得手工清理。全量校验一遍的代价是内存占用翻倍，但几千行的量级完全扛得住。

学号生成规则也要提前定。常见格式是「入学年份两位 + 院系代码两位 + 专业序号 + 流水号」，比如 24 级计算机学院某专业的第三十七个学生就是 2401037 这种。流水号千万不要用select max(student_no) + 1去算，并发导入时两个线程会算出同一个号，最后靠唯一索引报错。稳妥的做法是建一张学号序列表，用update ... set seq = seq + 1的原子操作取号，或者干脆让数据库自增主键做后缀，格式上稍微妥协一点换取绝对可靠。

5. 避坑与排查：五个最容易在答辩现场被问穿的点

这一章是我带项目和看别人项目时反复见到的翻车点，每一条都按现象、原因、解决三段写。有些问题在演示时看不出来，但只要评审老师多点两下就会暴露。

5.1 现象：删掉一个学生，成绩列表全乱了

原因通常是物理删除。学生主表记录被delete掉之后，成绩表里还留着一堆指向这个 ID 的记录，列表页关联查询时要么报空指针，要么出现一行没有姓名的成绩。更麻烦的是异动流水表，历史审核记录全成了孤儿数据，想追溯某个学生什么时候休过学，查不到了。

解决办法是全面改用逻辑删除：主表加deleted字段，所有查询默认过滤已删除记录，删除操作只更新标记。同时成绩和流水表不要建物理外键约束，改为在 Service 层做存在性校验，这样历史数据不会被级联删掉。测试时专门造一条「已删除学生 + 若干成绩」的数据，验证列表、统计、导出三个入口都不报错。

5.2 现象：批量导入跑到一半失败，数据库里多出一半数据

原因是事务边界划错了。有的实现把整批导入包在一个事务里，几千条跑完才提交，中途出错全部回滚，看着很安全，但文件一大就锁表；有的实现完全不开事务，逐条提交，出错时前面已经写进去了，用户不知道从哪一行重来。

合理的做法是分批加批内事务：每 500 条一个事务，批与批之间独立。这样单批失败只回滚这一批，前面的成功数据保留，返回结果里带上失败的行号范围，用户改完重新导入即可。要注意批量插入的 SQL 本身要写成多值 insert，而不是循环单条 insert，性能差着数量级。

5.3 现象：辅导员能看到别的院系学生信息

这个问题我在不止一个项目里见过。前端菜单是按角色渲染的，辅导员登录后只显示「我的班级」，但列表接口的参数里classId是前端传的，改一下请求就能查全校。根子在于权限只做了展示层，没做数据层。

解决分两步：一是在登录时把用户的管辖范围（班级 ID、院系 ID）写入会话，不信任任何前端传来的范围参数；二是在 Mapper 的查询条件里强制拼上范围条件，用 MyBatis 拦截器统一处理也可以，但要注意别把系统管理员的查询也拦了。测试用例里必须包含「用 A 辅导员的账号去查 B 班级」这一条，这是验收清单上的固定项。

5.4 现象：列表页显示 20 条，分页总数显示 5000

典型的分页统计错误。列表查询用了一对多关联（一个学生关联多条成绩），返回的行数被成绩撑大了，而 count 语句没做去重，或者 count 和 list 用了不同的查询条件。表现出来的现象就是翻到第三页之后数据开始重复或者空白。

处理办法是把列表查询和统计查询拆开写：列表只查主表字段，需要展示的关联信息用子查询或者二次查询补；count 语句单独写，只统计主表。如果确实需要一对多聚合，先用子查询把主表 ID 分页查出来，再按 ID 集合去查详情，这个模式在数据量上来之后比 join 分页稳定得多。

5.5 现象：状态改了，但报表里的数字没变

这是冗余字段不同步导致的。主表存了status，统计报表却是从流水表实时算的，两边口径不一致；或者反过来，主表改了但缓存没刷。答辩演示时先看列表再看报表，数字对不上，非常尴尬。

解决办法是明确单一数据源：所有「当前状态」的读取一律走主表，流水表只用于追溯历史，不参与实时统计。所有修改状态的地方必须走同一个 Service 方法，不允许在别处直接 update 主表。如果加了 Redis 缓存，更新主表之后要显式删缓存，而不是设个过期时间等着它自己失效——演示那几分钟里它大概率不会过期。

6. 验收与答辩：用一张检查表把系统跑给评审看

系统做完和系统能验收是两回事。我见过功能都写了但演示时手忙脚乱、数据对不上、来回切页面的情况，评审的印象分直接掉一档。稳妥的做法是提前准备三组「剧本数据」，每组对应一条完整的业务链路，演示时按顺序跑，跑完正好覆盖所有核心模块。

演示顺序建议从学生视角开始，再切辅导员，最后切教务管理员，这样权限差异一眼可见。每组数据跑完，顺手点开异动流水页面给对方看时间线，这是最能体现设计深度的地方。

答辩提问里出现频率最高的三个问题，提前把答案准备好。第一个是「你的系统和直接用 Excel 管理有什么区别」，答案落在状态约束和留痕上：Excel 挡不住把休学学生改成在籍这种非法操作，也追不到是谁改的。第二个是「并发怎么办」，答乐观锁加唯一索引，把status_ver那段讲清楚。第三个是「数据量大了怎么办」，答索引设计和分页策略，把联合索引的列顺序讲明白。

还有一个很多人忽略的加分项：现场跑一条一致性校验 SQL，证明主表状态和流水表最后一条记录是对得上的。

-- 一致性校验：找出主表状态与最新流水不一致的学生 SELECT s.student_no, s.status AS main_status, c.to_status AS last_change_status FROM student s JOIN student_status_change c ON c.id = ( SELECT id FROM student_status_change WHERE student_id = s.id ORDER BY effect_date DESC, id DESC LIMIT 1 ) WHERE s.status <> c.to_status AND s.deleted = 0;

这条 SQL 返回空结果，比说一百句「数据一致性好」都管用。答辩前我自己会跑三遍：导入数据后跑一遍，跑完三组剧本再跑一遍，演示前最后跑一遍。

从那以后我每次交付这类系统，都会在验收前把这张检查表和这条校验 SQL 强制走一遍，不为别的，就为了在别人问「你怎么知道它是对的」的时候，能当场给出证据。希望帮到你。

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