SpringBoot+Vue高校课程管理系统开发实战：从选课到成绩管理

写这套SpringBoot+Vue高校课程管理系统，前前后后我接触了不少从零搭到上线的项目，也被问过无数次“课程设计能不能做个这种系统”。今天不聊虚的，直接把这类系统的核心逻辑、技术选型、代码落地和调试过程摊开讲清楚，给准备做类似项目或者正在头疼毕设、课设的同学一份能照着落地的参考。

整套系统说白了就是管理高校里“课程”这条链路的数据：学生端看课、选课、查成绩，教师端点名、录成绩、看课表，管理员维护用户、审核课程、处理选课异常。技术栈很经典，后端SpringBoot接MySQL，前端Vue做单页面应用，前后端通过JSON接口通信。这套组合在目前的高校课程设计、毕业设计乃至小型实训项目里出镜率极高，生态成熟、资料丰富，遇到问题能找到对应的解决方案。

对于想把类似项目吃透的人，我的建议是别急着复制粘贴代码。先看业务表怎么设计，再看接口粒度怎么拆，最后看前端页面和数据怎么联动。这篇文章我会从实际项目的角度，把从环境搭建、角色权限设计、核心模块实现到服务部署和常见问题排查全流程的经验写下来，部分细节是常见实践的标准做法，少数是我个人踩坑后的补充方案，供大家参考。

1. 课程管理系统到底在管理什么：业务需求与模块拆解

很多人一听“课程管理系统”觉得就是选课、查成绩，真上手做才发现牵扯的角色和数据关系远比想象中多。我遇到过的需求里，最典型的用户角色有三种：管理员、教师、学生。这三者看着简单，但权限边界、数据隔离、流程流转一旦没设计好，后面改起来就是牵一发动全身。

1.1 用户与权限怎么设计才不会乱

一个老老实实从零做的系统，我建议先别急着上Spring Security那一整套复杂流程。先把用户表设计清楚，再用一个简单的角色字段控制访问，等业务跑通了再考虑引入成熟的权限框架。

用户表通常会包含几个核心字段：用户名、密码、真实姓名、角色类型、所属院系/班级、邮箱和手机号。密码存储务必加密，常见的做法是MD5加盐或者BCrypt，这里面BCrypt更稳妥，每次哈希结果随机，碰撞和暴力破解的难度都高得多。

权限控制的实现方式有两条路。一条是Spring Security配合JWT做Token鉴权，适合对安全性要求高、接口多的场景；另一条是拦截器校验，每个请求进来先判断当前登录用户的角色，再决定放行还是拒绝。对于课程管理系统这种角色固定的项目，拦截器方案更直观，调试起来也简单，代码量比Security那套配置少很多。

提示：如果是课设或毕设，不建议一上来就引Security全家桶。很多同学被配置折磨到崩溃，反而把核心业务的逻辑写得很粗糙。先做对业务，再做安全。

1.2 课程数据的核心链路：开课、选课、授课、评教

抛开外表看本质，高校课程管理系统管的是一条完整的数据流。

第一步是“开课”。管理员或教务人员创建课程信息，包括课程名称、课程编号、学分、授课教师、上课时间、上课地点、容量上限等。这里面有个容易忽视的点：开课信息要支持一个教师开多门课，也要支持同一门课多个班级分开教学，所以在表设计时要让课程表和教师表、课程安排表的关联字段留足余地。

第二步是“选课”。学生登录后看到可选课程列表，点击选课，系统要做两件事：判断课程容量是否已满，判断是否与已有课程冲突。容量判断好写，一个count就搞定；冲突判断就需要拿学生已有课程的周次、节次、上课时间做交叉验证，这块逻辑很容易出bug，我在后面会有专门的排查实录。

第三步是“授课与考勤”。教师能看到自己名下的课程列表，进入某门课后进行学生点名，维护考勤状态。考勤状态通常有出勤、迟到、请假、缺勤四种，对应的字段可以直接用数字枚举存储。

第四步是“成绩管理”。课程结束后，教师录入或修改学生的各项成绩，系统按比例自动算出总评。这个比例配置在不同课程可能不一样，比如有的课程平时分占40%，期末占60%，有的可能各占50%。设计时要支持自定义比例，不要写死。

第五步是“评教”。学生可以对已修课程进行匿名评价，教师也能看到反馈汇总。评教模块很多课设版本会砍掉，但只要是完整度和答辩加分的角度，加上它会明显提升系统的完整感。

1.3 额外模块：课表、公告、统计报表

除了主链路，我强烈建议加上课表展示和公告管理这两个模块。课表展示可以用表格形式，按星期几和第几节渲染网格，前端用Vue的循环指令很轻松就能实现。公告管理更简单，就是一条数据的新增、编辑、展示，但它的存在能撑起首页的内容，让系统看起来不是空壳。

统计报表属于加分项，管理员后台可以展示选课人数分布、教师课程数量排行、课程容量利用率等。这类数据用SQL的GROUP BY加几个聚合函数就能查出来，再配一个图表库如ECharts，非常出效果。这些看似边缘的小模块，实际面试或答辩时反而是亮点。

2. 为什么SpringBoot+Vue能成为这类项目的标配：选型逻辑

很多同学拿到课程设计任务，第一个问题就是“用什么框架”。我接触过的项目里，SpringBoot+Vue组合几乎是一边倒的选择。这不是偶然，背后有几个很实际的原因。

2.1 前后端分离带来的开发效率提升

传统开发模式里，服务端渲染页面，前端做了页面还要塞到后端模板里，改个按钮样式都要重启服务。前后端分离之后，前端是一个独立项目，跑在Node环境，通过HTTP请求调用后端接口。界面调整不用动Java代码，后端接口改了前端只要改请求地址即可，互不干扰。

对于课程管理系统这种表单密集、列表密集的应用，前端用Vue的组件化开发优势很明显。一个课程卡片组件、一个选课列表组件、一个表格组件都能抽出来复用。再加上Vue Router做路由切换，整个过程无刷新，用户体验也比传统的整页刷新舒服得多。

2.2 SpringBoot让后端开发从繁琐配置中解放出来

在没有SpringBoot的年代，搭建一个SpringMVC项目要写一堆XML配置，配置数据源、配置事务管理、配置视图解析器，光是让Tomcat跑起来都要半天。SpringBoot用自动配置把大部分样板工作干掉，一个启动类加几个注解，项目就能跑起来。

另外SpringBoot生态太成熟了。集成MyBatis就引入一个starter，集成Redis也是加一个starter，集成邮件发送、文件上传这些功能都有现成的封装。对于课程管理系统这种增删改查为主的项目，SpringBoot可以大幅缩短开发时间。

2.3 社区资料量和学习曲线决定了上手速度

判断一个技术栈适不适合做课设和毕设，除了性能更要看“遇到问题能不能搜到答案”。SpringBoot+Vue在国内的社区活跃度极高，各种踩坑笔记、完整教程一搜一大把。不管是Maven依赖报错、端口被占用、跨域拦截、还是页面路径404，基本都能找到对应解决方案。

相比之下接一些比较小众的框架，比如后端用Golang的Gin或者前端用Svelte，虽然性能更好、写起来更爽，但遇到奇怪问题的时候，能搜到的参考案例会少一个数量级。对于学生项目，时间有限，求稳才是关键。

2.4 部署和演示的便利性

课设和毕设往往需要现场演示，部署在这个场景下是个很要命的环节。SpringBoot项目可以用Maven打成可执行JAR包，服务器上只要装了JDK，一条命令就能运行。前端项目构建后生成静态文件，同样放到服务器上让Nginx或者直接由后端映射到静态资源目录也能跑。整套部署思路简洁明确，不至于在演示前被环境问题搞到崩溃。

3. 从零到一的关键实操：数据库、后端接口、前端页面

这部分是整篇文章最有分量的环节，我会把课程管理系统从空项目到核心功能可用的过程拆解成几个阶段。每个阶段的代码思路和配置方式都会讲清楚，涉及具体代码的部分我会写出关键片段和解释，方便直接参考。

3.1 数据库设计与建表SQL

一个课设级别的课程管理系统，最少需要六张核心表：用户表、课程表、学生选课表、考勤表、成绩表、公告表。如果加评教，再补一张评教表和一张课程评价表。下面是我推荐的表结构和关键字段设计思路。

用户表重点在于区分角色，我习惯用一个role字段，0代表管理员，1代表教师，2代表学生。这样做的好处是查询某个角色的用户列表非常方便，角色模型简单直接，缺点是不太好扩展细粒度权限，但课设和毕设完全够了。

课程表的字段需要覆盖开课的基本信息。除了课程名、编号、学分、总学时，还需要外键关联授课教师的用户ID。上课时间和地点可以放在单独的课表字段里，比如schedule字段存JSON字符串，格式是[{"week":1-16,"day":1-5,"section":1-4,"location":"A101"}]，前端解析渲染即可。这种JSON方案比单独建一张时间表简单，查冲突时前端端都可以处理，灵活度很高。

选课表是学生和课程的多对多关系映射。主键可以用自增ID，再加学生ID、课程ID作为联合唯一索引，防止重复选课。同时需要加一个status字段，代表选课状态，比如0表示已选、1表示退课后被标记取消。

考勤表和成绩表都要以选课表ID作为外键，尽量不直接用学生ID加课程ID的组合去关联，否则会出现一名学生选了课程之后有补考或者重修，导致同一课程ID产生多组数据的情况。用选课表ID作为唯一指向，链路上更安全。

下面给出用户表和课程表的建表SQL示例。

CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `username` varchar(50) NOT NULL COMMENT '登录账号', `password` varchar(100) NOT NULL COMMENT '加密密码', `real_name` varchar(50) NOT NULL COMMENT '真实姓名', `role` tinyint(4) NOT NULL COMMENT '角色 0管理员 1教师 2学生', `college` varchar(100) DEFAULT NULL COMMENT '所属院系', `class_name` varchar(100) DEFAULT NULL COMMENT '所属班级', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `course` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `course_code` varchar(20) NOT NULL COMMENT '课程编号', `course_name` varchar(100) NOT NULL COMMENT '课程名称', `credit` decimal(4,1) NOT NULL COMMENT '学分', `hours` int(11) NOT NULL COMMENT '总学时', `teacher_id` bigint(20) NOT NULL COMMENT '授课教师ID', `capacity` int(11) NOT NULL DEFAULT 50 COMMENT '容量上限', `schedule` text COMMENT '上课时间地点JSON', `is_open` tinyint(1) DEFAULT 1 COMMENT '是否开放选课', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表';

如果你用的是MyBatis，建表之后可以直接用MyBatis Generator反向生成实体类、Mapper接口和XML文件，省去大量手写基础CRUD的精力。不过我还是建议至少手写一遍最关键的两张表的查询SQL，比如选课冲突校验和成绩汇总，这样才能真正理解数据关系。

3.2 后端SpringBoot核心代码怎么组织

SpringBoot项目建议按包结构划分清楚：controller、service、mapper（或者dao）、entity、config、common。controller负责接收请求和返回结果，service处理业务逻辑，mapper负责数据库交互。不要觉得分层麻烦，一旦业务复杂起来，不分层的话代码会滚雪球一样失控。

以选课接口为例，controller层代码非常薄，只做参数接收和结果返回：

@PostMapping("/selectCourse") public Result selectCourse(@RequestParam Long courseId, @RequestParam Long userId) { try { String message = selectCourseService.selectCourse(courseId, userId); return Result.success(message); } catch (BizException e) { return Result.error(e.getMessage()); } }

service层才是核心，选课的完整业务流程是：先查课程信息，判断是否开放选课；再查课程容量，统计当前已选人数；然后查该学生已有课程的上课时间，做冲突判断；最后插入选课记录。每一步判断失败都要抛出业务异常，由全局异常处理器捕获后返回给前端。

关于统一返回结果，我强烈建议定义一个Result<T>包装类，包含code、message、data三个字段。这样前端能统一处理异常，不要有的接口直接返回对象，有的返回字符串，翻天后端的时候各处都要写类型判断。

另外，日期时间字段在前后端交互中容易踩坑。Java后端返回LocalDateTime默认格式是带T的ISO格式，前端直接展示非常难看。建议在全局配置里统一设置Jackson的日期格式，或者在后端直接把日期转换成时间戳字符串，再在前端格式化展示。

3.3 前端Vue项目结构和页面联动

Vue项目我建议用Vue CLI或者Vite创建，前者稳定、资料多，后者构建更快，但插件生态有些细节不一样，需要额外适配。课程管理系统这种规模，用Vue CLI完全够。

前端代码的组织方式看一下。router/index.js里配置路由和权限守卫，如果当前用户没有登录就跳转到登录页；store里放用户信息和登录状态；api目录里按照模块拆分请求函数，比如user.js、course.js、score.js。

页面联动一个经典的流程：学生登录进入系统首页，看到公告列表和自己已选的课程卡；点击“选课中心”，通过接口拉取所有开放选课的课程列表，每行有选课按钮；点击选课按钮，前端先把用户ID和课程ID发到后端，后端做完校验返回成功或错误信息，弹窗展示结果。

这里有一个关键点：数据刷新要处理好。选课成功后课程列表里的剩余容量要立即变化，最稳妥的做法是选课成功后重新拉取一次课程列表，虽然多一个请求但不会有状态同步误差。有些同学为了炫技去做前端状态缓存管理，反而容易在复杂交互下漏更新。

3.4 跨域和认证配置

前后端分离开发的经典问题就是跨域。前端跑在8080端口（开发服务器），后端跑在8081，前端发请求会被浏览器拦截。解决方案有几种，开发环境最简单的是在SpringBoot里加个CORS配置类，允许localhost:8080访问。

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:8080"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

登录认证我用的是JWT方案。用户登录成功后后端生成Token返回给前端，前端每次请求在Header里带上Authorization: Bearer <token>，后端通过拦截器解析Token，取出用户ID和角色信息存到ThreadLocal里供后续业务使用。

拦截器要注意放行登录接口和静态资源路径，不然验证码都加载不出来，这种低级错误很常见。配置拦截器拦截所有/api/**的请求，同时排除/api/user/login和/api/captcha等公开接口。

4. 部署发布、调试排错与基础修改实战手册

很多同学代码写完了能跑，但把项目交付出去、或者改一两个需求的时候就开始手忙脚乱。这一章节我的目的就是把部署和调试这条线讲顺，让项目不仅能在IDE里运行，还能用命令行跑起来，同时把大家常碰到的报错原因和解法集中整理一下。

4.1 本地运行这套系统的完整步骤

假设拿到一份课程管理系统的源码，怎么让它在本地跑起来？我总结了一套可以当作标准流程的操作路径。

后端先做三件事：修改application.yml或application.properties里的数据库连接信息，改成自己本地MySQL的用户名密码；创建一个名为course_manage的数据库，执行项目里附带的SQL脚本初始化表结构和预设数据；在IDEA里打开项目，等Maven把所有依赖下载完成，然后启动类直接运行，默认端口是8081，看到“Started Application”日志就说明后端启动成功。

前端也分三步：命令行进入前端项目目录，执行npm install安装依赖；如果缺少某些依赖导致报错，一般是因为网络原因没有拉全，可以再执行一次npm install；安装成功后在项目目录执行npm run dev启动开发服务器，默认端口是8080。打开浏览器访问http://localhost:8080，能看到登录页就说明前后端已经联通。

到这里如果登录页能打开但登录请求报错，先确认后端是否启动、数据库用户名密码是否没错、跨域配置是否生效、前端请求地址是否指向8081。这四个点按顺序排查，80%的问题都能解决。

4.2 常见报错速查表与解决思路

我在带项目过程中遇到过大量重复的高频报错，这里整理成一张表，方便大家迅速定位。

这张表里最常被忽略的是URL字符集参数。很多人本地MySQL创建表用的UTF-8，但连接URL没指定字符集，存进去的中文变成问号，各种排查都找不到原因。后来发现就是少了字符集参数，一加上立刻恢复。

4.3 基础修改的方法论

交付源码的时候客户或导师经常会提一些基础修改需求，比如“把系统名称改一下”、“加一个字段”、“改一下表格显示的列”。这些改动看似零星，但如果没有方法支撑，容易把好好的项目改出一堆bug。

改系统名称：前端项目里一般有一个配置文件，如config/index.js或者public/index.html，里面会有title字段，修改中包含系统名。如果是页面头部导航栏系统的显示，去对应布局组件里修改绑定文本即可。

加一个字段：以给学生表加一个“学号”字段为例。数据库表加一列student_no；后端实体类加一个字段studentNo；Mapper的查询SQL如果写了明确的返回列，要补上这个字段，建议用SELECT *的场景就不容易漏；前端对应页面的表单和表格都要加上这个字段的绑定。检查要不要在新增或编辑时传递，不要漏掉。

改表格显示的列：找到前端对应列表页面的代码，表格组件如el-table里的一列，删除或者改属性即可。这里要注意如果后端返回数据里没有这个字段，再怎么改前端都显示不出来，所以先确认后端接口返回的数据结构，再动前端列配置。

4.4 打包部署上线路径

课设项目和真实交付项目到最后都需要部署。后端项目在IDEA的Maven面板里选择package，如果不想打测试跳过测试可以在命令里加-DskipTests。打包完成后，target目录下会生成一个可执行的JAR包，使用命令nohup java -jar course-manage.jar > log.log 2>&1 &在服务器上后台运行。

前端项目执行npm run build，构建成功后生成dist目录。里面是纯静态文件，可以交给Nginx托管，也可以直接扔到后端项目的static目录下让SpringBoot托管。如果是后者，需要在SpringBoot里配置静态资源映射，或者在application.yml里设置spring.web.resources.static-locations指向前端文件目录。

部署时最容易踩坑的是MySQL版本差异和Linux环境下权限问题。如果是高版本的MySQL，连接驱动要把com.mysql.jdbc.Driver改成com.mysql.cj.jdbc.Driver；Linux服务器上执行JAR包之前需要确认有java环境且版本匹配。

5. 典型业务场景与异常情况处理实录

写了这么多基础内容，最后讲讲几个实际业务场景里容易被忽略但高频出现的异常情况。这些例子都来自实操过程中的真实场景，我调整了具体信息，但问题现象和处理思路是完全可复用的。

5.1 选课冲突的第一个坑：时间字段设计不合理

有个版本的课程表时间字段是单一的星期几加第几节，比如“周一第一大节”。学生选了两门课都是“周一第一大节”，冲突判断很容易查询出来。但如果一门课的老师因为教务调整把上课时间改了，课程表只有一个字段，历史选课数据就会集体得到错误的时间信息，改起来非常痛苦。

后来我把时间字段改成JSON结构，存一个学期内每周的上课时间和地点，改某一次课时单独更新即可。这个设计调整让冲突判断的查询写起来稍微复杂一点，但换来了灵活性和数据一致性，我认为是值得的。实际上不少教务系统也有类似改时间的场景，单一字段方案完全撑不住。

5.2 选课容量竞态问题

多个学生同时抢最后几个选课名额，是真实场景下非常容易出现的问题。如果后端逻辑是“查出已选人数，如果小于容量就insert”，两个并发请求可能同时通过校验，导致选课人数超过容量上限。

解决思路在数据库层面做限制：给选课表加一个唯一索引，约束学生ID和课程ID不能重复，从源头上避免同一学生重复选课。至于容量超卖，可以在插入前用带条件的更新语句去扣减课程表的剩余名额，update course set selected_count = selected_count + 1 where id = ? and selected_count < capacity，影响行数为1才说明抢课成功。这套方案比单纯依赖应用层判断稳定得多。

5.3 权限绕过隐患

有的开发者会在前端通过按钮或菜单隐藏来控制访问，比如学生看不到教师录入成绩的入口，就认为安全了。但接口本身没有校验，学生直接拿着接口地址发请求照样能访问教师接口，这是很严重的安全漏洞。

我在排错时遇到过一个真实项目：学生端调成绩录入接口，把参数改成自选课程ID，竟然能修改自己的成绩。原因就是controller层只用@RequestParam接收课程ID和学生ID，没有校验当前登录用户是否为该课程的任课教师。后来我在service层加了身份校验：从Token中解析出当前用户，判断当前用户的角色和与课程的关联，不匹配就直接抛业务异常。这个教训让我在此后的项目中都非常重视后端权限校验，前端隐藏只是体验问题，后端校验才是安全底线。

5.4 数据统计错误：SQL分组不当

统计报表里最容易出的问题就是不明确维度。曾经的报表里统计“教师课程数量排行”，SQL写成了把所有课程按教师ID分组，看起来没问题，但结果总是出错。排查下来发现是因为有些教师角色的人已经调离，但还有历史课程挂在名下，导致统计结果把离职教师也排进活跃教师里。

修正方案是分组前先关联用户表过滤当前有效教师，或者统计时增加一个课程状态的条件。这类问题做报表时几乎必现，只要你的数据不是完全干净的测试数据，过滤条件始终不能省。

6. 代码走读与二次开发扩展指南

最后一部分写给打算做二次开发或者想深入理解代码结构的人。代码走读这件事，很多人觉得枯燥，但读懂一份项目的代码结构，远比自己重新写一遍节省时间。

6.1 后端核心代码从哪读起

我建议从entity目录开始，先搞明白每一张表对应哪些实体类，字段类型和数据库的对应关系是什么。然后看mapper包里的SQL，了解关键查询语句。再往上走，看service层的业务方法，理解每个方法做了哪些流程判断。最后才是看controller层，理解暴露了哪些接口、接收什么参数、返回什么结构。

一个值得深读的部分是全局异常处理器。成熟的实践会在common包里定义一个@RestControllerAdvice的异常处理类，集中处理业务异常（如选课冲突、课程不存在）和系统异常（如空指针、数据库连接失败）。这样controller和service里不需要堆try-catch，代码清爽很多。

6.2 前端核心代码走读路线

前端的代码走读路线要从入口文件开始，比如main.js（或main.ts）。看它引入了哪些组件库、哪些全局插件、是否挂载了路由和状态管理。然后进入router目录，看路由层级和权限守卫。了解了能进哪些页面之后，再去读各个页面文件，从页面里看到请求调用的API，再从API文件对照后端的接口。

建议特别阅读utils/request.js或api/http.js这类请求封装文件，看一下它如何处理Token注入、如何处理错误码、如何统一弹错误提示。明白了这些才能搞清楚为什么某个请求报错时会跳转到登录页，或者为什么会弹出后端返回的错误信息。

6.3 二次开发的方向与建议

如果你想在这个项目里加入新功能，我的优先级建议是：先做公告管理和数据统计，这两个组件相对独立，不涉及主链路的复杂修改；再做消息通知，用于提醒教师提交成绩、提醒学生选课开启，这块需要引入WebSocket或者轮询，也比较适合展示技术深度；最后再尝试对接第三方登录，比如高校统一身份认证，这需要改动登录流程和Token签发逻辑，风险最高。

以加入“课程公告”功能为例，后端只需要新增一张表，做一个简单的CRUD接口；前端新增一个公告列表页，复用已有的列表组件和弹窗组件，半天时间就能完成。这类小而完整的功能点是练习二次开发的最佳起点。

7. 写在最后：一些实操经验总结

做这类管理系统，最怕的不是技术难点，而是需求边界不清晰就动手。很多同学把大量时间花在调CSS样式和优化交互动画上，结果核心的选课冲突逻辑没写完整，答辩的时候被一问就卡壳。技术应该服务业务，先把业务链路跑通，再美化外在表现。

调试方面最大的心得就是学会看日志。后端日志中出现的异常堆栈第一行就是问题的直接原因，不要每次都重新看一遍整个栈，找到“Caused by”那一行，往下几行往往就能定位到具体代码行。前端控制台的Network面板能告诉你请求是否发出、响应状态码是多少、返回体是什么。90%的前后端联调问题靠这两个工具就能解决，不需要瞎猜。

如果未来有计划继续做这个方向，可以考虑把它从一个单体SpringBoot项目逐步升级。比如引入Redis做缓存、MyBatis-Plus简化数据操作、Spring Security替换自定义拦截器。这些升级路径都是现成的，一步一步来，系统会越来越健壮。最后送大家一句话：课程管理系统这样的CRUD项目，做出来只是第一步，真正拉开差距的是边界情况处理和工程质量意识。希望这篇文章的内容能让你少踩几个坑。