1. 项目解读与整体功能设计
1.1 这个毕设项目到底解决什么问题
学生网上选课系统，在高校里属于最典型的信息管理系统场景。你去观察一下，不限选课、排课、成绩管理、图书馆占座，凡是涉及“学生—课程—教师—成绩”这四类角色互相打交道的业务，几乎都能用同一套骨架来做。这个项目之所以在毕业设计里长盛不衰，不是因为简单，而是因为它把信息管理系统的核心闭环全部覆盖了：身份认证、权限控制、核心业务流转、数据统计展示，一个不少。
我接触过的不少同学一上来就盯着“选课”两个字看，觉得核心功能就是把课程列表展示出来，学生点一下“选课”按钮就完事了。实际上要做到能过审、能答辩、能拿得出手，你需要处理的是几条核心业务线的交叉：
- 学生端：登录、查看课程、选课、退课、查看已选课程、查成绩、个人信息维护。
- 教师端：登录、查看自己授课列表、录入成绩、维护个人开课信息。
- 管理员端：学生管理、教师管理、课程管理、选课规则配置、排课信息审核、成绩总览、数据统计。
这还只是功能列表。真正让系统有“设计感”的，是三套权限之间如何共用一套登录认证，以及选课这种“多对多”业务在高并发场景下如何避免重复选课、超选等问题。很多同学在开题报告里写“本系统采用SpringBoot+Vue实现前后端分离”，但做出来的东西只是把页面和数据简单拼在一起，答辩时老师一问“你的权限是怎么控制的”“选课并发怎么处理”，就答不上来了。
这篇文章基于一个已完整落地的SpringBoot+Vue学生选课系统来拆解。整个项目包含完整的源码、开题/毕业论文文档，功能上覆盖了管理员、教师、学生三类角色，权限隔离清晰，核心业务逻辑完整，可以直接作为毕业设计主体项目来用，也可以在此基础上做二次开发扩展。
1.2 功能模块划分与边界控制
系统的功能结构，我从实际落地角度给你梳理成一张逻辑图，你在写论文的时候也可以按这个结构去画架构图和技术路线图：
学生端 ├── 登录/注销 ├── 选课中心（查看可选课程、按条件筛选） ├── 我的课表（已选课程、退课操作） ├── 成绩查询（按学期查看/导出） └── 个人信息维护 教师端 ├── 登录/注销 ├── 我的授课列表 ├── 成绩录入与修改（按课程、按学生） └── 个人信息维护 管理员端 ├── 登录/注销 ├── 学生账号管理 ├── 教师账号管理 ├── 课程信息管理（开课、排课、状态控制） ├── 选课规则配置（选课时间窗口、人数上限） └── 数据统计看板（选课人数、成绩分布等）模块划分的核心思路是“角色驱动”。你别小看这个划分，很多同学做炸都是因为在这里偷懒：把学生、教师、管理员全塞到一张user表里，用一个role字段去区分，然后前端根据role去显示不同菜单。听起来没什么问题，但做到后面你会发现权限校验散落在各个接口里，改一处漏三处，答辩时极易翻车。
这个项目的做法是：一张user表统一存账号密码和角色标识，但角色权限控制通过Spring Security + JWT在拦截器层面统一处理，而不是在每个Controller里写一遍判断逻辑。说白了就是让框架帮你干权限的事，你只负责在接口上声明“这个接口需要什么角色”，框架自动拦截不匹配的请求。
2. 技术选型与架构设计思路
2.1 为什么选SpringBoot+Vue这对黄金组合
说句实话，在Java后端生态里，SpringBoot早就不是“推荐选型”而是“默认选型”了。它是Spring Framework的封装升级版，把原来繁琐的XML配置、Bean装配、依赖管理全部简化成“约定大于配置”，你只需要通过注解和application.yml就能把项目跑起来，不用再像SSH/SSM时代那样写一堆配置文件。
SpringBoot的核心优势体现在这几个地方：
- 内嵌Tomcat，不需要单独部署WAR包，一个
java -jar就能启动。 - 自动配置机制，引入什么依赖就对什么组件做自动化配置，省去大量样板代码。
- 生态成熟，Spring Security、MyBatis-Plus、Redis这些在选课系统里用得上的组件都有官方或社区稳定的整合方案。
Vue作为前端框架，核心卖点是响应式数据绑定和组件化开发。你不必再像写jQuery那样手动操作DOM，页面上的数据变化会自动映射到视图，开发效率高一个量级。而且Vue的单文件组件结构（template、script、style三合一）非常利于代码组织和后期维护，做毕设答辩演示时也好看。
这个项目在前端用的是Vue2 + Element UI。我知道现在Vue3已经非常成熟了，但毕设场景下Vue2的生态更稳定，遇到问题搜答案也更容易，而且Element UI的组件风格非常适合信息管理类系统的后台界面，表格、表单、弹窗、日期选择器这些高频组件开箱即用。
2.2 前后端分离架构与数据交互约定
前后端分离是这个项目的架构基石，也是你论文里值得重点描述的“技术亮点”。理解了这个架构，你就理解了为什么前端叫Vue工程、后端叫SpringBoot工程、两者之间靠HTTP接口通信。
整个请求链路是这样的：
浏览器输入地址 → Vue前端路由接管 → 用户操作触发API调用 → Axios发送HTTP请求(带JWT令牌) → SpringBoot后端Controller接收请求 → Service层处理业务逻辑 → Mapper层操作MySQL数据库 → 数据逐层返回 → Vue组件渲染视图在具体实现上，有几个关键约定值得你关注：
统一响应体结构。后端所有接口都返回固定的JSON格式，包含
code、message、data三个字段。前端拿到响应后，先看code是否为200，成功才解析data。这套约定避免了对各种异常情况的杂乱处理。JWT令牌传递。用户登录成功后，后端签发一个有效期内的JWT令牌，前端存在localStorage里，每次请求在拦截器中自动放入请求头。这样一个无状态认证机制就完成了负载均衡友好的身份认证。
跨域处理。前后端分离开发时，前端跑在8080端口，后端跑在8081端口，浏览器会拦截跨域请求，因此后端需要配置CORS。这个项目里通过一个WebMvcConfigurer的配置类完成跨域放行。
2.3 数据库设计：把选课的业务本质想清楚
每张表的业务含义，是答辩时老师爱问的地方。我按表逐个给你拆解：
user表
这是登录认证的基础，存了账号密码、用户类型、昵称等。密码必须加密存储，项目里用了BCrypt加密。这里我特别提醒一下，很多毕设项目直接明文存密码，答辩时一旦被问到安全性就会很尴尬。
student表 / teacher表
为什么有了user表还要单独的student表和teacher表？因为user表只负责“登录这件事”，而学生的学号、专业、年级，教师的职称、所属院系，这些是业务档案信息，不该混在认证表里。两张表通过user_id字段和user表关联，这样做后续扩展（比如添加学生班级字段）就不用动user表结构。
course表
课程基础信息表，包含课程名称、课程编号、学分、学时、授课教师、上课时间、上课地点、选课人数上限等。注意授课教师这个信息，这里设计的是一对一关系（一门课一个老师），如果做多教师授课的扩展，就需要单独建联系表。
选课关系表（核心中的核心）
这就是那对“多对多”关系的中间表，通常叫student_course或select_course，字段包含：主键id、学生id、课程id、选课时间、成绩。这张表独特的业务价值在于，它不光是记录“谁选了哪门课”，还要承担成绩管理的数据来源——成绩字段直接挂在选课记录上，而不是单独建一张成绩表。
major表（可选）
如果你想把学生专业、学院做成联动筛选，就需要一张专业表。这个不是必须的，但加上之后，管理员维护课程时可以选择“面向专业”，选课列表里学生也更容易筛到自己专业相关的课。
3. 后端核心功能与关键代码实现
3.1 基于JWT的登录认证与权限控制
登录是每个系统的门面，也是整套安全机制的第一步。这个项目的登录认证链路是：前端把用户名和密码发给/api/auth/login，后端校验通过后，用JWT工具类生成一个携带用户id和角色信息的token返回给前端。
JWT的结构你可以理解成一个三段式的字符串：头部、载荷、签名。头部声明了算法类型，载荷里存用户信息，签名是用密钥对前两段做的哈希校验，防止内容被篡改。前端后续请求时带上这个token，后端用一个过滤器去解析，解析成功就把用户信息放到Spring的上下文中，接口通过注解去校验角色。
核心的JWT工具类是这样组织的：
public class JwtUtils { // 生成token，claims里放userId和role public static String generateToken(Integer userId, String role) { return Jwts.builder() .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } // 解析token，取出Claims public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); } }很多同学担心JWT写起来复杂，其实核心逻辑就这两个方法：生成和解析。剩下的就是在一个拦截器里把解析出来的用户信息传递到业务层。SpringBoot里有HandlerInterceptor机制，你可以实现一个JwtInterceptor，在preHandle方法里取请求头、校验token、放行或返回401。
3.2 选课接口的防重复与防超选设计
选课是整个系统业务逻辑的“心脏”，也是你答辩时最值得展开讲的地方。选课操作本质上就是往student_course表里插一条记录，但这件事有几个隐藏的坑：学生重复提交选课请求怎么办？课程选满之后超员了怎么办？多人同时抢同一门课的最后几个名额，数据库层面怎么保证数据一致性？
这个项目的做法是在Service层加了严密的判断链：
@Transactional public Result selectCourse(Integer studentId, Integer courseId) { // 1. 校验课程是否存在且已开放选课 Course course = courseMapper.selectById(courseId); if (course == null || course.getStatus() != 1) { return Result.error("课程不存在或未开放选课"); } // 2. 校验学生是否已选过这门课（防止重复选课） Integer count = selectCourseMapper.countByStudentAndCourse(studentId, courseId); if (count > 0) { return Result.error("你已选择过该课程"); } // 3. 校验选课人数是否已达上限（防止超选） Integer selectedCount = selectCourseMapper.countSelectedByCourse(courseId); if (selectedCount >= course.getMaxCapacity()) { return Result.error("该课程选课人数已满"); } // 4. 插入选课记录 SelectCourse selectCourse = new SelectCourse(); selectCourse.setStudentId(studentId); selectCourse.setCourseId(courseId); selectCourse.setSelectTime(new Date()); selectCourseMapper.insert(selectCourse); // 5. 更新课程已选人数 courseMapper.incrementSelectedCount(courseId); return Result.success("选课成功"); }这个逻辑看起来清晰，但要注意一个隐蔽问题：在高并发情况下，第三步的校验和第四步的插入不是原子操作，可能出现两个请求同时通过校验然后都插入成功的情况，导致超选。真正在生产环境要彻底解决，需要数据库层面加锁或使用唯一约束兜底。
对这个毕设项目，可以在student_course表的学生id和课程id上加联合唯一索引，这样即使并发情况下逻辑层漏了一个，数据库也会因为唯一约束把重复记录挡在外面。这是我想强烈建议你加上的优化点，代码改动不大，但答辩时老师听到你能说出“联合唯一索引兜底防重”这个方案，就知道你是真做过功课的。
3.3 成绩录入与修改的权限校验逻辑
成绩管理是教师端的核心功能。教师在界面上选中自己授课的一门课程，系统展示该课程的所有选课学生列表，教师在成绩输入框中录入分数，保存后写入student_course表的score字段。
这个功能从代码角度看就是简单的update操作，但有两层权限校验必须做好：
第一层，这个教师只能操作自己教的课。所以在查询授课列表时，SQL的where条件必须带上teacher_id，而不是返回所有课程让前端去过滤。第二层，录入成绩前要校验当前登录用户的角色是教师，并且课程确实属于该教师——这一层可以在Service层通过比对teacherId实现。
我见到不少项目在处理成绩管理时把两层校验做漏了一层，导致理论上一个教师可以绕过前端直接调接口改别人的课的成绩。虽然毕设系统不会真被攻击，但论文里写到“系统具有完善的权限控制”时，你心里得有底。
3.4 MyBatis-Plus是简化开发的利器
这个项目的持久层用了MyBatis-Plus，它和MyBatis的区别用一句话总结就是：MyBatis-Plus是MyBatis的增强版，内置了通用的Mapper CRUD方法，单表操作基本不用手写SQL。
举几个实际用得上的能力：
- BaseMapper提供了
selectById、insert、updateById、deleteById等基础方法，单表增删改查全搞定。 - 条件构造器
QueryWrapper/LambdaQueryWrapper，可以用链式调用的方式写查询条件。 - 分页插件
PaginationInnerInterceptor，一行配置就支持分页查询。
选课列表的查询，用LambdaQueryWrapper写起来非常直观：
LambdaQueryWrapper<Course> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Course::getStatus, 1) .like(StringUtils.hasText(keyword), Course::getName, keyword) .orderByDesc(Course::getCreateTime);like方法的第一个参数是个boolean值，当条件为true时才把这个条件拼进SQL，这样写的好处是模糊搜索时不用手动拼接字符串，代码干净很多，也不容易产生SQL注入风险。
4. 前端核心实现与关键交互
4.1 Vue工程搭建和请求封装
前端工程基于vue-cli创建，配合Vue Router做页面路由，配合Axios做HTTP请求。项目内的核心目录结构和作用如下：
src/ ├── api/ // 所有后端接口的封装 │ ├── student.js // 学生端接口 │ ├── teacher.js // 教师端接口 │ └── admin.js // 管理员接口 ├── router/ // 路由配置（含守卫） ├── store/ // Vuex状态管理 ├── views/ // 页面组件（按角色分目录存放） ├── components/ // 公共组件 └── utils/ └── request.js // Axios实例封装Axios封装的痛点在于请求拦截和响应拦截的统一处理。这个项目的request.js里做了几件关键的事：请求拦截器里从localStorage取出token并塞进请求头；响应拦截器里统一判断HTTP状态码，遇到401表示token过期或未登录，直接跳转登录页；业务状态码非200时，ElMessage直接弹出后端返回的错误提示。
路由守卫是前端权限控制的关键。Vue Router提供beforeEach全局前置守卫，在每次路由跳转前检查当前用户是否登录、该路由是否需要特定角色。比如/admin开头的路由需要管理员角色，学生登录后手动改URL进入管理后台，守卫就会拦截下来。
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.path === '/login') { next(); // 登录页直接放行 return; } if (!token) { next('/login'); // 未登录跳转登录页 return; } const role = localStorage.getItem('role'); if (to.meta.roles && !to.meta.roles.includes(role)) { next('/403'); // 有登录但角色不匹配，跳转无权限页 return; } next(); });这里的代码逻辑不难，关键是有这个意识和这个实现。前端权限能挡住“操作路径”上的越权，后端权限能挡住“直接调接口”的越权，两者配合才叫完整的权限控制方案。
4.2 选课中心的动态筛选与状态展示
选课中心页面是这个系统里交互最复杂的前端模块。它需要展示所有可选课程，并且每张课程卡片要体现几种状态：可选、已选、已满、未开放。几个状态对应的按钮和操作完全不同，这就非常考验前端的数据处理能力。
我的实现思路是这样：后端课程列表接口返回时，顺便把当前登录学生的选课情况关联进来。也就是说，每门课的数据对象里带一个selected布尔字段，前端根据这个字段决定按钮的展示状态：
selected == false且selectedCount < maxCapacity：显示“选课”按钮。selected == true：显示“已选”标签，并提供“退课”按钮。selectedCount >= maxCapacity：显示“已满”标签，按钮置灰。
这样一个简单的字段约定，把复杂的业务状态判断抽离到了后端，前端只做展示和事件触发，避免了前端同学在后端返回一堆原始数据后自己拼状态的尴尬。
筛选功能也要注意的是，尽量用后端查询而不是前端过滤。课程名称、开课学院、课程类型这些筛选条件，应该作为查询参数传递给后端，由MyBatis-Plus动态拼接SQL。系统课程数量少时前端过滤没感觉，但课程数量到几百门之后，一次性返回全部数据再在前端filter，性能和体验都会下降。
4.3 教师成绩录入的表格交互
成绩录入页面用的是Element UI的Table组件加Input输入框。默认的Table是一个纯展示组件，要让它支持编辑，标准做法是用Table的自定义列模板：
<el-table :data="scoreList"> <el-table-column prop="studentName" label="学生姓名" width="120" /> <el-table-column prop="studentNo" label="学号" width="140" /> <el-table-column label="成绩" width="150"> <template slot-scope="scope"> <el-input v-model="scope.row.score" placeholder="请输入成绩" type="number" min="0" max="100" /> </template> </el-table-column> <el-table-column label="操作" width="120"> <template slot-scope="scope"> <el-button type="primary" size="small" @click="saveScore(scope.row)"> 保存 </el-button> </template> </el-table-column> </el-table>这里我想提一个实际开发中比较容易忽略的点：评分标准校验。成绩不能直接输入任何数字就保存，必须在前端加取值范围校验（0~100），在后端Service层也要再做一次。为什么前端校验了还不够？因为前端校验只防君子不防小人，绕过前端直接调接口是可以提交非法数据的。后端Service层的校验才是最终防线，在保存成绩的方法里加个判断，不满足条件就抛异常。
教师保存成绩时用了逐行保存而不是整表提交，好处是改一条保存一条，避免一次性提交大量数据时网络波动导致整表单丢失。用户体验上一个不明显的点，但在实际使用中能省不少事。
5. 系统部署运行与完整源码使用指南
5.1 环境准备与版本匹配
我反复强调过一件事：做Java毕设，环境版本是你过的第一道坎。很多同学项目代码没问题，结果卡在JDK版本不匹配、Maven依赖拉不下来、Node版本太新导致node-sass编译失败的坑里，白白浪费一两天时间。
这个项目建议的版本组合是：
- JDK 1.8（互联网上绝大多数毕设项目都基于JDK8编写，不要上来就装JDK17/21，高版本会产生未知兼容问题）
- Maven 3.6及以上
- MySQL 5.7或8.0
- Node.js 14~16（对应npm 6~8，Vue2的老项目依赖对这些版本兼容性最好）
- 前端包管理器用npm或yarn均可
如果你的电脑上装了更高版本的JDK，建议不用卸载，通过IDEA的Project Structure单独给项目指定JDK8即可。Maven仓库建议配置阿里云镜像，否则第一次拉依赖可能会等得让人怀疑人生。
5.2 从零到一启动项目的完整步骤
拿到源码后，按下面的顺序操作可以避免大部分踩坑：
第一步，导入数据库。用Navicat或者命令行执行项目里提供的init.sql脚本，它会创建数据库、建表、插入初始化数据（默认管理员、教师、学生账号都在里面）。执行完先看表是否都生成了，数据行数是否符合预期。
第二步，配置后端。用IDEA打开backend目录，等待Maven完成依赖下载。然后修改application.yml里的数据库连接配置，重点是URL、用户名、密码三项。如果你的MySQL是8.0，驱动配置要注意是否需要添加时区参数serverTimezone=Asia/Shanghai。
第三步，启动后端。运行DemoApplication的主类，看到SpringBoot的启动日志输出启动成功，并且没有报数据库连接错误，说明后端这半已经起来了。可以在浏览器里直接访问某个Controller的测试接口，确认数据能正常返回。
第四步，配置前端。在命令行进入frontend目录，执行npm install安装依赖。这一步如果慢得离谱，检查是否配置了国内npm镜像：
npm config set registry https://registry.npmmirror.com第五步，启动前端。执行npm run serve，看到Compiled successfully后，浏览器访问http://localhost:8080，用初始化数据里的管理员账号登录，系统就能正常使用了。
这里我要提醒一个常见的坑：前端的API请求地址是写死的还是可配置的？很多项目在request.js或.env.development里配置了代理或baseURL，如果你修改了后端端口，前端对应的配置也必须同步修改。不然就会出现前端页面打开了，但所有表格数据都是空的、接口全都报403或404的情况。
5.3 源码目录结构导览与二次开发建议
清晰理解源码结构，是你做二次开发和写论文“系统实现”章节的基础。这个项目的后端目录结构如下：
src/main/java/com/example/selection/ ├── config/ // 配置类（跨域、Security、MyBatis-Plus分页） ├── controller/ // 接口层（接收请求、返回结果） ├── service/ // 业务逻辑层（核心业务处理） │ └── impl/ // 业务实现类 ├── mapper/ // 数据访问层接口 ├── entity/ // 实体类（对应数据库表） ├── common/ // 通用类（统一返回结果、异常处理、JWT工具类等） └── SelectionApplication.java // 启动类这个分层的设计逻辑是：Controller只做参数接收和结果返回，不写业务代码；业务逻辑写在Service里；数据操作通过Mapper接口完成。分层的好处是职责单一、便于维护、也符合答辩时“系统设计合理”的评分点。
如果你打算在这个项目基础上做个性化扩展，我建议优先考虑这几个方向：增加公告发布功能、增加学生选课时间窗口限制、增加数据可视化图表展示、增加课程评价功能。每个方向都在现有代码结构上动局部改动，不会伤筋动骨，但能让你在答辩时说出“我对原系统做了哪些改进”，这比照搬一个完整项目更让老师认可。
6. 常见问题与避坑经验实录
6.1 环境与依赖层面的高频问题
问题1：Maven依赖下载慢或下载失败
这种问题基本是网络原因。解决办法是在Maven的settings.xml里配置阿里云镜像，或者直接在项目的pom.xml里加阿里云镜像仓库。加了之后依赖下载速度会提升几个量级。
问题2：启动后端时报数据库连接失败
先确认MySQL服务是否已启动，再检查application.yml里用户名密码是否匹配，最后确认数据库是否已导入。注意MySQL 8.0以上版本的驱动需要配置时区参数，否则可能会报时区错误。
问题3：前端npm install后启动报错
最典型的是node-sass安装失败，报错信息里会出现Python或binding相关的字样。解决方案有两种：一种是降低Node版本到14或16；另一种是执行npm rebuild node-sass重新编译。如果你用的是现在最新的Node 20以上版本，建议直接换成环境要求的低版本，别在这上面硬耗。
6.2 业务与代码层面容易出现的问题
问题1：修改密码后旧token仍有效
JWT的无状态特性决定了服务端无法主动让某个token失效，所以“改密后强制下线”这个需求实现起来比较麻烦。一种简化做法是在生成token时把当前密码的hash值作为载荷的一部分，改密后用旧token解析出的hash和当前密码hash比对，不一致就拒绝请求。
问题2：退课后课程名额不释放
退课功能做了一半：从选课记录里删除了数据，但course表的selected_count没有同步减1，导致退课后再选选不上。这个问题听起来低级，实际里我见到不少项目翻车在这里。解决方式就是在退课的Service方法上加事务，删除记录和更新count放在同一个事务里。
问题3：Element UI表格数据更新后视图不刷新
Vue2的响应式系统有个经典的坑：直接通过索引修改数组元素this.list[0].name = 'xxx'，视图不会更新。解决办法是用this.$set(this.list, 0, newData)或者对数组整体重新赋值。这个坑在表格编辑场景出现得特别频繁，记住了能少走很多弯路。
7. 论文撰写配合与答辩准备建议
毕设项目不只是把代码跑起来，论文和答辩材料的质量直接决定了最终分数。许多同学在系统开发上花了很多时间，论文却被老师说“像是流水账”，核心问题是没把自己做的东西、做的决策、踩过的坑转化成有价值的内容。
我在准备这个项目的论文时，逻辑主线是这样的：先描述研究背景和意义，再梳理国内外研究现状，接着做需求分析（功能性需求和非功能性需求），然后是系统设计（架构设计、功能设计、数据库设计），再是系统实现（按模块截图加关键代码讲解），最后是系统测试（功能测试用例加测试结果分析）。
数据库设计章节不要只贴建表语句，要把关键的字段含义、表之间的关系讲清楚，尤其是学生、课程、选课记录这三张表的关系图，这是老师比较关注的部分。系统实现章节的每个模块截图建议配上关键代码片段，代码不用全贴，选最有代表性的部分讲解逻辑即可。
答辩时老师问得最多的几个问题，我提前给你打好腹稿：
- 为什么选SpringBoot而不是SSH？答：SpringBoot简化了配置，内嵌服务器，生态成熟，开发效率高。
- 权限控制是如何实现的？答：后端用了Spring Security加JWT，前端用了路由守卫，双重校验。
- 选课并发问题怎么处理？答：逻辑层校验加数据库唯一约束兜底，必要时可加对课程记录的悲观锁或乐观锁。
- 成绩和选课的关系为什么放在同一张表？答：选课记录天然是学生和课程的多对多关系，把成绩作为选课记录的属性，查询效率高且逻辑清晰。
这些问题在答辩前自己过一遍，脑子里有清晰的思路，现场就不会卡壳。说老实话，毕设答辩核心考察的不是你的代码写得有多优雅，而是你对自己做的东西理解有多深。
这套系统我在实际调试过程中前前后后跑了不下几十遍，从环境配置到功能联调，踩过的问题基本都梳理在文章里了。如果你想在现有基础上加功能、换主题、深化某个模块，最稳妥的方式就是先把当前这套完整的选课流程跑通吃透，再去动手改代码——骨架对了，往上添肉只是时间问题。
