基于SpringBoot2+Vue3+MyBatis-Plus的学生管理系统实战解析

从“学生管理系统”这类业务入手去讲技术栈选型，是不少刚接触前后端分离开发的读者最想看的切入点。正好有人问起一套基于 SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0 的学生信息管理系统源码，我也借着这个机会，把整个项目的设计思路、核心实现和部署踩坑记录完整梳理一遍。这套组合在当下Java Web开发里属于非常务实的主流方案：后端用SpringBoot简化配置和部署，MyBatis-Plus把单表CRUD操作简化到极致，前端用Vue3配合Element Plus快速搭建后台界面，MySQL8.0则承担稳定的数据存储。不管你是准备做毕业设计、课程设计，还是想系统学习前后端分离项目的搭建过程，这套系统的结构和代码都很有参考价值。

1. 项目整体设计与技术选型思路

1.1 为什么选择这个技术栈组合

先聊技术选型的底层逻辑。SpringBoot2到目前为止依然是国内多数中小型项目和生产环境的主力版本，3.x虽然已经发布，但许多第三方中间件、老项目的兼容性迁移成本并不低。SpringBoot2的好处在于生态成熟、社区资料多，遇到问题几乎都能搜到解决方案。配合内嵌Tomcat，打包成jar就能直接运行，避免了传统Java Web项目部署时的繁琐配置。学生在学习阶段用SpringBoot2入手，理解自动装配、Starter机制、配置文件优先级这些核心概念，比直接上3.x要平滑得多。

Vue3的选择同样是基于趋势考虑。Vue2虽然在2023年底官方停止维护，但存量项目量级依然庞大，而新写的项目没有理由不用Vue3。组合式API让逻辑复用和组件组织方式有了质的提升，配合Vite构建工具，开发时的热更新速度比Webpack时代的体验好了很多。更重要的是，Vue3的响应式原理和组件通信机制对于理解现代前端框架的运作方式很有帮助，学完Vue3再去看React或者其他框架，很多理念都能打通。

MyBatis-Plus在这个项目里扮演的是数据访问层的加速器角色。它不像JPA那样在复杂查询时需要花心思调优对象关系映射，也不像原生MyBatis那样需要写大量的重复XML。内置的BaseMapper提供insert、deleteById、selectById、updateById这些开箱即用的方法，项目里80%的CRUD操作不需要自己写SQL。剩下那些涉及多表关联、动态条件查询的复杂场景，再通过自定义Mapper接口和XML解决。这种“通用能力用框架、复杂逻辑写XML”的混合模式，非常贴近真实项目的开发节奏。

MySQL8.0则是数据库层面的默认选择。8.0相比5.7最重要的变化是默认字符集变成了utf8mb4，这意味着emoji表情和更多生僻字都能直接存进数据库，不需要额外修改配置。窗口函数、公共表表达式这些高级特性虽然在这个学生管理系统里用得不多，但未来做复杂统计报表时这些东西会非常有用。另一层考虑是，现在招聘市场上很多岗位的数据库Skill要求都写的是MySQL，熟悉8.0的常用操作和SQL写法本身就是就业加分项。

1.2 系统的模块划分和架构逻辑

整个系统按照典型的管理后台模式划分为前端和后端两个独立应用，通过RESTful API接口通信。后端项目结构采用经典的分层架构：Controller负责接收HTTP请求和参数校验，Service负责业务处理逻辑，Mapper负责数据库交互，Model存放实体类和DTO。这种分层结构看起来很传统，但它的价值在于清晰稳定：每一层职责单一，层与层之间通过接口衔接，后期加功能、改逻辑时不需要从入口到数据库全部重写一遍。

前端项目按Vue3的标准工程结构组织，以views目录为核心按业务模块拆分页面：登录页、学生管理页、班级管理页、课程管理页、成绩管理页、用户管理页。每个页面搭配对应的组件和API调用文件，路由配置统一放在router目录下。状态管理在项目初期只用了简单的全局store管理用户登录信息和菜单权限，不需要引入太重的状态管理方案，真正的数据状态尽量保存在页面组件内部，降低全局状态污染的风险。

模块划分上，系统业务主要围绕“学生”这个核心实体向外辐射：学生基础信息管理、班级信息管理、课程信息管理、考试成绩管理，再加上系统用户登录和权限控制，一共五个核心模块，覆盖了信息管理系统最常见的增删改查、条件分页查询、多表联查这几类操作模式。对于学习用途来说，这套结构麻雀虽小但五脏俱全——它包含了一个完整业务系统所必需的认证、授权、CRUD、关联查询、可视化反馈这些能力，学会一套就能举一反三移植到其他管理类项目中。

2. 核心功能模块详解与数据库落地

2.1 登录认证与权限控制的设计思路

学生信息管理系统虽然业务不复杂，但登录认证和权限控制是必不可少的基础设施。设计时没有引入Spring Security和Shiro这类重量级安全框架，而是用JWT + 拦截器的轻量方案实现。原因很简单：在这个项目里，RBAC权限模型的复杂度并不高，只需要区分管理员和普通操作人员两种角色，自己写一套拦截器配合JWT做身份验证，几十行代码就搞定了。如果引入Spring Security，配置过滤器链、自定义UserDetailsService、处理认证失败返回JSON格式这些环节反而容易把初学者绕晕。

JWT（JSON Web Token）的原理可以类比成一张带验证信息的通行证。用户登录成功后，后端将用户id、用户名、角色这些信息封装进Token中并做签名，前端把Token存储在本地（这里用的是localStorage），每次发起请求时在Header里带上。后端拦截器验证签名合法且没有过期，才允许请求继续访问Controller。这么做的好处是服务端无状态，多个实例部署时不需要额外做Session同步，缺点则是无法主动注销用户的登录状态，但在管理系统的场景下这个缺陷可以接受。

为了确保核心接口的安全性，还需要对部分路由增加角色校验。比如删除学生、重置密码、用户管理这些敏感操作，在拦截器验证JWT通过后，再检查当前用户的角色信息是否满足权限要求。如果权限不足，直接返回403状态码和统一格式的错误信息。前后端同时处理：后端做最终防线校验，前端根据用户角色动态渲染或隐藏操作按钮，比如普通操作员登录后看不到“用户管理”菜单，这样用户体验和安全性都有了保障。

2.2 数据库表设计与关联关系

数据库设计是一个管理系统的地基，表结构设计得好不好直接影响后期查询的复杂度和维护成本。这套系统一共设计了五张核心数据表：系统用户表（sys_user）、学生表（student）、班级表（class_info）、课程表（course）、成绩表（score）。每张表都设置了自增主键id，统一用create_time、update_time字段记录创建和更新时间，并利用MySQL8.0的DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP自动维护时间戳。

具体到字段设计，学生表除了姓名的短姓名、性别、手机号、邮箱、家庭地址这些基础信息外，还冗余了一个班级编号字段（class_id）与班级表建立逻辑关联。这里不需要物理外键约束，而是在应用层通过SQL查询来保证数据一致性。理由很实际：物理外键在批量导入数据、删除父表记录时容易引发约束冲突，而且对查询性能有影响。很多互联网公司的设计规范明确禁止使用物理外键，而是偏向用逻辑外键+应用层校验的方式。继承这套习惯，系统在数据灵活性上会有明显提升。

成绩表（score）是这套系统里最有数据关系代表性的表：它包含student_id和course_id两个业务外键，分别指向学生表和课程表，再加上成绩数值score和考试类型exam_type字段。为了避免同一个学生同一门课程重复录入成绩，专门为student_id和course_id建了联合唯一索引，这是数据表设计的一个实战细节。如果漏掉这个索引，代码里即使用普通的insert语句，在并发或重复提交的情况下也很容易出现脏数据。

建表脚本如下，可以直接在MySQL8.0中执行：

sql复制CREATE TABLE `student` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `student_no` varchar(20) NOT NULL COMMENT '学号',
  `name` varchar(50) NOT NULL COMMENT '姓名',
  `gender` tinyint DEFAULT '1' COMMENT '性别 1男 0女',
  `phone` varchar(20) DEFAULT NULL COMMENT '手机号',
  `email` varchar(100) DEFAULT NULL COMMENT '邮箱',
  `address` varchar(255) DEFAULT NULL COMMENT '家庭住址',
  `class_id` bigint DEFAULT NULL COMMENT '班级ID',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_student_no` (`student_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';

联合唯一索引的写法在成绩表中体现得更加明显，同时优化多表联查时关联字段的检索效率：

sql复制CREATE TABLE `score` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `student_id` bigint NOT NULL COMMENT '学生ID',
  `course_id` bigint NOT NULL COMMENT '课程ID',
  `score` decimal(5,2) DEFAULT NULL COMMENT '成绩',
  `exam_type` varchar(20) DEFAULT '期中' COMMENT '考试类型',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_student_course` (`student_id`,`course_id`,`exam_type`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩表';

2.3 通用CRUD与分页查询的MyBatis-Plus实现

MyBatis-Plus最香的特性在于它的BaseMapper和分页插件。实体类继承Model类（或者直接实现Serializable），Mapper接口继承BaseMapper之后，单表增删改查、批量操作、简单的条件查询全部自动获得。比如查询所有学生列表只要写studentMapper.selectList(null)，按条件查询学生按姓名模糊匹配可以拼一个LambdaQueryWrapper：

java复制LambdaQueryWrapper<Student> wrapper = new LambdaQueryWrapper<>();
wrapper.like(StringUtils.isNotBlank(name), Student::getName, name);
List<Student> students = studentMapper.selectList(wrapper);

注意like方法的第一个参数是条件判断，只有name不为空时才追加这个查询条件。这是MyBatis-Plus条件构造器的常见用法，能有效避免手写大量if拼接SQL的尴尬场面。对于姓名、学号、班级这三个搜索条件共存的分页查询，这种写法让代码可读性提升了不少。

分页查询用MyBatis-Plus自带的分页插件。使用前先注入一个PaginationInnerInterceptor配置Bean：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

配置好之后，调用selectPage方法就能自动生成带LIMIT的SQL：

java复制Page<Student> page = studentMapper.selectPage(
    new Page<>(pageNum, pageSize),
    wrapper
);
return page;

很多人第一次用这个分页插件的时候容易漏掉拦截器配置，结果发现分页不生效——查出来的数据一直是一整页全量数据，也没有生成LIMIT语句。这属于典型的配置遗漏，排查起来其实很快，确认总条数记录和当前页数据是否按预期变化就知道问题了。

2.4 多表关联查询的SQL落地

纯单表查询是撑不起实际业务的，学生信息列表需要显示班级名称，成绩列表需要显示学生姓名、学号、课程名称。这种场景下MyBatis-Plus的BaseMapper帮不上忙，需要手动写SQL做关联查询。做法是在Mapper接口中定义自定义查询方法，对应的XML中写SQL：

xml复制<select id="selectStudentPageWithClass" resultType="com.example.dto.StudentDTO">
    SELECT s.id, s.student_no, s.name, s.gender, s.phone, s.email,
           c.name AS className
    FROM student s
    LEFT JOIN class_info c ON s.class_id = c.id
    <where>
        <if test="name != null and name != ''">
            AND s.name LIKE CONCAT('%', #{name}, '%')
        </if>
        <if test="className != null and className != ''">
            AND c.name LIKE CONCAT('%', #{className}, '%')
        </if>
    </where>
    ORDER BY s.create_time DESC
</select>

用LEFT JOIN而不使用INNER JOIN的关键在于：班级数据可能因为种种原因被删除，如果使用INNER JOIN，班级已删除的学生会在查询结果中直接消失，而LEFT JOIN可以让这部分学生依然显示出来，班级名称为NULL，前端再做空值兜底处理，数据完整性更好。DTO类接收查询结果，不解耦的简单方式是在DTO中把学生基本信息字段和班级名称字段定义在一起，这与前端展示所需的字段保持了一致。

3. 后端SpringBoot2核心实现细节

3.1 项目初始化与分层配置

后端工程通过Spring Boot脚手架的Maven工程结构初始化。坐标使用SpringBoot2.7.x版本，Java8兼容，MySQL驱动、MyBatis-Plus Starter、Lombok、JWT工具库、Hutool这些常规依赖都通过pom.xml管理。SpringBoot2.7使用javax命名空间，用起来没有SpringBoot3引入jakarta带来的重新熟悉成本，这也是不少已有项目依然停留在2.x的现实原因之一。

application.yml是后端的一站式配置中心，数据库连接信息、MyBatis-Plus配置、JWT密钥和过期时间都在这里：

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/student_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

两点值得注意：第一，JDBC URL必须配置serverTimezone=Asia/Shanghai，否则MySQL8.0与Java驱动之间的时区差异会引发报错，这个问题当年困扰过很多人；第二，log-impl: StdOutImpl配置能在控制台打印完整的SQL日志，开发调试阶段保持这个配置，排查SQL问题效率会高很多。生产环境再手动切换为关闭日志输出。

3.2 统一响应与全局异常处理

前端与后端交互时，数据的返回格式应该统一。所有正常响应都包装在Result对象中，包含code（状态码）、message（提示信息）、data（业务数据）三个字段。code=200表示成功，code=500表示业务错误，前端axios拦截器统一判断code值，不再逐个处理多种返回格式。这样做的好处是后端逻辑边界清晰，也避免了前端对不同接口的不同异常结构做分散处理的麻烦。

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("操作成功");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

与之配套的是全局异常处理器。在Controller中不显式捕获业务异常，而是抛出自定义的BizException异常，由全局异常处理器拦截并返回统一格式的错误响应。这样一来，Controller层只用写正常业务逻辑，代码非常干净。权限拦截时抛出的异常也走同一套处理机制，前端拿到的永远是结构明确的JSON，而不是Tomcat默认的404或500错误页面。

3.3 JWT登录认证的落地流程

登录接口的核心逻辑：接收用户名和密码，从sys_user表中查出用户记录，对用户输入的密码做MD5加密或者更安全的BCrypt散列后与库中的密码比对。如果验证通过，则使用JWT工具类生成Token返回。生成Token时写入用户id和角色信息，并设置48小时的过期时间，保证系统的使用周期内不会频繁需要重新登录。

后端拦截器（或者称为认证过滤器）通过HandlerInterceptor实现，在preHandle方法中从请求头拿到Authorization字段，解析和验证JWT：

java复制public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    String token = request.getHeader("Authorization");
    if (token == null || token.isEmpty()) {
        throw new BizException("未登录或登录已过期");
    }
    LoginUser loginUser = JwtUtil.parseToken(token.replace("Bearer ", ""));
    if (loginUser == null) {
        throw new BizException("未登录或登录已过期");
    }
    request.setAttribute("loginUser", loginUser);
    return true;
}

在WebMvcConfigurer中注册拦截器并配置放行路径。登录接口、静态资源、错误路径放行，其余业务接口都进入拦截范围。前端在请求工具类中把Token从localStorage中取出，拼入请求头。这套流程完整跑通后，登录态传递的链路就清楚了：用户登陆获得Token，前端存Token，请求时带Token，后端拦截器解析Token，Controller从request中获取当前用户信息，整个链路闭环。

3.4 Service层业务逻辑实现范例

以学生信息的新增和编辑为例展示Service层的业务处理方式。新增学生时，先校验学号是否已存在，如果存在则抛出业务异常阻止重复添加。更新学生时，要先确认记录存在，然后对数据库中不存在该id的情况做统一兜底处理。删除学生时，需要考虑到该学生在成绩表中可能有关联记录，如果直接删除会造成数据悬挂，因此在删除学生之前需要同步删除或标记其成绩记录，考虑到项目的教学定位，这里采用了先查成绩表、有记录就同步删除的方案。

这种业务逻辑在Service层完整呈现，Controller层只是简单调用service的方法并返回结果。Service控制事务边界：在方法上方加@Transactional注解确保多表操作的事务性。比如删除学生时先删成绩再删学生，两步操作必须在一个事务中，任一步失败则回滚，避免出现学生已经删掉但成绩表残留孤儿数据的脏情况。

用户管理模块中有一个很细节的业务点很值得学习：密码重置功能。管理员可以执行重置密码，将指定用户密码重置为默认密码（比如123456），这个操作和普通编辑不同，它需要独立的Service方法和专门的接口。日志信息里也要记录操作人和被重置用户名，这在真实系统中是审计的基本要求。

4. Vue3前端实现与界面交互逻辑

4.1 Vite工程搭建与Element Plus引入

前端采用Vite创建Vue3工程。在初始化时选择vue模板之后，npm install安装Element Plus、Pinia、Vue Router、Axios四个核心依赖。Element Plus是当前Vue3生态中最成熟的中后台组件库之一，表格、表单、弹窗、消息提示这些管理系统的常见组件都有现成实现，界面风格统一度很高。

引入Element Plus有两种方式：全量引入适合快速开发阶段，按需自动导入则能让打包体积更小、项目更专业。用unplugin-auto-import和unplugin-vue-components两个插件，配合ElementPlusResolver就能自动按需引入组件和对应的样式文件，不需要手动在main.js里注册。实际开发中建议一步到位做按需引入，因为后期项目变大时再迁移的改造成本更高。

4.2 Axios请求封装与拦截器设计

前端与后端交互的核心代码就是axios实例的封装。拦截器首先从localStorage获取Token并加入请求头，所有与后端交互的请求都由这个统一出口发出，避免在每个页面重复写写Token的代码。

响应拦截器做统一处理：当响应状态码是200且业务code是200时，返回data数据给调用页面；当业务code是500时，弹出异常消息；当HTTP状态码是401时，说明Token过期，跳转回登录页。

javascript复制const service = axios.create({
  baseURL: '/api',
  timeout: 10000
});

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

service.interceptors.response.use(
  response => {
    const res = response.data;
    if (res.code === 200) {
      return res.data;
    }
    ElMessage.error(res.message);
    return Promise.reject(new Error(res.message));
  },
  error => {
    if (error.response?.status === 401) {
      localStorage.removeItem('token');
      router.push('/login');
    }
    return Promise.reject(error);
  }
);

开发环境Vite配置的proxy代理指向http://localhost:8080，这样前端通过/api开头的请求就会自动转发到后端服务，省去了生产环境跨域配置的烦恼，前后端联调时不会出现跨域相关的诡异报错。

4.3 学生管理页面的完整交互实现

学生管理页面是系统中最核心的交互页面。页面布局遵循经典的后台列表模式：顶部Condition查询区域，中间是操作按钮区域，下面是表格数据区，弹窗承载新增和编辑表单。模板结构用Element Plus的el-table和el-dialog完成。

el-table的列字段与后端返回的字段一一对应，班级名称字段用模板插槽显示，操作列中放编辑和删除按钮。新增、编辑共用同一个对话框组件，打开时通过判断当前编辑对象是否为空来区分新增或编辑模式。弹窗关闭时重置表单等代码细节，看似简单的处理却能避免很多异常情况。删除操作采用气泡确认框（el-popconfirm），防止用户误触误删。

前端页面还有一个小亮点是性别字段的显示转换：数据库里存的是0和1，表格中直接显示“男/女”。通过Element Plus的formatter属性或者自定义v-if判断都能实现，这种字段转换逻辑在前台实现比让后端返回中文字符串更符合数据规范。

4.4 路由权限与侧边菜单的动态生成

普通操作员只能看到学生管理、班级管理、课程管理、成绩管理这些业务模块，系统管理员才有用户管理菜单。这种菜单级别的权限控制采用静态路由和动态菜单相结合的方式实现：基础业务路由全量注册，用户管理路由通过权限标识进行权限判断后再动态加入。

其实这里更进阶的做法是后端返回当前用户的菜单权限列表，前端根据返回值动态添加路由并生成侧边菜单，可以很好地适配多种角色体系。考虑到项目角色有限，在代码里通过if (userInfo.role === 'admin')这样的简单判断去控制页面渲染也能完成任务。深入了解这个以后在设计大型后台的权限菜单时就不用手忙脚乱了。

vue-router的全局前置守卫是登录状态判断的基础：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token');
  if (!token && to.path !== '/login') {
    next('/login');
  } else {
    next();
  }
});

这套代码阻止未登录用户直接通过URL访问内部页面，而在登录后也无法通过浏览器的回退或其他方式跳转到登录页，除非手动退出登录，整体体验完整。

5. 环境搭建、部署运行与避坑指南

5.1 本地开发环境准备

项目跑起来需要准备的环境如下：JDK1.8以上，这里推荐JDK8或者JDK11，与SpringBoot2完美兼容；MySQL8.0数据库，需要提前安装并配置好账号密码；Node.js14以上，确保npm install依赖时不会出现奇奇怪怪的Engine版本问题；IDEA开发工具中安装Lombok插件，否则实体类编译时会报找不到getter或setter方法的错误。

MySQL8.0安装完以后，需要先创建数据库实例并导入项目提供的数据初始化SQL脚本。SQL脚本包含建库、建表和基础数据插入语句，例如管理员账号admin，密码为经过加密的密文，普通操作员账号test。这里提醒一句：如果命令行导入SQL报编码错误，记得在连接URL中加入characterEncoding=utf8参数，UTF-8中文才能正确写入。

5.2 前后端联调阶段的经典报错与排查

前后端联调时最容易出问题的就是跨域、Token失效、字段名不匹配这几类问题。

跨域错误最常见的是前端访问后端接口时报Access-Control-Allow-Origin相关错误。开发环境里用Vite的proxy配置代理就完全规避了跨域，生产环境将前端打包后由Nginx提供服务，也需要在Nginx配置中设置反向代理来处理/api路径的转发。如果非要通过跨域方式访问，后端需要配置CORS过滤器或使用@CrossOrigin注解，但这种方式一般只推荐在开发阶段临时使用。

Token失效问题的表现是登录成功后请求接口依然返回401，或者控制台提示JWT解析失败。先检查前端有没有把Token放进请求头，再检查后端JWT密钥是否与生成时一致。很多初学者习惯把JWT密钥直接写在代码里，而后端重启后密钥常量不变其实并没有问题，真正需要注意的是如果改成从配置文件读取时，配置文件中的密钥字符串必须与外层代码读取的完全一致，多一个空格都不能容忍。

字段名不匹配导致的拿不到数据也很常见。后端返回的字段是驼峰命名如studentNo，前端取的时候写成了student_no，页面显示出来就全是空。另一种情况是后端通过JOIN查询返回的DTO字段中没有包含前端需要展示的className，导致前端表格该列空白。遇到这类问题，在浏览器开发者工具中查看网络请求的实际响应数据体，就能快速定位是后端数据缺失还是前端取值错误。

5.3 MyBatis-Plus逻辑删除与分页坑位实录

MyBatis-Plus的逻辑删除配置能让数据删除变成UPDATE操作。在实体类的deleted字段上加上@TableLogic注解，并在application.yml中配置逻辑删除字段名，数据库字段默认0表示未删除、1表示已删除。这样执行deleteById时MyBatis-Plus会自动在SQL后面拼接UPDATE student SET deleted=1 WHERE id=? AND deleted=0，原本可能误删的数据记录就被相对安全地保留了。

但逻辑删除也带来了一个必须警觉的坑：多表关联查询时，如果手动写了SQL而没有带上AND deleted=0条件，那些被逻辑删除的数据依然会出现在关联查询结果中。比如成绩列表JOIN学生表查姓名时，如果学生已被逻辑删除，成绩记录依然能关联查出来这条已经被“删除”的学生数据，造成脏数据展示。最稳妥的办法是自定义SQL时显式加上逻辑删除条件，同时在涉及数据统计的场景里保持一致的过滤规则。

分页插件的坑在2.5小节已经提过，这里额外补充一个使用场景：当分页查询配合多表JOIN时，Page对象的total数值是基于外层COUNT查询结果得到的，但在SQL中写SELECT s.*, c.name AS className拼接多表时，COUNT查询生成的SQL有时候会嵌套过多层次。遇到total值不准的情况时，尽量用COUNT(DISTINCT s.id)这种明确写法或者拆分查询，避免错误的总页数影响前端分页跳转逻辑。

5.4 部署上线注意事项与体验优化

本地跑起来之后，部署到服务器上需要考虑下面几个点。后端打包使用Maven的package命令生成jar包，然后在服务器上执行java -jar student-system.jar来启动。如果服务器上还有其他服务占用80或8080端口，在启动命令后加--server.port=9999参数覆盖配置文件中定义的端口即可。

生产环境建议关闭MyBatis-Plus SQL日志输出，避免生产LOG文件被SQL淹没。把配置文件拆分成application.yml和application-prod.yml两个文件，在application.yml中通过spring.profiles.active=prod来激活生产环境配置。数据库连接字符串中也应调整连接池参数，比如maximum-pool-size这个配置，HikariCP默认最大连接池大小是10，在低并发内部系统场景其实是合适的，不需要硬调大，除非有并发量验证需求。

前端部署较传统。先执行npm run build，生成的dist目录由运维放到Nginx配置的root目录下。由于前端路由使用的是history模式，Nginx需要配置try_files $uri $uri/ /index.html，否则刷新页面时容易报404错误，这是SPA应用特有的部署细节。配好这一步后，访问域名下的任意前端路由都能正确回退到首页路由入口。

6. 常见问题速查与个人实践总结

我把项目开发过程中被问得最多的几个问题和对应的排查建议整理成了表格，方便直接对照查。

实际的研发过程中，我发现最有反思价值的一点：复杂业务不是靠框架和技巧堆出来的，而是基础功的体现。比如查询条件需要加班级名称过滤，如果你在设计数据库表时预先思考到冗余字段和查询维度，写查询就很顺畅；如果一开始没考虑，后续加需求的时候才又在SQL里临时拼接WHERE条件。这个系统虽然业务简单，但它完整地走过从需求分析、表结构设计、前后端开发、联调测试到部署上线的流程，走完一遍后对于自己做更大的业务系统的信心会明显更足。

最后说一个小技巧：如果你打算在这个项目基础上做拓展，从我的经验看，优先增加日志审计模块和高斯登录验证码功能。日志审计能记录谁在什么时间改了哪条数据，在真实系统的安全审计中几乎是必备模块；验证码则是防止暴力破解登录接口的第一道防线。这两个模块跟现有系统的认证和权限结构天然契合，加上去之后系统完整度和项目简历的含金量都会有明显提升。