企业官网建设流程全解析

1. 毕设选题背后：为什么这个题目值得做

教育辅导班信息网这个题目，放在2026年仍然有很强的现实意义。你去看各类毕设选题库，ssm+vue组合的题目占了一大半，但真正能讲清楚"为什么这么设计"的同学反而不多。这套题目的核心价值在于：它覆盖了当前中小型Web系统的主流技术栈，前端用Vue做单页应用，后端用SSM（Spring + SpringMVC + MyBatis）处理业务逻辑，两者通过RESTful接口通信，正好对应了企业里前后端分离开发的常见形态。

再说业务层面，教育辅导班这个场景非常典型——机构需要管理课程、排课、老师、学员；学员需要在线查看课程、报名、缴费；家长可能需要了解课时消耗和剩余费用。这些需求拆开看都是增删改查，但组合起来就有意思了：课程和老师是多对一，学员和课程是多对多（通过报名记录关联），排课涉及时间冲突校验，缴费涉及订单状态流转。这种数据关系和业务规则的复杂度，刚好能体现一个毕业设计应有的工作量，又不至于难到做不完。

对于需要答辩的同学来说，这个题目的友好之处在于：业务逻辑贴近生活，评委老师不需要太多背景介绍就能理解你在做什么。演示的时候你可以很自然地讲"这里是排课管理，我做了冲突检测"，"这里是学员报名，报名后自动生成待缴费订单"，每句话都能落到具体功能上，而不是空谈技术。

2. 开发前的环境准备与基础配置

工欲善其事必先利其器，这一部分看起来基础，但每年都有同学在这里折腾一两天。我先把推荐的工具链列出来，后面再逐个说明需要注意的细节：

• JDK版本：建议JDK 1.8，兼容性最稳。哪怕你机器上装了JDK 11或17，也可以单独装一个1.8用来跑这个项目，避免MyBatis或旧版Spring的兼容问题。
• Maven：3.6.x即可，注意配置阿里云镜像，否则拉依赖会慢到怀疑人生。
• Node.js：14.x或16.x，对应npm 6/8。新版Node（比如18+）跑老项目时，node-sass这类原生模块容易编译失败，这是最常见的坑之一。
• 数据库：MySQL 5.7，其次是8.0。8.0需要注意驱动和时区配置，后面会讲到。
• IDEA：用Ultimate版，社区版没有Spring Initializr和数据库工具，写SSM项目会麻烦很多。

这里面有几个我踩过的坑值得单独提。第一个是Maven镜像问题，默认中央仓库在国内下载速度很不稳定，经常卡在某个依赖上下载半天。解决方式是打开maven/conf/settings.xml，在mirrors节点里加上阿里云镜像：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

第二个是Node版本。很多教程会让你装最新版Node，但对于Vue 2 + webpack 3/4的老项目，高版本Node会直接报digital envelope routines::unsupported错误，这是OpenSSL版本变化导致的签名算法不兼容。最简单的办法是用nvm管理Node版本，切到14.x。如果你不想装nvm，也可以在package.json的scripts里加上NODE_OPTIONS=--openssl-legacy-provider（仅限Node 17+，但不推荐）。

第三个是数据库。MySQL 8.0默认的认证插件是caching_sha2_password，老版本的mysql-connector-java（5.x）无法识别，会报Unable to load authentication plugin。解决思路有两条：要么驱动换成mysql-connector-java 8.0.x，要么在MySQL里把root用户的认证插件改回mysql_native_password。我建议直接换驱动，顺便把驱动类从com.mysql.jdbc.Driver改成com.mysql.cj.jdbc.Driver，URL里加useSSL=false&serverTimezone=Asia/Shanghai。

数据库本身的设计也很关键。下面给出一套可以直接用的表结构，覆盖了辅导班信息网的核心业务：

CREATE DATABASE edu_class DEFAULT CHARACTER SET utf8mb4; CREATE TABLE admin ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) UNIQUE NOT NULL, password VARCHAR(100) NOT NULL ); CREATE TABLE teacher ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, subject VARCHAR(50), phone VARCHAR(20), intro TEXT ); CREATE TABLE course ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, subject VARCHAR(50), teacher_id INT, price DECIMAL(10,2), total_hours INT, start_date DATE, end_date DATE, max_students INT, schedule VARCHAR(200), description TEXT, FOREIGN KEY (teacher_id) REFERENCES teacher(id) ); CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, phone VARCHAR(20) UNIQUE, parent_name VARCHAR(50), grade VARCHAR(20), balance DECIMAL(10,2) DEFAULT 0 ); CREATE TABLE enroll ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT, course_id INT, enroll_time DATETIME, status VARCHAR(20) DEFAULT 'PENDING', FOREIGN KEY (student_id) REFERENCES student(id), FOREIGN KEY (course_id) REFERENCES course(id) ); CREATE TABLE payment ( id INT PRIMARY KEY AUTO_INCREMENT, enroll_id INT UNIQUE, amount DECIMAL(10,2), pay_time DATETIME, method VARCHAR(20), FOREIGN KEY (enroll_id) REFERENCES enroll(id) );

这套表结构做了一点刻意的设计：student表里加了balance字段，用来记录学员账户余额，后续扣课时费、退费都从这里走；enroll表里的status字段用PENDING表示待缴费、PAID表示已缴费，这样报名和缴费就拆成了两个状态，逻辑上更清晰，演示的时候也可以多讲一步"状态流转"。如果你想让系统再复杂一点，可以加course_comment表做课程评价，或者notice表做公告发布，但基础表够用就行。

3. SSM后端：理解三层架构的本质

很多同学写SSM项目时是"照着模板敲"，敲完也不知道Controller为什么要分两层、Service里那层接口到底有什么用。这里我花点篇幅把设计思路讲透，你明白了之后，不管拿到的代码长什么样都能自己改、自己讲。

SSM的三层架构是Controller、Service、Mapper，每一层各管一件事。Controller负责接收请求、解析参数、返回结果，它不关心数据怎么算出来的；Service负责业务规则，比如学员报名课程时，要检查课程是否满员、学员是否重复报名、然后创建订单；Mapper就是MyBatis的接口层，负责和数据库打交道。为什么要把Service单独抽出来？因为Controller是跟HTTP协议绑定的，如果哪天你不做Web了，换成消息队列接收指令，Controller直接扔掉，Service和Mapper还能原封不动地复用。这就是分层的好处——降低耦合。

下面给一段贴合本项目的代码示例。比如学员报名这个操作，实际写起来是这样的：

@Service public class EnrollServiceImpl implements EnrollService { @Autowired private CourseMapper courseMapper; @Autowired private EnrollMapper enrollMapper; @Override @Transactional public Result enrollStudent(Integer studentId, Integer courseId) { Course course = courseMapper.selectById(courseId); if (course == null) { return Result.error("课程不存在"); } // 校验名额 int count = enrollMapper.countByCourse(courseId); if (count >= course.getMaxStudents()) { return Result.error("课程已满员"); } // 校验重复报名 Enroll exist = enrollMapper.findByStudentAndCourse(studentId, courseId); if (exist != null) { return Result.error("请勿重复报名"); } Enroll enroll = new Enroll(); enroll.setStudentId(studentId); enroll.setCourseId(courseId); enroll.setStatus("PENDING"); enrollMapper.insert(enroll); return Result.success("报名成功，待缴费"); } }

这段代码里有几个细节。第一是@Transactional注解，这就是事务控制：如果中途某个操作失败，前面插入的订单也会回滚，不会留下"报了名但没生成记录"的脏数据。第二是手动做业务校验，满员和重复报名都在Service层判断，而不是让数据库报错——数据库只能告诉你唯一键冲突，但无法替你返回"请勿重复报名"这种用户能看懂的消息。第三是Result对象，统一包装返回值，前端拿到后根据code判断成功失败，而不是让后端直接抛异常。这三条原则延伸到项目的任何业务模块里，都是通用的。

再聊聊MyBatis这块。用XML写SQL还是用注解写SQL？网上争论很多，我的看法是：这个项目里简单SQL用注解没毛病，但涉及联表查询和动态条件时，XML更合适。比如说课程列表要支持按名称模糊搜索、按学科筛选、按老师筛选，Mapper里写一个动态SQL：

@Mapper public interface CourseMapper { List<Course> searchCourses(@Param("keyword") String keyword, @Param("subject") String subject, @Param("teacherId") Integer teacherId); }

对应XML：

<select id="searchCourses" resultType="com.example.entity.Course"> SELECT * FROM course <where> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="subject != null and subject != ''"> AND subject = #{subject} </if> <if test="teacherId != null"> AND teacher_id = #{teacherId} </if> </where> </select>

<where>标签会智能处理AND关键字，不需要你自己写"WHERE 1=1"这种丑代码。这也是MyBatis比JPA灵活的地方——动态SQL组合完全可控，不会被框架的自动生成SQL给绕晕。

项目里还有一个容易乱的点：统一返回结果。建议定义一个通用的Result类，比如Result.success(data)/Result.error(msg)，所有Controller都返回这个结构。这样前端的axios拦截器只需要处理一种数据格式，不用每个接口单独判断。如果做得再规范一点，还可以加一个全局异常处理器，用@RestControllerAdvice拦截业务异常，统一包装成Result返回，这样Service层就可以大胆抛异常，而不是层层传递错误码。

4. Vue前端：让页面和数据真正联动起来

Vue这块的内容量很大，从环境搭建到组件通信，再到和SpringBoot联调，每一步都有同学卡住。我按实际开发顺序来讲，你跟着走基本不会出大问题。

前端入口文件通常是main.js，这里做的核心事情是创建Vue实例、注册全局组件、挂载路由和状态管理。一个参考的配置里，要特别注意的是vue-router和axios的引入路径。在Vue 2项目里，引入方式是：

import Vue from 'vue' import App from './App.vue' import router from './router' import ElementUI from 'element-ui' import 'element-ui/lib/theme-chalk/index.css' Vue.use(ElementUI) Vue.config.productionTip = false new Vue({ router, render: h => h(App) }).$mount('#app')

ElementUI是这套系统里最常用的UI组件库，表格、表单、弹窗、分页全都有现成组件。对于毕设来说，用ElementUI比手写样式高效太多，而且观感统一，评审老师看着也舒服。

axios请求封装这里，我建议直接建一个utils/request.js统一处理：

import axios from 'axios' 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) { this.$message.error(res.msg) return Promise.reject(new Error(res.msg)) } return res.data }, error => { this.$message.error(error.message) return Promise.reject(error) } ) export default request

把baseURL统一设成/api，配合Vue的代理配置，可以完美解决跨域问题。开发环境的跨域配置在vue.config.js里（如果你用的是Vue CLI），后面联调时再细说。响应拦截器的好处是，你不需要在每个页面里写if (res.code === 200)这种重复判断，失败时自动弹错误提示，业务代码里只剩成功路径，清爽很多。

再聊聊路由。教育辅导班信息网的页面不算多，但路由结构还是要设计清楚的。我建议分为两种路由：/admin开头的管理端路由和/portal开头的门户端路由。管理端包括课程管理、教师管理、学员管理、报名管理、缴费管理、系统设置；门户端则是课程列表、课程详情、报名页、个人中心。

路由配置示例：

const routes = [ { path: '/admin', component: Layout, redirect: '/admin/course', children: [ { path: 'course', component: () => import('@/views/admin/CourseList.vue') }, { path: 'teacher', component: () => import('@/views/admin/TeacherList.vue') }, { path: 'student', component: () => import('@/views/admin/StudentList.vue') }, { path: 'enroll', component: () => import('@/views/admin/EnrollList.vue') }, { path: 'payment', component: () => import('@/views/admin/PaymentList.vue') } ] }, { path: '/portal', component: PortalLayout, children: [ { path: 'courses', component: () => import('@/views/portal/CourseList.vue') }, { path: 'course/:id', component: () => import('@/views/portal/CourseDetail.vue') }, { path: 'my', component: () => import('@/views/portal/MyCourses.vue') } ] } ]

这里用的是懒加载写法() => import(...)，好处是首屏只加载必要的代码，页面多了以后性能也不会拖垮。对这个项目来说，路由懒加载不是必须的，但写上去可以在答辩时多一个亮点，说明你考虑了首屏加载性能。

前端另一个核心点是组件复用。课程卡片、报名弹窗、状态标签这类地方，如果每个页面都复制一份HTML，后面改样式要改十几处。抽成公共组件后，只用改一处。比如说课程卡片是一个高频组件，可以把props设计成：

<template> <el-card class="course-card"> <h3>{{ course.name }}</h3> <p>学科：{{ course.subject }}</p> <p>教师：{{ course.teacherName }}</p> <p>价格：￥{{ course.price }}</p> <p>开课：{{ course.startDate }} 至 {{ course.endDate }}</p> <el-button type="primary" @click="handleEnroll">立即报名</el-button> </el-card> </template> <script> export default { name: 'CourseCard', props: { course: { type: Object, required: true } }, methods: { handleEnroll() { this.$emit('enroll', this.course) } } } </script>

用props接收父组件传进来的课程数据，用$emit通知父组件用户点了报名按钮。这种"子组件只负责展示，父组件负责业务"的模式，就是Vue组件通信的基本套路，熟练之后很多场景都能套用。

5. 前后端联调：代理、跨域和接口对接

前端页面写好了，后端接口也通了，但两边一对接就出问题，这是最常见的崩溃现场。绝大多数问题的根源就两个：跨域，以及接口路径对不上。先解决跨域。

开发环境下，前端跑在localhost:8080（Vue默认端口），后端跑在localhost:8081（SpringBoot默认端口）。浏览器看到端口不同，就视为跨域请求，会阻止浏览器读取响应。解决方式有很多，但对这个项目来说最简单的是用Vue的devServer代理。在vue.config.js里配置：

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

意思就是：前端所有发往/api开头的请求，都让devServer转发到后端的8081端口。浏览器访问的还是同一个8080，所以不存在跨域问题。注意这个代理只在开发环境生效，生产环境的请求路径是真实的后端地址，所以部署时还要在Nginx里做同样的代理配置。

跨域问题解决了，接下来是路径规范。我在很多同学的项目里看到过这个问题：前端调/api/course/list，后端Controller的RequestMapping写的是/course，方法上是@GetMapping("/list")，按说能对上。但是前端服务里封装了baseURL为/api，而后端的context-path如果配了/api，那实际请求路径就变成了/api/api/course/list，直接404。这种坑非常隐蔽，排查方法就是打开浏览器开发者工具看Network面板，看请求URL是长什么样，再对照后端的完整路径分析。

接口对接时还存在一个很典型的问题：后端返回的是{code: 200, data: {...}}这种结构，前端请求封装已经拆包了，拿到了res.data。但有人会在业务代码里再写一层res.data.data，结果取到undefined，页面空白。建议的做法是：后端统一返回Result，前端在拦截器统一拆包，页面组件里只接收业务数据，这个约定要跟写后端的朋友（或者自己）明确对齐。

联调阶段还有一个常见坑：日期格式。后端返回2026-03-15T00:00:00.000+00:00这种带时区的字符串，前端直接展示很丑。最简单的处理方式有两种：后端在Jackson配置里设置日期格式，或者在实体类的日期字段上直接用@JsonFormat注解：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private Date createTime;

注意一定要指定timezone = "GMT+8"，否则Jackson默认按UTC序列化时间，你看到的时间比实际时间少了8小时，这在项目演示时非常尴尬，因为所有时间都对不上。

联调通过后，如果你想把前端项目打包放进SpringBoot里一起部署，搞一个单文件应用，有一个经典做法：先把Vue项目执行npm run build，生成dist文件夹，然后把dist里面的静态文件复制到SpringBoot项目的src/main/resources/static目录下。这样启动后端一个进程就够了，前端页面和后端接口都在同一个端口提供服务，不需要额外部署前端，非常适合毕设演示环境。这里注意一件事：如果前端路由使用了history模式而不是hash模式，刷新二级页面会404，必须在后端配置一个转发规则，或者在打包时改回hash模式。对毕设场景来说，我建议直接用hash模式（默认带#号），省心一大截。

6. 核心业务场景实现：从排课到报名缴费的完整链路

光讲框架知识还不够，我挑几个业务里的典型场景，把完整的实现思路给你串一遍。这样你在写论文、做答辩PPT的时候，可以直接把这几段作为"核心功能设计"的素材。

排课管理这个模块看起来就是个CRUD，其实暗藏一个容易忽略的校验点：时间冲突。一个辅导班会同时有多个教室、多个老师，如果一个老师同一时间段被排了两门课，那就是事故。在后端的Service层，保存排课时要做一次冲突检测：

List<Course> courses = courseMapper.findByTeacherAndTime(teacherId, startTime, endTime); if (!courses.isEmpty()) { return Result.error("该老师在该时间段已有课程"); }

查询逻辑是在课程表里找同一个老师的时间段相交的记录。时间冲突的判断稍微有点绕："新课程的开始时间 < 已有课程的结束时间 且 新课程的结束时间 > 已有课程的开始时间"，两条边界条件缺一不可。我在不少代码评审里看到过只判断一边的写法，结果某一天正好卡着边界就漏判了。建议在数据库表里就把时间字段设计成start_date、end_date（或start_time、end_time）两个字段，别用单个日期字符串加time文本，那样没法在SQL里做范围比较。

再来看报名+缴费链路。这套流程涉及三张表：报名时往enroll表插入一条PENDING状态记录；缴费成功后更新enroll.status为PAID，同时往payment表插入一条缴费记录。有人会问：为什么不直接在enroll表里加一个pay_status字段，非得拆一张payment表？拆表的理由是：一个报名记录未来可能出现"部分缴费"、"退款"等操作，支付记录本身是一个独立实体，后续要做对账、统计收入，直接查payment表就行，不用在enroll表里塞一堆跟报名无关的信息。这是典型的数据库设计权衡——为了扩展性，拆一张表是合理的。

缴费过程还涉及学员账户余额的更新。如果学员有余额，报名时可以勾选"使用余额抵扣"，余额部分直接从balance字段扣减，差额走扫码支付（演示环境可以模拟）。这里又要用到事务：扣减余额和更新订单状态必须同时成功或同时失败。代码写在Service层，加上@Transactional就行。

课程列表的展示是门户端最核心的页面。用ElementUI的el-table还是el-card展示课程？管理后台用表格更直观：每一行是一门课，操作列放"编辑"、"删除"、"查看学员"按钮。门户端用卡片更好看：每个课程一张卡片，配课程名称、简介、价格、开课时间，点击卡片进入详情。这里有一个细节：卡片组件在一个页面上可能渲染几十次，如果每次都在组件里发请求去查老师姓名，效率很差。正确做法是后端列表接口直接把老师姓名联表查出来：

<select id="selectCourseWithTeacher" resultType="map"> SELECT c.*, t.name AS teacher_name FROM course c LEFT JOIN teacher t ON c.teacher_id = t.id </select>

前端拿到teacher_name字段直接展示，不用二次请求，页面渲染快，代码也简洁。这类优化说起来很小，但答辩时如果你能主动提到"我做了联表查询，避免了N+1请求问题"，面试官或评审老师对你的系统设计评价会明显不一样。

7. 访问控制与权限设计：登录态和角色管理

教育辅导班信息网至少要区分两种角色：管理员和普通学员（如果是门户端的话）。管理员管后台，学员看前台。怎么控制哪些页面能访问？核心是前端路由守卫 + 后端接口校验这套组合。

前端路由守卫长这样：

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

逻辑很简单：访问/admin开头的页面必须要有token，没有就跳登录页。这个守卫只能挡得住普通用户，毕竟前端代码是公开的，懂点技术的人可以直接在控制台改localStorage。所以后端接口也需要做校验。

后端的校验方案有几种：最完整的是Spring Security + JWT，对毕设来说这是加分项，但有学习成本；如果你求稳，可以用最简单的Interceptor实现登录拦截。我自己写过很多次这种简易拦截器，核心逻辑是这样的：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { response.setStatus(401); return false; } // 校验token，从Redis或数据库查会话 // 如果通过，把用户信息放入request context return true; } }

然后注册到WebMvcConfigurer里，把/admin/**路径都拦一下：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/admin/**") .excludePathPatterns("/admin/login"); } }

这里有个细节：/admin/login必须排除掉，否则用户没法登录了。学有余力的同学，建议直接上Spring Security + JWT的组合，答辩时可以重点讲"我用了基于JWT的无状态认证方案"。但如果时间紧张，Interceptor + Redis存session的方式也完全够用，重点是把"前端有守卫，后端有拦截"这套思路讲清楚。

密码存储方面，千万不要用明文。用BCrypt加密，Spring Security里自带这个工具类。如果不想引入Spring Security全家桶，也可以用jBCrypt库或者Java自带的消息摘要算法加盐处理。答辩时如果被问到"你的密码安全怎么做的"，能说出"BCrypt加盐哈希存储"就达标了。

8. 部署与演示环境：本地跑通到可演示的最后一公里

毕设做到能跑还不够，要在答辩当天顺畅演示，部署环节得提前演练。最稳妥的方案是本地直接跑前后端：后端IDEA启动，前端npm run serve启动，两个进程并行。这个方案依赖最小，不会因为环境变量或服务器配置出问题。

如果你想让演示环境更接近真实部署，可以把Vue打包后扔进SpringBoot里，再用java -jar启动。方法前面提到了：npm run build生成dist，复制到static目录。但有一个问题要注意：打包后的dist里引用的资源是相对路径还是绝对路径。Vue CLI默认的publicPath是/，如果你部署在服务器根路径没问题，但如果是放在子目录或SpringBoot的context-path下，就需要在vue.config.js里设置：

module.exports = { publicPath: './' }

这样资源引用会变成相对路径，不会因为部署位置变化而404。

前端部署的另一个坑是history模式的路由刷新问题。如果你用的是history模式（URL里没有#号），在SpringBoot里刷新/admin/course页面时，后端找不到对应的Controller路由，会返回404。解决思路有几种：改用hash模式；或者在SpringBoot里配置一个转发规则把非静态资源的请求转发到index.html。回头看，对毕设来说hash模式是最省事的，URL里多个#无关大雅。这个细节很多教程不会讲，但真遇到了就是卡半天。

数据库的初始化也要提前准备。答辩机器上如果没装MySQL，演示之前要确保数据导入完整。推荐在项目根目录放一个sql/init.sql，包含建库建表脚本和基础测试数据。测试数据要刻意造得"好看"一点：课程名称有语文、数学、英语、物理等，老师有几个，学员注册几条，缴费记录有几条，让系统打开后不是空荡荡的，演示效果完全不同。

最后提醒一个关于IDEA的小细节：如果你的项目里同时有SSM后端和Vue前端，建议用两个IDEA窗口分别打开，后端窗口跑SpringBoot，前端窗口跑npm。在后端窗口里给SpringBoot配置好1.8的JDK版本，在前端窗口的Terminal里确认node版本是14或16。别小看这些基础配置，我就是因为没检查Node版本，浪费了整整半天在解决sass-loader编译报错。

9. 写在最后的一点建议

这个题目做下来，你的收获远不止一个能运行的系统。SSM让你理解了Spring的IoC、AOP核心思想，了解一个Web请求从浏览器到数据库再返回的完整链路；Vue让你掌握了现代前端框架的组件化思维、路由管理和状态管理；前后端分离的开发模式让你体会了真实企业项目的协作方式。这些东西，比代码本身值钱得多。

我的个人建议是：不要为了赶进度跳过设计和思考。先把表结构画出来，把核心功能的流程图理清楚，再动手写代码。很多同学一上来就找代码、往IDE里导入，改了几个页面就说"做完"了，结果答辩时连业务流程都讲不清。你要是能把课程排课、报名缴费这几条核心链路讲透，代码哪怕有一些小瑕疵，老师们也会认可你的工作量。

最后留一个小技巧：答辩前一天，把系统完整跑一遍，每个菜单点开看一眼。我当时就是这么干的，结果发现在缴费模块点击退款时后端报了个NPE——就是因为有个学生的enroll_id在数据里是NULL。修掉之后，整个演示过程顺畅无比。这种事前演练的习惯，值得养成。