如果你正在做基于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 数据库表结构规划基于上面的业务分析我设计了以下几张核心表。先声明一下这是我在实际项目中经过多轮调整后的方案不是教科书上的标准答案但基本覆盖了教师评价系统的主要业务场景。用户表设计上我采用了统一账号表加扩展表的方案。用户表保存登录账号、密码、角色教师和学生分别用扩展表保存各自独立的业务属性。这样做的原因是登录认证只需要查一张表而教师信息、学生信息又不会相互干扰。表名作用关键字段sys_user登录账号统一管理username, password, role, real_nameteacher_info教师扩展信息user_id, teacher_no, title, collegestudent_info学生扩展信息user_id, student_no, major, gradesemester学期信息name, statuseval_template评价模板name, type, remarkeval_dimension评价维度template_id, name, weighteval_item评价题项dimension_id, content, max_scoreeval_record评价提交记录student_id, teacher_id, template_id, semester_id, total_scoreeval_answer评价答案明细record_id, item_id, score, comment这里重点说几个容易设计错的表。一是评价记录表。为了防止同一个学生对同一个教师同一学期重复评价必须在这张表上建立联合唯一约束字段组合是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出参用VOEntity只在Service和Mapper之间传递。虽然代码量会多一点点但结构清晰接口文档也好写。3.2 评价业务核心接口设计接口设计直接决定前后端协作效率和代码可维护性。这整套系统我梳理下来核心接口大概是下面这些接口说明角色POST /api/auth/login登录认证返回JWT令牌全部GET /api/student/todo-teachers获取当前学期待评教师列表学生GET /api/student/eval/form/{teacherId}获取指定教师的评价表单学生POST /api/student/eval/submit提交评价数据学生GET /api/teacher/eval/result查看个人评价结果教师GET /api/admin/teachers教师信息分页查询管理员POST /api/admin/teachers新增教师管理员PUT /api/admin/teachers修改教师信息管理员DELETE /api/admin/teachers/{id}删除教师管理员GET /api/admin/stats/overview评价结果统计分析管理员以最关键的提交评价接口为例。这个接口表面上只是接收一个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 LambdaQueryWrapperEvalRecord() .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.6IDEA用任意较新的版本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里最好加上useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai不然中文乱码和时区问题会一起找上门。端口被占用是启动失败的另一个高频原因。Spring Boot默认端口是8080如果你本机开了多个服务就会报“Port 8080 was already in use”。解决办法是在application.yml里改端口或者启动时用--server.port8081参数临时指定。还有一个隐藏比较深的问题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 21 。日志文件保留在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只是把开发门槛降低了背后的业务建模和工程组织能力才是你在这个项目中真正获得的东西。