从零搭一套高校学生评教系统SpringBootVue前后端分离该怎么做这篇文章从我实际开发的一套模拟项目出发把整个设计思路、表结构、核心接口、权限控制、前端实现到踩坑记录全都捋一遍新手可以直接照着路子走。作为一款面向高校教学管理的典型业务系统学生评教系统的核心目标很明确解决纸质评教效率低、数据统计滞后、结果不透明的问题用线上化的方式把“学生打分—教师查看—管理员管理”这条链路完整串起来。我做的这套系统后端采用SpringBoot 2.x MyBatis Plus MySQL前端采用Vue 2 Element UI ECharts部署上采用前后端完全分离的方式。无论你是准备做课程设计还是想在公司内部搭一套类似的问卷评分系统这套方案都有直接参考价值。1. 项目整体设计与技术选型1.1 为什么选择SpringBootVue这套组合先聊选型。很多人在做这类系统时会在几套方案之间纠结比如直接用JSPServlet、用Python的Django、或者用前后端不分离的传统单体。我的选择理由是SpringBoot是目前Java后端效率最高的起步框架内嵌Tomcat、自动配置、生态成熟配合MyBatis Plus能把CRUD的代码量压缩到极致Vue则解决了传统模板引擎下DOM操作繁琐、页面交互僵硬的问题组件化开发让评教表单这类复用度高的页面可以抽成独立组件。这套组合真正解决的问题是前后端通过JSON交互后端只负责业务逻辑和数据持久化前端只负责渲染和交互职责清晰。一个团队里哪怕只有两个人一个负责后端一个负责前端也能并行开发互不阻塞。1.2 系统核心模块与角色划分评教系统的用户角色天然分为三类学生、教师、管理员。围绕这三个角色系统核心模块可以做如下划分学生端查看自己本学期需要评教的课程列表、填写评教问卷指标打分评语、查看已评教记录。教师端查看自己被评教的平均分、各维度得分对比、学生评语汇总匿名化处理。管理员端维护学生与教师基础数据、维护课程与选课关系、维护评教指标模板、启动/关闭评教批次、查看全局统计报表。还有一个隐藏的关键点同一个用户在不同角色之间切换。我采用的方案是用户表里直接加role字段不引入复杂的RBAC表因为对于课程设计或中小型校园系统来说三种固定角色的代号字段已经足够用。如果你想做得更灵活一点可以引入角色表权限表但复杂度会明显上升收益有限。1.3 业务流程的设计思路业务流程可以抽象成一句话管理员发起一个评教批次学生在批次开放期间对已选课程逐门进行评价系统汇总数据后向教师展示统计结果。这里有个容易忽略的细节评教批次。为什么需要批次这个概念因为一个学期可能开展两次评估期中、期末同一门课同一批学生不能重复评价如果没有批次字段做隔离就会出现数据覆盖和重复记录的问题。我建议在设计表结构时从一开始就把批次ID纳进去哪怕第一版只有一个批次也要把这条扩展路径铺好。2. 数据库设计核心表结构与防重复评教方案2.1 核心表结构说明评教系统的表结构并不复杂关键是理清关系。我最终落地的表设计包含了以下核心表sys_user用户表字段为id、username、passwordBCrypt加密、real_name、role0管理员/1教师/2学生、created_at。course课程表字段为id、course_name、teacher_id关联教师、credit、course_code。semester学期表字段为id、semester_name、is_active用于区分不同学期。student_course选课关系表字段为id、student_id、course_id、semester_id成绩表里没有维护成绩的就不要硬关联。evaluation_batch评教批次表字段为id、batch_name、semester_id、start_time、end_time、status。evaluation_indicator评教指标表字段为id、indicator_content、category、weight、sort_order。指标分组可以简单分成“教学态度”“教学内容”“教学方法”“教学效果”四个维度。evaluation_record评教记录表字段为id、batch_id、student_id、course_id、total_score、comment、create_time。evaluation_detail评教明细表字段为id、record_id、indicator_id、score每项指标的得分落在这一层。为什么要把总分和明细分开因为如果只存一个总分教师端就看不到“哪个维度拖了后腿”统计报表也失去了分析价值。明细表虽然会增加一些写入量但对MySQL来说这种量级毫无压力。2.2 防重复评教的唯一键设计这是我最想强调的一个点。学生重复提交评教是这类系统最常见的脏数据来源。常规做法是先查一下有没有记录没有就插入——但在并发场景下学生连点两次提交、前端没有禁用按钮两个请求同时查到“无记录”然后同时插入就产生了两条有效记录。正确的解法是在数据库层面做约束给evaluation_record表加一个唯一键联合(batch_id, student_id, course_id)。这样一来不管并发请求来多少条MySQL的唯一索引会帮你挡下重复插入第二次插入直接报DuplicateKeyException。我在项目里同时配合了事务来控制明细表与记录表的一致性前者保证不重复后者保证不残缺。ALTER TABLE evaluation_record ADD UNIQUE KEY uk_batch_student_course (batch_id, student_id, course_id);2.3 评教总分如何计算总分计算方案上我采用的是最简单的加权均分模型每项指标有独立的分数(1-5分)同一维度下各项分数的均值作为该维度得分四个维度得分的算术平均值再乘以某个系数折算成百分制即得出该教师在该课程下的最终得分。公式大致为总分 (教学态度维度均分 教学内容维度均分 教学方法维度均分 教学效果维度均分) / 4 * 20。实际实现时不需要在Java里做太复杂的计算SQL里用AVG GROUP BY即可搞定统计。查询教师的平均分时从evaluation_detail表按教师维度聚合效率非常高。这里有一个设计上要注意的点指标权重。如果你想让“教学内容”的权重高于“教学态度”就需要在indicator表里加weight字段在计算时乘以权重系数。我第一版没有做权重第二版补上后计算公式变成了加权求和。2.4 数据库设计的几个实操心得实操中有几个点属于踩过坑才明白的所有表的主键统一用bigint自增不要用UUID字符串做主键因为UUID作为主键在MySQL InnoDB下会导致索引页随机写入数据量大时有明显性能下降。create_time字段统一用datetime类型不要用timestamp否则会遇到2038年问题。软删除字段deleted统一用tinyint默认0所有查询强制带上deleted0的条件。这个习惯在项目上线后做数据恢复时非常有用。字符串字段尽量用varchar而不是texttext字段无法直接加索引排序和分组都会受影响。评语字段我限制在500字内varchar(500)足够用。3. 后端核心接口设计与关键代码实现3.1 接口文档先行避免前后端扯皮在动手写Controller之前我强烈建议先把接口文档用表格形式列出来。定好路径、请求方式、参数、返回结构前后端各干各的不要边写边改。我这次定义的接口清单大致如下功能模块接口路径请求方式说明登录/api/auth/loginPOST用户登录返回token与角色获取待评教课程/api/student/courses/pendingGET学生端评教列表提交评教/api/student/evaluation/submitPOST保存评教记录明细查看评教历史/api/student/evaluation/historyGET学生已提交的记录教师查看统计/api/teacher/statistics/overviewGET教师平均分与维度分布管理员获取全部批次/api/admin/batch/listGET批次列表管理员创建批次/api/admin/batch/createPOST新增评教批次管理员获取全局统计/api/admin/statistics/globalGET汇总所有班级课程均分统一的返回结构我使用的是Result 对象包含code、message、data三个字段。这样前端axios拦截器可以统一处理异常码不需要每个接口单独判断。3.2 提交评教的核心事务实现提交评教是系统里最核心的写入接口。一次提交要同时写入evaluation_record和evaluation_detail两张表中间任何一步失败都要整体回滚所以必须加事务。事务的粒度是整个提交方法而不是单个SQL。我把Service层代码简化为下面这个思路Transactional(rollbackFor Exception.class) public void submitEvaluation(EvaluationSubmitDTO dto) { // 1. 获取当前登录学生ID与批次ID // 2. 构造EvaluationRecord实体过滤掉已存在的重复数据try-catch DuplicateKey // 3. 遍历dto.getIndicators()逐条构造EvaluationDetail // 4. 批量插入明细数据 }事务注解上必须使用rollbackFor Exception.class否则Spring默认只在遇到RuntimeException时才回滚。如果你在代码里自定义了一个业务异常但不是运行时异常事务就不会生效提交一半的数据就留在了库里。这一点我特意踩过当时排查了半天才发现是异常类型的问题。3.3 MyBatis Plus条件下的动态SQL条件查询如果用MyBatis Plus的LambdaQueryWrapper可以大幅减少代码量。比如查询学生待评教课程列表其实涉及三张表关联student_course、course、evaluation_batch这种场景用Wrapper就不太合适了我选择直接写一个自定义Mapper方法加Select注解。如果你不想手写SQL也可以在Service层分步查完再组装但这样会带来N1查询问题。比如你先查出10门课程再循环每门课程查一次教师和批次就会产生21条SQL性能上虽然在学校这种几百人的规模下还好但属于坏味道能避免就避免。我建议对这种多表关联统计场景直接手写联表SQL一次查询返回完整结果。3.4 登录鉴权与接口权限控制权限控制这块我要特别多说几句。很多前后端分离项目在实现用户认证时都用JWT但JWT有一个特点无状态。这意味着后端签发的token在到期之前是无法主动作废的所以如果学生被禁用了他手里的token依然可以调接口直到token过期。一种优化方案是把token存到Redis里后端校验时不仅验证JWT签名还验证Redis中是否存在这个token。这样管理员禁用用户时可以删除Redis中的key来强制下线。我在这个项目里就用的是这种方案代价是每次请求多一次Redis查询换来的控制力是值得的。接口级权限我采用的是自定义拦截器拿到token解析出userId和role再把当前请求路径与允许访问的角色做匹配。例如/api/teacher/**只允许role1访问/api/admin/**只允许role0访问。学生提交评教接口还要额外校验当前登录学生是否已选了这门课程这个属于业务权限需要在Service里再查一次选课关系表不能只靠URL拦截。4. 前端页面架构与核心交互实现4.1 前端页面结构与路由设计前端我采用的是Vue 2 Vue Router Axios Element UI。整个前端项目的pages目录相对简单/login登录页/student/courses学生端课程列表待评教/student/evaluate/:courseId评教表单页/student/history我的评教记录/teacher/statistics教师统计查看页/admin/index管理员管理页包含批次、课程、用户管理三个Tab路由守卫的逻辑很简单在router.beforeEach里读取本地存储的token如果访问的不是登录页且没有token就强制跳转登录页如果用户角色没有访问该路由的权限就重定向到401页面。需要说明前端路由守卫只解决“页面入口”问题后端必须有真实拦截否则用户直接请求接口就绕过限制了。4.2 评教表单页的动态渲染方案评教表单是整站交互最复杂的页面。因为指标是管理员动态配置的前端不能写死。我的做法是页面加载时请求后端获取当前课程的评教批次和指标模板返回一个指标数组前端用v-for循环渲染组件。每个指标渲染为一个评分组件element-ui的el-rate或者自己封装单选按钮组最后统一提交。评教页有一个交互细节评分未完成时按钮置灰全部指标评分后再允许提交。实现上可以用一个computed属性去判断已评分数量是否等于总指标数量。不要用watcher逐个监听效率低且代码乱。computed: { allScored() { return this.indicatorList.every(item this.scores[item.id] 0); } }提交后前端要做跳转前提示评教一旦提交无法修改是否确认提交这里直接调用el-messagebox.confirm确认后展示loading状态接口返回后跳转到历史记录页。4.3 统计展示中的ECharts接入教师端统计是系统里最有“价值感”的页面。我用了ECharts来展示三组图表各课程平均分柱状图各维度得分雷达图学生评语字数分布或分数区间饼图后端返回的统计接口数据结构是扁平化的数组前端需要map成ECharts所需的格式。比如雷达图的indicator需要name和maxseries的data需要value数组这些转换逻辑可以写在独立工具文件里保持组件干净。ECharts的图表需要响应式如果容器宽度变化后图表不刷新会显示不全。解决方案是在窗口resize事件里调用chart.resize()卸载组件时调用chart.dispose()。不要忘了定时器也可能引起内存泄漏用完后要clear。4.4 通用组件与Axios封装Axios封装是每次前端项目的必备环节。我在utils/request.js里统一做了三件事请求拦截器带上token字段、响应拦截器统一处理业务code、遇到401时跳回登录页并清除本地状态。service.interceptors.response.use( response { const res response.data; if (res.code 200) { return res; } if (res.code 401) { localStorage.removeItem(token); router.push(/login); } return Promise.reject(new Error(res.message || Error)); }, error { Message.error(error.message || 服务器错误); return Promise.reject(error); } );组件封装方面我把评分图标封装成了一个StudentRate.vue组件只接收value和disabled两个prop向父组件触发change事件。这一层封装的好处是如果后续想把五分制改成十分制只需要改一个组件。5. 常见问题与排查技巧实录5.1 前后端联调中的跨域问题前后端分离项目中跨域是必须过的关。最直观的方案是后端开启CORS配置一个WebMvcConfigurer加上addCorsMappings方法允许所有来源开发环境或指定域名生产环境访问。不要在生产环境放开所有来源否则任何网站的脚本都能向后端发起请求。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }如果你用的是Vue CLI开发服务器还可以在vue.config.js里配置proxy代理来转发/api前缀的请求避免开发环境频繁处理CORS。两种方式可以同时保留线上走CORS、本地走代理。5.2 事务失效的几个隐蔽场景事务失效是评教这类写操作系统的致命伤。除了前面提到的rollbackFor问题还有两种高频场景值得注意第一种是同类内部调用。比如StudentEvaluationServiceImpl中有两个方法submitEvaluation方法里直接调用了同类里的validateAndSave方法如果validateAndSave自己加了Transactional它是不生效的。原因是Spring的事务是通过代理对象实现的内部调用的this.method()不会经过代理。解决方案是把带事务的方法放到另一个Service里注入或者自己注入自己。第二种是异常被捕获后吞掉。我在早期代码里习惯在Service里try-catch所有异常导致事务管理器认为方法正常返回提交了部分数据。正确做法是catch到异常后手动抛出RuntimeException或者干脆把所有校验放在Service方法的最前面最后统一执行插入。5.3 查询效率与统计报表性能优化当评教记录达到数万条时教师端的统计查询可能变慢。我遇到过在evaluation_detail表上不加任何索引联表统计一次耗时3秒多的情况。优化方向非常明确给外键字段建索引特别是record_id、indicator_id、course_id。加上索引后同样的统计查询降到几十毫秒。统计接口不要直接查明细表再在Java里循环累加尽量用一条GROUP BY SQL完成聚合。比如查询某教师所有课程的平均分SELECT c.course_name, ROUND(AVG(er.total_score), 2) AS avg_score FROM evaluation_record er JOIN course c ON er.course_id c.id JOIN student_course sc ON sc.course_id c.id WHERE c.teacher_id #{teacherId} GROUP BY c.id;5.4 前端评教页的性能与状态管理坑评教表单如果指标特别多超过50个v-for渲染再加上每项绑定监听Vue的响应式系统会有一定压力。实测下来50个指标以内几乎无感知。如果将来指标扩充到上百个可以考虑把评分数据改用普通对象存储提交时一次性读取减少响应式依赖追踪的开销。还有一个状态管理的常见坑学生评完一门课后回到课程列表页这门课应该从“待评教”列表里移除。我的实现是通过路由跳转后调用列表刷新接口来实现的。不要试图用全局状态管理保存列表数据因为不同设备、不同时间看到的待评教列表必须实时从服务端拉取缓存状态容易给用户造成“我评了但列表里还在”的错觉。5.5 常见问题速查表现象原因解决方案登录后接口全部401前端axios没有携带token请求拦截器统一加headers提交评教提示重复并发重复点击或唯一键冲突后端捕获DuplicateKeyException并友好提示教师端统计为0学生评教记录未落到对应批次检查批量提交时batch_id是否传对评教表单无法提交前端校验全选未通过检查scores对象里是否用指标ID作为键中文乱码SpringBoot编码设置问题配置server.servlet.encoding.forcetrue分页后数据重复排序字段不唯一排序加主键id作为二级排序条件上传的评语太长截断数据库字段长度不够前端做字数限制后端长度校验写在最后评教系统的可扩展方向这套系统做完后我的感受是评教系统的难点不在增删改查而在于“规则”和“边界”——防重复、算权重、控权限、统计多维数据。这些规则一旦在开发初期没有想清楚后期改动成本非常高。比如我当时是在第一版完成后才加入批次概念结果要改表结构、改查询条件、改前端列表筛选前后折腾了一个多星期。如果你想在这套系统上继续扩展有两个方向我觉得很实用第一个方向是增加导出能力管理员端一键导出Excel版评教报告方便线下备案和通知第二个方向是增加定时任务批次到时间后自动关闭并触发结果通知前端用WebSocket推送已出结果的消息少打扰管理员手动操作。另外一个值得预留的口子是引入通用问卷引擎把评教指标从固定模板变成可配置的问卷题目这样这套系统不只是评教还能做成360度测评、课程调研等更通用的场景使用。
从零搭一套高校学生评教系统SpringBootVue前后端分离该怎么做这篇文章从我实际开发的一套模拟项目出发把整个设计思路、表结构、核心接口、权限控制、前端实现到踩坑记录全都捋一遍新手可以直接照着路子走。作为一款面向高校教学管理的典型业务系统学生评教系统的核心目标很明确解决纸质评教效率低、数据统计滞后、结果不透明的问题用线上化的方式把“学生打分—教师查看—管理员管理”这条链路完整串起来。我做的这套系统后端采用SpringBoot 2.x MyBatis Plus MySQL前端采用Vue 2 Element UI ECharts部署上采用前后端完全分离的方式。无论你是准备做课程设计还是想在公司内部搭一套类似的问卷评分系统这套方案都有直接参考价值。1. 项目整体设计与技术选型1.1 为什么选择SpringBootVue这套组合先聊选型。很多人在做这类系统时会在几套方案之间纠结比如直接用JSPServlet、用Python的Django、或者用前后端不分离的传统单体。我的选择理由是SpringBoot是目前Java后端效率最高的起步框架内嵌Tomcat、自动配置、生态成熟配合MyBatis Plus能把CRUD的代码量压缩到极致Vue则解决了传统模板引擎下DOM操作繁琐、页面交互僵硬的问题组件化开发让评教表单这类复用度高的页面可以抽成独立组件。这套组合真正解决的问题是前后端通过JSON交互后端只负责业务逻辑和数据持久化前端只负责渲染和交互职责清晰。一个团队里哪怕只有两个人一个负责后端一个负责前端也能并行开发互不阻塞。1.2 系统核心模块与角色划分评教系统的用户角色天然分为三类学生、教师、管理员。围绕这三个角色系统核心模块可以做如下划分学生端查看自己本学期需要评教的课程列表、填写评教问卷指标打分评语、查看已评教记录。教师端查看自己被评教的平均分、各维度得分对比、学生评语汇总匿名化处理。管理员端维护学生与教师基础数据、维护课程与选课关系、维护评教指标模板、启动/关闭评教批次、查看全局统计报表。还有一个隐藏的关键点同一个用户在不同角色之间切换。我采用的方案是用户表里直接加role字段不引入复杂的RBAC表因为对于课程设计或中小型校园系统来说三种固定角色的代号字段已经足够用。如果你想做得更灵活一点可以引入角色表权限表但复杂度会明显上升收益有限。1.3 业务流程的设计思路业务流程可以抽象成一句话管理员发起一个评教批次学生在批次开放期间对已选课程逐门进行评价系统汇总数据后向教师展示统计结果。这里有个容易忽略的细节评教批次。为什么需要批次这个概念因为一个学期可能开展两次评估期中、期末同一门课同一批学生不能重复评价如果没有批次字段做隔离就会出现数据覆盖和重复记录的问题。我建议在设计表结构时从一开始就把批次ID纳进去哪怕第一版只有一个批次也要把这条扩展路径铺好。2. 数据库设计核心表结构与防重复评教方案2.1 核心表结构说明评教系统的表结构并不复杂关键是理清关系。我最终落地的表设计包含了以下核心表sys_user用户表字段为id、username、passwordBCrypt加密、real_name、role0管理员/1教师/2学生、created_at。course课程表字段为id、course_name、teacher_id关联教师、credit、course_code。semester学期表字段为id、semester_name、is_active用于区分不同学期。student_course选课关系表字段为id、student_id、course_id、semester_id成绩表里没有维护成绩的就不要硬关联。evaluation_batch评教批次表字段为id、batch_name、semester_id、start_time、end_time、status。evaluation_indicator评教指标表字段为id、indicator_content、category、weight、sort_order。指标分组可以简单分成“教学态度”“教学内容”“教学方法”“教学效果”四个维度。evaluation_record评教记录表字段为id、batch_id、student_id、course_id、total_score、comment、create_time。evaluation_detail评教明细表字段为id、record_id、indicator_id、score每项指标的得分落在这一层。为什么要把总分和明细分开因为如果只存一个总分教师端就看不到“哪个维度拖了后腿”统计报表也失去了分析价值。明细表虽然会增加一些写入量但对MySQL来说这种量级毫无压力。2.2 防重复评教的唯一键设计这是我最想强调的一个点。学生重复提交评教是这类系统最常见的脏数据来源。常规做法是先查一下有没有记录没有就插入——但在并发场景下学生连点两次提交、前端没有禁用按钮两个请求同时查到“无记录”然后同时插入就产生了两条有效记录。正确的解法是在数据库层面做约束给evaluation_record表加一个唯一键联合(batch_id, student_id, course_id)。这样一来不管并发请求来多少条MySQL的唯一索引会帮你挡下重复插入第二次插入直接报DuplicateKeyException。我在项目里同时配合了事务来控制明细表与记录表的一致性前者保证不重复后者保证不残缺。ALTER TABLE evaluation_record ADD UNIQUE KEY uk_batch_student_course (batch_id, student_id, course_id);2.3 评教总分如何计算总分计算方案上我采用的是最简单的加权均分模型每项指标有独立的分数(1-5分)同一维度下各项分数的均值作为该维度得分四个维度得分的算术平均值再乘以某个系数折算成百分制即得出该教师在该课程下的最终得分。公式大致为总分 (教学态度维度均分 教学内容维度均分 教学方法维度均分 教学效果维度均分) / 4 * 20。实际实现时不需要在Java里做太复杂的计算SQL里用AVG GROUP BY即可搞定统计。查询教师的平均分时从evaluation_detail表按教师维度聚合效率非常高。这里有一个设计上要注意的点指标权重。如果你想让“教学内容”的权重高于“教学态度”就需要在indicator表里加weight字段在计算时乘以权重系数。我第一版没有做权重第二版补上后计算公式变成了加权求和。2.4 数据库设计的几个实操心得实操中有几个点属于踩过坑才明白的所有表的主键统一用bigint自增不要用UUID字符串做主键因为UUID作为主键在MySQL InnoDB下会导致索引页随机写入数据量大时有明显性能下降。create_time字段统一用datetime类型不要用timestamp否则会遇到2038年问题。软删除字段deleted统一用tinyint默认0所有查询强制带上deleted0的条件。这个习惯在项目上线后做数据恢复时非常有用。字符串字段尽量用varchar而不是texttext字段无法直接加索引排序和分组都会受影响。评语字段我限制在500字内varchar(500)足够用。3. 后端核心接口设计与关键代码实现3.1 接口文档先行避免前后端扯皮在动手写Controller之前我强烈建议先把接口文档用表格形式列出来。定好路径、请求方式、参数、返回结构前后端各干各的不要边写边改。我这次定义的接口清单大致如下功能模块接口路径请求方式说明登录/api/auth/loginPOST用户登录返回token与角色获取待评教课程/api/student/courses/pendingGET学生端评教列表提交评教/api/student/evaluation/submitPOST保存评教记录明细查看评教历史/api/student/evaluation/historyGET学生已提交的记录教师查看统计/api/teacher/statistics/overviewGET教师平均分与维度分布管理员获取全部批次/api/admin/batch/listGET批次列表管理员创建批次/api/admin/batch/createPOST新增评教批次管理员获取全局统计/api/admin/statistics/globalGET汇总所有班级课程均分统一的返回结构我使用的是Result 对象包含code、message、data三个字段。这样前端axios拦截器可以统一处理异常码不需要每个接口单独判断。3.2 提交评教的核心事务实现提交评教是系统里最核心的写入接口。一次提交要同时写入evaluation_record和evaluation_detail两张表中间任何一步失败都要整体回滚所以必须加事务。事务的粒度是整个提交方法而不是单个SQL。我把Service层代码简化为下面这个思路Transactional(rollbackFor Exception.class) public void submitEvaluation(EvaluationSubmitDTO dto) { // 1. 获取当前登录学生ID与批次ID // 2. 构造EvaluationRecord实体过滤掉已存在的重复数据try-catch DuplicateKey // 3. 遍历dto.getIndicators()逐条构造EvaluationDetail // 4. 批量插入明细数据 }事务注解上必须使用rollbackFor Exception.class否则Spring默认只在遇到RuntimeException时才回滚。如果你在代码里自定义了一个业务异常但不是运行时异常事务就不会生效提交一半的数据就留在了库里。这一点我特意踩过当时排查了半天才发现是异常类型的问题。3.3 MyBatis Plus条件下的动态SQL条件查询如果用MyBatis Plus的LambdaQueryWrapper可以大幅减少代码量。比如查询学生待评教课程列表其实涉及三张表关联student_course、course、evaluation_batch这种场景用Wrapper就不太合适了我选择直接写一个自定义Mapper方法加Select注解。如果你不想手写SQL也可以在Service层分步查完再组装但这样会带来N1查询问题。比如你先查出10门课程再循环每门课程查一次教师和批次就会产生21条SQL性能上虽然在学校这种几百人的规模下还好但属于坏味道能避免就避免。我建议对这种多表关联统计场景直接手写联表SQL一次查询返回完整结果。3.4 登录鉴权与接口权限控制权限控制这块我要特别多说几句。很多前后端分离项目在实现用户认证时都用JWT但JWT有一个特点无状态。这意味着后端签发的token在到期之前是无法主动作废的所以如果学生被禁用了他手里的token依然可以调接口直到token过期。一种优化方案是把token存到Redis里后端校验时不仅验证JWT签名还验证Redis中是否存在这个token。这样管理员禁用用户时可以删除Redis中的key来强制下线。我在这个项目里就用的是这种方案代价是每次请求多一次Redis查询换来的控制力是值得的。接口级权限我采用的是自定义拦截器拿到token解析出userId和role再把当前请求路径与允许访问的角色做匹配。例如/api/teacher/**只允许role1访问/api/admin/**只允许role0访问。学生提交评教接口还要额外校验当前登录学生是否已选了这门课程这个属于业务权限需要在Service里再查一次选课关系表不能只靠URL拦截。4. 前端页面架构与核心交互实现4.1 前端页面结构与路由设计前端我采用的是Vue 2 Vue Router Axios Element UI。整个前端项目的pages目录相对简单/login登录页/student/courses学生端课程列表待评教/student/evaluate/:courseId评教表单页/student/history我的评教记录/teacher/statistics教师统计查看页/admin/index管理员管理页包含批次、课程、用户管理三个Tab路由守卫的逻辑很简单在router.beforeEach里读取本地存储的token如果访问的不是登录页且没有token就强制跳转登录页如果用户角色没有访问该路由的权限就重定向到401页面。需要说明前端路由守卫只解决“页面入口”问题后端必须有真实拦截否则用户直接请求接口就绕过限制了。4.2 评教表单页的动态渲染方案评教表单是整站交互最复杂的页面。因为指标是管理员动态配置的前端不能写死。我的做法是页面加载时请求后端获取当前课程的评教批次和指标模板返回一个指标数组前端用v-for循环渲染组件。每个指标渲染为一个评分组件element-ui的el-rate或者自己封装单选按钮组最后统一提交。评教页有一个交互细节评分未完成时按钮置灰全部指标评分后再允许提交。实现上可以用一个computed属性去判断已评分数量是否等于总指标数量。不要用watcher逐个监听效率低且代码乱。computed: { allScored() { return this.indicatorList.every(item this.scores[item.id] 0); } }提交后前端要做跳转前提示评教一旦提交无法修改是否确认提交这里直接调用el-messagebox.confirm确认后展示loading状态接口返回后跳转到历史记录页。4.3 统计展示中的ECharts接入教师端统计是系统里最有“价值感”的页面。我用了ECharts来展示三组图表各课程平均分柱状图各维度得分雷达图学生评语字数分布或分数区间饼图后端返回的统计接口数据结构是扁平化的数组前端需要map成ECharts所需的格式。比如雷达图的indicator需要name和maxseries的data需要value数组这些转换逻辑可以写在独立工具文件里保持组件干净。ECharts的图表需要响应式如果容器宽度变化后图表不刷新会显示不全。解决方案是在窗口resize事件里调用chart.resize()卸载组件时调用chart.dispose()。不要忘了定时器也可能引起内存泄漏用完后要clear。4.4 通用组件与Axios封装Axios封装是每次前端项目的必备环节。我在utils/request.js里统一做了三件事请求拦截器带上token字段、响应拦截器统一处理业务code、遇到401时跳回登录页并清除本地状态。service.interceptors.response.use( response { const res response.data; if (res.code 200) { return res; } if (res.code 401) { localStorage.removeItem(token); router.push(/login); } return Promise.reject(new Error(res.message || Error)); }, error { Message.error(error.message || 服务器错误); return Promise.reject(error); } );组件封装方面我把评分图标封装成了一个StudentRate.vue组件只接收value和disabled两个prop向父组件触发change事件。这一层封装的好处是如果后续想把五分制改成十分制只需要改一个组件。5. 常见问题与排查技巧实录5.1 前后端联调中的跨域问题前后端分离项目中跨域是必须过的关。最直观的方案是后端开启CORS配置一个WebMvcConfigurer加上addCorsMappings方法允许所有来源开发环境或指定域名生产环境访问。不要在生产环境放开所有来源否则任何网站的脚本都能向后端发起请求。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }如果你用的是Vue CLI开发服务器还可以在vue.config.js里配置proxy代理来转发/api前缀的请求避免开发环境频繁处理CORS。两种方式可以同时保留线上走CORS、本地走代理。5.2 事务失效的几个隐蔽场景事务失效是评教这类写操作系统的致命伤。除了前面提到的rollbackFor问题还有两种高频场景值得注意第一种是同类内部调用。比如StudentEvaluationServiceImpl中有两个方法submitEvaluation方法里直接调用了同类里的validateAndSave方法如果validateAndSave自己加了Transactional它是不生效的。原因是Spring的事务是通过代理对象实现的内部调用的this.method()不会经过代理。解决方案是把带事务的方法放到另一个Service里注入或者自己注入自己。第二种是异常被捕获后吞掉。我在早期代码里习惯在Service里try-catch所有异常导致事务管理器认为方法正常返回提交了部分数据。正确做法是catch到异常后手动抛出RuntimeException或者干脆把所有校验放在Service方法的最前面最后统一执行插入。5.3 查询效率与统计报表性能优化当评教记录达到数万条时教师端的统计查询可能变慢。我遇到过在evaluation_detail表上不加任何索引联表统计一次耗时3秒多的情况。优化方向非常明确给外键字段建索引特别是record_id、indicator_id、course_id。加上索引后同样的统计查询降到几十毫秒。统计接口不要直接查明细表再在Java里循环累加尽量用一条GROUP BY SQL完成聚合。比如查询某教师所有课程的平均分SELECT c.course_name, ROUND(AVG(er.total_score), 2) AS avg_score FROM evaluation_record er JOIN course c ON er.course_id c.id JOIN student_course sc ON sc.course_id c.id WHERE c.teacher_id #{teacherId} GROUP BY c.id;5.4 前端评教页的性能与状态管理坑评教表单如果指标特别多超过50个v-for渲染再加上每项绑定监听Vue的响应式系统会有一定压力。实测下来50个指标以内几乎无感知。如果将来指标扩充到上百个可以考虑把评分数据改用普通对象存储提交时一次性读取减少响应式依赖追踪的开销。还有一个状态管理的常见坑学生评完一门课后回到课程列表页这门课应该从“待评教”列表里移除。我的实现是通过路由跳转后调用列表刷新接口来实现的。不要试图用全局状态管理保存列表数据因为不同设备、不同时间看到的待评教列表必须实时从服务端拉取缓存状态容易给用户造成“我评了但列表里还在”的错觉。5.5 常见问题速查表现象原因解决方案登录后接口全部401前端axios没有携带token请求拦截器统一加headers提交评教提示重复并发重复点击或唯一键冲突后端捕获DuplicateKeyException并友好提示教师端统计为0学生评教记录未落到对应批次检查批量提交时batch_id是否传对评教表单无法提交前端校验全选未通过检查scores对象里是否用指标ID作为键中文乱码SpringBoot编码设置问题配置server.servlet.encoding.forcetrue分页后数据重复排序字段不唯一排序加主键id作为二级排序条件上传的评语太长截断数据库字段长度不够前端做字数限制后端长度校验写在最后评教系统的可扩展方向这套系统做完后我的感受是评教系统的难点不在增删改查而在于“规则”和“边界”——防重复、算权重、控权限、统计多维数据。这些规则一旦在开发初期没有想清楚后期改动成本非常高。比如我当时是在第一版完成后才加入批次概念结果要改表结构、改查询条件、改前端列表筛选前后折腾了一个多星期。如果你想在这套系统上继续扩展有两个方向我觉得很实用第一个方向是增加导出能力管理员端一键导出Excel版评教报告方便线下备案和通知第二个方向是增加定时任务批次到时间后自动关闭并触发结果通知前端用WebSocket推送已出结果的消息少打扰管理员手动操作。另外一个值得预留的口子是引入通用问卷引擎把评教指标从固定模板变成可配置的问卷题目这样这套系统不只是评教还能做成360度测评、课程调研等更通用的场景使用。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
