企业官网建设流程全解析

最近总有学生朋友来找我聊线上辅导班系统的毕设选题，问得最多的就是这类“SpringBoot+Vue”项目到底怎么入手。源码拿到手，SQL脚本也导进去了，可一启动就报错，或者前后端根本连不上，整个人卡在环境配置上动弹不得。我拆解过不少这类项目，先说个结论：这类项目真正难的不是某个功能怎么写，而是你根本没有把“业务逻辑、表结构、接口约定”这三条线串起来想清楚。代码只是最终的表现形式，前面的设计思路才是毕设答辩时最能体现你水平的东西。

这篇文章我会围绕线上辅导班系统平台的完整实现链路，从业务模块拆解、技术选型逻辑、数据库设计、接口文档怎么用到部署联调，再到答辩时老师爱问的点，一条线讲清楚。保证你看完不光能把项目跑起来，还能在答辩台上讲出设计层面的东西。

1. 辅导班系统到底在管理什么：先拆透业务模块

很多同学拿到项目第一件事就是开IDE看代码，这个习惯我得先劝一句。代码是业务的下游产物，你连系统“管理了哪些对象、哪些角色在操作、操作流程长什么样”都没理清，代码在你眼里就是一堆乱麻。线上辅导班系统从业务上其实和电商平台有相似之处：都有用户、都有商品（课程）、都有交易（报名/订单），只是交付物从实体商品变成了教学服务，而且多了一条“授课过程”的链路。

1.1 三个核心角色与他们的诉求

系统通常同时维护三类账号：学生（学员端）、老师（讲师端）、管理员（运营后台）。我见过不少新手会把用户表设计成一张大表，用一个role字段区分身份，这在最简单的Demo里可行，但线上辅导班系统一旦涉及机构、多老师、班级维度，单表设计就会让后续统计和权限控制很难受。完整度高的项目一般会拆成用户基础表加角色关联表，或者至少保证每个角色有独立的扩展信息表，比如学员表存学年年级、老师表存擅长科目和简介，这样课程推荐和师资展示都不需要到处拼接数据。

学生端的核心流程是：浏览课程列表 -> 查看课程详情（含师资与大纲） -> 下单报名 -> 进入我的课程 -> 上课（直播/视频） -> 提交作业 -> 查看成绩与评价。这里每一步都涉及至少一张表的读写，比如浏览列表涉及课程与分类表的联查，下单涉及订单表与课程表的事务操作。

老师端要处理的则是另一个闭环：创建课程或班级 -> 发布课表与章节 -> 布置作业 -> 批改打分 -> 回复评价。注意“上课”这个动作在辅导班场景里比较特殊，很多毕设会做成直播链接的集成或者录播视频的播放页面，系统本身不直接做流媒体服务器，而是通过外链或嵌入播放器实现，这个设计取舍我在后面接口部分会讲。

管理员后台的活相对重而杂：审核老师注册或课程上架、管理课程分类、查看报名统计、处理订单退款、发布站内公告、配置轮播图。从数据层面看，管理员操作的本质就是对各个核心表的增删改查加状态流转控制。

1.2 业务状态机：每个关键字段背后都有流程

辅导班系统和简单CRUD的新闻发布系统有个本质差别：它的核心数据有“状态流转”。比如订单就绝不是只有“下单”和“支付成功”两个值，通常要包含待支付、已支付、已取消、已退款、已完成这样的状态链。课程也有草稿、待审核、已上架、已下架、已结课的状态变化。

这一点在答辩时特别加分。你如果能指着订单表的状态字段，讲清楚“用户在待支付状态下点击取消走哪个接口，超过30分钟未支付由定时任务批量关单”，这个系统就不只是增删改查，而是一个带业务规则的交易系统了。设计表结构时，状态字段建议用tinyint存数字，并在注释里写明每个数字对应的语义，而不是直接存中文，因为接口层需要对状态做数值判断和分支处理。

辅导班系统的业务闭环还要特别注意“人、课、班”三者的关系。简单说就是：一门课程可以开多个班级（班次），每个班次在特定时间段上课，一个学生报名的是某个具体班次而非笼统的课程。如果表结构里没有体现“班次”这个概念，你的系统在面对“同一课程不同时段”的场景时就会露馅，老师一追问你就答不上来了。

2. 为什么是SpringBoot+Vue：技术选型背后的黄金搭档逻辑

每次有学生问我毕设选什么技术栈，只要不是对某个框架有执念，我基本都推荐SpringBoot+Vue这套前后端分离组合。理由不是它“最先进”，而是它处在“行业普遍使用、学习资料充足、就业技能匹配、毕设演示友好”这四个圈的交集里，几乎没有短板。

2.1 后端SpringBoot到底替你解决了什么

SpringBoot最核心的价值是“约定大于配置”。做Java Web的同学如果经历过SSH或SSM时代，一定记得那种写一堆XML配置的痛：数据源配一遍、事务配一遍、MyBatis映射配一遍、包扫描配一遍，配错一个标签整个应用直接起不来。而SpringBoot通过自动装配，把“最常见的配置组合”通过starter依赖直接内置了。你引入spring-boot-starter-web，内嵌Tomcat和SpringMVC就都齐了；引入spring-boot-starter-data-jpa或者mybatis-spring-boot-starter，数据访问层的默认配置也就位了。

这不是说SpringBoot没有配置文件，而是它把配置文件收敛成了一个简洁的application.yml，而且支持多环境配置。我在跑这类毕设项目时第一个要看的就是application.yml里的三样东西：数据源地址、端口号、以及MyBatis的mapper-locations路径。这三个地方出错，项目必然起不来或者启动后访问接口就报404/500。很多网上流传的项目会把数据库密码写成自己的本地密码，你不改它就连不上，这是新手遇到的第一个拦路虎。

SpringBoot的另一个大优势是生态整合能力。辅导班系统要加登录鉴权，直接引入JWT或Sa-Token依赖；要加文件上传，SpringMVC本身就支持MultipartFile；要做定时关单，一个@EnableScheduling加@Scheduled注解就搞定了。毕设项目的功能点翻来覆去就那么几个，SpringBoot几乎都有官方的starter或成熟三方库，你不用拿SpringMVC手写轮子。

2.2 前端Vue给项目带来的展示力

Vue作为前端框架，核心优势是响应式数据和组件化开发。在辅导班系统里，课程列表页需要根据分类条件实时筛选，购物车或报名页要动态计算订单金额，学生端“我的课程”页面要根据课程状态显示不同操作按钮——这些交互用传统JSP+jQuery写起来会非常痛苦，你要手动操作DOM来同步数据和页面状态。而Vue的data对象一变，视图自动更新，心智负担低很多。

组件化的价值体现在复用上。比如课程卡片组件，在首页推荐位、课程列表页、搜索结果页都可能用到，你只需要封装一个CourseCard.vue，通过props传入课程数据，就能在不同页面复用同一套展示逻辑；修改时也只需要改一个文件。这在答辩演示时也是个可以讲的亮点：你用多少组件、各自承担什么职责、父子组件怎么通信，这些是能在项目文档里写出花来的。

需要提醒的是，Vue项目本身需要通过Node.js环境进行依赖安装和构建。npm install的时候终端刷一堆报错主要是版本兼容问题：Vue 2项目用了Vue 3的依赖包，或者Element UI与Vue版本不匹配。拿到源码后先看package.json里的依赖版本，再倒推应该安装哪个版本的Node.js。这是从“能看代码的人”到“能把项目跑起来的人”之间最常踩的一道坎。

2.3 前后端分离到底为什么是加分项

前后端分离架构在答辩时几乎是必被问到的。你要讲清楚的核心逻辑是：后端只负责提供JSON数据接口，前端只负责渲染和交互，二者通过HTTP协议通信，彼此不关心对方的内部实现。这就意味着后端可以单独测试接口（用Postman），前端可以用Mock数据先开发页面，两边并行推进。对于线上辅导班这种页面多、接口多的项目，并行开发的价值非常大，这也是为什么企业项目普遍采用这种模式。

分离架构还带来一个技术红利：部署时可以完全解耦。后端打成一个jar包跑在服务器上，前端打包成静态文件用Nginx托管，两边可以分别调整机器配置和扩缩容。虽然毕设不要求你搞集群，但你把部署图里的“静态资源-API服务-数据库”三层画出来，老师就知道你不是只会写CRUD。

3. 从SQL脚本反推数据库设计：这些表为什么必须存在

拿到项目的SQL脚本，不要只想着“运行它”，去读它。数据库脚本是整份源码里“信息密度”最高的文件，它决定了业务规则怎么落地。辅导班系统的核心表我按重要程度排了个序，也是我建议的解读顺序：用户/角色表、课程与分类表、班次表、订单表、作业与成绩表、内容管理表（轮播图与公告）。

3.1 核心业务表的设计逻辑

先说用户侧。用户表一般包含id、username、password（存的是BCrypt加密后的哈希串，不是明文）、phone、email、avatar、status、create_time这些字段。角色要是多对多关系，就得有user_role和role表；简单场景直接单字段role也行。这里有个扣分点和加分点的差别：扣分是“把密码明文存数据库”，这是安全常识问题，答辩被问到会很尴尬；加分点是密码传输至少要用HTTPS或前端加密，字段上体现密码哈希存储，这个细节能体现你考虑过安全问题。

课程表是系统的核心资产。常规字段有course_id、course_name、cover_image、category_id、teacher_id、price、original_price、description、course_type（录播/直播/线下）、status、create_time。price字段必须用decimal(10,2)而不是float/double，因为浮点数在计算金额时有精度问题，订单金额不一致在交易系统里是严重Bug。teacher_id关联老师用户ID，就能实现“老师只能看到自己课程”的数据隔离。category_id关联分类表，分类表一般设计成支持两级分类，方便前端展示树形筛选。

班次表往往容易被忽略，但它恰恰是帮助系统从“课程展示平台”升级为“教学管理平台”的关键。一个course_id在班次表里可以对应多条记录，每条记录有start_date、end_date、schedule_info（比如“每周六 14:00-16:00”）。学生报名的订单不管挂在课程上还是班次上，业务上都必须落到具体班次。否则系统就变成了“卖课程视频的商店”，而不是“辅导班管理系统”。

订单表我建议重点讲。它至少要有order_no、user_id、course_id（或者class_id）、amount、pay_type、status、pay_time、refund_time、cancel_time。order_no最好用“时间戳+随机数”生成唯一业务单号，这也是一个加分细节。订单表与支付对接通常是Mock方式——模拟一个支付成功回调，开发阶段用支付宝或微信沙箱容易在资质审核上卡壳，Mock的支付回调能让整套状态流走通。

3.2 辅助表也不是可有可无的

作业表（homework）和成绩表是辅导班业务闭环里最具行业特色的部分。作业要求学生提交答案或文本，教师批改后给出评分和评语。设计上要包含homework_id、course_id/class_id、teacher_id、title、content、deadline、create_time，以及学生提交表的submit_id、student_id、submitted_content、submit_time、score、comment、status。成绩统计功能就是从这两张表联查出来的。

内容管理类表，比如banner（轮播图）、notice（公告），本质上就是“富文本或图片的发布存储”。很多没经验的同学会在主业务表里混入广告位字段，让表结构变得很乱。更规范的做法是独立成表，字段包含id、title、image_url、sort_order、status、start_time、end_time。管理员在后台配置，前端首页通过接口读取。

还有一个极易被忽视的表：操作日志表或者叫系统日志表。别小看它，答辩时它能侧面证明你的系统“具备可审计性”。记录内容不用复杂，包含user_id、operation、method、params、ip、create_time就可以，用Spring的AOP切面或过滤器统一记录。这算是我强烈建议你在项目管理里追加的一个小模块，工作量不大，谈资却不少。

3.3 索引与数据字典：脚本里被忽略的高级细节

打开SQL脚本，除了CREATE TABLE，还要关注有没有CREATE INDEX。核心表的主键索引数据库会自动建，但针对高频查询场景的辅助索引需要设计者主动添加。比如订单表的user_id（查某人的订单列表）、订单表的order_no（唯一索引，根据单号精确查询）、课程表的category_id和status组合索引（前台按分类筛选上架课程）。这些索引能让查询从全表扫描变成索引查找，数据量上来之后性能差距是数量级的。

还有一个能看到设计功力的点：数据字典字段的注释是否齐全。好的脚本会给每个字段写comment，用来说明这个字段存的到底是什么状态、什么单位、什么含义。我在评审项目代码时，字段注释完整度几乎是第一眼就看的。注释都写不明白的，业务逻辑大概率也是含糊的。

4. 接口文档的正确打开方式：会读、会调、会对着写

接口文档是前端和后端之间的“合同”。拿到一个带接口文档的毕设项目，能不能快速跑起来，很大程度取决于你会不会按文档去核验接口行为。而如果你打算把模拟项目改成自己的毕设，你必然要新增功能接口，那时候读文档的能力就直接转化为写文档的能力了。

4.1 先理解统一返回体与状态码

正规的前后端分离项目，所有接口不会零散地返回裸数据，而是包一层统一返回结构。最常见的格式是：

{ "code": 200, "message": "操作成功", "data": { "token": "xxxx", "userInfo": { "userId": 1, "username": "stu001" } } }

code是业务状态码，200表示成功，401表示未登录或登录已过期，403表示无权限，500表示服务器异常。data是具体的业务数据，没有数据时可以为null。你在看接口文档时，一定要确认每个接口在几种场景下会返回什么code。尤其在实际调试时，前端页面上如果一直弹“请求失败”，不要急着改代码，打开浏览器开发者工具看Network里接口的响应体，一旦发现code是401，先查Token是不是没传或过期了。

状态码的设计需要前后端统一约定。有些项目会把code定义成字符串，有些用数字。没有绝对标准，但必须在文档里写清楚，并且在前后端代码里都使用常量或枚举引用，而不是在业务代码里散落魔法数字。

4.2 鉴权设计：Token流程贯穿所有操作

线上辅导班系统里，课程列表、课程详情这类查询接口可以匿名访问，但“创建订单、查看我的课程、提交作业”这些接口必须登录后才能调用，这就是鉴权要解决的粒度问题。主流做法是JWT（JSON Web Token）：用户登录成功后，后端签发一个Token返回给前端；前端把Token存到localStorage或者Pinia/Vuex里；之后每次请求，前端在请求头加一个Authorization: Bearer ；后端通过SpringBoot拦截器或过滤器校验Token，解析出用户ID和角色，再决定是否放行。

这个流程在答辩时可以被拆成三个问题：Token什么时候发？（登录接口成功后）；前端怎么附带？（Axios请求拦截器统一加头）；后端怎么校验？（拦截器+解析工具类）。能把这个完整链路讲清楚，比背十篇八股文都管用。

小细节：除了API鉴权，前端路由也要做权限控制。Vue Router的全局前置守卫可以根据本地存的登录态判断用户是否允许访问某些页面，比如未登录跳转登录页、老师登录后不能访问学生端页面。这份代码里如果再配合动态路由（根据角色路由表动态生成菜单），整个系统的权限体系就完整了，相当加分。

4.3 辅导班系统里典型的接口清单

以线上辅导班系统的通用需求，一个完整的接口文档通常覆盖以下模块：

• 认证模块：登录、注册、退出、刷新Token、发送验证码
• 用户模块：获取个人信息、更新头像昵称、修改密码
• 课程模块：课程分页列表、课程详情、按分类筛选、课程搜索、课程上下架（管理员）、课程审核（管理员）
• 班次模块：根据课程查询班次列表、老师创建班次
• 订单模块：创建订单、取消订单、订单支付（Mock回调）、订单列表、订单详情、退款申请与处理
• 作业模块：老师发布作业、学生提交作业、作业列表（课程维度）、学生成绩单
• 内容模块：轮播图列表、公告列表、公告详情

每个接口的文档至少要包含：请求方法（GET/POST/PUT/DELETE）、请求路径、请求参数（名称、类型、是否必填、说明）、响应示例、错误状态码。你可以拿着这个列表去和源码里的Controller层一一对应，检查一下这份源码到底补全了哪些模块，又有哪些模块是个半成品。

4.4 用Postman把接口调试跑通

拿到接口文档后我强烈建议你做的第一件事是：打开Postman，新建一套接口集合，把登录接口配好，然后把需要登录的接口都挂到一个父文件夹下，在父文件夹的Authorization里统一配置从登录响应中提取Token。Postman的Tests脚本支持从JSON响应里取字段存为环境变量，这是联调效率利器。

比如登录接口的Tests可以写：

var jsonData = pm.response.json(); pm.environment.set("token", jsonData.data.token);

后面的请求认证方式选择Bearer Token，在Token框里填入{{token}}，这样你在调试“创建订单→支付→查看我的课程”这个链路时，就不用逐个手填Token了。调试链路的意义在于：它能帮你验证“文档描述”和“真实行为”是否一致，很多毕设源码的接口文档会跟代码实现有出入，文档写着POST，实际代码用的是GET，或者参数名大小写对不上，这时候你只有在真实的HTTP报文里才能发现。

5. 把项目从源码变成线上运行的完整过程与高频坑位

如果你已经能读懂SQL脚本和接口文档，下一步就是让这个项目真正在你电脑上跑起来，或者部署到服务器上。这一步基本是翻车重灾区，我按我自己带学生跑项目的经验，把完整顺序和高频报错都列出来，你照这个来能省两三天时间。

5.1 环境准备清单

先从装机环境开始。无论项目多花哨，最底层依赖就这几样：

• JDK 8或11，注意SpringBoot 2.x版本一般用JDK 8就可以，SpringBoot 3.x则要求JDK 17以上。先看pom.xml里的SpringBoot版本再决定装哪个JDK，这是过来人的忠告，装错版本启动直接报UnsupportedClassVersionError。
• Maven 3.6+，配置好阿里云镜像，不然拉依赖能等到怀疑人生。
• MySQL 5.7或8.0，注意字符集要统一成utf8mb4，否则课程名称里存中文容易乱码。
• Node.js 14/16/18（看Vue版本，Vue 2和Vue 3对Node版本要求不同）。
• npm或yarn，作为前端包管理器。

5.2 初始化的三步关键动作

第一步是导入数据库。用Navicat或命令行执行SQL脚本。执行完毕后不要急着写代码，先打开数据库看几件事：表数量和脚本里CREATE TABLE的数量是否一致；关键表里有没有初始数据（比如管理员账号、测试老师账号、测试课程数据）；如果脚本里自带一个admin用户，那么登录密码在SQL里通常能看到哈希值来源，或者文档会有说明。

第二步是改后端配置。打开application.yml或application-prod.yml，把数据源连接串改成你本地的账号密码。SpringBoot的配置优先级是先读application.yml再读环境变量，如果你本机环境变量里有SPRING_DATASOURCE_URL这类配置，数据源会被环境变量覆盖，这也是一个隐性坑。

第三步是启动前端。在vue目录里依次执行npm install和npm run serve。npm install时间长短取决于网络；如果卡着不动，检查npm registry是不是被切到了国外源，换成淘宝镜像能提速一个量级。启动成功后终端会打印本地访问地址（通常是http://localhost:8000或8080），用这个地址打开页面，而不是直接双击index.html——后者会因为跨域和ES模块机制完全无法展示。

5.3 高频报错与排查思路

以下是我在各类线上线下辅导班项目中遇到最多的报错，按出现频率排序：

• 后端启动报数据库连接失败（Access denied for user）：用户名密码或库名错误。百分之九十是这个原因，不要先怀疑代码。
• 前端请求接口报跨域（CORS）：本地开发时Vue跑在8080端口，后端跑在8081端口，浏览器默认会拦截跨域请求。解决方式有两种：后端配置CorsFilter允许指定来源；或者前端通过Vue CLI的devServer.proxy把/api开头的请求代理到后端地址。项目里应该有现成配置，你要做的是确认代理地址写的后端端口对不对。
• 把jar包或前端打包上传到Linux服务器后，访问接口返回404：大概率是后端接口前缀和前端请求路径不一致。检查server.servlet.context-path配置，以及Controller类上的@RequestMapping("/api")前缀。
• 前端页面白屏但控制台没有接口请求：先看是不是静态资源本身加载失败，打开Network看JS文件是不是404，尤其用history模式路由时，服务器没做try_files转发的话刷新就白屏。

我自己做项目时的一个排查习惯是“从前到后、从网络到代码”。出现任何一个页面问题，先F12看Network，确认接口有没有发出、返回什么状态码和响应体；再看Console报什么JS错误；最后才打开IDE看业务代码。大部分联调问题都能在这个三步流程里定位，不要一上来就怀疑后端逻辑写错了。

5.4 静态资源与文件上传的处理

辅导班系统里涉及课程封面图、老师头像、用户头像的上传。开发阶段最简单的方式是存本地磁盘，数据库只存访问URL路径。但这里有个部署坑：本地开发时路径指向你电脑的某个文件夹，别人访问你接口时用的是图片主机地址拼接路径，跨机器访问就会404。比较规范的做法是：后台上传接口接收MultipartFile，保存到服务器配置的upload.dir目录；前端访问时通过一个静态资源映射前缀把磁盘路径映射成URL访问。如果毕设想做得更“企业级”一点，可以把文件存储切到MinIO对象存储，这大概是我最近被问得最多的话题，用SpringBoot整合MinIO做一个独立的文件服务接口，把上传和替换逻辑统一封装，课程封面这类图片就走这个接口入库存URL。这个扩展在答辩时的含金量远超讲CRUD，值得花时间加进去。

还有一个细节：Vue项目打包后通常会把图片压缩打成一个static目录，如果你在代码里把上传的图片URL写死成“localhost:8080/upload”这种绝对地址，那么上线后要么图片变红叉，要么所有访问用户都在看本机。这种错误容易在答辩现场出大丑，演示完页面图片加载不出来，老师印象分会低不少。稳妥的做法是在前端环境变量里配置baseUrl，区分开发、测试、生产环境，所有请求和资源地址都拼上这个baseUrl。

6. 从源码到答辩：怎么把项目讲出一个“准工程师”的深度

很多人的答辩PPT通篇是“我用SpringBoot写了登录注册”，这种讲法基本等于白讲。你自己回忆一下看的最好的项目分享，是不是都在讲“当时为什么这么选、踩了什么坑、怎么权衡的”？答辩也一样，老师想听的是你作为开发者所做的决策过程，不是你复述教程。

6.1 高频答辩问题与可参考的回答方向

我收集了带毕设这几年学生反馈的高频问题，你可以提前预演：

第一个必问问题：这个项目的技术选型为什么是SpringBoot+Vue？回答建议从“方案对比”角度切入：传统的JSP+Servlet视图渲染耦合太重，纯前端静态页又没法处理动态数据和业务逻辑，而SpringBoot+Vue前后端分离能明确分层、便于并行开发、后续扩展也方便。再加一句“这套技术栈也是当前中小型企业的常见组合，我能通过这个项目更快适应实习和工作的工程环境”，这个回答就不仅说技术，还体现了职业意识。

第二个高频问题：数据库怎么设计的？不要上来就说“我建了十张表”，而要说“我优先拆分了用户、课程、订单三条主线，围绕业务闭环延伸出班次、作业、评价等辅助表。重点考虑了三方面：一是订单状态流转需要记录时间链；二是课程和班次分离以支持同一课程多时段开班；三是所有金额字段用decimal来避免精度丢失。”你这样回答，基本就封住了老师大部分追问的空间。

第三个高频问题：有哪些地方体现了你的思考或解决方案？这个我建议你准备一个真实的“翻车案例”，比如跨域问题的排查、数据精度导致的金额错误、前端路由刷新404、上传图片后访问不到……任何一个都行。用“问题现象-排查思路-根因定位-解决方案”的叙事结构讲出来。这类实战经历是区分“照着敲代码”和“真的做过项目”的分水岭。

第四个进阶问题：你这个项目如果上线，哪些地方需要改进？这其实是送分题，但很多人答“没有”就白白浪费了。你可以从性能、安全、架构三个维度各说一点：性能上缓存热点课程数据到Redis；安全上增加接口限流与参数校验；架构上把文件服务独立成MinIO对象存储，把定时关单改用消息队列异步触发。能说出来就说明你不只能做加法，还知道系统演进的方向。

6.2 演示环节怎么准备更从容

演示节奏上，我建议你按“需求→演示→小结”的节奏走：先花一分钟口头介绍这个系统解决什么问题、三种角色怎么协作；然后用管理员身份演示课程审核、老师创建班次、学生报名进入课程的完整核心链路，不要零散地这个页面点一下那个页面点一下；最后用1-2分钟小结时强调一个你最得意的小设计（比如订单超时关单的定时任务、或者权限拦截与动态路由的配合）。

另外有几个实操细节必须提前确认：演示时保持数据库数据和图片资源齐全，别一上来首页是空的；预先把浏览器放大到合适比例，字体别太小看不清；如果依赖本地的后端服务，提前把缓存数据热起来；演示过程中万一报错或者网络卡了，直接重启一次要有心理准备，所以那些流程步骤不要让老师在你操作“中间环节”的时候提问，演示完再统一答疑会更顺畅。

6.3 预设几个进阶扩展的加分方向

如果你的毕设进度比较快，我建议在“完整性”已经保证的前提下，再补以下任何一个点，都会让项目层级上一个台阶：

• 在用户登录注册里增加图形验证码或短信验证码Mock逻辑，能体现安全意识的同时也解决了真实开发中“防刷”的问题；
• 给课程列表页增加一个基于课程标题和描述的模糊搜索，用MySQL的LIKE配合索引，简单但很实用；
• 加一个数据可视化统计页面：每周新增订单数、每门课程的报名人数排行，用ECharts画两个图表，管理员的“Dashboard感”马上就出来了；
• 将文件上传部分切换到MinIO并写一个FileService的统一封装，对图片做大小压缩和水印，前端拿到的是处理后的图片URL。

这些扩展点的工作量不算大，但每一条都能在答辩时接住老师的提问，让你的项目从“课设模板”变成“有个人思考的作品”。

回想一下我带过学生的最大感受：拿到一份SpringBoot+Vue的线上辅导班系统源码，把它完整跑通只是最低目标。你能不能解释清楚为什么要拆这些表、接口为什么这么设计、Token链路是怎么流转的、订单状态机在代码里如何实现——这些才是决定你能否通过答辩、以及你的代码能力在面试中被认可的关键。如果这篇文章里的某一节帮你少熬了一个夜，或者让你在答辩台上多答上了一问，那这份整理的时间就花得值了。