基于Spring Boot的教师评价系统：从设计到部署全实践

如果你正在做基于Spring Boot的教师评价系统，不管是为了毕业设计、课程设计，还是公司里真实要落地的教学管理需求，最开始困扰你的大概率不是“怎么写代码”，而是“评价这件事到底怎么建模”。我最早拿到这个题目时，第一反应是找个现成的管理系统改改就完事，但做进去才发现，教师评价和普通的增删改查系统完全不在一个难度等级上。它涉及多角色权限、按学期组织的评价任务、动态指标配置、匿名提交、分数汇总与可视化展示，还要考虑防止学生重复提交、保证数据统计口径一致这些实际问题。

网上关于Spring Boot的教程一抓一大把，但大多数是零散的登录注册、CRUD示例，看完依然不知道怎么组织一个完整的教师评价系统。我和几个同样在做这个题目的朋友交流过，大家共同的困惑是：表结构怎么设计才能支持多套评价模板？学生提交评价时后端怎么校验有没有重复评过？不同角色登录后看到的菜单和页面为什么不一样？评价结果怎么算权重、怎么画雷达图？这些点单个拿出来都能搜到答案，但串在一起就找不到一篇能直接照着做的完整资料。

这篇文章我会用一套完整的项目实践来回答这些问题。内容包括需求拆解、数据库设计、后端接口实现、前端页面组织、答辩文档与PPT的制作思路，以及我在实际部署和调试过程中踩过的坑。项目本身是基于Spring Boot + Vue + MySQL这套组合实现的，整套源码结构和文档也一并梳理清楚，你可以直接把它作为一个可复现的参考模板，按自己的业务场景去调整。

1. 项目核心需求拆解——教师评价系统到底要解决什么问题

1.1 教学评价业务的痛点与系统边界

教师评价系统并不是简单的“学生给老师打个分”。在真实业务场景里，它要解决的核心问题是：学校或教学管理机构如何在一个学期结束时，快速收集学生对任课教师的教学质量反馈，并把这些反馈转化成可用于教学改进和管理决策的数据。

手工统计方式有很多让人头疼的地方。几千个学生每人要对多门课程的老师打分，如果靠纸质问卷或Excel汇总，光是数据录入就要耗费大量人力。而且人工汇总很容易出错，问卷丢失、漏填、统计口径不一致是家常便饭。更重要的是，手工方式很难控制“一个学生对同一个老师只评价一次”，也无法保证评价数据的匿名性和严肃性。

系统要管的事情，我梳理下来无非三类：

• 基础数据维护：教师信息、学生信息、学期信息、评价指标体系的增删改查。
• 评价业务流程：学生在指定学期对待评教师进行打分和填写主观评价，提交后不可修改。
• 结果统计分析：按教师、按学院、按职称、按评价维度等维度查看得分、排名、趋势和评语。

把边界划清楚很重要。我见过一些同学把这个系统越做越大，又想管排课，又想管成绩，最后数据库几十张表，功能做不完，答辩时还被问得漏洞百出。做系统最忌讳的就是功能范围失控。教师评价系统就聚焦评价这件事，其他模块要么不做，要么只保留最必要的关联。

1.2 用户角色与典型业务流程

这个系统里有三种核心角色，分别对应三类完全不同的使用诉求：

• 管理员：负责系统配置和宏观管理。管理员要维护教师和学生的基础信息，配置评价指标模板，设置当前学期，查看全校范围的评价进度，导出统计数据。
• 学生：评价的执行者。学生登录后能看到本学期需要评价的教师列表，逐一对教师进行打分，填写主观评语，确认提交。
• 教师：评价的接收者。教师登录后能查看自己在各个学期的评价得分、各项维度的得分情况、学生留下的匿名评语，以及同职称或同学院教师的横向对比。

完整的业务流程是这样的：管理员先维护好本学期的教师和学生数据，配置好评价指标模板，比如教学态度、教学内容、教学方法、教学效果这几个一级维度；然后学生在规定时间内登录系统，看到本学期的待评任务，一份份完成打分并提交；最后管理员和教师各自查看统计分析结果。

一个容易忽略但很关键的点是“学期状态”管理。如果系统不区分当前学期，学生在任何时候登录都能看到所有历史评价任务，数据会变得很混乱。比较合理的做法是只有处于“进行中”状态的学期才允许学生提交评价，历史学期只能查看结果，不允许再操作。

1.3 为什么选择Spring Boot作为技术底座

教师评价系统的核心技术选型，我选择的是Spring Boot + MyBatis-Plus + MySQL + Vue这套组合。这个选择不是跟风，而是综合考虑了开发效率、学习成本、部署难度和答辩需求。

Spring Boot最大的价值在于自动装配和约定优于配置。以前用SSM框架，要手写一大堆XML配置文件，配置数据源、配置事务、配置MyBatis的SqlSessionFactory，每一步都有可能出错。Spring Boot把这些繁琐的配置变成了自动化的starter依赖，引入一个依赖就自动配置好对应的组件，开发者只需要在application.yml里写核心参数即可。

这一点对做毕设或者课程项目的同学尤其友好。你不需要理解底层源码也能把项目跑起来，把更多精力放在业务逻辑上。如果后续想深入，Spring Boot的自动装配原理、条件注解、启动流程这些内容也足够作为答辩时展示技术深度的切入点。

再说为什么不选择过于复杂的微服务架构。看到有些同学在毕设里硬拆用户服务、评价服务、统计服务，还要上Nacos、Feign、Sentinel，我只能说这是在给自己挖坑。教师评价系统的业务量级完全不需要微服务，单体应用配合清晰的分层结构，部署简单、调试方便、代码量可控，这才是最务实的选择。

2. 核心功能模块与数据库设计

2.1 评价指标体系的设计思路

评价指标体系是整个系统里最核心的业务模型。很多初学者容易把它做成一张固定的表，字段是“教学态度分”“教学内容分”“教学方法分”，这样做的后果是业务一旦变化就要改表结构，代码也没法复用。

正确的设计思路是把指标体系抽象成“模板—维度—题项”三层结构。一个评价模板对应一种评价场景，比如理论课评价模板、实验课评价模板；模板下面包含多个评价维度，比如教学态度、教学内容；每个维度下面再挂若干具体的评分题项。

这样做的好处非常明显。第一，业务上可以灵活配置，不同学院、不同课程类型可以绑定不同的评价模板；第二，代码逻辑统一，前端根据模板ID动态渲染题目，后端根据模板和维度计算汇总分数；第三，答辩时能体现出你对业务模型的理解深度，而不是只会做写死的增删改查。

评分方式建议用5分制或10分制的单选评分。每个维度的权重可以配置，多个题项的得分取平均值作为该维度的得分，所有维度按权重加权求和得到总分。

2.2 数据库表结构规划

基于上面的业务分析，我设计了以下几张核心表。先声明一下，这是我在实际项目中经过多轮调整后的方案，不是教科书上的标准答案，但基本覆盖了教师评价系统的主要业务场景。

用户表设计上我采用了统一账号表加扩展表的方案。用户表保存登录账号、密码、角色，教师和学生分别用扩展表保存各自独立的业务属性。这样做的原因是登录认证只需要查一张表，而教师信息、学生信息又不会相互干扰。

这里重点说几个容易设计错的表。

一是评价记录表。为了防止同一个学生对同一个教师同一学期重复评价，必须在这张表上建立联合唯一约束，字段组合是student_id + teacher_id + semester_id。这条唯一约束是防重复的最后一层数据库保障，后面讲后端逻辑时还会再提到。

二是评价答案表。题项不是固定写死在程序里的，而是动态配置的，所以答案必须逐题存储。每一条答案记录对应唯一一个评价记录中的一个题项。主观评语并不要求每个题项都有，通常一个教师一条评价记录对应一段整体评语就够了，所以我把comment字段放在答案表里，由前端只传一次。

三是学期表。建议加一个status字段标记当前学期。业务逻辑中，只有status为1的学期才允许学生提交评价，这样能避免历史数据被误操作。

2.3 权限模型设计

权限模型上我采用的是基于角色的访问控制。系统只有三种角色：管理员、学生、教师，所以直接用Spring Security内置的ROLE_XXX机制就能满足需求，不需要引入复杂的RBAC权限表设计。

具体到访问控制，需要区分两个层级。第一个层级是接口级权限，通过Spring Security的URL规则和@PreAuthorize注解实现。比如/api/admin/**下面的接口只允许ADMIN角色访问，/api/student/**下面的接口只允许STUDENT角色访问。第二个层级是数据级权限，这个必须在Service层自己控制。最典型的例子是学生只能查看分配给自己的评价任务，教师只能查看自己的评价结果。如果不做数据级权限控制，用户登录后拼参数就能查到别人的数据，这在答辩演示时是很尴尬的安全漏洞。

关于匿名评语的处理，这里要特别说明一下。为了让学生敢说真话，教师端只能看到评语内容，不能看到评语是哪个学生写的。这是业务层面的匿名要求。如果后续要做审计追溯，可以在数据库里保留记录ID，但展示层绝不返回学生姓名和学号。

3. Spring Boot后端关键实现细节

3.1 项目工程结构规划

我建议按功能分包，而不是按技术分层分包。两种分包方式在代码量小的时候差别不大，但功能分包在业务复杂后更容易维护。我实际使用的包结构如下：

com.example.teachereval ├── common │ ├── Result.java // 统一返回结构 │ ├── ResultCode.java // 状态码枚举 │ └── exception ├── config │ ├── SecurityConfig.java // Spring Security配置 │ ├── MybatisPlusConfig.java │ └── WebMvcConfig.java // 跨域、资源映射 ├── controller │ ├── admin │ ├── student │ └── teacher ├── service │ ├── impl ├── mapper ├── entity ├── dto └── vo

统一返回结构Result是前后端联调时的关键。我的设计是code + message + data三段式，前端根据code判断请求是否成功，不需要后端抛异常才能感知错误。

一个值得注意的细节是DTO和VO的使用。很多同学喜欢实体类Entity直接返回给前端，这样会把密码等敏感字段暴露出去，而且当数据组装逻辑比较复杂时，Entity根本表达不了。我的做法是入参用DTO，出参用VO，Entity只在Service和Mapper之间传递。虽然代码量会多一点点，但结构清晰，接口文档也好写。

3.2 评价业务核心接口设计

接口设计直接决定前后端协作效率和代码可维护性。这整套系统我梳理下来，核心接口大概是下面这些：

以最关键的提交评价接口为例。这个接口表面上只是接收一个JSON数组，但背后涉及参数校验、幂等判断、事务控制等多个环节。我实际的Service层逻辑大致是这样的：

@Transactional(rollbackFor = Exception.class) public void submitEvaluation(SubmitRequest request) { // 1. 校验当前学期是否存在且处于进行中 Semester semester = checkSemesterOpen(SemesterContext.getCurrentSemesterId()); // 2. 查询评价任务，判断是否允许当前学生对当前教师进行评价 EvaluationTask task = checkEvaluationTask(request.getTeacherId()); // 3. 防重复：查询是否已经提交过评价 int count = evalRecordMapper.selectCount(new LambdaQueryWrapper<EvalRecord>() .eq(EvalRecord::getStudentId, currentStudentId) .eq(EvalRecord::getTeacherId, request.getTeacherId()) .eq(EvalRecord::getSemesterId, semester.getId())); if (count > 0) { throw new BusinessException("您已完成对这位教师的评价，请勿重复提交"); } // 4. 保存评价主记录 EvalRecord record = new EvalRecord(); // ... 组装主记录字段 record.setStudentId(currentStudentId); record.setTotalScore(calculateTotalScore(request.getItems())); evalRecordMapper.insert(record); // 5. 批量保存每题答案 for (SubmitItem item : request.getItems()) { EvalAnswer answer = new EvalAnswer(); answer.setRecordId(record.getId()); answer.setItemId(item.getItemId()); answer.setScore(item.getScore()); answer.setComment(item.getComment()); evalAnswerMapper.insert(answer); } }

这里我用了@Transactional注解保证主记录和答案明细要么全部成功，要么全部回滚。如果第5步插入答案时中途失败，主记录也会跟着回滚，不会出现“评价记录有了但没有答案”的不一致状态。

3.3 基于Spring Security的权限控制

Spring Security在这个项目里承担两块职责：认证和授权。认证就是验证用户名密码，签发JWT令牌；授权就是根据令牌中的角色判断是否能访问某个接口。

JWT的方案网上有大量现成教程，但有一个细节我踩过坑：JWT的SecurityContext是每次请求时通过过滤器解析令牌动态设置的，不是登录成功后全局唯一的。所以一定要在OncePerRequestFilter里做令牌解析，而不能在Controller里解析。原因很简单，一旦服务重启，内存中的登录态就全部丢失了，每次请求必须重新校验令牌。

public class JwtAuthenticationFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token = getTokenFromRequest(request); if (StringUtils.hasText(token) && jwtUtils.validateToken(token)) { String username = jwtUtils.getUsernameFromToken(token); UserDetails userDetails = userDetailsService.loadUserByUsername(username); UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities()); authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request)); SecurityContextHolder.getContext().setAuthentication(authentication); } chain.doFilter(request, response); } }

基于JWT的方案在前后端分离项目里是很顺手的选择。但使用Spring Security时，有一个版本迭代的大坑：旧版本的SecurityConfig需要继承WebSecurityConfigurerAdapter，并使用configure(AuthenticationManagerBuilder auth)方法配置认证管理器。Spring Boot 2.7+之后，这套写法已经废弃了，新项目再照着老教程写会直接报错。正确做法是用SecurityFilterChain的方式注册过滤链。

3.4 防重复提交与幂等处理

这一块是实践中最容易被忽视、又最容易出问题的环节。学生提交评价时手速快连点了两次提交按钮，或者前端网络超时后自动重试，都可能导致同一条评价被写入两条记录。数据库层面的联合唯一约束能兜住生产事故，但用户体验上会直接显示数据库异常，很不友好。

更友好的方案是三层防护配合。第一层在前端，点击提交后立即禁用按钮，并加一个“提交中”的状态标识；第二层在后端Service中进入业务逻辑前先查询是否已评价，查到就直接返回业务码提示“您已评价过这位教师”；第三层靠数据库唯一约束兜底。这里有个取舍值得说：是否要用Redis做分布式锁？

我的结论是：单机部署的教师评价系统完全没必要。业务量根本到不了分布式锁要解决的问题程度，引入Redis反而增加部署复杂度。如果项目要求展示技术亮点，可以用本地锁或者数据库唯一索引，配合统一异常处理，让重复提交返回一个友好的提示信息就可以了。

如果你确实想用Redis做幂等令牌，实现思路是：前端在打开评价表单时请求一个唯一token，后端把token存Redis并设置过期时间，提交评价时带着token，后端通过setnx命令尝试删除，只有删除成功才放行。这个方案在真实的互联网项目里很常见，但用在毕设项目里，会给答辩增加不必要的复杂度，需要自己掂量清楚。

4. 前端页面与交互设计要点

4.1 技术选型与页面结构

前端我选的是Vue 3 + Element Plus + Vite + ECharts。这套组合在开发体验和数据可视化方面都非常成熟，尤其是Element Plus的表单组件和ECharts的图表组件，几乎是管理系统和数据可视化项目的标配。

关于页面结构，管理端和用户端没有必要分开做成两套系统。通过路由守卫和侧边栏菜单的动态渲染，根据登录用户角色显示不同的菜单项即可。一个前端工程加一套登录接口，就能同时支撑三种角色的使用，避免了维护多套前端的成本。

典型的页面划分是：

• 登录页：账号密码登录，登录后跳转到对应角色首页。
• 学生端：待评教师列表页、评价表单页、我的评价记录页。
• 教师端：个人评价结果页、评语查看页。
• 管理端：教师管理页、学生管理页、模板配置页、学期管理页、数据统计页。

4.2 评价表单的动态渲染

评价表单是前端最核心的一个页面。因为题目存在数据库里，前端不可能写死每个题目的DOM，而是要根据后端返回的模板数据结构动态渲染。

后端返回的评价表单数据，我设计成的结构是一个模板对象，里面包含维度和题项列表。前端拿到后，用v-for遍历维度，在每个维度下面再遍历题项，用radio-group渲染评分选项。评分组件用el-rate可能体验更好，但要注意el-rate渲染出来的星星和分值之间的映射关系。5分制的话，每颗星对应1分；10分制的话，可以每颗星对应2分。

动态表单的关键点在于收集数据。不能用简单的v-model绑定每一个题目，因为题目数量不固定。我的做法是在提交时遍历所有维度下的所有题项，构建一个对象数组，每个元素包含itemId和score。同时处理主观评语，把评语保存在表单数据中，提交时一起传。

function buildSubmitData() { const items = []; for (const item of formState.itemList) { items.push({ itemId: item.id, score: item.score }); } return { teacherId: route.query.teacherId, moduleId: route.query.moduleId, comment: formState.comment, items }; }

4.3 统计图表可视化

统计分析页面我选择了ECharts作为可视化方案。因为ECharts对中文文档和社区资源都比较友好，雷达图、柱状图、折线图都有现成的示例，稍微改改配置就能用。

教师评价结果里最直观的图表，第一个是“各维度得分雷达图”，能把一个教师在多个维度上的表现形象地呈现出来；第二个是“得分趋势折线图”，展示教师在不同学期的总评分数变化；第三个是“学院/职称对比柱状图”，把某个教师和同类别的平均分放在一起对比，让数据有参照系。

后端返回给前端的数据格式，直接决定图表能不能顺利渲染。我的经验是让后端返回“已经计算好的、结构化清晰的VO”，而不是原始记录让前端自己去聚合。比如教师个人评价结果，后端返回：

{ "teacherName": "张老师", "semester": "2024-2025-1", "totalScore": 92.5, "dimensionScores": [ { "dimension": "教学态度", "score": 95.0 }, { "dimension": "教学内容", "score": 90.0 }, { "dimension": "教学方法", "score": 91.5 }, { "dimension": "教学效果", "score": 93.2 } ], "commentList": ["课程条理清晰，讲解生动", "希望增加互动"] }

前端拿到这个结构，直接拆开填充到ECharts的配置项里，逻辑简单又不容易出错。请记住：前后端分离项目中，接口返回的数据结构尽量做到“语义化+结构化”，前端才能少写冗余的格式转换代码。

5. 答辩文档、PPT与源码组织

5.1 论文结构的组织思路

很多同学在写完代码后才开始写论文，这是顺序上的一个常见误区。正确做法是论文和系统同步推进，需求和设计阶段就把论文的核心章节框架定下来，写代码的过程其实就是在填充论文的“系统实现”部分。

一篇标准的教师评价系统毕业论文，我建议按下面的结构组织：

• 绪论：选题背景与意义、国内外研究现状、研究内容。
• 相关技术介绍：Spring Boot、MyBatis-Plus、Vue、MySQL。
• 需求分析：可行性分析、功能需求、非功能需求。
• 系统设计：总体架构设计、功能模块设计、数据库设计。
• 系统实现：每个功能模块的关键代码和实现效果展示。
• 系统测试：测试环境、测试用例、测试结果分析。

写作时需要注意的问题是，不要大段贴代码。论文是给评审老师看的，他要看的是你的设计思路、技术选型理由、问题解决方案，而不是代码清单。每一段实现描述都应该先写“这个功能要解决什么问题”，再写“我用了什么技术方案”，最后简单展示核心代码片段即可。

5.2 PPT制作与答辩演示顺序

答辩PPT有一个容易被忽视的原则：一页PPT只讲一个核心信息。很多人喜欢一页PPT堆满文字，评委根本看不清，而且照着PPT念是答辩大忌。

我建议PPT控制在12~15页。结构可以按这条线走：选题背景与研究意义，系统需求分析，系统架构图，功能模块划分，数据库ER图与核心表说明，系统主要功能演示截图，系统测试情况，总结与展望。

答辩现场的操作顺序，我强烈建议你事先排好。无论用什么方式演示，按这个顺序最不容易乱：先登录管理员账号，展示教师管理、学生管理、评价模板配置、学期管理；再退出登录学生账号，演示查看待评教师、填写评价表、提交评价；最后切换教师账号，查看评价结果和图表。这个顺序完整走一遍，系统的主要功能就全部展示清楚了，也符合业务逻辑链。

PPT上有一个小技巧，页面上的截图要提前“修剪”干净，不要露出数据库地址、控制台日志、IDEA报错信息等无关内容。截图里的浏览器地址栏、开发环境窗口标题，最好也处理干净，不然会显得很业余。

5.3 源码与注释的工程规范

源码组织对答辩加分有很大的帮助，但也是很多同学最忽视的地方。我看到过不少项目的源码文件名还是默认的“新建文件夹”或者汉字命名，注释几乎没有，打包也缺README，这是非常减分的。

合理的源码组织结构应当是，后端Maven工程严格按照standard目录结构，文件命名遵循驼峰规范，Controller/Service/Mapper分层清晰；前端是Vue工程，页面放在views目录下按角色分文件夹，公共组件放components目录。

注释不需要每行都写。正确做法是，在每个类上方写清楚类的职责，在每个公开方法上方写清参数含义和业务逻辑。比如“提交评价”这个方法，注释里应当说明“校验当前学期、校验任务、防重复、保存主记录和答案明细”这几步。

最后强烈建议写一个README.md，内容包括：项目介绍、环境要求、数据库脚本执行方式、启动步骤、默认账号、功能列表。这不仅是给答辩老师看的，也是给未来的自己看的，一周之后你再看自己的代码，就知道README有多重要了。

6. 环境搭建与部署踩坑实录

6.1 本地开发环境配置

这部分是很多初学者卡壳的地方。教师评价系统的开发环境，我推荐使用一套稳定且经过验证的版本组合，不要盲目追求最新版。

JDK推荐1.8，倒不是说新版本不好，而是绝大多数Spring Boot项目的网上资料、排错经验都是基于JDK1.8的，遇到问题容易查到解决方案。Maven用3.6+，IDEA用任意较新的版本，MySQL用5.7或8.0都可以。Spring Boot版本选择上，推荐使用2.7.x的最终版本。为什么不用Spring Boot 3.x？因为3.x最低要求JDK17，而且很多旧教程的依赖坐标在新版本下面不兼容，对做毕设项目来说，选2.7.x是风险最低的选择，开发体验和功能都足够。

一个很常见的问题是本地已经装了JDK17或更高版本，而项目要求JDK1.8。建议用IDEA的Project Structure把项目SDK切到1.8，同时确认Maven的Settings里的Java版本是1.8，不然pom.xml里配置了source/target，实际编译还是可能用错版本。

6.2 Spring Boot版本兼容性问题处理

这里分享两个我在实际项目中遇到过的真实问题。

第一个问题很典型。Spring Boot 3.x里，javax.包名被换成了jakarta.。如果你从网上找到的参考代码还是import javax.persistence，在Spring Boot 3.x下会直接编译报错。如果你已经用了Spring Boot 3.x，解决办法就是全局替换import javax为import jakarta。但这个替换涉及的地方可能很多，所以我更推荐直接用2.7.x，省去这一系列麻烦。

第二个问题是我在使用Spring Security时踩的坑。网上大量的教程还在用WebSecurityConfigurerAdapter这种方式配置安全规则，但在Spring Boot 2.7.x中，这个类已经被废弃了。我当时照着旧教程写完，启动时确实能用，但IDEA里全是废弃警告，而且后来升级小版本后直接跑不起来了。解决办法是用SecurityFilterChain + HttpSecurity的Bean方式配置，功能完全一致，代码还更简洁。

6.3 常见部署问题排查

我把实际部署中碰到的问题整理成了一份排查清单，做同样项目时可以少走不少弯路。

数据库连不上的情况，首先要检查MySQL服务是否启动，然后检查application.yml里的数据库连接配置是否正确。MySQL 8.x的驱动类名是com.mysql.cj.jdbc.Driver，不是旧版的com.mysql.jdbc.Driver。连接URL里最好加上useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，不然中文乱码和时区问题会一起找上门。

端口被占用是启动失败的另一个高频原因。Spring Boot默认端口是8080，如果你本机开了多个服务，就会报“Port 8080 was already in use”。解决办法是在application.yml里改端口，或者启动时用--server.port=8081参数临时指定。

还有一个隐藏比较深的问题：MyBatis-Plus的Mapper接口扫描。如果你启动时遇到“Invalid bound statement”的报错，说明Mapper接口和XML文件没有关联上。检查启动类上有没有加@MapperScan注解，检查XML文件是否放在resources/mapper目录下，以及mybatis-plus.mapper-locations配置是否正确。

打包部署环节，我建议用Maven的package命令打成jar包，然后用java -jar方式运行。运行前先在本地验证一遍打包好的jar能正常启动，而不是只会在IDEA里点运行。对于有容器化部署需求的同学，可以写一个简单的Dockerfile，把jar包打进镜像，用docker desktop运行。基础镜像选择openjdk:8-jre-alpine就行，别选太大的镜像，不然构建和拉取时间都很难受。

关于Spring Boot应用启动后窗口关闭就停止的问题，这在远程服务器上比较常见。可以加一条nohup命令挂后台运行：nohup java -jar teacheval.jar > app.log 2>&1 &。日志文件保留在app.log里，排查问题时就靠它了。

6.4 评价业务逻辑的测试验证

系统开发完成后，测试这部分不要敷衍。我建议至少覆盖以下几条关键用例：

• 学生正常提交评价后，数据库出现一条主记录和对应答案明细。
• 学生对同一教师重复提交，系统提示“已评价”，不产生脏数据。
• 非当前学期，学生不能提交评价。
• 学生无法通过修改URL访问管理员接口。
• 教师只能查看自己的评价结果，不能查看其他教师数据。
• 管理员导出统计报表时数据汇总正确，指标权重计算与手工核算一致。

把测试用例固化下来，在答辩时可以当作“系统测试”章节的素材，也是展示严谨性的加分项。

我这里补一段Service层单元测试的基本结构，供参考。用Spring Boot Test + Mockito，可以轻量地验证核心业务逻辑，不需要启动完整数据库环境。

@SpringBootTest @Transactional class EvaluationServiceTest { @Autowired private EvaluationService evaluationService; @Test void testSubmitTwice_shouldThrowException() { // 构造第一次提交，成功 evaluationService.submitEvaluation(buildSingleRequest()); // 构造第二次提交，应该抛出业务异常 assertThrows(BusinessException.class, () -> evaluationService.submitEvaluation(buildSingleRequest())); } }

这类用例很能体现一个开发者的工程素养。答辩时老师问到“怎么证明你的系统是无误的”，你拿出这些测试用例，比说一百句“我测过了”都有说服力。

做完整个教师评价系统，我的总体感受是：业务型系统的技术难点其实不在某个单独的技术点，而在于怎么把多个技术点串成一个逻辑自洽的整体。评价模板怎么设计才能灵活配置，防重复怎么实现才能既简单又可靠，角色权限怎么划分才能保护数据安全，统计口径怎么统一才能让图表有意义，这些才是真正考验设计能力的地方。Spring Boot只是把开发门槛降低了，背后的业务建模和工程组织能力，才是你在这个项目中真正获得的东西。