企业官网建设流程全解析

做毕设这几年，每年都会被问到同一个问题：“一个课设级别的管理系统，选什么技术栈最稳、最容易做出效果？”如果让我给一个不踩坑的答案，那大概率就是“SpringBoot + Vue + MySQL”这三件套。今天我想好好拆一个非常典型的题目——大学生计算机基础网络教学系统管理平台。这类平台不光是毕设和课设里的热门方向，哪怕放到实际工作中，也是标准的在线教育业务模型：课程、资源、作业、考试、讨论，全链路都有。它难度适中，模块清晰，既能展示后端 Java 功底，又有 Vue 前端交互的发挥空间，非常适合拿来练手或者当成答辩底稿。

我见过不少同学一上来就想去搞一堆微服务、Redis 缓存、消息队列，结果做了一半自己先崩了。一个课设/毕设项目，最忌讳的就是“业务没闭环、技术拼盘乱”。而“大学生计算机基础网络教学系统管理平台”这个题目，天然能让你把“布置作业 → 提交作业 → 截止提醒 → 教师批改 → 成绩回显”这种业务闭环讲清楚。本文会从项目定位、数据表设计、核心代码实现、常见坑点、答辩技巧这几个角度一路拆完。如果你是刚开始接触前后端分离的 Java 学习者，或者正在为选题发愁，这篇内容应该能让你少走一大截弯路。

1. 项目定位与核心功能拆解

1.1 为什么“SpringBoot + Vue + MySQL”成了毕设的黄金组合

先说结论：这三样技术不是最新最酷的，但对一个需要“一个人从零干完”的教学系统项目来说，它们是性价比天花板。SpringBoot 解决的是“后端怎么跑起来”的问题，内嵌 Tomcat、自动装配、大量 Starter 依赖，省掉了过去 SSM 时代写一堆 XML 配置的麻烦；Vue 解决的是“页面怎么撑起来”的问题，数据绑定、组件化、加上 Element UI，做管理后台基本是拖拽式开发效率；MySQL 则负责把所有业务数据老老实实存住，部署成本低，社区资料多，搜问题一搜一大把。

这类组合之所以特别适合教学平台，还因为它足够符合“前后端分离”的潮流。答辩的时候，老师看到你项目结构是vue-frontend和springboot-backend两个独立工程，天然就有了话题点：谁负责页面、谁负责接口、跨域怎么解决、权限怎么控制。这些问题你只要真的做过一遍，基本都能接住。反观很多 JSP/Servlet 老项目，前端套着模板引擎，逻辑全堆在一个 Servlet 里，答辩时很难讲出系统设计感。

1.2 系统里有哪三类角色，各自在忙什么

一个完整的网络教学平台，最基础的就是“谁在用、拿它干什么”。我通常把它拆成三类角色来设计：

• 学生：登录后看课程公告、下载课件、看视频回放、做在线测验、提交作业、在讨论区发帖。成绩和作业批改结果也要能查询。学生的核心诉求是“别让我绕弯子”，所以学生端首页一定要把“最近课程、最新通知、待办作业”直接甩出来——这个设计细节答辯时特别加印象分。
• 教师：维护课程基本信息，管理课程章节和课件，上传教学视频，布置作业并设置截止时间，批改学生提交内容，维护题库和发布测验。教师端是最能体现系统“管理”价值的部分，权限边界必须明确。
• 管理员：管理教师和学生账号，禁用异常账户，查看登录日志，处理基础数据字典。很多课设会把管理员功能做得特别薄，但我建议至少保留“账号管理和数据统计”，因为这是整张权限图的顶层，老师一定会问“如果学生账号异常你从哪里管”。

我见过一种常见的翻车做法，就是只做了学生端页面，教师端直接用 SQL 改数据，管理员完全没有。这不能说不行，但它把“管理系统”四个字的含金量直接打没了一半。哪怕时间再紧，也老老实实把三种角色的登录入口和首页搭出来。

1.3 功能模块全景与课设取舍建议

基于“大学生计算机基础”这个课程背景，建议模块列表和难度评估如下：

第一眼可能觉得模块有点多，但真实工作量并没有翻倍。关键要学会取舍：资源管理和考试判分是主线，必须完整；数据统计能简则简，别为了画一堆饼图硬上框架。很多代码包喜欢搞很重的可视化大屏，我只能诚实地说，那是花架子。老师问“平台怎么证明有教学效果”，你回答“看每位学生的作业提交状态和测验成绩回溯”就足够了，业务闭环比炫技重要得多。

2. 架构设计与数据模型，从目录结构到表关系

2.1 前后端分离请求链路与基础配置

一个典型请求的走向是这样的：Vue 页面上用户点击按钮 → Axios 发起 HTTP 请求 → 后端 Controller 接收 → Service 处理业务 → Mapper 访问 MySQL → 结果层层返回 → Vue 响应式更新页面。整条链路里三个关键配置必须提前做好：

第一是跨域。前端开发服务器在localhost:5173，后端在localhost:8080，不是同一个源，浏览器会拦截。后端要么开启 CORS，要么前端 Vite 层做代理。我用得最多的是 Vite 代理：开发环境所有/api开头的请求都转发到后端，代码里不用写完整域名，上线后也方便用 Nginx 做反向代理。示例配置：

// vite.config.js server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

第二是统一响应结构。后端接口不要一会儿返回Map、一会儿返回String，建议所有接口都走一个统一包装类：

public class Result<T> { private Integer code; private String message; private T data; // getter/setter 省略 }

好处显而易见：前端 axios 拦截器只需要解析一次code，是 200 就进成功分支，否则弹出message。鉴权过期统一返回 401，前端拦截后跳回登录页。这个习惯我建议从课设就开始养成，真实工作里也是这么玩的。

第三是全局异常处理。用@RestControllerAdvice兜底捕获业务异常、参数校验异常和意外异常，防止一堆堆栈直接暴露给前端。这也属于答辩时的“系统完善性”亮点。

2.2 核心数据库表设计（附表结构）

数据表我建议按下图思路设计，每个模块尽量独立，但又有关联字段：

• sys_user：用户表（学生、教师、管理员都放这，用 role 区分）
• course：课程表
• course_chapter：章节课表
• course_resource：课程资源表（课件、视频、文档）
• homework：作业表
• homework_submit：作业提交表
• exam：测验表
• exam_question：测验题目表
• exam_record：测验记录表（一次交卷一条）
• exam_record_answer：每道题的作答明细（可选，但推荐留）
• discussion_post和discussion_reply：帖子与回复表

几个容易踩的细节我单独说一下。第一，用户表里密码字段不要明文，用 BCrypt 加密后的字符串，长度为 60 左右，所以字段类型建议varchar(100)而不是 32/64，免得后面换加密算法还要改表。第二，题目选项我习惯用varchar(500)存 JSON 数组，例如多选题选项就是["A","B","C","D"]对应的文案数组，后端按 JSON 解析。课设级系统这么做没问题，别为了选项再拆一个option子表，徒增复杂度。第三，所有表都建议加create_time、update_time两个字段，排序、追责、看时间线都用得上。

以作业模块为例，表结构大致是这样的：

CREATE TABLE homework ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL COMMENT '所属课程', title VARCHAR(200) NOT NULL, description TEXT COMMENT '作业要求', deadline DATETIME NOT NULL COMMENT '截止时间', status TINYINT DEFAULT 1 COMMENT '1启用 0停用', create_time DATETIME, update_time DATETIME ); CREATE TABLE homework_submit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, homework_id BIGINT NOT NULL, student_id BIGINT NOT NULL, content TEXT COMMENT '文字内容', file_url VARCHAR(500) COMMENT '附件路径', score DECIMAL(5,2) COMMENT '教师评分', submit_time DATETIME, status TINYINT DEFAULT 0 COMMENT '0未交 1已交 2已批改' );

看到homework_submit.status这个字段没有？它就是整个作业闭环的状态机。学生提交后置 1，教师批改后置 2，同时回写 score。有了状态，前端按钮渲染、后端权限校验都变得非常精确。

2.3 接口设计与统一返回结构

接口路径我建议按“角色 + 资源”来命名，比如：

• POST /api/auth/login：登录
• GET /api/student/course/list：学生获取我的课程
• GET /api/teacher/course/{id}/students：教师查看某课程学生列表
• POST /api/teacher/homework：教师布置作业
• POST /api/student/homework/{id}/submit：学生提交作业
• POST /api/student/exam/{id}/finish：学生交卷

接口名字里直接带上角色，可以实现第一个粗粒度的权限控制，比如学生角色的 Token 访问/api/teacher/**就报“无权限”。这也是答辩时面试官看你代码结构第一眼就会注意到的细节。另外，资源型接口建议把课程 ID 这类业务主键放在路径里，不要用?lessonName=...这种无约束参数去查询，不然容易出现越权问题。比如一个学生传courseId=99就能查不属于自己的课程资源，这就是典型的水平越权。我一般在 Service 层会加一道“当前登录用户是否属于该课程”的校验，这道防线讲出来含金量很高。

3. 关键模块实现：认证、资源、测验、作业、讨论

3.1 基于 JWT 的登录认证与权限控制

前后端分离下，我不想依赖 Session，最常用的就是 JWT。流程是：用户提交账号密码 → 后端校验成功 → 生成包含用户 ID 和角色的 Token 返回前端 → 前端存到本地存储 → 每次请求在 Header 带上Authorization: Bearer <token>→ 后端拦截器校验并解析出用户信息。

核心工具类就是两个操作：生成 Token 和解析 Token。使用io.jsonwebtoken时，密钥要设得足够长，过期时间一般设 24 小时，课设期间别再引入 Redis 管黑名单，不然复杂度上去了。生成后，通过一个ThreadLocal或UserContext把当前用户信息放入上下文，方便在 Service 里随时取。

拦截器里做三件事：

1. 从请求头取 Token，取不到就返回 401；
2. 解析 Token，失败或过期同样返回 401；
3. 从解析结果里读角色，校验访问路径前缀是否匹配。

检查路径前缀可以用一个简单方法，比如判断request.getRequestURI()是否以/api/teacher开头，并且当前角色不为 teacher，就拒绝。这种方式虽然不够优雅，但课设阶段胜在直观、好讲解。进阶一点的方案是自定义@RequireRole("teacher")注解加 AOP 切面校验，在面试时能加分，但代码量会多一些。

需要特别提醒的一点：登录接口、静态文件访问、用户注册（如果开放）以及文件预览路径都要放到放行名单里，否则项目一启动，前端调登录都调不通。我调试时最喜欢看后端日志里那个红色异常，十次有八次是拦截器把不该拦的路径拦了。

3.2 课件/视频/作业附件的上传与管理

这个模块是学生最容易踩坑的，也是答辩老师重点想看的地方。最简单的实现是本地磁盘存储：后端接收MultipartFile，把文件写到配置好的目录，然后数据库里只存相对路径。但有几个坑必须防好。

第一是文件名不要直接存原始上传名。一方面可能包含中文和特殊字符，另一方面存在路径穿越风险。我的做法是用时间戳加短 UUID 重命名，保留原扩展名。第二是文件类型要校验，只允许常见的pdf、ppt、pptx、zip、mp4，解析扩展名时转小写再比较。第三是大小限制，SpringBoot 默认单文件 1MB，不调肯定不够用，需要在配置文件里改：

spring: servlet: multipart: max-file-size: 500MB max-request-size: 500MB

视频播放又是另一个坑。如果直接用http://localhost:8080/files/xxx.mp4给前端，浏览器也许能放，但快进体验很差，因为没实现 Range 请求。课设阶段为了简单，我建议视频采用“前端播放时由后端返回文件流并附带 content-type”，至少保证 Chrome 能拖进度条。要说真正分流播放，那就得上对象存储或流媒体服务，这一步留给后续扩展即可，别在课设里死磕。

前端用 Element Plus 的el-upload时，记得在请求头手动加上 Token，不然后端拦截器直接给你 401。这是联调时最容易碰到的现象：文件明明选好了，一传就被拦截，页面却只报“上传失败”。我当初排查这个问题，来回看了半天才发现是漏了 headers。

3.3 在线测验与自动判分如何闭环

学生端在线测验核心有这几个状态：未开始、进行中、已交卷。交卷动作可以有两种：学生手动点击交卷，或者倒计时结束前端强制交卷。后端设计里，exam_record表存每一次考试记录，字段包含学生 ID、测验 ID、总得分、交卷时间。作答明细表exam_record_answer存每一道题的学生答案和是否得分。

判分逻辑讲清楚，不仅代码好写，答辩也更占优势。单选和判断比较简单，直接比对字符串即可。多选题比较坑，我用的是“完全匹配才得分”策略：学生答案排序后与正确答案排序后的字符串比较，不一致就 0 分。虽然有些心软的老师会觉得部分得分更合理，但课设这么实现更简单、规则明确：

public static boolean checkMultiChoice(String userAnswer, String correctAnswer) { // 答案存形如 "A,B,D" 的字符串 String[] userArr = userAnswer == null ? new String[0] : userAnswer.split(","); String[] correctArr = correctAnswer.split(","); if (userArr.length != correctArr.length) { return false; } Arrays.sort(userArr); Arrays.sort(correctArr); return Arrays.equals(userArr, correctArr); }

交卷的接口要做“幂等”处理：同一名学生同一场考试只能交卷一次。后端收到交卷请求后，先查exam_record是否已存在，存在就拒绝再次提交，防止学生刷新页面或重复点击产生两条记录。顺带还可以做“截止时间”校验，超过时间交卷直接拒绝。这道防线对防止刷分很重要，也能体现你处理并发边界的想法。

题目的前端渲染也不算难。数据里存type字段（1单选、2多选、3判断），通过v-if/v-show切换是显示单选框组还是复选框组。考试页建议用全屏布局，把倒计时固定显示在右上角，交卷前弹确认框，避免学生误触。这些小体验点写进“测试说明”里都是加分项。

3.4 作业布置、提交、评分与状态流转

作业模块比考试更强调状态流转。我再强调一遍它在商业系统中的意义：一个学生作业从“未提交 → 已提交 → 已批改”，反映的是业务闭环。你在实现时把这张状态图刻在脑子里，写代码就不会乱。

教师端布置作业，表单包含标题、内容、截止时间，提交后写入homework表。学生端看到的是“未交/已交”两种状态。点击提交，把文本内容和附件路径写入homework_submit。这里有个细节：每个学生在一份作业下只能有一条提交记录。最简单的做法是给homework_id + student_id建唯一索引，否则高并发下可能出现两条数据。有了唯一索引，后端插入时捕获 DuplicateKeyException，返回“请勿重复提交”。

教师批改时，先按作业查出所有学生的提交记录，再逐个打分。我需要提醒的是，教师在页面上输入分数后，后端更新时要把status从 1 改成 2，而不是只写分数。很多新手把分数写进去了，但状态还停在“已提交”，学生端就会一直显示“待批改”，这种逻辑错误特别容易被答辩老师一针见血地指出来。

还要考虑一个自动化能力：作业截止后，没有提交的学生应该被标为“未提交”，试卷状态自动关闭。后端可以写一个简单的定时任务，每分钟扫一次作业表，把deadline < now的作业置为“已截止”，把所有应交未交的学生生成一条“未提交”记录。定时任务用 Spring 的@Scheduled就能实现，十分钟的事，但在答辩时讲出来，老师会认为你考虑到真实场景了。

3.5 讨论区与通知中心：低代码功能也能做出亮点

讨论区看似简单，但也有可聊的东西。表结构就是帖子表和回复表，学生发帖时传入标题和内容，回复后回写帖子的回复数。回写要在同一个事务里完成，否则极端情况下计数会不准。我习惯把“回复数”作为冗余字段存在帖子表，展示列表时直接查，避免连表 count，这也是业界常见做法。

通知中心更轻，教师发一条，学生首页查最新几条。有一点可以花心思：学生首页默认展示“最近课程 + 最近通知 + 待办作业数”，这种感觉上很像一个真实教学平台的工作台。而工作台这种布局，在你用 Vue 写起来也快，数据无非就是三个接口汇总。

4. 本地运行、打包部署与避坑手册

4.1 开发环境准备与前后端联调配置

推荐环境组合给一个我实测很稳的版本：JDK 8（SpringBoot 2.7.x）、Maven 3.6+、Node.js 16/18、MySQL 5.7 或 8.0。JDK 和 SpringBoot 版本尽量配对，SpringBoot 3.x 至少要求 JDK 17，如果同学们电脑上是 JDK 8，就别强行升到 3.x，否则一堆依赖不兼容。

后端启动前要做三件事：导入 SQL 脚本、配置application.yml里的数据库账号密码、确认端口。使用 Maven 启动：

mvn spring-boot:run

前端进入项目目录后先安装依赖，再启动开发服务：

npm install npm run dev

联调时，前端所有请求走/api，由 Vite 代理到后端。上线部署时，后端打 jar 包，前端npm run build生成dist目录，然后用 Nginx 把dist作为静态资源目录，再把/api反向代理到后端端口即可。我把这个流程完整跑通后，才觉得“前后端分离部署”这个概念真正落地了，而不是只会在本地开两个终端。

4.2 常见报错与排查思路速查

这里我最想强调“看日志”。经常有同学报“接口报错”，贴图只有前端红字，后端日志一字没截。排查任何接口问题，先看后端控制台异常栈，99% 的答案就在日志里。课设阶段的后端错误基本都是字段名、SQL语法、空指针这三类，日志一翻全明白。

4.3 答辩时怎么讲这个项目才不吃亏

很多同学做完项目，只会说“我用了 SpringBoot 和 Vue”，这等于什么都没说。我建议把答辩思路按照“业务 → 设计 → 实现 → 异常处理”四段来准备。先讲清楚系统给谁用、解决什么问题；再讲模块划分和数据表如何设计；然后挑一两个模块展开，比如在线考试判分逻辑、文件上传的校验与存储；最后主动提两三个你处理过的异常场景，比如重复提交作业、超时交卷、文件大小超限。这三条任何一条讲清楚，都比念一遍 PPT 有说服力。

如果代码不是你亲手写的，是参考项目拿过来学习的，我建议至少做一件事：把数据库表关系画一遍，再把每个表对应的 Controller 和 Service 找到，默写一遍核心 Service 的业务流程。你不能在答辩时只说“我负责前端页面”，那等于直接把项目的含金量扔了。真实工作里也一样，能讲清楚一个模块的完整数据流，才是真正参与过这个项目的人。

5. 个人实操体会

如果是我自己动手去实现这套系统，我会优先把作业和考试两个模块打通，因为它们才是教学平台的核心价值。资源下载和讨论区可以放到第二梯队去做。建表时我会先画状态流转图，先想清楚“一条作业记录从生到死经历哪些状态”，再回头落表。这样做的好处是，写 Service 的时候思路极其清晰，每一层校验对应一个状态，不会出现“写着写着发现少个字段又要回表加”的尴尬情况。

最后分享一个小技巧：用户表里加一个role字段还不算完，最好在登录返回的 JSON 里同时带上角色名称和可访问的路由前缀，前端路由守卫可以根据这个来控制菜单显示。学生登录看不到“作业管理”菜单，教师登录看不到“账号维护”菜单，这样一个细节会让整个系统的权限设计立刻完整起来。真到了答辩现场，你直接点开登录页演示三种账号登录，画面切换带来的实际效果，比任何图表都更能说明问题。这套平台改造成其他学科也很快，替换课程表里的种子数据，再改改资源分类，一个通用在线教学平台就出来了。核心价值永远在模块之间的数据流转和状态控制里，把这个吃透，你就真正掌握了一个中型管理系统最通用的底层逻辑。