企业官网建设流程全解析

做Java Web方向的项目，尤其是毕业设计或课程设计，我见过太多自嘲“增删改查”的管理系统了。但今天要把“师生共评作业管理系统”这个项目拿出来认真聊一聊，因为这个标题里有两个很关键的字：共评。它不是一个老师布置、学生提交、老师一个人改分的单向流程，而是引入了学生互评机制，让教师和学生共同参与作业评价。项目的技术栈也很主流——SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0，前后端完全分离，源码里还带了配套文档。这个组合，无论是用来做毕设、课设，还是作为想系统入门前后端分离开发的练手项目，都非常合适。

接下来我会把这个项目从设计思路、数据库设计、后端核心逻辑、前端工程化，再到部署排错，完整地拆开讲一遍。文中所有实现方案都来自我实际跑通项目的经验，不是停留在概念层面。你可以直接照着做，也可以根据自己的业务场景去改。

1. 项目整体设计与思路拆解

1.1 这个系统到底解决了什么问题

先聊一个教学场景。传统的作业管理，尤其在大班教学下，问题非常明显：作业通过邮件、微信群、网盘各种渠道收，文件命名五花八门，老师下载下来整理就要花半天；评分更是纯体力活，一份一份看、一份一份写评语，工作量巨大；学生收到分数后只能看个数字，不知道为什么扣分，也不知道别人做得好的地方在哪里，学习反馈几乎为零。

“师生共评”给了一个新的解题角度。学生交完作业后，除了教师评分，还要由同班同学进行互评打分和点评。这样做至少有四个直接好处：

• 教师只需要点评部分作业或者对学生评分做最终确认，把批量初评的工作分摊出去，负担大幅下降；
• 学生在看别人作业和写评语的过程中，被迫去对比、去思考“如果我做这个题目，哪里会没想到”，学习效果反而更深；
• 评分不再是老师一家之言，权重可以配置，最终成绩更加多元、更让人信服；
• 作业数据全部系统化沉淀，成绩导出、课程分析都有原始数据支撑。

这个系统围绕三类角色展开，权限边界非常清晰：管理员管人和管课程，教师管作业、管评分、管看统计，学生管提交、管互评、管查分。整个业务流程是一条清晰的状态链路：教师发布作业 → 学生提交作业 → 作业截止 → 学生互评 → 教师评分 → 系统按权重汇总 → 学生查看成绩。

1.2 技术栈选型背后的考量

为什么是这个组合？我可以负责任地说，这个技术栈是现阶段的“最优性价比组合”，每一层都是仔细权衡过的。

SpringBoot2而不是SpringBoot3，是目前很多教学资料、企业存量项目仍然采用SpringBoot2的原因。SpringBoot2在2.7.x版本已经非常成熟稳定，网上能搜到的解决方案、异常排查案例也最多，新手遇到问题基本都能搜到答案。SpringBoot3强依赖JDK17和Spring6，虽然更新，但版本升级会连带很多依赖兼容问题，对一个管理系统的毕业设计来说没必要冒这个险。

Vue3 + Vite，这是目前前端的主流方向。Vue3的组合式API（Composition API）写起来比Vue2的选项式API更灵活，而且Vite的开发服务器启动速度非常快，HMR（热更新）体验比Webpack时代舒服太多。配合Element Plus组件库，做后台管理系统效率非常高。

MyBatis-Plus，简单说就是MyBatis的增强版。它保留了你手写SQL的能力，但把单表CRUD、分页查询、条件构造这些高频操作全部内置了。开发效率极高，省下的时间可以用来专注业务逻辑——比如这道题核心的“共评”评分规则。

MySQL8.0，相比5.7，性能和默认字符集支持都更好，也是当前新项目的主流选择。只要注意驱动配置里的时区、认证插件这些细节，用起来非常顺手。

这个组合唯一要提醒的是：MyBatis-Plus虽然省事，但你不能完全不会SQL。遇到多表联查、复杂统计，最终还是得手写XML。所以项目里我会把“MyBatis-Plus处理单表、XML处理复杂查询”作为原则，两条路都带你们走一遍。

2. 数据库设计与后端核心逻辑实现

2.1 表结构怎么设计才不返工

我见过太多人在这个环节翻车，拿到题目就写代码，结果表结构设计得一塌糊涂，后期到处打补丁。这个系统我建议至少设计下面这几张核心表：

这里有一个最容易犯的设计错误：试图把教师评分和学生互评塞进同一张表，或者一个字段塞多个值。正确做法是把“提交”和“评价”彻底分开。

submission表记录“学生交了什么东西”，其中teacher_score存放教师评分，final_score放最终加权汇总分；每次评价则单独放review表，一条提交记录可以对应多条学生互评记录。这样，一个作业的评分历史被完整保留，以后想做“成绩修改留痕”或者“权重调整重新算分”都非常方便。

为防止同一个学生对同一个作业重复评价，可以在review表加一个唯一索引uk_assignment_reviewer（assignment_id + reviewer_id）。这是一个性价比极高的细节，一行索引声明就能解决业务上的重复提交问题，比在代码里先查再插靠谱得多。同理，submission表可以对(assignment_id, student_id)加唯一索引，从数据库层面拦住重复提交作业。

2.2 SpringBoot2 + MyBatis-Plus 集成配置要点

依赖坐标不啰嗦，直接上核心配置。MyBatis-Plus在SpringBoot2项目中引入mybatis-plus-boot-starter即可，版本建议选3.5.x系列，功能和稳定性都不错。要注意MyBatis-Plus 3.5.3以上的分页插件写法变了，很多人还拿着网上老教程的PaginationInterceptor抄，结果直接报错。新版标准配置是这样的：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); // DbType.MYSQL 告诉拦截器当前数据库类型，生成正确的分页语句 interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

请注意，这个MybatisPlusInterceptor是MyBatis-Plus 3.4.0之后引入的拦截器体系，替代了旧版的PaginationInterceptor。如果你用的是老版本依赖，分页插件类名找不到，多半就是版本不匹配。

然后是application.yml里几个必填配置：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/homework_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: your_password mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml global-config: db-config: id-type: auto

注意几个点。第一，MySQL8.0的驱动类名是com.mysql.cj.jdbc.Driver，不是老的com.mysql.jdbc.Driver。第二，URL里必须带serverTimezone=Asia/Shanghai，否则会报时区错误。第三，allowPublicKeyRetrieval=true是MySQL8.0默认认证插件caching_sha2_password下常见问题的一个解法，等你们实际部署时一定会遇到，这里先留个印象。

实体类设计方面，建议统一继承一个BaseEntity，把id、createTime、updateTime这些公共字段放在里面。配合MyBatis-Plus的自动填充功能，插入和更新时不需要手动维护时间字段：

@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } }

2.3 师生共评核心逻辑的实现思路

整个系统里最有技术含量的部分，不是登录注册，而是评分状态的流转和最终成绩的计算。

先给作业定义状态。我的做法是在assignment表加一个status字段，用整数表示：0-草稿、1-已发布（学生可提交）、2-已截止（提交关闭，互评开启）、3-已归档（评分为最终值，学生只能查看）。每次操作前，第一步永远不是“执行操作”，而是“校验当前状态和操作是否匹配”。比如学生提交作业，必须校验作业状态为1；学生互评，必须校验作业状态为2；教师评分，必须校验作业状态大于等于2。这个约束用代码写清楚，业务就不会乱。

然后是评分权重的设计。我这里提供一种可配置方案：在系统里预置权重常量，比如教师评分占60%，学生互评平均分占40%。这个比值放在配置文件里，以后要调可以直接改配置而不用改代码。最终成绩计算逻辑如下：

public BigDecimal calcFinalScore(BigDecimal teacherScore, List<BigDecimal> studentScores) { if (teacherScore == null) { throw new BusinessException("教师尚未评分，不能计算最终成绩"); } // 学生互评均分，保留两位小数 BigDecimal avgStudentScore = studentScores.stream() .reduce(BigDecimal.ZERO, BigDecimal::add) .divide(BigDecimal.valueOf(studentScores.size()), 2, RoundingMode.HALF_UP); // 教师权重0.6，学生互评权重0.4 BigDecimal finalScore = teacherScore.multiply(new BigDecimal("0.6")) .add(avgStudentScore.multiply(new BigDecimal("0.4"))) .setScale(2, RoundingMode.HALF_UP); return finalScore; }

这段逻辑用BigDecimal而不是double或float是必须的，成绩计算最忌讳浮点数精度误差。同时在触发“教师评分完成”这个动作时，用@Transactional包裹，一次事务内完成：更新submission的teacher_score → 汇总review表学生评分 → 计算final_score → 更新submission状态与final_score。任何一步失败，全部回滚，保证成绩数据永远处于一致状态。

接口层面，学生提交作业要处理文件上传。这里给一个后端接收上传文件的参考写法：

@PostMapping("/submit") public Result submit(@RequestParam("assignmentId") Long assignmentId, @RequestParam("file") MultipartFile file, @RequestParam("content") String content) { // 1. 校验作业是否可提交（状态=1） // 2. 文件大小/类型校验 if (file.isEmpty() || file.getSize() > 10 * 1024 * 1024) { return Result.error("文件不能为空且大小不能超过10MB"); } // 3. 存储文件，建议按日期分目录 String filePath = uploadFile(file); // 4. 插入提交记录 return Result.success(); }

文件存储本地磁盘时有个细节很多人会踩坑：存到项目相对路径下，打包部署后重启服务文件就丢了，或者路径变得很诡异。我的建议是配置一个绝对路径存储目录，比如/data/homework/files/，通过配置项注入，不要写死。

3. Vue3 前端实践与前后端联调

3.1 Vite工程化搭建与基础设施封装

前端部分我用的Vue3标准姿势：Vite + Vue3 + vue-router + Pinia + Element Plus + Axios。这里特别说明一下，状态管理建议直接用Pinia，它是Vue3官方推荐的新一代状态库，API比Vuex简洁太多，没有那么多历史包袱，用起来非常顺手。

创建项目直接跑官方脚手架：

npm create vite@latest homework-front -- --template vue

然后安装依赖：

cd homework-front npm install npm install element-plus axios pinia vue-router@4 @element-plus/icons-vue

工程目录结构我按模块划分，方便后续维护：

src/ ├── api/ # 接口请求封装，按模块拆分（user.js、course.js、assignment.js） ├── components/ # 通用组件 ├── views/ # 页面组件 │ ├── teacher/ # 教师端页面 │ ├── student/ # 学生端页面 │ └── admin/ # 管理端页面 ├── stores/ # Pinia状态 ├── router/ # 路由配置 ├── utils/ # axios实例、工具函数 └── App.vue

axios实例封装是前端基础设施里最重要的一环。统一接口前缀、统一token注入、统一错误提示，能把大量重复代码收敛掉：

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '../router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：自动携带token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) // 响应拦截器：统一处理业务码和登录过期 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error(error.message || '网络异常') return Promise.reject(error) } ) export default request

这里有个后端设计上的配套要求：所有后端接口统一返回{ code, message, data }结构，前端拦截器只认这个结构。这套规范要在项目开始时就和后端约定好，而不是等联调了再改。

3.2 路由权限控制与动态界面

管理系统的权限控制，分为“路由级控制”和“按钮级控制”两层，但很多初学者只做了前端隐藏，这是远远不够的，后端的每个接口都必须再做一次角色校验。前端的隐藏只是让界面不显示，后端的校验才是真正的安全防线。

前端的路由权限做法是：在路由meta上声明允许的角色，然后在全局前置守卫里做判断：

// 路由配置示例 { path: '/teacher/assignment', name: 'TeacherAssignment', component: () => import('../views/teacher/AssignmentManage.vue'), meta: { roles: ['TEACHER'], title: '作业管理' } } // 路由守卫 router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') const role = localStorage.getItem('role') if (!token && to.meta.roles) { next('/login') return } if (token && to.meta.roles && !to.meta.roles.includes(role)) { next('/403') // 统一403页面 return } next() })

前端根据角色渲染侧边栏菜单，用角色字段过滤菜单数组即可。登录接口返回用户信息时，后端应该把role、username、realName等一并返回，前端存好之后用来驱动界面展示和路由判断。

3.3 前后端联调的坑：跨域、时间格式与文件上传

本地开发最常遇到的就是跨域问题。解决的规范姿势是在Vite配置文件里设置代理，而不是在后端开启CORS大开门：

// vite.config.js export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

这样前端请求/api/xxx时Vite会把请求转发到后端http://localhost:8080/api/xxx，浏览器视角里是同一个源，跨域问题直接消失。

时间格式问题也值得提前写规范。后端返回LocalDateTime默认序列化成数组或者带T的ISO字符串，前端处理起来很痛苦。建议后端配置统一的时间格式化，返回yyyy-MM-dd HH:mm:ss。在SpringBoot2中配置Jackson：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai

这样所有接口的时间字段都统一格式，前端直接展示，不需要再写转换函数。这是一个非常小但体验提升明显的配置。

文件上传还有一个小坑：Element Plus的el-upload组件默认的action路径不走axios实例，所以它发请求时不会自动携带token，也不会走你的统一错误拦截。使用时要手动设置headers或者在http-request里自定义上传逻辑，让上传走我们封装好的axios方法。如果你不做这一步，就会发现“登录后刷新页面再传文件”，后端报401未授权，原因就在这里。

4. MySQL8.0部署环境与常见问题排查实录

4.1 MySQL8.0环境准备与项目初始化

部署环境这块非常容易被轻视，但实际上很多项目卡壳就卡在这一步。MySQL8.0的安装方式这里不展开（Windows用zip免安装版或者安装包，Linux用yum/apt源或者docker都很方便），重点说项目连接时一定会碰到的配置。

数据库初始化建议手写一个init.sql，包含建库、建表、初始数据（管理员账号、测试教师和学生账号）。这么做的好处是可复现。不要在服务器上手动一条条建表，也不要指望MyBatis-Plus自动建表——它的schema自动初始化能力并不完善，管理表结构这件事老老实实用SQL脚本，是更稳妥的工程习惯。

初始化脚本开头固定写三样东西：

CREATE DATABASE IF NOT EXISTS homework_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE homework_system; SET NAMES utf8mb4;

注意，字符集必须用utf8mb4而不是utf8。MySQL里的utf8实际上是阉割版，最多只能存3个字节的字符，像某些生僻字和emoji会存不进去报错，而utf8mb4是真正的完整UTF-8支持。

4.2 高频报错与解决方法速查表

我在部署和运行过程中整理了一张报错速查表，覆盖了学生问我的90%以上的问题：

这里面最典型的是Vite代理和后端路径前缀配合的问题。我要求前后端都要有统一前缀/api，后端所有Controller的@RequestMapping("/api/...")，前端代理转发/api，这样路径语义一致，排查起来非常省力。

4.3 我实际踩过的一些独家坑

最后分享几个常规文档里不会写的经验。

一是后端打包部署时，SpringBoot默认使用内嵌Tomcat，打包成jar后直接java -jar运行很爽，但你要确保文件上传目录是绝对路径，并且部署时给这个目录可写权限。很多人在Windows本地跑得好好的，一到Linux服务器上传文件就报FileNotFoundException，多半就是上传目录没有创建或者权限不对。

二是前后端分离部署时，前端npm run build产出的dist目录里，静态资源路径要配置成相对路径或者通过环境变量控制。很多人把base设置成了/，结果部署到子路径下所有资源全部404，白屏半天找不出原因。Vite里可以配base: './'解决。

三是这类系统的数据库设计文档、接口文档一定要跟着项目更新。我自己的习惯是用一个docs/目录，里面放需求说明.md、设计文档.md、部署手册.md，每完成一个模块就随手更新对应部分。等最后写毕设论文或者项目答辩时需要材料，这些就是现成的素材，不用重新回忆。

四是线上环境务必把application.yml里的密码、密钥用环境变量覆盖，不要写死在配置里。这个习惯越早建立越好。

我个人在实际操作中的体会是，像“师生共评作业管理系统”这类业务，最难的部分从来不是某个技术难点，而是把角色、状态、权限理清楚，并且用代码把这些约束落地。技术栈只是工具，真正值钱的是你对业务的理解和工程化的思维。如果照着上面的思路把这套系统完整地写下来，收获的绝对不止是一个能跑的demo，而是一整套“如何拆解一个业务需求并落地成系统”的方法论。以后再做任何管理系统，你都能用同一套框架去思考。