学生管理系统项目实战：从数据库建模到认证与联调

“学生管理系统”应该是我见过出现频率最高、但最容易被做砸的项目之一。为什么这么说？因为大部分人拿到题目后的第一反应是“这不就是一套增删改查吗”，然后照着网上的模板敲一遍，页面能开、数据库能连、成绩能录进去，就觉得自己完成了。但等到答辩或者面试被追问一句“你的成绩表为什么这样设计”“班级删了学生怎么办”“token过期了接口怎么处理”，立刻卡壳。

这篇文章我打算从一个非常务实的技术选型出发，把“学生管理系统”从需求拆解、数据库建模、后端认证与接口、前端联调，一直讲到实测中会踩到的真实故障和排错链路。全文不整花活，用的都是社区里最常见、最容易复现的技术组合，适合正在做课程设计、准备简历项目，或者想把这个经典题目做到“能讲清楚”的开发者参考。

1. 拆解“学生管理系统”五个字：需求边界、考核点与技术选型

1.1 没有需求文档时，先锁住四个问题

很多老师出题时就给五个字，连角色划分都不写。这时候最忌讳的不是做不出来，而是自己把范围越扩越大。我见过有同学在学生管理系统里塞了自动排课、在线考试、消息推送、人脸签到，结果半个月过去，连学生的基本档案都没做完。课程设计类项目最重要的能力是“收敛范围”。

没有需求文档时，建议先按最经典的四块功能做：管理员登录、学生信息管理、班级课程维护、成绩管理。学生信息管什么？管学号、姓名、性别、出生日期、手机号、所属班级、入学年份这些基础档案。班级和课程是两类基础数据，班级下面挂着学生，课程和成绩通过一张成绩表产生业务关系。这样一来，系统的业务闭环就出来了：管理员登录后维护班级和课程，再录入学生、给学生登记各科成绩，列表页提供查询、分页、修改和删除。

提示：如果题目来自实际企业或老师给出的详细说明，一定以题目要求为准。这里说的是“只有标题没有正文”时的兜底方案。

功能边界明确后，可以把模块拆成一张表，方便自己对照进度：

1.2 隐藏的考核点不是增删改查，而是约束和异常

判断一个人是真写过代码还是背过模板，最好的办法不是看他功能全不全，而是问几个边界问题：学号重复了怎么办？成绩表里同一门课录了两遍怎么处理？一个已经有学生的班级被删除了，学生数据去哪了？搜索框传了 1; DROP TABLE student 这种内容怎么办？

这些问题全是学生管理系统里的真实场景，也是整个项目真正的考核点。一个合格的系统必须有字段唯一性约束、业务层重复校验、删除前的关联数据校验、参数合法性校验和数据库操作的安全处理。这些东西加起来，远比“能用”重要，这才是能拿去给面试官讲的东西。

1.3 技术选型为什么建议“稳”，不追“新”

技术栈的选择没有标准答案，但我个人强烈建议课程设计和简历项目优先选社区资料最多、自己所在学校或小组最可能熟练使用的组合，而不是挑一个“听起来很酷”的冷门框架。后端用 Spring Boot，前端用 Vue，数据库用 MySQL，这组搭配在目前的主流讨论里资料最全、坑基本都被人踩平了，遇到问题半天之内就能搜到答案。

版本上也要克制。Spring Boot 用 2.x 或 3.x 任一稳定版都行，但建议一开始就锁死具体版本号，不要今天升这个、明天升那个。MyBatis-Plus 可以减轻单表 CRUD 的工作量，把精力放在登录认证、分页、事务这些真正的业务点上。前端如果时间紧张，用 Vue + Element Plus 这类组件库最省事，表格、弹窗、表单、分页全是现成的，能少写大量重复样式代码。

提示：我这里按最主流的 Java + Vue 方案展开。如果你用 Python Flask、Django，或者纯 JSP + Servlet，后端和数据库设计的思路依然通用，区别主要在具体框架的语法层。

2. 数据库建模的取舍：从实体关系到五张核心表的落地

2.1 先用关系分析代替“灵光一现”式的建表

我见过不少人打开 Navicat 就开始建表，建到一半发现学生表里没法直接存多门成绩，又回去拆表，拆完又发现班级字段不知道放哪里。根本原因是跳过了实体关系分析这一步。

在学生管理系统里，核心实体有五个：管理员、学生、班级、课程、成绩。它们的关系是这样的：一个班级下有多个学生，所以班级和学生是一对多关系，学生表里存班级编号；一个学生可以选多门课程，一门课程可以被多个学生选，学生和课程是多对多关系。但多对多不能在数据库里直接表达，必须拆出一张中间表，也就是成绩表，成绩表里同时保存学生编号和课程编号。这样五张表就齐了。

这个分析过程看起来很简单，但它决定了后面所有 SQL、接口、页面怎么写。建议在动手之前先花十分钟把这个关系写出来，不要直接编码。

2.2 核心表字段怎么定：建表时要把索引和约束一起想清楚

核心表的 SQL 可以直接参考下面这套，字段和注释都比较贴近课程项目的实际需求。

班级表：

sql复制CREATE TABLE `t_class` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '班级主键',
  `class_name` VARCHAR(50) NOT NULL COMMENT '班级名称，如 软件2101',
  `grade` VARCHAR(20) NOT NULL COMMENT '年级，如 2021',
  `major` VARCHAR(50) NOT NULL COMMENT '专业，如 软件技术',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_class_name` (`class_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='班级表';

学生表：

sql复制CREATE TABLE `t_student` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '学生主键',
  `student_no` VARCHAR(20) NOT NULL COMMENT '学号',
  `name` VARCHAR(50) NOT NULL COMMENT '姓名',
  `gender` TINYINT NOT NULL DEFAULT 1 COMMENT '性别 1男 2女',
  `phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号',
  `class_id` BIGINT NOT NULL COMMENT '班级ID，逻辑关联 t_class.id',
  `status` TINYINT NOT NULL DEFAULT 1 COMMENT '状态 1在读 0休学/已离校',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_student_no` (`student_no`),
  KEY `idx_class_id` (`class_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';

课程表和成绩表在业务上同样关键，课程表用来解决“成绩属于哪门课”的问题，成绩表则承载了系统的核心业务规则：

sql复制CREATE TABLE `t_course` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '课程主键',
  `course_name` VARCHAR(100) NOT NULL COMMENT '课程名称',
  `credit` DECIMAL(3,1) DEFAULT NULL COMMENT '学分',
  `teacher` VARCHAR(50) DEFAULT NULL COMMENT '任课教师',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_course_name` (`course_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表';

CREATE TABLE `t_score` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '成绩主键',
  `student_id` BIGINT NOT NULL COMMENT '学生ID，逻辑关联 t_student.id',
  `course_id` BIGINT NOT NULL COMMENT '课程ID，逻辑关联 t_course.id',
  `score` DECIMAL(5,2) NOT NULL COMMENT '成绩分数 0-100',
  `exam_type` TINYINT NOT NULL DEFAULT 1 COMMENT '考试类型 1期中 2期末 3补考',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_student_course_exam` (`student_id`, `course_id`, `exam_type`),
  KEY `idx_course_id` (`course_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生成绩表';

这套设计里最值得讲的是成绩表的联合唯一索引 uk_student_course_exam。它保证了同一学生同一门课同一种考试类型只能有一条成绩记录。这是数据库层面的最后一道防线，就算后端代码里忘记做重复判断，数据库也不会让你插进去。

2.3 两个容易忽略的设计细节：为什么不建物理外键、为什么要冗余状态字段

很多课程设计喜欢在创建表时直接写 FOREIGN KEY 物理外键，实际项目里反而几乎不用。原因是物理外键会带来一系列连锁问题：删除有成绩记录的学生时会报错、批量导入数据时容易失败、分布式的环境里根本无法保证外键约束。学生管理系统虽然数据量不大，但既然你要做的是“像一个真正干过项目的人”，就更推荐用逻辑外键，也就是只在应用层维护关联关系，通过业务校验保证数据一致。面试官问到的时候，你能说清楚这个理由，比直接用外键加分得多。

另外在业务表中加入创建时间、更新时间和状态字段，是一种成本极低、收益极高的习惯。后面如果学生出现休学或毕业，不需要物理删掉记录，用 status 区分即可；排查数据问题时，时间字段能帮你快速定位“这条数据是什么时候被谁改的”。

3. 后端最难遮掩的三个设计环节：认证、分页与事务

3.1 登录认证：JWT 不是加分项，而是这个项目绕不开的底座

学生管理系统如果不做登录认证，所有页面都能直接访问，那这个项目在演示时基本拿不出手。最常用的方案是用 JWT + 拦截器。后端登录成功时签发一个带有效期的 token，前端调用业务接口时在请求头里携带 token，后端用一个拦截器统一做校验。

认证逻辑可以按下面的思路写，先在登录接口里完成用户校验和 token 签发：

java复制@PostMapping("/login")
public R<LoginVO> login(@RequestBody @Valid LoginDTO dto) {
    AdminUser user = adminUserService
            .lambdaQuery()
            .eq(AdminUser::getUsername, dto.getUsername())
            .eq(AdminUser::getStatus, 1)
            .one();
    if (user == null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) {
        throw new BizException("用户名或密码错误");
    }
    String token = JwtUtil.createToken(user.getId(), user.getUsername());
    return R.ok(new LoginVO(token, user.getNickname()));
}

再写一个拦截器，对非登录接口统一做 token 解析和用户上下文注入：

java复制public class LoginInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 前端跨域预检请求直接放行
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }
        String token = request.getHeader("Authorization");
        if (token == null || token.isEmpty()) {
            throw new BizException(401, "未登录或登录已过期");
        }
        Long userId = JwtUtil.parseToken(token);
        UserContext.set(userId);
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        // 防止内存泄漏
        UserContext.clear();
    }
}

用户密码一定不能明文存在数据库里，使用 BCrypt 这类带盐的哈希算法做加密。把这段代码放到项目里之后，接口的安全性就上了一个台阶，演示的时候你可以当场打开浏览器，不登录直接访问接口地址，看到 401 提示，这就是一个能说出口的亮点。

3.2 分页查询与动态条件：把搜索做成分页而不是全表 list

学生列表最常见的诉求是：管理员想按姓名搜某个学生，或按班级筛选，或按入学年份筛选。新手最容易犯的错误是把符合条件的记录全部查出来返回给前端，让前端再去做内存筛选。数据量小的时候看着没事，一旦录入几千个学生，每次请求都全表扫描，接口响应就会越来越慢。

正确做法是把分页参数和查询条件封装成一个查询对象，后端动态拼接条件。MyBatis-Plus 里最简单的写法长这样：

java复制public PageResult<StudentVO> pageStudents(StudentQuery query) {
    Page<Student> page = new Page<>(query.getPageNo(), query.getPageSize());
    LambdaQueryWrapper<Student> wrapper = Wrappers.lambdaQuery(Student.class)
            .like(StringUtils.hasText(query.getName()), Student::getName, query.getName())
            .eq(query.getClassId() != null, Student::getClassId, query.getClassId())
            .eq(query.getGender() != null, Student::getGender, query.getGender())
            .orderByDesc(Student::getCreateTime);
    Page<Student> result = studentMapper.selectPage(page, wrapper);
    // 再转换成 VO 返回给前端，避免把数据库实体直接暴露出去
    return PageResult.of(result, StudentVO::fromEntity);
}

这里要注意两个细节。第一个是安全，所有动态查询条件必须走参数绑定，不能把前端传来的内容直接拼进 SQL 字符串，否则就存在 SQL 注入风险。第二个是空值过滤，前端的搜索框如果不填、下拉框选择“全部”通常传 null，后端要通过条件判断决定这个条件是否参与拼接，保证查出的是“全部符合条件的数据”而不是“被空值条件过滤完的零条数据”。

3.3 成绩录入的事务边界：为什么 rollbackFor 必须写

成绩录入不是简单的单表 insert。正常的业务逻辑是：先检查学生是否存在，再检查课程是否存在，再检查同一学生同一课程的同一考试类型是否已经录过分，最后才插入成绩。这一连串操作里任何一步出现异常，都不应该让前面的检查结果落库。

所以成绩录入方法必须加上事务注解：

java复制@Transactional(rollbackFor = Exception.class)
public void addScore(ScoreDTO dto) {
    Student student = studentMapper.selectById(dto.getStudentId());
    if (student == null) {
        throw new BizException("学生不存在");
    }
    Course course = courseMapper.selectById(dto.getCourseId());
    if (course == null) {
        throw new BizException("课程不存在");
    }
    Long count = scoreMapper.selectCount(Wrappers.lambdaQuery(Score.class)
            .eq(Score::getStudentId, dto.getStudentId())
            .eq(Score::getCourseId, dto.getCourseId())
            .eq(Score::getExamType, dto.getExamType()));
    if (count > 0) {
        throw new BizException("该学生该课程的此类型成绩已存在");
    }
    scoreMapper.insert(convertToEntity(dto));
}

这段代码里有一个实际项目中踩过无数次的坑：@Transactional 默认只对 RuntimeException 做回滚，而如果你抛的是自定义的业务异常且没继承运行时异常，事务就不会生效。因此这里要显式写 rollbackFor = Exception.class，把根因说清楚。

事务失效的另外两个常见场景也得明白。一是同一个类内部的方法直接调用，事务注解会被绕过，因为 Spring 事务基于代理对象，内部调用没有经过代理；二是 MySQL 表的存储引擎不是 InnoDB，事务一样不生效。如果录成绩时发现数据异常半途插入进去了，优先排查这三类情况。

4. 管理端页面与接口联调：那不是把组件堆上去

4.1 页面结构先定信息流，再动手写组件

Vue 项目的页面结构建议遵循经典的登录页、首页布局、业务列表页三层结构。登录页拿到 token 后存到本地，并写入请求封装里；首页布局是左侧菜单加右侧内容区；菜单对应的业务页面就是学生管理、班级管理、课程管理、成绩管理。

有同学喜欢一上来就写表格，写一半发现不知道接口返回什么结构，又反复改。先定信息流可以把前后端接口定清楚：登录接口传什么参数，返回什么 token；学生分页接口的入参是 pageNo、pageSize、name、classId、gender，返回值里要有 total 和 records 两层结构。这个结构一旦定好，前端组件可以很快推进，后端也能同步去实现。哪怕两个角色是一个人，先定接口也会让思路清晰很多。

4.2 字段命名不一致，是联调事故的重灾区

学生管理系统联调时最普遍的现象是：前端表格永远空白，打开控制台看到接口返回 200，数据也有，但表格就是不显示。绝大多数原因是后端返回的字段是 studentNo，而前端表格列里写的是 student_no，或者反过来。这背后是 Java 的驼峰命名和数据库下划线命名不一致导致的经典问题。

解决思路有两个层面的经验。后端持久层框架建议开启下划线转驼峰映射，这样数据库的 student_no 能正确映射到实体的 studentNo。但向前端返回数据时，不要直接拿数据库实体类转 JSON，建议单独封装 VO 对象，VO 里的属性名就是你对外暴露的接口契约，跟前端约定好之后就不要轻易改动。这样做的好处是数据库字段改变不会直接冲击页面接口，后端内部实现细节也被隔离了。

4.3 统一 axios 请求封装和错误处理，至少节省三小时排查时间

写前端请求时，如果每个页面都自己调 axios、自己处理错误，项目一大会出现大量重复代码，而且错误提示五花八门。建议集中封装一个 request 实例，把 token 注入、响应拦截、业务错误提示统一放在一个文件里。

js复制import axios from 'axios'
import { ElMessage } from 'element-plus'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

request.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = token
  }
  return config
})

request.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code !== 200) {
      ElMessage.error(res.msg || '请求失败')
      return Promise.reject(new Error(res.msg))
    }
    return res
  },
  error => {
    if (error.response && error.response.status === 401) {
      ElMessage.error('登录已过期，请重新登录')
      localStorage.removeItem('token')
      window.location.href = '/login'
    } else {
      ElMessage.error(error.response?.data?.msg || '网络异常')
    }
    return Promise.reject(error)
  }
)

前端表单校验和后端参数校验要双重做，但最终以数据库和后端为准。前端做手机号格式、非空判断，是为了用户体验更好；后端必须再做一遍，因为绕过前端直接调接口是很容易的事情。学号重复这种业务校验，可以在插入前先用查询条件检查一次，同时数据库唯一索引做兜底，双保险万无一失。

5. 联调与实测中的三个真实故障：完整排查链路记录

5.1 登录成功之后，所有业务接口全部 401

表现：登录接口正常返回 token，但跳转到首页后，学生列表接口全部报 401 未登录。打开浏览器控制台，发现请求头里确实带了 Authorization。

排查链路我建议按三层来走：

第一层：先确认前端是否正确注入 token。如果使用的是上面的 axios 封装，优先检查是不是在登录成功之后没有把 token 写入 localStorage，或者跳转首页时页面刷新导致内存里的 token 丢了，但 localStorage 又没读到。

第二层：后端拦截器的放行规则是否把登录接口排除了。如果拦截器 addPathPatterns("/**") 拦截了所有路径，而登录接口本身没有 token，它也会被拦截并返回 401。需要配置登录接口为白名单。

第三层：最隐蔽的一层是跨域预检请求。浏览器在发起带 Authorization 头的跨域请求前，会先发一个 OPTIONS 预检请求，如果拦截器把预检请求也拦截了，后端直接返回 401，浏览器就会认为真正的请求不可用。修复方式就是在拦截器里对 OPTIONS 请求放行，并正确配置跨域规则。

提示：实际项目里建议给所有涉及认证的接口写一个最小的集成测试，至少保证“登录后获取当前用户信息”这条链路在部署时是通的，别等演示现场才发现过期时间设成了 30 秒。

5.2 页面表格里中文正常，导出 Excel 时中文文件名乱码

很多学生管理系统做到后期会加“导出学生列表”功能，然后就会遇到这个问题：页面显示完全正常，但导出的文件名变成 %E5%AD%A6%E7%94%9F%E5%88%97%E8%A1%A8.xlsx 这样的字符串，或者文件里的中文内容变成乱码。

文件名乱码的根本原因是 HTTP 响应头里的 Content-Disposition 不支持浏览器默认解析的中文字符，必须做 URL 编码。写法上不要直接写文件名：

java复制String fileName = "学生名单.xlsx";
fileName = URLEncoder.encode(fileName, StandardCharsets.UTF_8.name()).replaceAll("\\+", "%20");
response.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + fileName);

文件内容乱码的情况要检查响应头字符集是不是被设置成了 text/html，正确做法是为下载接口设置 application/vnd.openxmlformats-officedocument.spreadsheetml.sheet，不要画蛇添足地加 charset=UTF-8。

5.3 删除已被学生绑定的班级，列表页出现一堆“无班级”学生

这个故障在我的印象里几乎每个学生管理系统都会出现一次。操作路径是：管理员在班级管理页面删除了一条班级记录，回到学生列表，发现原来属于这个班级的学生仍然存在，但班级字段已经变成空或显示不出来。

根因不在前端，而在后端删除逻辑没有做关联校验。数据库里没有物理外键，删除班级时不会阻止操作，学生的 class_id 仍然指向那个不存在的班级编号，形成悬空引用。

正确的业务设计有两种。最常见也更符合真实管理场景的是：删除班级前先查学生表有没有这个班级下的学生。如果有，就不允许删除，并返回一句人话提示：“该班级下仍有学生，无法删除”。如果确实需要删除班级并保留学生记录，则要在同一个事务里把学生的 class_id 置为某个待分配状态，或者做重新分班，而不是放任不管。

注意：添加这种业务判断后一定要顺手验证“把学生转移后再删除班级”的路径，否则可能出现学生已经被移走，但删除仍被误拦的情况。

6. 把“能跑”变成“能讲”：答辩素材、简历写法与扩展路线

6.1 至少准备三个能讲透的“为什么”

项目做完只是第一步，答辩或者面试时，真正拉开差距的是你能不能把一个点讲透。与其背十个功能的操作流程，不如提前准备三个问题。

第一个是数据库设计：为什么学生和课程是多对多，为什么要拆出成绩表？答案很简单，成绩要记录“哪个学生、哪门课、哪次考试、考了多少分”，这四个维度必须用一张独立表承载。第二个是数据一致性：删除班级时怎么办、成绩重复录入了怎么办？对应你写过的业务校验和事务处理。第三个是登录安全：密码怎么存、token 为什么设置有效期、为什么拦截器要放行 OPTIONS 请求。这三个点已经足够撑起十分钟左右的深入询问。

6.2 简历描述要把“做了什么”改成“解决了什么”

写简历时，不要只写一句“负责学生管理系统的增删改查”，那是减分项。建议提炼成可验证的实现细节，比如：设计五张核心业务表及学生与课程的多对多关系；通过联合唯一索引防止成绩重复录入；基于 JWT 实现登录认证并统一拦截未授权请求；通过分页与动态条件组合优化学生列表查询。

需要注意一个原则：简历上写的每句话都得是真能在追问中回答上来的。比如写了“优化查询”，那就要能说清楚原来是什么写法、现在的分页怎么处理、条件和参数是怎么绑定的。没有实际做过压测的数据，不要编。

6.3 后续值得扩展的三个方向，不要贪多

如果做完基础功能还有富余时间，优先做这些和现有业务契合的扩展，而不是新开一个大模块。导入导出 Excel，把学生名单批量导进系统，再把查询结果导出成文件；学生照片上传，锻炼文件存储和访问路径管理；成绩统计报表，按班级和课程维度输出平均分和及格率，锻炼聚合查询能力。

我做这类项目时习惯保留一个“十分钟演示脚本”，把核心操作固定在几张页面上。开场先登录，其次进学生列表演示分页搜索，接着录一条成绩故意重复录入看系统怎么拦截，最后展示删除有学生的班级时提示怎么返回。每一段都对应一个能说的设计点，整个演示就是一个完整的故事结构，比自己临时点来点去效果好得多。很多系统做出来不难，难的是演示时让听的人相信你真的理解它，这个小习惯帮我避免过不少次冷场。