企业官网建设流程全解析

每年到毕业季，我总能看到不少学弟学妹在论坛里问“教务管理系统怎么做”“SpringBoot和Vue怎么组合”，说实话，这类题目确实经典——它不是纯业务管理系统那种CRUD花架子，也不像电商秒杀那样上来就搞分布式高并发，对本科生来说难度刚刚好，用来做毕业设计既能展示技术栈，又能把数据库设计和前后端联调讲清楚。我第一次完整做这个项目是在带学生毕设的时候，前前后后从表结构设计到部署上线踩了不少坑，今天这篇就把整个项目的拆解思路和实操细节一次性写清楚，给正在写这个题目或者想自己动手实现一个完整前后端分离项目的朋友当参考。

先说清楚这套系统具体能做什么：面向高校教务场景，把学生管理、教师管理、院系班级结构、课程开设、学生选课、教师录入成绩、管理员发布公告这些核心流程全部串起来。角色上分三种——管理员、教师、学生，每种角色登录后看到的菜单和能操作的功能是完全不同的。底层是MySQL存数据，后端用SpringBoot提供REST接口，前端用Vue配合Element UI搭界面，前后端通过JSON交互。它解决的痛点很直接：替代传统Excel表格排课、选课、统计成绩的手工流程，让教务管理变得可查询、可追溯、可操作。适合的人群也很明确——计算机、软件工程等专业需要完成毕业设计的本科生，或者是想系统学习SpringBoot+Vue全栈开发、想找个完整项目练手的同学。

我见过不少人拿到这类项目源码后，照着跑起来就觉得完事了，其实这是最亏的。答辩时老师问一句“为什么选课表要设计成这个结构”“JWT放在哪里校验的”，卡壳的太多了。所以这篇不只是讲代码怎么写，还会把设计原因和实战经验一起讲透，让你不光能跑通，还能讲明白。

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

1.1 为什么选SpringBoot+Vue这套组合

市面上能用来做管理系统后端的东西挺多，SSH、SSM、SpringBoot，甚至Python的Django、Flask也都能做，但SpringBoot在这个需求里确实是性价比最高的选择。核心原因有几点。

第一，SpringBoot把Spring生态里最常用的组件整合在了一起，内嵌Tomcat，不用再单独部署WAR包，写个main方法就能跑起来。对于习惯了“点运行就启动”的学生来说，学习成本和环境配置成本都低了很多，这点比传统的SSM要友好得多。第二，SpringBoot和MyBatis Plus组合做业务开发非常快，尤其是单表的增删改查，MyBatis Plus内置的BaseMapper直接把常用方法都封装好了，省掉的代码量是肉眼可见的。第三，网上关于SpringBoot的教程和案例极其丰富，遇到问题基本都能搜到解决方案——对毕设这种项目来说，可参考性是很重要的选型依据。

前端用Vue而不是JSP模板或者FreeMarker，考虑的是前后端分离。教务管理系统虽然业务不算复杂，但涉及的角色和界面状态不少——学生选课要实时显示可选余量，老师录入成绩要对应到具体选课记录，管理员维护基础数据时要频繁切换页面。如果用JSP服务端渲染，每次交互都要刷新页面，体验很差；Vue这种数据驱动的响应式框架，操作完数据后视图自动更新，开发效率和用户感受都明显更好。

1.2 教务系统的核心需求解构

做任何一个系统之前，先别急着建工程写代码，第一步一定是梳理角色和业务流程。教务管理系统从使用者的视角来拆，能划分为三个角色、四条核心链路。

三个角色分别是谁？管理员，负责最底层的基础数据维护，包括院系、班级、教师、学生的信息导入与编辑，还要负责每学期课程的开设和审核，同时也发布教学相关的通知公告。教师，主要做的是查看自己名下的课程列表，查看选了自己课的学生名单，以及给这些学生录入成绩、修改成绩、导出成绩。学生，做的事情比较集中——浏览当前学期开放的课程，选课或者退课，查看自己已选课程的成绩，接收公告信息。

四条核心链路是什么？链路一是管理员维护基础数据，即“院系→班级→学生/教师”这种层级关系的建立；链路二是管理员开设课程，把课程分配到指定教师名下，设定学分、上课时间、人数上限；链路三是学生选课，涉及余量判断、冲突检测、选课记录写入；链路四是教师录入成绩，最终学生端能查询到成绩，形成完整的闭环。把这四条链路画成流程图，系统的骨架就出来了，后面所有的表结构和接口设计都是为它们服务的。

1.3 技术栈版本选择与项目目录规划

版本选择这块我吃了不少亏，重点说一下。SpringBoot不要用太新的版本，我遇到过用SpringBoot 3.x配MyBatis Plus或者某些老依赖时出现类名冲突、包路径变更的坑。毕设项目求稳，用SpringBoot 2.5.x或者2.7.x是比较稳妥的选择，配套的JDK用1.8或11就行。前端Vue用2.x配合Element UI是最成熟的方案，组件全、资料多、踩坑最少。如果你对前端比较熟悉，也可以用Vue3 + Element Plus，但Vue3的组合式API对新手来说写起来不算特别直观，考虑到毕设时间有限，除非你对Vue3本来就很熟，否则我建议Vue2。

MySQL用5.7或者8.0都可以，注意8.0需要配置时区，连接URL里加上serverTimezone=Asia/Shanghai就能避开常见的时区报错。Maven用来管理后端依赖，Node和npm用来跑前端开发环境，这些基础工具最好提前配置好。

后端项目和前端项目强烈建议分成两个目录，比如course-backend和course-frontend，相互不干扰。后端按标准Maven结构建：src/main/java/com/xxx/edu下放controller、service、mapper、entity、config、common等包；src/main/resources下放application.yml、mapper.xml文件等。前端用Vue CLI生成工程后，按api、components、views、router、store、utils这几个目录组织核心代码。这样做的好处是结构清晰，答辩时老师看项目方便，查问题也快。

这里想补充一句：很多人做项目图省事，全部功能堆在一个后端类里，刚开始觉得方便，等后面加选课模块、成绩模块时，代码越来越乱，自己都不知道某个方法在哪。分层这个东西看起来是额外成本，实际上是在给你自己省时间。

2. 数据库设计核心与表结构解析

2.1 从业务链路推导表清单

数据库设计是整个系统里最值得花时间的地方，因为它决定了后续写法简单还是复杂。一开始我先不急着建表，而是把前面梳理的四条链路逐一映射成数据实体，整理出第一版表清单：

• 用户表（sys_user）：保存登录账号信息，字段包括id、username、password、role、status（启用/禁用）、real_name，所有角色统一走这一张表登录，用role字段区分身份，而不是给管理员、教师、学生各建一张登录表，这样登录逻辑就只管一张表，简单直接。

• 院系表（college）、班级表（clazz）：这两张表体现学校的组织架构。院系下有班级，班级下有学生，这是很固定的一对多关系。

• 学生表（student）、教师表（teacher）：存各自附属信息。学生归属班级，教师归属院系，同时通过user_id和用户表关联。

• 课程表（course）：开设课程时产生。字段有课程名称、课程编码、学分、上课时间、上课地点、开课学期、课程容量等。

• 选课表（course_selection）：这是系统里最重要的关联表，记录“哪个学生选了哪门课”，字段包括id、student_id、course_id、select_time、status。一门课程可以被很多学生选，一个学生能选多门课，多对多关系必须靠中间表来拆。

• 成绩表（score）：记录教师给学生打的成绩，字段包括id、course_selection_id或者(student_id、course_id)、score、remark。成绩表应该在选课记录之后生成——也就是说，只有选了这门课的学生，教师才能录成绩，逻辑上成绩是绑定在选课记录上的。

• 公告表（notice）：发布的通知，字段有title、content、publish_time、publisher_id。

以上这些表就够支撑核心功能了。实际建表时还可以根据需求加一个“学期表”，如果老师们需要跨学期查历史开课记录，那学期字段单独建表会更规范。不过毕设出一版系统，把学期作为课程表的一个普通字段也能解释过去，不用非要拉一张表。

2.2 关键表字段设计的细节分析

选课表里有一个很容易忽视的点：余量怎么算。有人会在课程表里存一个selected_number字段，每次选课成功就加1，退课减1。这种设计的风险在于，如果选课接口和高并发场景碰在一起，并发更新同一个字段容易出问题。虽然毕设系统并发量不会很大，但用事务加锁来改计数很容易写错。我更推荐的做法是不存这个冗余计数字段，每次查询时用SQL实时统计：SELECT COUNT(*) FROM course_selection WHERE course_id = ?，然后和课程表的capacity字段比较，大于等于容量就不能选。这样虽然多一次查询，但逻辑不会错，也比较容易讲明白。

成绩表的设计也可以优化。最朴素的方式是成绩表独立存放，包含student_id和course_id以及score。但仔细想想，教师录入成绩时，他看到的页面一定是“某个课程下选了这个课的学生列表”，而这个列表天然就在course_selection表里。所以另一种做法是直接在course_selection表上增加score字段，让“选课记录”同时承担“成绩记录”的职责——这条记录在选课时生成，在录入成绩时给它填上分数。这种设计减少了表的数量，也让“没有选课就不能录成绩”的约束天然存在。当然，独立成绩表也有它的好处：可以保存补考成绩、重修信息、平时成绩和期末成绩等多个字段。具体怎么选，取决于答辩时你想怎么讲。我个人习惯用独立成绩表，扩展性更好，更符合“教务系统”这个业务域的常规认知。

密码字段的处理也值得多说一句。很多参考源码直接明文存密码，这是很糟糕的。哪怕毕设也应该至少用MD5加盐，或者用Spring Security的BCryptPasswordEncoder。项目中可以手动引入commons-codec做MD5，也可以在注册时用DigestUtils，实际上手也很简单：

String encodePwd = DigestUtils.md5DigestAsHex((password + salt).getBytes());

这样数据库里即使被人看到，密码也不是明文，答辩时也算一个小亮点。

2.3 外键用还是不用

这个问题我很建议在文档里专门写一段。不少教材强调在表之间设置物理外键，比如选课表的student_id要FOREIGN KEY指向学生表的id。但真正做项目时，主流开发方式普遍不推荐物理外键，而是用“逻辑外键”，也就是在业务层保证关联一致性。物理外键的缺点有几个：在删数据时会因为约束导致操作失败，影响灵活的删除策略（比如删除学生时想保留历史选课记录）；会降低写入性能；在分库分表、微服务化这种场景下物理外键根本不适用。管理系统虽然不需要那么极致，但既然你学的是当前业界主流做法，就应该讲“外键不用物理约束，而是在代码里做关联查询”。关联完整性由事务和业务判断去兜底。比如删除课程前，先查一下选课表是否还有关联记录，如果有就不允许删。这种设计到答辩时可以非常从容地解释，展示的是你对数据库设计深度的理解，而不是简单地建两张表。

2.4 建表语句和初始化数据准备

数据库建好后，还要准备一份基础测试数据。比如至少要有1个管理员账号、3个教师账号、几十个学生账号、几个院系和班级、若干门课程以及一些选课记录。没有初始化数据的系统看起来非常空，界面全是空表格，没法演示。我通常会单独写一个init.sql脚本，把建库、建表、插入测试数据一次性做完，方便其他人部署时直接导入。

初始化数据时要注意账号密码统一写一个简单的值，如admin/123456，老师账号teacher001，学生账号stu001，方便现场演示。真实的系统里密码要加密存储，测试数据里可以不加密但注释里要说明演示环境的常规处理方式。另外，课程时间字段建议用字符串保存“周一第1-2节”这种格式，比起单独的星期和时间段字段更好维护，展示也直观。数据库的字符集设置建议统一为utf8mb4，可以正常保存中文和特殊符号。

建表完成后可以把ER图画出来，这个图不只在论文里需要，自己开发时也能帮你理清表间关系。画图工具可以用Navicat内置的模型功能，或者使用draw.io、ProcessOn这类在线工具。

3. 后端SpringBoot核心功能实现要点

3.1 工程搭建与依赖配置

后端工程如何快速搭建？两种方式：IDEA创建Spring Initializr项目，或者在start.spring.io上生成后导入。需要注意生成的时候Group填com.example.edu，Artifact填course-backend，Java版本选8，依赖先勾上Spring Web、MySQL Driver、MyBatis Framework。之后还要手动在pom.xml里加入MyBatis Plus相关依赖和Lombok。

一个小建议：一定记得在application.yml里配置好数据源和MyBatis Plus。尤其是MyBatis Plus的分页插件需要单独加一个Configuration类，写好@Bean PaginationInnerInterceptor。因为后面所有的分页列表查询都会用到它，不配好会导致前端传了page和size却只拿到全部数据。这个属于非常典型的隐性坑，很多人项目跑不起来就卡在这一步。

下面是一个典型的配置骨架，供参考。

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/edu_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 mybatis-plus: configuration: map-underscore-to-camel-case: true 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

实体类、Mapper、Service、Controller这四层，可以用MyBatis Plus的BaseMapper配合少量自定义SQL来完成。比如学生列表查询可能需要按姓名模糊搜索，这时直接利用MyBatis Plus的QueryWrapper去构造条件，不写XML也能完成。如果是要多表关联查询，比如“查询选课详情时同时展示课程信息”，建议在Mapper里自己写一个自定义SQL，返回一个自定义VO对象，不要强求用ORM把多表关系拼出来。

3.2 统一返回体与全局异常处理

接口通信必须约定一种统一的返回格式，不能有的接口返回JSON对象，有的返回布尔值，否则前端处理起来非常痛苦。我习惯的定义如下：

{ "code": 200, "msg": "success", "data": { } }

后端统一封装一个Result类，提供Result.ok(data)、Result.error(msg)静态方法。Controller每个接口都返回这个Result对象。这样写的好处是前端Axios拦截器只需要判断code字段是否为200，就能统一处理所有成功或失败情况。

全局异常处理要用@RestControllerAdvice注解，把业务异常、校验异常、其余异常分别处理。比如定义一个BizException，当业务上不允许删除某条记录时，直接throw new BizException("该课程已有学生选课，不能删除")，然后由全局异常处理器把message返回给前端。这样业务代码里不用写大量try/catch，代码简洁干净。

3.3 登录鉴权与角色权限控制

登录接口这块，如果不想引入太复杂的Spring Security，用JWT加拦截器是最好理解也最常被采用的方案。流程是：用户输入账号密码，后端校验成功后生成一个包含用户id和role的JWT token返回给前端；前端把token存到localStorage里，后续每个请求都在请求头里带上Authorization: token；后端写一个拦截器，拦截所有需要登录才能访问的接口，解析token，校验是否合法；通过后再把当前登录用户的信息放到请求上下文里，供Controller使用。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); // 解析token，校验签名与过期时间 // 失败则返回401状态码 return true; } }

权限控制上，除了登录态校验，还要做角色校验。比如“录入成绩”接口只有教师角色能调用，“删除课程”只有管理员角色能调用。最简单的方式是自定义一个@RequireRole("TEACHER")注解，放在Controller方法上。然后在拦截器里取出token里的role，和注解要求的角色比对，不通过就返回“无权限访问”。当然，从小白友好的角度，也可以在Controller方法里直接判断当前用户角色来做限权。毕设系统只有三个角色，这种方式完全够用，也容易讲清楚。

3.4 核心业务接口的实现逻辑

选课接口算是最能体现业务逻辑的地方。它的实现要点是三步操作：第一，根据课程id查询课程，判断当前时间是否在选课时段内；第二，实时统计该课程已选人数，如果已达到了容量上限，返回“课程已选满”；第三，判断该学生是否已经选过这门课，如果选过则提示“不能重复选课”，如果没有则插入选课记录。

这三步必须放在同一个事务里。因为第一步到第三步之间，数据库状态可能被其他人的选课操作改变，没有事务的话容易产生数据不一致。在SpringBoot中用@Transactional注解即可，事务回滚能保证最多只有一个请求成功插入。

@Transactional(rollbackFor = Exception.class) public Result selectCourse(Long studentId, Long courseId) { Course course = courseMapper.selectById(courseId); if (course == null) { return Result.error("课程不存在"); } Integer selected = courseSelectionMapper.selectCount( new QueryWrapper<CourseSelection>().eq("course_id", courseId)); if (selected >= course.getCapacity()) { return Result.error("该课程已选满"); } Long count = courseSelectionMapper.selectCount( new QueryWrapper<CourseSelection>().eq("course_id", courseId).eq("student_id", studentId)); if (count > 0) { return Result.error("你已选择过该课程"); } // 插入选课记录 return Result.ok(); }

退课接口则反过来操作，先删除选课记录，同时可以把关联的成绩记录标记删除或物理删除，具体根据你的设计处理。成绩录入接口相对简单，更新成绩表的score字段，但要注意成绩值的合法性校验，比如成绩必须在0~100之间。教师查询所授课程下的学生名单，需要做一次多表关联：选课表join学生表join课程表，按教师id过滤。这种查询可以用MyBatis自定义SQL，也可以先查出教师所有课程，再用课程id集合查询选课记录。后者做起来更简单，但数据量大时效率低。毕设用第一种方式写SQL，性能没有任何问题，代码也更清晰。

4. 前端Vue核心实现与联调细节

4.1 Vue工程结构与路由权限设计

创建前端工程用Vue CLI或者Vite都行。如果用的是Vue2，命令行运行vue create course-frontend，选默认配置或手动选择Router、Vuex即可。项目创建完成后，第一步不是急着写页面，而是先把目录结构理清。把views目录下按角色建子目录，比如admin、teacher、student，每个角色相关的页面放进去；router/index.js中配置路由时给路由对象加上meta: { role: 'ADMIN' }这样的标记，然后在全局路由守卫里检查当前登录用户的角色，不是该角色就重定向到首页或登录页。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (!token && to.path !== '/login') { next('/login'); } else { const userRole = localStorage.getItem('userRole'); if (to.meta.role && to.meta.role !== userRole) { next('/no-permission'); } else { next(); } } });

这样做的好处是，前端也不会出现“管理员页面被学生直接通过URL访问到”的漏洞，安全性提升了不少。

4.2 Axios请求封装与接口统一管理

前端请求后端，我强烈建议封装一个统一的axios实例。创建一个utils/request.js，用axios.create构造实例，设置基础路径为/api（这样可以配合后端统一前缀），设置超时时间为10秒。然后在请求拦截器里从localStorage取token，添加到请求头；在响应拦截器里解析后端返回的Result，如果code不是200就弹出错误提示并返回reject；如果code是401就跳转到登录页。

业务代码里不要到处直接写axios.get这种散装调用，而是按模块建api文件，比如api/student.js里导出getStudentList(params)、addStudent(data)等函数。组件里只引入这些函数调用即可。这个习惯很实用，后面如果要改接口路径，只需要改api文件一处就行。

4.3 核心页面实现与组件用法

登录页是整个项目最简单的页面，只需要表单校验和登录按钮。用Element UI的el-form加上rules规则，对账号密码做非空校验。提交后把token和用户角色存到localStorage，跳转到对应角色的首页Dashboard。开发时可以不用做得特别花哨，但务必保证表单校验完整，因为演示时老师很可能故意不填账号就点登录。

管理员的“学生管理”页基本就是增删改查的模板。el-table展示数据，el-pagination做分页，el-dialog弹窗做新增和编辑表单，el-select做班级下拉选择。这里需要注意：查询学生列表接口要支持分页查询和按姓名搜索，前端传递pageNum、pageSize、keyword三个参数，后端用MyBatis Plus的Page对象接收并返回给前端。

教师的“成绩录入”页稍微麻烦一点。页面先通过一个课程下拉框筛选教师任课的课程，选中某门课程后，表格自动展示选修该课程的学生名单和成绩输入框。当老师修改成绩时，可以使用失焦事件或“保存”按钮触发更新接口。我建议设计成一个“暂存”机制，不要每改一格就请求一次后端，而是点击“统一保存”按钮，把表格里修改过的记录一次性批量提交。批量接口在后端用循环update即可，虽然不算高性能，但业务场景完全够用。

学生的“选课”页要突出课程列表和已选状态。课程卡片上应显示课程名、教师、时间、容量余量（已选/总容量），以及“选课”或“已选”按钮。选课成功后按钮即时变为“已选”并禁用，前端可以在选课接口返回成功时直接更新当前行的状态，也可以重新刷新列表。经验之谈，重刷列表会闪动一下，体验稍差，但代码更简单，对毕设来说完全可接受。

4.4 跨域问题与生产环境部署配置

开发环境中，Vue默认跑在8081端口，SpringBoot跑在8080端口，前后端不同源，浏览器会拦截请求，这就是典型的跨域问题。解决方式有三种：后端写CORS配置类、前端用Vue的devServer配置代理、两者同时配置。最省心的是在vue.config.js里配置代理：

module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

这样前端请求时直接写/api/user/login，开发环境由Vue代理转发到后端8080。部署到生产环境时，我通常建议前端执行npm run build，生成dist目录，然后把dist目录里的静态文件复制到SpringBoot的src/main/resources/static下，这样整个项目就变成一个可执行jar包，后端同时负责接口和静态页面。访问时不再有跨域问题。不过需要注意，如果静态资源和接口都用同一个8080端口，并且统一使用/api前缀，那么前端打包后的接口地址也要做适配。更规范的做法是在publicPath设置为/，接口请求统一用相对路径或从环境变量取，避免写死8080端口。

5. 系统部署、源码整合与常见问题排查

5.1 从源码到运行的全流程操作

拿到一份别人写的源码，或者你写完一版系统之后，如何从0开始把它跑起来？很多新人在这一步就跪了，其实只要按顺序做就不会出问题。

第一步，把环境准备好。需要安装JDK 1.8或11、Maven、MySQL、Node.js。Node版本不要太新，Vue2项目在Node 18以上偶尔会出OpenSSL兼容问题，推荐使用Node 14或16的稳定版本。

第二步，创建数据库。在MySQL里执行init.sql脚本，这一步创建库表并写入初始数据。执行完成后，用Navicat或者命令行show tables;确认一下表是否都建出来了。

第三步，改后端配置。打开application.yml，确认数据库地址、账号、密码是否正确。如果你的MySQL端口不是3306，别忘记改端口。之后在IDEA中打开后端项目，等待Maven依赖下载完毕，直接运行主类。如果控制台打印出Tomcat started on port(s): 8080，说明后端启动成功。

第四步，跑前端。在命令行进入course-frontend目录，先执行npm install安装依赖。如果下载太慢，设置npm淘宝镜像：

npm config set registry https://registry.npmmirror.com

然后执行npm run serve，启动完成后浏览器访问http://localhost:8081，能出现登录页就说明开发环境已经通了。

第五步，如果想打包演示，后端先执行mvn clean package，得到jar包；前端执行npm run build，再把dist复制到static目录，重新打jar包。部署到服务器上就用java -jar course-backend-0.0.1-SNAPSHOT.jar启动。这种方式对于毕设答辩前的本机演示足够了。

5.2 高频报错与排查思路速查

做成一个专题，把实际遇到的问题整理成速查表，既方便自己，也可以直接用在论文“系统调试”章节。

第一类问题是数据库相关。最常见的是Access denied for user 'root'@'localhost'，说明账号密码或权限不对；Unknown database说明数据库没有创建或者名字和配置不一致。时区问题The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，解决方式就是在连接URL后加serverTimezone=Asia/Shanghai。另外，如果建表语句里用了中文，但表里乱码，检查库的字符集是否为utf8mb4。

第二类问题是Maven依赖相关。Cannot resolve symbol 'springframework'一般是依赖没有下载成功，先检查网络，再把IDEA的Maven仓库配置到阿里云镜像。很多情况其实是IDEA没有自动刷新Maven，点一下“Reload All Maven Projects”就好。版本冲突也是常客，比如MyBatis Plus版本和SpringBoot版本不兼容，用2.5.1.x通常能解决大部分问题。

第三类问题是后端返回异常。比如MyBatis SQL语法错误，控制台会打印SQL语句，直接复制到Navicat里执行，很快就能定位是字段名写错还是表名字写错。接口返回500时先看后端日志的堆栈信息，多数都是空指针或SQL错误。这里我建议开启MyBatis Plus的日志输出，也就是之前配置里的log-impl，这样调试时接口实际执行了什么SQL一目了然。

第四类问题是前端相关。最常见的跨域报错“No 'Access-Control-Allow-Origin' header is present”，原因是没有配置代理或后端CORS。控制台报Cannot read property 'xxx' of undefined，通常是因为后端返回的数据格式和前端预期不一致，比如后端data是数组，前端当成对象取属性；或者是字段大小写问题，后端返回的字段是下划线，而前端用的是驼峰。统一使用map-underscore-to-camel-case: true配置能解决一部分，另外可以在实体类上用@JsonProperty注解校正。

第五类问题是租约和环境。Vue启动报Digital Envelope Routines::unsupported，最常见原因是新版Node的OpenSSL对旧依赖不兼容，解决办法是在package.json的script里设置set NODE_OPTIONS=--openssl-legacy-provider，或者干脆换Node版本。npm install时报ERESOLVE unable to resolve dependency tree，一般是依赖版本冲突，可以尝试在package.json中调整相关版本或删掉node_modules重新安装。

把这些问题整理成一个表格，写进论文的“系统测试”或“常见问题处理”章节，老师会觉得项目很扎实。

5.3 源码整合中要注意的坑

网上流传的毕设源码质量参差不齐，有的确实能跑，有的缺依赖、缺初始化SQL、甚至缺少关键文件。如果参考别人的源码做二次开发，有几件事一定要检查。

第一，检查数据库脚本是否完整。下载源码后不要急着运行，先看看压缩包里有没有sql文件，如果没有，那这个源码八成是残缺的。如果有，打开SQL脚本，检查是否存在建库语句；有些压缩包里的SQL只有表结构没有数据，你可能连登录账号都找不到。第二，检查依赖版本和JDK版本是否匹配。很多老项目的SpringBoot版本如果是1.x，那么配套的Maven插件和JDK版本很可能不兼容。第三，检查前端是否有package-lock.json或node_modules，如果没有，需要执行npm install重新装依赖。第四，检查是否有遗漏的静态资源，比如图片、logo、上传文件目录。这些在开发时可能被忽略，一旦缺失，界面会显示异常图片或文件上传失败。

我在实际帮别人调项目时发现，大量时间都耗在“环境不一致”上。比如对方用的MySQL是5.7，而脚本里用了MySQL8.0才有的语法；或者对方的Maven仓库里没有私有依赖导致编译失败。所以拿到源码后的第一步绝对是“看文档、看README、看SQL脚本”，不要上来就点运行。

6. 论文文档撰写与答辩准备的实战建议

6.1 文档结构如何组织

毕业设计论文不是把你写的代码贴上去就行，它要讲清楚“你为什么要做这个系统”“系统是怎么设计的”“怎么证明系统是好的”。常见的章节课可以参考这个思路：绪论，包括背景与意义、国内外现状、研究内容；相关技术介绍，包括SpringBoot、Vue、MyBatis Plus、MySQL、JWT；系统分析与设计，包括需求分析、用例图、流程图、数据库概念结构设计（ER图）、逻辑结构设计（表结构）；系统实现，分前端和后端讲核心功能代码；系统测试，写测试用例和测试结果。最后一章是总结与展望。

写文档时有几个细节可以提高质量：数据库表结构文档要图文并茂，每张表的核心字段都放到一个表格里，字段名、类型、说明、备注列清楚；接口文档用表格列出接口地址、请求方式、参数、返回结果；主要流程图用Visio或者draw.io画清楚，尤其是选课流程图和成绩录入流程图。这些图表比一大段文字更直观，答辩时讲得也省力。

6.2 测试用例与演示脚本提前准备

很多学生做完功能就完事了，到了答辩现场才临时打开系统，结果忘了测试账号，或者数据被改乱了。我强烈建议提前准备好一份“演示脚本”，按顺序走一遍核心流程。演示脚本大概是这样的：第一步，管理员登录，进入学生管理页面，新增一条学生记录，展示新增后列表数据变化；第二步，管理员进入课程管理页面，新增一门课程，设置容量为2；第三步，切换学生账号登录，选择刚才新增的课程进行选课，观察“已选人数”变化，再尝试选满后看前端提示；第四步，切换教师账号登录，进入成绩录入页面，录入该学生成绩；第五步，切换学生账号查看成绩，确认能够查询到结果。整个流程下来，系统的三个角色和核心功能全部覆盖到了，老师看到的是一个闭环演示，而不是零散的页面展示。

测试用例在论文里也要写，至少每个角色要有5到10个用例。用例表格包括编号、功能模块、前置条件、操作步骤、预期结果、实际结果、是否通过。重点覆盖登录失败、重复选课、选满课程、删除被占用的课程等异常场景。

6.3 答辩高频问题与应答思路

答辩老师喜欢问的问题其实很固定，提前准备就行。比如“为什么选SpringBoot而不选SSH”，回答说SpringBoot简化了配置、内置容器、生态好；再比如“你的密码怎么存储的”，回答用MD5加盐或用BCrypt加密；还有“外键怎么实现”，回答逻辑外键，解释物理外键不适合当前高并发场景；“JWT和Session有什么区别”，回答JWT无状态、不需要服务端存储，但有过期时间和续签问题，本项目用拦截器统一验证。这些回答不需要背，但一定要理解清楚。我见过有人被问到“你有分页功能吗，前端传的pageNum是从1开始还是从0开始”这种细节时就慌了，其实只要你真的亲手调试过，这个根本不难。

另外，答辩时最忌讳的是把源码从头到尾讲一遍，老师根本没兴趣听。应该讲重点：系统的三种角色权限怎么控制，数据库表之间怎么关联，前端路由怎么拦截未登录用户。这些才是体现你真实掌握了项目的点。

项目收尾阶段的一些经验

最后再分享一点个人经验。我做这个项目最大的体会是，毕设系统不在于功能堆得多，而是把一条主业务线做完整做扎实。教务管理系统的核心永远是“开课、选课、录成绩、查成绩”这条链路，把这条链路里的事务、权限、数据一致性处理好，已经能覆盖论文和答辩的大部分要求了。如果还学有余力，可以再加一两个亮点，比如用Redis做验证码存储、用MinIO存头像或课件、用ECharts做班级成绩统计图，这些在简历上都能写一笔，但前提是不要影响主功能的稳定。

如果你现在手上正拿着一份不知道能不能跑通的源码，我建议花一天时间先把环境跑起来，然后逐行读懂选课和录成绩这两个核心接口，再按我上面说的演示脚本走一遍，基本就稳了。源码和数据库脚本永远是参考，只有你自己调试过、理解过，答辩时才不会露怯。希望这篇能给你一些实实在在的帮助，祝答辩顺利。