1. 项目概述与核心需求拆解说起来高校教务评教系统算是校园信息化建设里的“常青树”项目了。每学期末学生给任课老师打分教务处汇总成绩、分析反馈这套流程几乎每个高校都在跑。但真正落地过一个评教系统的人都知道这里面坑不少评教时间集中、并发量不低学生对指标理解不一致教务处要的统计报表维度又多而且不同学校的评教规则差异很大——有的学校要按课程评有的要按老师评还有的是课程老师混合评。如果系统设计得不够灵活光需求沟通就能让人崩溃。我用 SpringBoot Vue 这套组合做了一个高校教务评教系统前后端分离架构覆盖了从学期初的评教任务配置到学期末学生评教、教师查看结果、教务处统计分析的全流程。系统支持管理员动态配置评教指标和评分权重评教任务可以按院系、年级、课程类型分别发布学生端每次评教逐题打分提交后由后端汇总生成多维统计报表支持按教师、按课程、按院系三个维度钻取查看。这篇内容适合正在做毕业设计或者刚进公司需要快速上手全栈项目的同学也适合学校里负责教务信息化的老师作为系统选型参考。我会把整体设计思路、关键表结构、核心接口实现、前端页面拆解以及那些只有实际联调才会遇到的坑都尽量写清楚。你能照着这篇文章把系统搭起来也能从中理解为什么评教系统要这么设计而不是一上来就闷头写代码。2. 技术选型思路为什么是 SpringBoot Vue2.1 技术栈选型的底层逻辑前后端分离现在已经是大势所趋但具体选什么框架还是得从项目实际出发。后端选 SpringBoot理由很实在第一Java 生态在高校、政企这类场景里认可度极高后续要对接统一身份认证、数据上报这类系统SpringBoot 的兼容性比 Node.js 或 Python 好太多第二SpringBoot 的自动配置大大减少了 xml 配置的繁琐程度一个 SpringBoot 项目起步也就是几分钟的事第三教务评教系统里涉及到权限控制、事务管理、数据校验、定时任务这类通用能力SpringBoot 的生态组件太成熟了Spring Security、MyBatis-Plus、Quartz 全都是现成的轮子。前端选 Vue 也很好理解。Vue 的学习曲线在三大框架里最平缓稍微懂点 HTML、CSS、JavaScript 就能上手而且 Vue 的响应式数据绑定和组件化开发方式非常适合评教系统这种“多个表单页面 多个数据展示页面”的项目形态。管理端和教师端基本都是表格、表单、弹窗之类的 CRUD 页面用 Vue Element Plus 开发效率极高学生端如果用 PC 浏览器访问也完全没问题如果想适配手机端稍作调整或者另做一套移动端页面也方便。注意如果项目要求学生用手机微信里直接访问前端建议用 Vue 3 Vant 单独做一套移动端 H5而不是直接把 PC 管理端的页面塞到手机里。两套前端共用同一套后端接口工作量增加不大但体验差别很明显。2.2 竞品方案对比参考我整理了几个常见替代方案方便你根据自己的实际情况选型技术方案优势劣势适用场景SpringBoot Vue本项目生态成熟、招人容易、前后端分工清晰前后端联调成本略高大多数高校、企业管理系统Django Vue开发效率高、自带 admin 后台国内 Java 运维体系不一定适配团队以 Python 为主的小型项目Node.js Express Vue全栈都用 JavaScript语言统一事务处理、并发稳定性不如 SpringBoot团队小、迭代快的原型项目纯 JSP / Thymeleaf 单体部署最简单一个 war 包搞定前后端耦合严重后期维护性差老系统改造前的过渡方案我最终选了第一个方案。评教系统说到底是个业务系统核心价值在业务逻辑的准确性和数据统计的可靠性用最稳妥的 SpringBoot 生态来做最合适。前端页面量不小但是每个页面复杂度有限用 Vue 开发效率很高。3. 系统整体架构与功能模块设计3.1 系统架构分层拆解整个系统采用经典的前后端分离三层架构前端展示层Vue 3 Element Plus Pinia Axios负责页面渲染和用户交互。管理端、教师端、学生端基于同一套代码通过路由和权限控制区分避免维护三套前端工程。后端服务层SpringBoot 作为主体框架按业务拆分为 controller、service、mapper 三层。Controller 层负责接收请求和参数校验Service 层处理具体业务逻辑和事务Mapper 层通过 MyBatis-Plus 操作数据库。数据存储层MySQL 8.0 存业务数据Redis 做缓存和防重复提交的令牌存储。工作量不重不需要引入微服务和消息队列单机部署完全够用。各层之间通过标准 RESTful API 通信用 JSON 格式传输数据JWT 做身份认证。每个请求都会经过拦截器校验 token再根据用户角色判断接口访问权限。3.2 功能模块规划系统的功能模块我拆成了六个大块用户管理模块学生、教师、管理员三类用户的账号管理。账号由管理员统一导入或单个创建初始密码统一设置支持导入 Excel 批量创建账号这功能对教务处来说非常实用——每学期新生入学、新教师入职都需要批量开账号。基础数据模块学院、专业、班级、课程的维护。课程要和授课教师做关联一门课程可能由多个教师分段授课这种多对多的关系在评教任务配置时要考虑进去。评教配置模块管理员配置评教指标、创建评教任务。指标支持一级分类和具体题目两级结构每道题有对应的评分区间和权重。评教任务要指定参与对象哪些学生、被评对象哪些教师/课程、评教周期。学生评教模块学生在任务周期内对待评教的课程和教师进行打分可提交文字评价和建议。提交后允许在截止日期前修改一次超过截止日期则锁定不可修改。评价查询模块教师端能查看自己课程的学生评分汇总及文字反馈管理员能看到全校的评教数据支持按院系、按课程、按教师筛选和导出 Excel 报表。系统管理模块管理员改密码、重置用户密码、日志查看、数据备份等基础功能。3.3 角色权限矩阵功能模块管理员教师学生用户管理完全操作查看个人信息查看个人信息基础数据管理完全操作查看不可见评教任务配置创建/发布/停用不可见查看待评任务提交评教不可操作不可操作打分/提交/修改查看评教统计全校所有数据仅本人课程数据不可见系统管理完全操作不可见不可见这套权限矩阵在实际开发中通过后端接口级权限校验实现光靠前端控制是不够的。理论上前端页面隐藏了菜单但用户直接拿接口地址拼接请求就能绕过前端所以 SpringBoot 后端必须做角色校验配合拦截器。4. 数据库表结构设计与核心算法4.1 核心数据表设计评教系统的数据库设计是整个项目的重中之重。表设计得合理后面写代码就顺畅表设计得不好后面每加一个需求就要改表结构牵一发动全身。我花了不少时间在表设计上最终核心表如下用户表 t_user字段名类型说明idbigint主键usernamevarchar(50)学号/工号passwordvarchar(200)BCrypt 加密后的密码real_namevarchar(50)真实姓名role_typetinyint1-学生2-教师3-管理员dept_idbigint所属院系statustinyint1-正常0-禁用教师授课表 t_teacher_course字段名类型说明idbigint主键teacher_idbigint教师用户IDcourse_idbigint课程IDclass_idbigint班级IDsemestervarchar(20)学期如 2024-2025-1这个表非常关键它是连接学生、教师、课程三者的桥梁。学生根据所在班级关联到授课记录从而确定自己需要评哪些教师和课程。评教指标表 t_evaluation_indicator字段名类型说明idbigint主键categoryvarchar(50)指标分类如教学态度、教学内容、教学效果contentvarchar(500)具体题目内容score_typetinyint1-五分制2-百分制3-等级制sort_orderint排序号评教任务表 t_evaluation_task字段名类型说明idbigint主键task_namevarchar(100)任务名称start_timedatetime开始时间end_timedatetime结束时间statustinyint0-未开始1-进行中2-已结束target_typetinyint1-评教师2-评课程3-综合评教答案表 t_evaluation_answer字段名类型说明idbigint主键task_idbigint评教任务IDstudent_idbigint学生IDteacher_course_idbigint授课记录IDindicator_idbigint指标IDscoredecimal(5,2)得分comment_texttext文字评价4.2 评教总分汇总的加权算法评教总分不是把所有题目得分简单相加取平均而应该按分类加权计算。比如教学态度类题目共 3 题占总分权重 30%教学内容类题目共 4 题占总分权重 40%教学效果类题目共 3 题占总分权重 30%。这种情况下单题得分要先按分类聚合再乘上分类权重最后合计成百分制总分。计算公式如下总分 Σ(该分类题目平均分 / 该分类满分 * 100 * 该分类权重)举个例子假设教学态度分类下有 3 道题每题满分 5 分学生实际打了 45413 分则该分类平均分为 13/3≈4.33 分换算成百分制为 4.33/5×10086.6 分该分类权重为 30%则计入总分为 86.6×30%25.98 分。三个分类都这样计算后加总得到最终百分制评分。如果一个教师被 100 个学生评教最终得分由 100 份评教结果取平均。这个算法我在实现时做成了后端一个独立工具类ScoreCalculator是为了保证同一套算法在所有场景中都被一致使用——学生端实时预览、教师端个人统计、管理员端全校报表全都调它避免多处实现导致口径不一致。4.3 防重复提交的幂等设计评教系统最容易出的故障就是学生点提交时网络卡顿于是又点了一次结果生成两条评教记录评分权重被重复计算。我在后端做了基于 Redis 的幂等处理核心逻辑学生提交评教时后端先去 Redis 查询taskId:studentId:teacherCourseId这个键是否存在。如果不存在说明是第一次提交允许写入并设置该键过期时间设为任务截止时间如果存在说明已经提交过直接返回“请勿重复提交”的提示。业务数据写入数据库后如果事务提交成功Redis 里的键就作为已验证标记继续保留如果数据库写入失败删除这个键让学生可以重新提交。同时数据库层面给t_evaluation_answer表的(task_id, student_id, teacher_course_id, indicator_id)四元组加上唯一索引双保险。实测压测环境下 200 个并发请求同时提交同一份评教数据库记录始终只有一份。5. 后端关键实现从接口到业务的落地过程5.1 项目初始化与依赖配置SpringBoot 项目我用的是 2.7.x 版本这个版本稳定性和兼容性都比较好不要一上来就追最新版本有些第三方组件还没适配就有得折腾了。核心依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version4.4.0/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency这里有几个实际经验一是 MyBatis-Plus 版本别和 SpringBoot 差太多3.5.3 配 2.7.x 是经过实践验证的稳定组合。二是 JWT 选com.auth0这个库而不是io.jsonwebtoken前者 API 更简洁代码量少很多。三是 Redis 用 Spring Data Redis 的StringRedisTemplate就够了不需要引入 Redisson 那么重的东西。5.2 统一返回结构与全局异常处理接口返回格式必须统一否则前端处理逻辑会很痛苦。我定义的统一返回结构是public class ResultT { private Integer code; // 200 成功500 服务器异常401 认证失败403 无权限 private String message; private T data; }全局异常处理用RestControllerAdvice注解实现。业务异常比如评教任务已截止抛出BusinessException由全局处理器统一捕获并返回友好提示参数校验异常由MethodArgumentNotValidException处理器捕获逐条返回具体错误信息。未捕获的 Exception 统一返回“系统繁忙请稍后重试”避免把内部错误信息直接暴露给前端。注意异常处理一定要把具体的 error 信息打印到后端日志里但返回给前端的信息要友好化。否则出了 bug 你连日志都没有只能前端一句“系统异常”排查全靠猜。5.3 鉴权与拦截器实现前端登录成功后拿到 JWT token后续每个请求都要在 header 里带Authorization: Bearer token。后端写一个拦截器统一校验public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或登录已过期); } String jwt token.substring(7); // 解析token验证签名和有效期 DecodedJWT decoded JWT.require(Algorithm.HMAC256(secret)) .build().verify(jwt); // 将用户ID和角色存入request attribute后续controller直接获取 request.setAttribute(userId, decoded.getClaim(userId).asLong()); request.setAttribute(roleType, decoded.getClaim(roleType).asInt()); return true; } }角色权限校验我用自定义注解RequireRole配合 AOP 实现。在需要限制权限的接口上标注注解比如管理员才能调用的接口标注RequireRole(role 3)AOP 切面从 request attribute 里取出当前用户角色做比较不匹配直接抛出 403 异常。这样比在 controller 里写一堆 if else 优雅得多也符合开闭原则。5.4 学生评教提交接口的实现细节学生评教提交是系统核心接口也是并发压力最大的接口。前端会一次性提交该学生所有待评课程的评分数据。请求体格式如下{ taskId: 12, items: [ { teacherCourseId: 56, scores: [ { indicatorId: 1, score: 5, comment: 讲解透彻 }, { indicatorId: 2, score: 4, comment: } ] }, { teacherCourseId: 58, scores: [ { indicatorId: 1, score: 5, comment: } ] } ] }后端处理逻辑分四步第一步校验任务状态。查询任务是否存在当前时间是否在开始和结束时间区间内。如果任务还没开始或已经截止直接拒绝提交。第二步校验评教对象。遍历 items 里的 teacherCourseId确认这些授课记录在当前任务内确实属于该学生需要评教的范围防止越权提交不属于自己的评教对象。查数据库确认学生所在班级与教师课程表的 class_id 匹配。第三步幂等检查。按taskId studentId teacherCourseId查 Redis 和数据库判断是否已提交。第四步事务写入。在Transactional方法中批量插入评教答案记录。这一步必须使用事务保证一个教师的所有评分记录要么全部写入成功要么全部失败不能出现写了一半的情况。整个接口要控制在 200ms 内完成所以 SQL 要用批量插入而不是循环单条插入。MyBatis-Plus 提供了saveBatch方法可以直接使用底层是合并成一个 insert 语句的批量执行性能提升明显。5.5 教师端个人评教统计报表教师端要展示的是“我教的每个班、每门课的评分情况”。核心 SQL 按授课记录分组聚合SELECT tc.id AS teacher_course_id, c.course_name, cl.class_name, ROUND(AVG(a.total_score), 2) AS avg_score, COUNT(DISTINCT a.student_id) AS student_count FROM t_teacher_course tc LEFT JOIN t_course c ON tc.course_id c.id LEFT JOIN t_class cl ON tc.class_id cl.id LEFT JOIN ( SELECT teacher_course_id, student_id, SUM(score) AS total_score FROM t_evaluation_answer GROUP BY teacher_course_id, student_id ) a ON a.teacher_course_id tc.id WHERE tc.teacher_id #{teacherId} AND tc.semester #{semester} GROUP BY tc.id, c.course_name, cl.class_name;这段 SQL 的核心是用子查询先把每个学生对每门课的总分算出来再对总分取平均得到最终均分。如果不加子查询直接对明细行做 AVG把每个题目的得分都当独立记录处理算出来的均分语义就不正确——一个学生评了 5 道题他的打分权重会被放大 5 倍最终结果和真实平均分严重偏离。这个问题在实际开发中非常容易踩写 SQL 时务必想清楚聚合维度。6. 前端工程化实践Vue3 落地实录6.1 项目创建与目录结构前端使用 Vue 3 Vite Element Plus Pinia Vue Router Axios 的组合。用 Vite 而不是 Vue CLI 创建项目启动速度和热更新体验是 Vite 碾压级的优势。项目目录结构按模块划分src/ ├── api/ # 接口请求封装 │ ├── auth.js │ ├── evaluation.js │ ├── user.js │ └── statistics.js ├── assets/ # 静态资源 ├── components/ # 公共组件 │ ├── Pagination.vue │ ├── UploadExcel.vue │ └── ScoreRadio.vue ├── router/ # 路由配置 │ └── index.js ├── stores/ # Pinia 状态管理 │ ├── user.js │ └── app.js ├── views/ # 页面组件 │ ├── admin/ # 管理员端页面 │ ├── teacher/ # 教师端页面 │ └── student/ # 学生端页面 └── utils/ # 工具函数 ├── request.js # axios 封装 └── auth.js # token 管理6.2 Axios 请求封装与拦截器Axios 封装是整个前端架构的地基封装得好了平时写页面非常舒服封装得不好每个页面都要重复写一堆错误处理代码。我的封装思路如下// utils/request.js import axios from axios import { ElMessage } from element-plus import { useUserStore } from /stores/user import router from /router const request axios.create({ baseURL: /api, timeout: 15000 }) // 请求拦截器自动携带token request.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer ${userStore.token} } return config }) // 响应拦截器统一处理错误码 request.interceptors.response.use( response { const res response.data if (res.code 200) { return res.data } if (res.code 401) { // token过期清除本地状态跳转登录页 useUserStore().logout() router.push(/login) return Promise.reject(new Error(登录已过期)) } ElMessage.error(res.message) return Promise.reject(new Error(res.message)) }, error { ElMessage.error(网络请求异常请稍后重试) return Promise.reject(error) } )6.3 学生端评教页面实现学生端评教页面是整个系统交互最复杂的页面。每个学生有多门待评课程每门课程包含多个评分指标指标又分布在多个分类下。我的实现方式是左侧显示待评课程列表点击某个课程后右侧展示该课程的评分表。评分表用动态渲染实现点击课程后调接口获取该课程的评分指标然后按分类分组渲染。每道题是一个评分单选组件使用 Element Plus 的el-rate组件设为五分制下方预留文字评价输入框。学生滚动到底部还有一个总分实时预览区域完整走一遍评分计算流程——这样学生能看到的最终分数就是提交后的真实分数不会出现预览 95 分提交后却显示 90 分这种信任何崩塌的事。页面完整代码量比较大这里只贴评分区域的核心模板结构template div v-forcategory in indicatorGroups :keycategory.name classcategory-block h4{{ category.name }}/h4 div v-forindicator in category.items :keyindicator.id classindicator-item div classindicator-content{{ indicator.content }}/div el-rate v-modelscoreMap[indicator.id] :texts[很差, 较差, 一般, 较好, 很好] show-text / /div /div /template这里有一个实际经验el-rate组件的 v-model 不能直接绑定对象动态属性时一开始不生效需要先在scoreMap初始化时把所有 indicatorId 对应的值设为 0确保对象里有这个属性Vue3 的响应式系统才能正确追踪变化。我第一次用 Vue3 的 reactive 对象时没初始化直接赋值结果页面一点都不动排查了半天才意识到是响应式代理的问题。6.4 管理员端数据报表可视化管理员端除了表格数据展示外我还引入了 ECharts 做统计图表。主要用到三个可视化场景教师平均分对比图横轴是教师姓名纵轴是平均分用柱状图展示方便教务处直接看出哪些老师评分偏低。课程类别合格率图用饼图展示各类型课程的优秀、良好、合格、不合格占比。单门课程评分趋势图用折线图按班级维度展示不同班级对同一门课的打分差异。ECharts 在 Vue3 里的使用我封装了一个简单的BaseChart.vue组件接收optionprop在watch里监听 option 变化调用setOption方法自动销毁实例防止内存泄漏。7. 权限控制与安全性实现要点7.1 前端路由守卫与菜单动态生成前端路由需要在跳转前检查用户是否登录以及角色是否有权限。Vue Router 的全局前置守卫写起来不复杂router.beforeEach((to, from, next) { const userStore useUserStore() if (to.path /login) { next() return } if (!userStore.token) { next(/login) return } // 路由meta中标记了角色要求不匹配则跳转首页 if (to.meta.roles !to.meta.roles.includes(userStore.roleType)) { next(/403) return } next() })管理员的菜单根据角色动态生成。登录后拿到用户信息根据 roleType 从路由配置中筛选出有权限访问的菜单项用 Element Plus 的el-menu动态渲染。这样不同角色登录后看到的左侧菜单完全不同学生只看到“我的评教”和“个人中心”管理员能看到全部菜单。7.2 后端接口越权防护虽然前端做了路由守卫和菜单控制但后端接口依然要防越权。这是非常容易被忽略的地方。比如学生只能查看自己的评教记录如果一个学生把请求里的studentId改成别人的 ID后端如果没有校验就可能导致信息泄露。我在实现查个人评教记录之类接口时每次都从 JWT token 里解析当前登录用户的 ID而不是信任前端传的 userId 参数然后强制让接口内部使用 token 里的 userId 查询。更加敏感的管理接口比如删除用户、更改角色接口上标注RequireRole(role 3)注解确保只有管理员角色能调用。7.3 数据脱敏与密码安全密码存储必须用加密算法。我在项目里用的是 BCrypt每次调用BCryptPasswordEncoder.encode()都会生成不同的哈希值即使两个用户密码相同存储结果也不同避免通过哈希比对反推密码规律。登录时用matches()方法校验。还有一个细节用户列表接口中密码字段必须返回空字符串不能把哈希值返回给前端。MyBatis-Plus 的JsonProperty(access JsonProperty.Access.WRITE_ONLY)注解可以做到只允许写入、不允许读出序列化。8. 部署方案与性能优化实录8.1 前后端分离部署架构项目部署我采用经典方案Nginx 托管前端静态文件并反向代理后端接口。SpringBoot 项目打成 jar 包运行MySQL 和 Redis 作为独立服务。Nginx 配置核心要点server { listen 80; server_name yourdomain.com; # 前端静态资源 root /opt/evaluation-frontend/dist; index index.html; # 前端history路由配置刷新页面时回退到index.html location / { try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这段配置最容易踩的坑就是 Vue Router 的 history 模式刷新后 404 问题。如果用的不是 hash 模式刷新某个路由路径时 Nginx 会去服务器找对应的文件找不到就 404。try_files指令就是为了解决这个问题把请求回退到 index.html 由前端路由接管。8.2 性能优化与高并发应对评教系统每学期评教高峰期并发量并不小一个 2 万人的学校集中在一个上午评教并发峰值可能达到每秒几百个请求。针对这个场景我做了几项优化第一静态资源缓存。打包后的 JS、CSS 文件都带 hash 值Nginx 配置expires 7d让浏览器强缓存这些文件避免反复请求服务器。第二接口数据缓存。评教指标这类几乎不变的数据学生端每次进入评教页面都从 Redis 读取不用每次查数据库。用 Spring Cache 的Cacheable注解实现。第三提交接口避免大事务。学生一次提交可能包含几十条明细数据如果全部塞在一个大事务里数据库连接占用时间过长。实际上明细数据单独操作。解决方案是把“校验任务状态”放到事务外执行事务里只做纯粹的 insert 操作缩短事务时间。第四数据库连接池调优。MySQL 连接池默认 10 个连接在高并发时明显不够我把 HikariCP 的 MaximumPoolSize 调到了 50同时把连接超时时间调整为 3000ms避免连接池耗尽后请求无限排队。注意MaximumPoolSize 不是越大越好连接数太多会加重数据库负担。MySQL 默认 max_connections 是 151如果系统里还有其他应用共用数据库50 已经很激进了。如果单机真的扛不住峰值流量更合理的方案是任务分批开放——比如按院系错峰评教而不是单纯加配置。8.3 Docker 化部署参考如果服务器环境需要频繁迁移或者搞一体化交付Docker 是个好选择。我给项目写了一个简单的 DockerfileFROM openjdk:8-jre WORKDIR /app COPY target/evaluation-backend-1.0.0.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]前端也可以用 Nginx 镜像打包整个项目用 Docker Compose 编排 MySQL、Redis、前后端四个服务一条命令就能拉起整套环境。对毕设答辩演示或者给学校做 POC 演示特别方便环境问题直接消灭。9. 常见问题与排查技巧实录9.1 前端报跨域错误开发环境最常见的坑就是跨域。Vue 的 Vite 开发服务器默认端口是 5173SpringBoot 接口跑在 8080两者端口不同浏览器就会触发同源策略报跨域错误。解决办法是在 Vite 配置里代理// vite.config.js export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端代码里的请求都走/api前缀Vite 开发服务器把请求转发到后端浏览器看到的只是同源请求从根上规避了跨域问题。生产环境 Nginx 反向代理也能解决一般不需要后端开启 CORS 配置。9.2 评教数据统计结果总和与明细不一致这个问题我在测试阶段遇到过。管理员端显示某个教师的总平均分是 92.5点进明细看每个学生的打分手动算平均值却得 93.1相差不少。排查后发现问题出在数据库层面——一个学生提交评教后修改了一次修改时生成的明细记录没有先删旧数据而是直接又插入了一份导致同一个学生对同一门课存在两份评分记录。解决方法是修改评教接口时先执行 delete 删除该学生该教师旧的答案记录再执行批量 insert 写入新记录保证同一学生在同一任务下对同一教师只有一份评教数据。数据库唯一索引没法完全防住这种情况还是要在业务代码层保证“先删后插”的语义。9.3 批量导入学生数据乱码管理员用 Excel 导入学生名单时经常遇到中文乱码问题。Excel 文件另存为的时候默认用 GBK 编码但后端读文件时 JSON 格式统一用 UTF-8两边对不上就乱码了。处理方案是后端读取 Excel 时强制指定编码格式或者在上传文档时做编码转换。更稳妥的做法是要求统一使用固定的导入模板后台把模板文件提供下载大家在模板基础上填数据再上传格式就有保障了。9.4 高并发下有学生反馈评教提交后成绩没变化上线第一学期就遇到一个真实问题——评教高峰期有几个学生反馈提交后马上查看老师平均分发现分数没变化怀疑自己评教没成功。排查后确认不是数据丢失而是统计查询接口为了性能做了 Redis 缓存提交删缓存和查询读缓存之间存在一个极小的时间窗口提交后立即查询很可能命中旧缓存。这个问题的本质是对“实时性”的定义。评教统计结果本身没有秒级一致性的要求教师最终成绩一般都在评教结束后统一查看管理员也不会在高峰期秒级刷新统计。我给统计接口设置了 60 秒的缓存过期时间并在前端页面做了“数据更新时间为每分钟刷新一次”的提示把预期管理做好这个问题就不再是问题了。10. 项目心得与拓展建议这个项目从头到尾做完我最深的感受是评教系统表面上是 CRUD 管理系统的套路但真正做深了处处都是业务判断。比如评教指标设计五个一级维度还是八个维度、每个维度下放几道题虽然属于学校教务的业务决策范畴但作为系统设计者你需要理解这些指标最终会汇总成什么、每种算法会产生什么效果才能把系统设计得不偏不倚。一味套模板的系统最后只会被使用部门嫌弃“不好用”。再比如用户体系很多学校已有统一身份认证平台如果未来系统真要上线第一件事绝对是对接统一认证而不是自己再维护一套账号体系。好的系统架构要预留认证接入的扩展点我当时在用户表里预留了source_type字段和third_party_id字段就是为了后续对接统一认证做准备——架构上留一手真到对接的时候就能少很多麻烦。最后再分享一个实用小技巧系统里所有涉及时间的字段统一用datetime类型Java 后端用LocalDateTime接收前端用dayjs做格式化别用Date类型。这能省掉一堆时区和格式转化的麻烦也是我在项目里踩过坑之后总结出来的习惯。如果后续想在这个系统上继续扩展我建议优先考虑三个方向一是对接学校统一身份认证二是增加学生给助教、实验课独立评教的子模块三是把统计报表做成可视化大屏在教务会议上投屏展示。这些都是评教系统真实业务场景中的延伸需求做完任何一个都能让项目的实战价值再上一个台阶。