企业官网建设流程全解析

简介：这份学籍管理系统毕业论文配套资料面向计算机相关专业本科生与毕业设计指导教师，围绕高校学生信息、课程成绩与学籍异动等管理场景，提供从需求分析、数据库设计到功能实现、测试部署的完整参考。压缩包共24个文件，约323KB，以Java源文件与编译后的class文件为主体，辅以Word版论文及程序设计报告、Access数据库文件和若干bak备份与ldb临时文件，便于对照阅读代码、文档与数据表结构。资源已有346人学习，适合需要完成同类选题、梳理系统模块划分或补充论文素材的读者。其中论文文档可帮助把握需求边界、功能模块与测试章节的写作脉络，源码部分则覆盖学生信息、成绩查询、学籍变更等增删改查逻辑，配合数据库文件可还原表结构与字段关系；备份文件也有助于理解版本迭代和调试过程。整体体量轻便，适合作为毕业设计选题参考与实现思路对照。

1. 学籍管理系统毕业论文这套资源，真正省时间的地方不在论文模板

带毕设的开发者常犯一个顺序上的错误：先拆开压缩包翻论文正文，觉得五段式结构都差不多，模板能套就行，代码留到最后一周再看。结果登录进去是一片空白，控制台报Table 'xxx.student' doesn't exist，这时候离答辩只剩三天。血泪经验是，一套学籍管理系统毕业论文资源里最值钱的部分不是那几十页文档，而是功能清单和数据表——它们决定了论文里每一张图能不能在代码里找到落点。这套东西解决三件事：把功能边界提前定夺、把库表口径先对齐、把"论文写的"和"系统做的"缝在一起。适合计算机相关专业做毕设的人、要交带可运行系统的课程设计的人，以及被临时拉去带毕设、需要快速摸清一套陌生代码的开发者。不适合谁也很清楚：它是个单校区、单批次、演示体量的教务练习项目，别指望直接搬去当生产系统跑。

2. 论文骨架和代码骨架对不上：先对齐功能模块表再动手

这类资源最常见的毛病不是代码烂，是论文和代码两套语言。论文按"需求分析—总体设计—详细设计—系统实现—系统测试"往下走，代码按 controller / service / mapper 三层横向铺开，中间没有任何映射关系。你如果直接开始读代码，读到第三天会有种"我好像在做一个和论文无关的项目"的错觉。

所以第一步不是打开 IDE，是拿张纸把论文的三级目录抄一遍，每条后面标一个代码落点。标不上的那几条，就是后面要补或者要删的。这个动作花两小时，后面能省两天。

2.1 需求分析里的用例，要能一一落到 Controller 方法上

论文里"学生信息管理"这五个字，在代码里通常拆成五到七个接口：分页列表、详情、新增、修改、逻辑删除、批量导入、导出。你拿一张对照表把它们压平，答辩时被问"你这个模块做了什么"就能直接顺着讲。

填这张表的时候有三类格子最容易空着。第一类是论文写了但代码没做的，比如"奖惩信息管理"，很多包只在学生表里留了个reward_punish文本字段。第二类是代码做了但论文没写的，比如登录日志、字典管理，这些在论文里补一小节"系统辅助功能"就行，不补也不算硬伤。第三类是两边都有但口径不一样的，比如论文写"分页查询支持多条件组合"，代码里其实只有单关键字模糊匹配，这种要么改代码要么改论文措辞，别留着。

分页参数是这类系统里最容易踩坑的一处，常见写法是pageNum从 1 开始、pageSize默认 10，查询条件统一塞一个keyword走like。要注意的是 MyBatis-Plus 的分页插件必须显式注册，不注册的话selectPage返回的是全量数据，前端看起来"分页没生效"，实际是每页查了全表。

2.2 数据库设计章节：E-R 图和建表语句必须是同一套

论文的 E-R 图通常是通用模板改的，动辄十二三个实体：学生、班级、专业、院系、课程、成绩、教师、奖惩、宿舍、社团、缴费、用户。而压缩包里的sql目录往往只有七八张表，多出来的实体要么并进了主表，要么根本不存在。这个落差是查重和答辩的双重雷区。

处理办法只有两条路，选一条走到底：要么以代码为准重画 E-R 图，把合并掉的实体在图注里说明"奖惩信息作为学生扩展属性存储"；要么老老实实补表，补完记得同步 mapper 和接口。我一般选前者，因为补表会牵出一串连锁改动，答辩前一周动数据库是自找麻烦。

字段设计上有两个细节值得在论文里单独写一句，答辩时很加分。一是学号用varchar(20)而不是bigint，因为学号会带字母前缀，而且不做算术运算，用整型反而会导致前导零丢失。二是所有业务表加deleted和create_time，逻辑删除比物理删除更符合教务场景——学籍数据删了是要出事的。

下面这段是学生表的核心建表语句，注意索引和注释的写法：

CREATE TABLE `student` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `stu_no` varchar(20) NOT NULL COMMENT '学号，业务唯一键', `name` varchar(50) NOT NULL COMMENT '姓名', `gender` tinyint DEFAULT 1 COMMENT '性别 1男 2女', `id_card` varchar(18) DEFAULT NULL COMMENT '身份证号，脱敏展示', `class_id` bigint NOT NULL COMMENT '所属班级，关联 clazz.id', `enroll_date` date DEFAULT NULL COMMENT '入学日期', `status` tinyint DEFAULT 1 COMMENT '学籍状态 1在读 2休学 3退学 4毕业', `deleted` tinyint DEFAULT 0 COMMENT '逻辑删除 0正常 1删除', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_stu_no` (`stu_no`), -- 学号唯一，防止重复录入 KEY `idx_class_id` (`class_id`), -- 班级维度列表页高频查询 KEY `idx_name` (`name`) -- 姓名模糊查询走前缀匹配 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生学籍主表';

uk_stu_no这个唯一索引不只是为了快，它顺便挡住了"同一学生录两次"的脏数据。idx_class_id是因为班级列表页天天按班级查人，不加索引在几千行数据上也能感觉到卡。idx_name对like '%张%'这种前置通配是无效的，这点在论文里别写错，写了会被追问。

2.3 技术选型章节：把"为什么不用"写出来才算过关

大部分毕设论文的技术选型章节长这样："本系统采用 Spring Boot 框架，因为它简化了配置、提高了开发效率。"这句话放在任何一篇论文里都成立，也就是说它等于没写。真正能过答辩的写法是把取舍讲出来。

这类学籍管理系统常见的搭配是 Spring Boot 单体 + MyBatis-Plus + MySQL + Vue 前后端分离。选单体的理由很实在：部署包一个 jar 加一个 dist 目录，答辩现场用笔记本就能跑，不需要 Docker、不需要注册中心。不上微服务不是因为不会，是因为四个模块的系统拆成六个服务，光是端口和配置就够你排错一晚上。

权限这块也值得说。很多包用的是自己写的 JWT 拦截器加角色字段，而不是引入 Shiro 或 Spring Security。优点是代码短、能讲清楚；缺点是细粒度到按钮级的权限做不了，只能在接口层拦。论文里就照实写"采用基于 JWT 的轻量级认证，权限控制粒度为接口级"，别硬吹成 RBAC 模型。

下面是一个典型的拦截器注册片段，关键是放行路径和 token 解析：

@Configuration public class WebConfig implements WebMvcConfigurer { @Autowired private JwtInterceptor jwtInterceptor; @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor) // 所有业务接口都拦，除了登录和静态资源 .addPathPatterns("/**") .excludePathPatterns( "/auth/login", // 登录接口 "/auth/captcha", // 验证码 "/error", // 统一错误页 "/doc.html", "/webjars/**" // 接口文档，演示时可留 ); } }

addPathPatterns("/**")配上excludePathPatterns是白名单式写法，比黑名单安全，新增接口默认受保护。/error一定要放行，否则任何异常都会被拦成 401，你在前端只能看到"登录失效"，排查时会怀疑人生。/doc.html那行在正式答辩前建议保留，老师让你现场演示接口时很省事。

3. 把系统在本机跑起来：建库、启服务、通接口的四步

环境这一步翻车率最高，而且翻车方式特别隐蔽——不是报大红字，是启动成功了但接口 404，或者登录返回的 token 前端存了但下次请求没带上。下面按顺序走，每步都有验证动作，别跳。

3.1 版本对齐：先看 pom 和 package.json，别先装环境

拿到包第一件事不是装 JDK，是打开pom.xml看spring-boot-starter-parent的版本，再打开package.json看 vue 和 node-sass 的版本。这两个文件决定了你该装什么环境，反过来装很容易撞墙。

JDK 这块值得多说一句。Spring Boot 2.3 以前的版本大量使用javax.servlet，从 2.4 开始逐步转向jakarta，如果你拿 JDK 17 去跑一个 2.1 的项目，编译能过但启动会抛NoClassDefFoundError。这不是玄学，是包名改了。判断方法很简单，看pom.xml里 parent 版本号，2.3 及以下就老老实实装 JDK 8。

3.2 建库和初始化数据：字符集和时区一次配对

压缩包里的 sql 文件通常直接是建表语句，不带create database。你得自己建库，名字跟application.yml里的库名对上。

-- 库名跟配置文件保持一致，字符集必须 utf8mb4，否则姓名生僻字会变问号 CREATE DATABASE `student_manage` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE `student_manage`; -- 先执行表结构，再执行 data.sql 里的初始化数据 -- 初始化数据一般包含：管理员账号、院系专业班级基础字典、几门课程

参数说明上，utf8mb4而不是utf8是因为 MySQL 的utf8实际只有 3 字节，存不下 emoji 和部分生僻字，学生姓名里出现这类字符不是没可能。utf8mb4_general_ci排序不区分大小写，学号里的大写字母查询时不会漏。

初始化数据里最容易出问题的是密码。很多包的sys_user表里存的是一段 MD5 或者 BCrypt 密文，而文档里没写明文是什么。这时候去看登录接口的校验逻辑：如果是BCrypt.matches(raw, encoded)，说明是 BCrypt，你需要自己生成一个；如果是 MD5，直接算。也可以临时把校验逻辑改成明文比对，跑通之后再改回去，但改回去这一步别忘了，答辩现场被看到明文密码挺尴尬。

3.3 后端启动与接口连通性验证

配置文件通常在src/main/resources/application.yml，重点看四处：端口、数据源、context-path、JWT 密钥。

server: port: 8080 servlet: context-path: /api # 前端 baseURL 必须带上这段 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/student_manage?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: root mybatis-plus: configuration: map-underscore-to-camel-case: true # 数据库 stu_no 自动映射成实体 stuNo global-config: db-config: logic-delete-field: deleted # 逻辑删除字段名 logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: your-secret-key-here # 答辩前记得换掉默认值 expire: 7200 # 单位秒

serverTimezone=Asia/Shanghai这个参数不加，MySQL 8.0 会抛The server time zone value is unrecognized，这是新手最常见的启动失败原因之一。map-underscore-to-camel-case不开的话，实体里stuNo字段永远是 null，而数据库里明明有值，这种静默失败很难查。

启动之后别急着开前端，先用 curl 打一发登录，确认后端链路是通的：

# 1. 登录，拿到 token curl -X POST http://localhost:8080/api/auth/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"admin123"}' # 期望返回：{"code":200,"data":{"token":"eyJhbGciOi..."},"msg":"success"} # 2. 带上 token 访问受保护接口，验证拦截器放行逻辑 curl http://localhost:8080/api/student/page?pageNum=1&pageSize=10 \ -H "Authorization: Bearer eyJhbGciOi..." # 3. 不带 token 访问同一接口，期望返回 401，验证拦截器生效 curl -i http://localhost:8080/api/student/page?pageNum=1&pageSize=10

这三步的意义在于把"后端有没有起来"和"权限有没有生效"分开验证。如果第 1 步就返回 404，看context-path是不是漏了/api；如果第 2 步返回 401，说明 token 没解析出来，去拦截器里打印一下 header；如果第 3 步也返回 200，说明拦截器根本没注册上，回去看WebConfig有没有被@Configuration扫到。

3.4 前端联调：baseURL 和代理是两回事

前端起来之后第一件事是配baseURL。很多人把地址写死在request.js里，本机跑没问题，换个机器就全 404。

// src/utils/request.js import axios from 'axios' const service = axios.create({ // 走环境变量，打包时按 .env.production 切换，别写死 localhost baseURL: process.env.VUE_APP_BASE_API || '/api', timeout: 10000 }) // 请求拦截：统一挂 token service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) // 响应拦截：401 统一跳登录，别的错误统一弹提示 service.interceptors.response.use( res => res.data, err => { if (err.response && err.response.status === 401) { localStorage.removeItem('token') location.href = '/login' } return Promise.reject(err) } ) export default service

baseURL走/api相对路径，开发阶段靠vue.config.js里的devServer.proxy转发到 8080，生产阶段靠 Nginx 转发。这样同一份代码两边都能跑，不会出现"开发环境好好的，打包就废了"。

代理配置长这样：

// vue.config.js module.exports = { devServer: { port: 9528, proxy: { '/api': { target: 'http://localhost:8080', // 后端地址 changeOrigin: true // 必须开，否则后端拿到的 Host 是前端端口 } } } }

注意这里不需要pathRewrite，因为后端的context-path本身就是/api，把/api重写掉反而会对不上。这一点很多教程写反了，抄过来就是 404。

4. 学籍业务的三张主表和两条链路：异动与成绩怎么串起来

学籍管理系统的"业务深度"其实只有两条线：一条是组织结构线（院系—专业—班级—学生），一条是状态变更线（入学—在读—休学/转专业—毕业/退学）。论文里把这两条线讲透，比堆十个功能模块都管用。

4.1 学生—班级—专业—院系的树形结构，别做成无限级

有人一看"树形"就想上递归、上parent_id自关联。教务场景里层级是固定的四层，深度不会变，用四张表加外键关联反而更清晰，查询也不用递归。用自关联树的唯一好处是"以后加一层不用改表"，但这个"以后"在毕设周期里不存在。

层级与编码的对应关系建议在论文里列成表：

学号生成规则是这套系统里少数几个能体现"设计感"的点，规则写清楚，答辩时老师会点头。常见做法是"入学年份 4 位 + 院系 2 位 + 专业 2 位 + 班级 2 位 + 班内序号 3 位"，共 13 位。

public String generateStuNo(Long classId, int seq) { // 一次查出班级及其上级，避免在循环里查库 ClazzVO vo = clazzMapper.selectWithParent(classId); return String.format("%d%s%s%s%03d", vo.getGrade(), // 入学年份，如 2024 vo.getDeptCode(), // 院系编码，2 位 vo.getMajorCode(), // 专业编码，2 位 vo.getClassCode(), // 班级编码，2 位 seq); // 班内序号，左补零到 3 位 }

%03d保证序号从 1 到 999 都是三位，排序时不会出现 "10" 排在 "9" 前面。序号不能简单用count(*) + 1，因为逻辑删除过的记录还在表里，会算出重复学号，正确做法是取当前班级下max(seq)再加一，或者干脆用数据库自增再回填。

4.2 学籍异动的状态机：能做什么比做了什么更重要

学籍异动这块，新手最容易写成"随便改状态"，前端给个下拉框，后端直接 update。结果就是出现"已退学的学生又复学了"这种数据。异动的本质是有限状态机，必须把允许的迁移列出来。

这张表直接对应代码里的校验逻辑：

public enum StudentStatus { STUDYING(1, "在读"), SUSPENDED(2, "休学"), QUIT(3, "退学"), GRADUATED(4, "毕业"); // 允许的状态迁移：key 是当前状态，value 是可达状态集合 private static final Map<StudentStatus, Set<StudentStatus>> ALLOWED = Map.of( STUDYING, Set.of(SUSPENDED, QUIT, GRADUATED, STUDYING), // STUDYING 自迁移用于转专业 SUSPENDED, Set.of(STUDYING, QUIT), QUIT, Set.of(), // 终态，不允许再变更 GRADUATED, Set.of() ); public static boolean canTransfer(StudentStatus from, StudentStatus to) { return ALLOWED.getOrDefault(from, Set.of()).contains(to); } }

这里把"转专业"设计成STUDYING → STUDYING的自迁移，是为了让它和"休学复学"走同一套异动记录逻辑，代码只有一条路径，不容易漏。QUIT和GRADUATED是终态，集合留空，任何变更请求直接拒绝。这种写法比一堆if-else好维护，答辩时也好讲。

异动表一定要存old_value和new_value，而不是只存一个change_type。原因很实在：老师问"这个学生什么时候从哪个专业转过来的"，你只有类型字段答不上来。

4.3 成绩与学籍的联动查询：快照比关联更可靠

成绩查询表面上是student join score join course三表联查，真正的问题在转专业之后。学生大二从专业 A 转到专业 B，他在专业 A 修的课还算不算？成绩单上显示的"所属专业"是 A 还是 B？如果查询时用当前class_id去关联，历史成绩单的专业口径就会跟着变，学生一看就懵。

解决办法是在异动记录里存专业快照，查询时按学期关联当时的快照：

-- 按学号查完整成绩单，专业列取"该学期生效的专业" SELECT s.stu_no, s.name, c.course_name, c.credit, sc.score, sc.term, -- 若该学期存在转专业异动，取异动前的专业名，否则取当前专业 COALESCE( (SELECT m2.major_name FROM student_change ch JOIN major m2 ON m2.id = ch.old_major_id WHERE ch.stu_id = s.id AND ch.change_type = 'TRANSFER_MAJOR' AND ch.effect_date <= LAST_DAY(STR_TO_DATE(CONCAT(sc.term,'-01'), '%Y-%m-%d')) ORDER BY ch.effect_date DESC LIMIT 1), m.major_name ) AS major_at_term FROM student s JOIN score sc ON sc.stu_id = s.id JOIN course c ON c.id = sc.course_id JOIN clazz cl ON cl.id = s.class_id JOIN major m ON m.id = cl.major_id WHERE s.stu_no = #{stuNo} ORDER BY sc.term DESC, c.course_name;

COALESCE的第一个参数是快照查询，查不到就退回当前专业，保证没有异动记录的学生也能正常显示。effect_date <= 该学期最后一天这个条件保证只取生效过的异动，未来的异动不影响历史成绩单。ORDER BY ... LIMIT 1取最近一次，处理一个学期内多次异动的极端情况。

这条 SQL 在论文的"详细设计"章节可以单独列一小节，配一张"转专业学生成绩单口径"的示意图。它比那些"学生管理增删改查"的截图有说服力得多，因为它体现的是对业务的理解，不是对框架的熟练度。

5. 论文与代码对齐时的四个翻车点：从查重到答辩追问

前面讲的是怎么把系统跑起来、把业务讲圆。这一章讲的是具体在哪些地方会翻车，每条都是实打实会遇到的现象。

5.1 坑一：论文里 12 个实体，库里只有 7 张表

现象：E-R 图画得很饱满，学生、教师、课程、成绩、奖惩、宿舍、社团、缴费一应俱全，打开 sql 文件数了数，7 张表，多出来的实体一个都没有。

原因：论文模板是通用教务系统改的，代码是精简实现的教学 demo，两边压根不是一次做出来的。很多人拿到包只顾着跑代码，跑到最后才发现论文里的图对不上库。

解决：以代码为准，重画 E-R 图，把合并掉的实体在图下方的说明里交代清楚，比如"奖惩信息以记录形式存于 student_ext 扩展表，不单独建实体"。同时在论文的"系统实现"章节加一句"为控制演示规模，部分辅助实体做合并处理"，主动承认比被追问强。如果反过来补表，记得同步补 mapper、service、controller 三层，答辩前一周做这件事风险很高。

5.2 坑二：查重率突然飙高，多半是技术选型章节整段抄

现象：初稿查重 18%，改了两天变成 42%，改的地方还是自己写的业务章节。

原因：查重系统比对的是连续相同字数，而"Spring Boot 简化了配置、提高了开发效率"这类套话在库里被抄了几万遍，任何一篇毕设都会撞。你越是想把这章写"规范"，越容易撞库。

解决：把技术选型章节改写成"踩坑叙述"。不要写"采用了 Spring Boot"，写"最初用 xxx 方案，在 yyy 场景下出现 zzz 报错，换成 Spring Boot 后通过 aaa 配置解决"。具体的报错信息、版本号、解决步骤，这些内容查重库里没有，天然低重复。副作用是这章会变长，但答辩时老师更愿意听这个。

5.3 坑三：本机能跑，换台机器全 404

现象：自己笔记本上一切正常，拷到答辩教室的电脑上，登录页能开，点登录转圈，控制台一片红。

原因：九个里有八个是baseURL写死了http://localhost:8080，而换机器后后端端口或者路径变了；剩下一个是前端路由用了 history 模式，直接打开二级页面找不到资源。

解决：baseURL一律走环境变量，生产构建用相对路径/api，配合 Nginx 或者serve做转发。路由模式在答辩场景下建议直接用 hash 模式（地址带#），省掉服务端配置 fallback 的麻烦，虽然不好看但不会出错。提前一天在答辩用的机器上完整跑一遍，别等到现场。

5.4 坑四：被问"这个字段为什么这么设计"，答不上来

现象：老师随手一指student表里的status字段，问为什么用tinyint不用varchar，为什么没有单独的状态表，当场卡住。

原因：只跑了代码没读表。字段是别人设计的，你只是把它跑起来了，一旦追问设计意图就露馅。

解决：给每张核心表写三句话——存什么、谁写入、谁读。以student_change为例："存学籍变更的流水，辅导员提交时写入，管理员审批时更新状态，成绩单和学籍卡查询时读取。"这三句话能挡住 80% 的追问。再给每个枚举字段准备一句理由，比如status用tinyint是因为取值固定且只做等值判断，加索引占空间小。准备这些不费时间，一个下午能把七张表过完。

6. 答辩演示版怎么攒：种子数据、演示动线和一个自检脚本

演示版和自己跑通的版本是两回事。自己跑通只要不报错，演示版要保证在任何一台陌生机器上，三分钟内能展示出"系统是活的"。核心就三样：够用的种子数据、一条不会卡壳的点击动线、一个开跑前的自检。

6.1 种子数据要覆盖"有故事"的状态

不要只插一堆"在读"的学生，那样演示异动功能时没东西可点。种子数据里至少要有：一个正常在读的、一个休学的、一个转过专业的、一个已毕业的。这样演示异动审批、成绩单口径、状态筛选时都有现成数据。

-- 演示用种子数据，覆盖四种学籍状态 INSERT INTO student (stu_no, name, gender, class_id, enroll_date, status) VALUES ('2024010302001', '张A', 1, 1, '2024-09-01', 1), -- 在读 ('2023010302007', '李B', 2, 1, '2023-09-01', 2), -- 休学 ('2022010303012', '王C', 1, 2, '2022-09-01', 1), -- 转过专业，仍在读 ('2020010301005', '赵D', 1, 3, '2020-09-01', 4); -- 已毕业 -- 对应的转专业异动记录，成绩单口径演示靠它 INSERT INTO student_change (stu_id, change_type, old_major_id, new_major_id, effect_date, audit_status) VALUES (3, 'TRANSFER_MAJOR', 1, 2, '2023-09-01', 1);

audit_status要用 1 表示已通过，别插成待审批，否则演示时点"查看历史"什么都看不到，还得现场改数据。

6.2 演示动线：从登录到出结果不超过五步

答辩演示最怕的是"点进去发现自己也不知道下一步该点哪"。提前把动线定死，写在一张纸上贴在屏幕边：

第 4 步是加分项：故意对一个"已退学"的学生点休学，让系统弹出"当前状态不允许该操作"，比任何 PPT 都能说明你做了状态校验。

6.3 一个开跑前的自检脚本

答辩当天早上花两分钟跑一遍，比现场手忙脚乱强。脚本只做三件事：库连得上、服务起着、关键接口返回 200。

import requests, sys BASE = "http://localhost:8080/api" checks = [] def check(name, fn): try: fn() checks.append((name, "OK")) except Exception as e: checks.append((name, f"FAIL: {e}")) # 1. 登录接口能返回 token def login(): r = requests.post(f"{BASE}/auth/login", json={"username": "admin", "password": "admin123"}, timeout=5) assert r.status_code == 200 and r.json()["data"]["token"], "no token" global TOKEN TOKEN = r.json()["data"]["token"] # 2. 核心列表接口能返回数据，且种子数据存在 def student_page(): r = requests.get(f"{BASE}/student/page", params={"pageNum": 1, "pageSize": 10}, headers={"Authorization": f"Bearer {TOKEN}"}, timeout=5) assert r.status_code == 200, f"status {r.status_code}" assert r.json()["data"]["total"] >= 4, "种子数据不足 4 条" # 3. 无 token 必须被拦 def auth_guard(): r = requests.get(f"{BASE}/student/page", timeout=5) assert r.status_code == 401, f"拦截器失效，返回 {r.status_code}" check("登录", login) check("学生分页", student_page) check("鉴权拦截", auth_guard) for name, result in checks: print(f"[{result}] {name}") sys.exit(0 if all(r == "OK" for _, r in checks) else 1)

三项检查分别对应三种最常见的现场故障：库没导、种子数据忘了插、拦截器配错导致越权访问。返回码为 0 才继续，任何一项 FAIL 就先修，别硬着头皮上台。

最早带第一版的时候，我图省事，把种子数据和建表脚本合并成一个文件，本地跑了两周没问题，结果答辩机器上 MySQL 版本低了一档，DEFAULT CURRENT_TIMESTAMP那行直接报错，整个脚本中断，表一张都没建上。从那以后我每次交出去之前，都强制把"建库、建表、种子数据"拆成三个独立文件，并且在一台干净的虚拟机上从零跑一遍。这个习惯后来救过不止一次。希望帮到你。

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