企业官网建设流程全解析

做教师评价系统这个题目的人不少，但很多同学卡住的往往不是代码本身，而是不知道怎么把 Spring Boot、数据库、权限控制、评价流程这些散件组合成一套能跑通、能答辩、能写进论文的完整项目。这篇文章就以一个典型的 Spring Boot 教师评价系统为例，从需求拆解、数据库设计、核心功能实现，到开发环境配置、调试部署，再到常见坑位排查，完整过一遍。无论你是拿它做毕业设计、课程设计，还是想练手 Spring Boot 全流程开发，这套思路都可以直接套用。

项目本身属于典型的 Java Web 管理系统，后端用 Spring Boot，前端用模板引擎加 Bootstrap 这类轻量方案，数据库用 MySQL，配套源码、数据库脚本、调试部署文档和一万字以上的论文说明。这类项目的价值不在于功能有多炫，而在于它把日常开发中最常用的技术点都串起来了，而且每个环节都有明确的交付物，非常适合作为学习样板。

1. 项目整体设计与功能拆解

1.1 需求分析与角色权限设计

教师评价系统的核心业务不复杂，就是“学生评教、教师看结果、管理员管全局”。但简单归简单，三个角色的权限边界必须一开始就划清楚，否则后面写接口的时候会到处打补丁。

系统里至少要拆出三类角色：

• 学生：登录后能看到自己需要评价的课程或教师列表，逐项打分、填写评语、提交评价。学生只能评价自己被分配的教师，不能评价无关人员，也不能重复评价。
• 教师：登录后能查看学生对自己的评价结果，包括各项指标的平均分、评语汇总、评价人数等。教师只能查看自己的数据，不能看到其他教师的评价。
• 管理员：负责维护教师信息、学生信息、课程信息、评价指标项，设置评价批次（比如按学期启用/关闭评教），统计和导出所有评价结果。

这个权限模型的本质是“登录用户 + 角色 + 数据范围”三层控制。登录和角色判断负责“能不能进这个功能”，数据范围负责“进去之后能看到哪些数据”。很多初学者只做了前两层，结果教师登录后可以通过改 URL 参数看到别人的评价记录，这在答辩时很致命。

权限相关的表建议直接设计成 user 表加 role 字段的方式，而不是单独拆 user_role 中间表。原因很简单：这个系统的角色是固定枚举，不会出现一个用户同时是学生又是教师的情况，把角色字段直接放在用户表里，代码判断最简单，查询也少一次关联。如果以后真的要做复杂的 RBAC（基于角色的访问控制），再拆中间表也不迟，毕设阶段没必要过度设计。

1.2 技术栈选型与理由

这个项目选型非常典型，很多教材和培训机构都这么教，因为它稳定、资料多、出了问题能搜到答案。

• JDK 1.8 + Spring Boot 2.x：这组合是当前兼容性最好的黄金搭配。JDK 1.8 不挑环境，Spring Boot 2.7.x 版本成熟稳定，各种第三方 starter 的兼容性都验证过。如果非要上 JDK 17 和 Spring Boot 3.x，大概率会遇到 javax 包名改成 jakarta、MyBatis 插件不兼容一类的问题，新手排查起来非常痛苦。建议老老实实 JDK 1.8 + Spring Boot 2.7，别在版本上搞花活。
• MySQL 5.7 或 8.0：两者在语法上有细微差异，如果项目里用到了 8.0 的窗口函数之类特性就选 8.0，否则 5.7 完全够用。需要注意 8.0 的驱动类名是 com.mysql.cj.jdbc.Driver，5.7 也能用这个驱动，但 5.7 时代常用的 com.mysql.jdbc.Driver 在 8.0 下会报错。
• MyBatis-Plus 3.5.x：相比原版 MyBatis，MyBatis-Plus 最直接的优势是自带的 BaseMapper 把单表增删改查全部封装好了，你只需要写业务方法和复杂查询的 SQL。教师评价系统里大量操作是单表 CRUD 加简单条件查询，用 MyBatis-Plus 能省下至少三分之一的工作量。
• 前端方案：Thymeleaf 服务端渲染加 Bootstrap 布局。这种方案的好处是不需要单独起前端服务，页面和后端打成一个 jar 包就能跑，部署成本极低。如果上 Vue 前后端分离，虽然界面更现代，但需要处理跨域、前端构建、接口联调等一系列问题，毕设阶段容易把自己绕晕。
• 数据库连接池：Druid 或 HikariCP 都行。Spring Boot 2.x 默认用 HikariCP，性能很好，零配置直接跑。Druid 多一个监控页面，可以在浏览器里看 SQL 执行情况，答辩演示的时候会好看一些，但配置项也更多。如果不熟建议直接用默认的 HikariCP，少配置就少出错。

选型的时候有个原则：用你自己最熟悉、资料最多的技术，不要为了炫技引入没把握的框架。教师评价系统这种项目，技术点越稳越好，重点是把业务逻辑写清楚。

2. 数据库设计与核心表结构实现

2.1 数据模型设计思路

数据库设计是整个项目的地基。很多同学喜欢上来就写代码，写到一半发现表结构不对疯狂返工，这是最浪费时间的。我的习惯是先花半天时间把表设计出来，再用草稿纸把表之间的关系画一遍，确认无误后再动手建库建表。

教师评价系统的基础表可以拆成这几张：

• user：用户表，包含学生和教师账号，以及管理员账号，通过 role 字段区分。
• teacher：教师信息表，存放教师姓名、工号、职称、所属院系等基本资料。
• student：学生信息表，存放学号、姓名、班级、专业等资料。
• course：课程表，记录课程名称、授课教师、上课时间等信息。
• evaluation_config：评价批次配置表，控制某个评价任务的时间范围和状态。
• evaluation_indicator：评价指标表，存储评价维度，比如“教学态度”“课堂互动”“作业批改”等。
• evaluation_record：评价记录表，核心业务表，一条记录代表学生对某位教师某门课程的一次评价。
• evaluation_detail：评价明细表，按指标项存储每一个维度上的具体得分，和评价记录表是一对多关联。

这里有个设计取舍：为什么不把所有指标得分直接塞进 evaluation_record 表？比如加 score1、score2、score3 这样的字段。确实有人这么干，但一旦评价指标要动态调整（管理员新增一个评价维度），表结构就要改，代码也要改。而拆成明细表之后，指标可以存在配置表里，动态增删，主表不需要动，扩展性完全不一样。

2.2 关键表结构详解

下面给三张核心表的具体设计，这也是数据库设计文档里必须写清楚的部分。

user 表

evaluation_record 表

这张表有一个非常关键的约束：唯一索引要建立在 student_id + teacher_id + course_id + batch_id 上。意思是同一个学生、在同一批次、对同一门课程只能评价一次。这是防止重复评价的数据库层面兜底，不能只靠代码判断。

evaluation_detail 表

这个明细表本质上是在记录“哪一次评价”+“哪一个指标”+“得了多少分”，通过 record_id 和 indicator_id 两个外键管理关联关系。查询某个教师的平均分时，只要按 teacher_id 关联记录表，再按指标分组聚合明细表就行。

表之间不要用物理外键，最好只用逻辑关联。我的理由是物理外键在插入数据时有额外的约束检查，会影响写入性能，而且后期如果要做分库分表或者数据迁移，物理外键就是大麻烦。在项目里只需要保证 MyBatis-Plus 的实体类里有对应字段做关联查询就够了，数据库层面的约束用索引来控制。

2.3 初始化数据与脚本组织

数据库脚本的存放方式也有讲究，不要只给一个 database.sql 扔在那里。常见的组织方式是分成三份：

1. schema.sql：建库建表语句，按依赖顺序执行。先建 user、teacher、student，再建 course，最后建评价相关的表。
2. data.sql：初始化数据，包含一个管理员账号、若干个测试老师、测试学生、以及一套默认的评价指标。
3. demo_data.sql：演示数据，生成几十条评价记录，方便直接看统计效果。

这样做的好处是，正式交作业时评阅老师可以按顺序执行脚本，一两分钟就能跑起一套完整的环境。如果你的论文里有“系统测试”章节，演示数据也方便截图。

3. 核心功能模块开发与实现细节

3.1 登录鉴权与角色权限控制

用户登录和权限控制是每个管理系统的第一道关口，教师评价系统也不例外。这里我用的方案是 Session 加拦截器，没有引入 Spring Security 和 JWT。原因很简单：这套系统是单体应用，前后端不分离，Session 天然够用；Spring Security 虽然功能强大，但配置复杂，新手学起来成本高，遇到权限坑容易卡住。

登录成功后，把用户 ID 和角色存到 Session 里，同时加一个全局拦截器：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object userId = session.getAttribute("userId"); if (userId == null) { response.sendRedirect("/login"); return false; } return true; } }

拦截器注册到 Spring Boot 配置类里，注意放行登录页、静态资源这些不需要登录就能访问的路径。

那怎么区分学生、教师、管理员呢？我的做法是写一个简单的角色判断工具类，或者直接在 Controller 里从 Session 里取出角色字段做判断。比如学生评价的接口，进入方法前先检查当前登录用户角色是否为 1；教师查看评价结果的接口，检查角色是否为 2。角色不对就返回一个错误提示页或者 JSON 数据。

实际开发中我发现一个容易被忽略的细节：教师查看自己的评价结果时，不能只在前端隐藏其他教师的数据，后端查询接口必须强制加上当前登录教师的 ID。也就是说，接口的路由可以设计成/teacher/evaluation/result，但内部逻辑是根据 Session 里的教师 ID 去查，而不是接收前端传过来的 teacherId 参数。这是最基础的数据越权防护，也是答辩时老师很喜欢问的一个点。

密码加密部分统一用 BCrypt。Spring Boot 的 spring-security-crypto 包里直接提供了 BCryptPasswordEncoder，不需要引入整个 Spring Security，用法很简单：

// 密码加密 String encoded = passwordEncoder.encode(rawPassword); // 密码校验 boolean matches = passwordEncoder.matches(rawPassword, encodedPassword);

绝对不能明文存密码，也不能用简单的 MD5。BCrypt 每次加密结果都不同，但校验逻辑可以正常匹配，安全性比 MD5 高一个数量级。

3.2 评价流程实现与防重复提交

评价流程是整个系统的核心业务。学生登录后看到自己本学期需要评价的课程列表，点进去之后逐项打分，最后填一段评语提交。

这个流程里有三个重点：

第一，待评价列表怎么来。

待评价列表不是管理员手动给学生一条条分配的，而是通过课程表推导出来的。课程表里记录了每个课程对应的教师和上课班级，学生所属的班级匹配上了，就把这门课程加入该学生的待评列表。SQL 大致是这样：

SELECT c.id AS course_id, c.course_name, t.teacher_name, c.semester FROM course c JOIN teacher t ON c.teacher_id = t.id WHERE c.class_id = #{classId} AND c.id NOT IN ( SELECT course_id FROM evaluation_record WHERE student_id = #{studentId} AND batch_id = #{batchId} )

这个查询里 NOT IN 子查询非常关键，它直接把已经评过的课程过滤掉，避免学生重复评价。

第二，防重复提交的三重保障。

• 前端：提交按钮点击后立即置灰，并加 loading 提示，防止学生双击。
• 业务层：提交评价前先查 evaluation_record 是否存在该学生对这门课程的记录，存在则直接抛异常。
• 数据库层：在 evaluation_record 表上建了解释过的唯一索引，即使前两层都失效，数据库也能拦住。

这三道防线缺一不可。前端负责体验，数据库负责兜底，业务层负责友好提示。

第三，总分怎么算。

计算总分前要先确认评价方式。教师评价系统常见的评分方式有两种：一种是所有指标按百分制打分，然后取平均值；另一种是每个指标分权重，加权求总。权重方案更科学，因为“教学态度”和“课堂互动”的重要程度可能不一样。

假设配置了一个权重表，比如指标 A 权重 0.4、指标 B 权重 0.3、指标 C 权重 0.3，那总分就是：

总分 = 指标A得分 × 0.4 + 指标B得分 × 0.3 + 指标C得分 × 0.3

存储的时候，建议把加权后的结果存到 evaluation_record.total_score 字段里。这样统计教师成绩时不需要每次临时计算，只要直接按教师 ID 分组求平均值就行。如果用的是 MyBatis-Plus，这个需求可以这样实现：

QueryWrapper<EvaluationRecord> wrapper = new QueryWrapper<>(); wrapper.select("teacher_id", "AVG(total_score) AS avg_score") .eq("batch_id", batchId) .groupBy("teacher_id");

3.3 评价结果统计与图表展示

评价结果的展示是这类系统最出彩的部分，因为它直接关系到一个教师端的好用程度。统计逻辑不复杂，本质就是聚合查询加数据可视化。

常见的统计维度有三个：

1. 按教师汇总：每个教师的综合平均分、评价人数、各指标得分。管理人员打开页面就能看到全局排名。
2. 按指标分析：比如全校学生对“课堂互动”这项指标的平均分是 4.2，横向对比能看出教师整体在哪些方面偏弱。
3. 按批次对比：同一个教师在不同学期的评价得分变化趋势。这个功能需要记录批次信息，所以在 evaluation_record 表里特意留了 batch_id 字段。

可视化方面，如果用的是 Thymeleaf 加 Bootstrap 的轻量方案，推荐直接引入 ECharts 的 CDN，用几个简单的折线图和柱状图就能搞定。ECharts 的图表本质上是 JS 数据对象，后端把统计数据封装成 JSON 返回，前端用 Thymeleaf 的 th:inline 解析 JSON 渲染图表。

如果还需要导出 Excel，可以用 EasyExcel 或者 Apache POI。EasyExcel 的 API 设计更友好，而且内存占用比 POI 低很多。导出内容建议包含教师姓名、工号、课程名、各指标得分、平均分、评价人数、评价批次这些字段，这也是论文里“数据导出模块”的展示重点。

4. 开发环境搭建与调试部署

4.1 开发环境清单与版本匹配

先列一张环境版本表，个人建议严格按这套来，别擅自升级：

这里特别提醒一个坑：Spring Boot 3.x 和 2.x 的包名不一样，所有 javax.servlet 开头的类都要改成 jakarta.servlet。如果你习惯看网上的旧教程，拿着 Spring Boot 2.x 的代码去配 3.x 的项目，会有大量类找不到的报错。所以真的别用版本太高的 Spring Boot，除非你有把握处理包名迁移问题。

4.2 Spring Boot 核心配置详解

项目跑起来第一件事是配置 application.yml。下面是一份精简配置，其中每一步都有存在的理由：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/teacher_evaluation?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 thymeleaf: cache: false mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

几个关键参数的说明：

• serverTimezone=Asia/Shanghai：很多同学 JDBC 连接 MySQL 8.0 时报错，报时区问题，加入这个参数基本能解。这是数据库连接必填项，没有它 MySQL 8.0 会直接拒绝连接。
• characterEncoding=utf8：保证中文正常存储和读取。如果你发现插入的数据变成问号，九成是这里没配或者数据库的字符集不对。
• thymeleaf.cache=false：开发阶段必须关掉模板缓存，否则你改了 HTML 页面刷新浏览器不生效。部署到生产环境时再打开缓存提升性能。
• map-underscore-to-camel-case=true：让数据库的 user_name 自动映射成 Java 实体的 userName，省去大量手写映射。
• StdOutImpl：启动后 SQL 语句会打印在控制台，排查数据库问题非常方便。这是 MyBatis-Plus 自带的功能，默认是关闭的，开发阶段建议打开。

4.3 项目启动与端到端调试

整套项目的启动流程可以缩成四步：

1. 创建数据库：在 MySQL 里执行CREATE DATABASE teacher_evaluation DEFAULT CHARACTER SET utf8mb4;。
2. 导入表结构：把 schema.sql 和 data.sql 按顺序导入。
3. 修改配置：确认本地 MySQL 用户名和密码，与 application.yml 保持一致。
4. 启动项目：IDEA 里直接运行主启动类，控制台看到 “Started Application in x.x seconds” 就是成功了。

运行之后建议按这个顺序做一遍完整的端到端自测：

• 用管理员账号登录，新增一个教师、一个学生、一门课程，配置好评价指标。
• 启用评价批次。
• 用学生账号登录，看到待评价课程，完成一次评价。
• 用教师账号登录，查看自己的评价结果。
• 用管理员账号查看统计汇总，尝试导出 Excel。

这个链路走通一遍，系统就没有大问题了。如果中途某个环节报错，优先看控制台日志，定位是前端报错还是后端接口报错，再决定排查方向。

部署方面，这个项目最简单的方式就是打 jar 包。在 IDEA 右侧 Maven 面板执行mvn clean package -DskipTests，在 target 目录下会生成一个可执行 jar 包。上传到服务器，执行：

java -jar teacher-evaluation-system.jar

后端就启动了。如果服务器有 Docker，也可以写一个简单的 Dockerfile 做容器化部署，但这不是必须的，毕设阶段直接 jar 包运行完全能说明问题。

5. 常见问题排查与避坑经验

5.1 启动阶段高频报错与解决

花了大量时间整理这几年做同类项目最常遇到的启动报错，整理成表格直接供对照：

启动报错记住一个核心原则：看最早的 StackTrace，不要被后面的刷屏信息干扰。Spring Boot 启动报错时经常刷一长串异常，很多时候真正原因在最上面第一条。

5.2 运行期问题与功能 bug 排查思路

跑起来之后的问题更隐蔽，这里挑三个最常见的典型说。

页面能打开但 CSS、JS 不加载：大概率是拦截器把静态资源拦截了。在拦截器注册类里要放行/static/**、/css/**、/js/**、/images/**这些路径。另外如果用 Thymeleaf，注意 HTML 里引资源时要写th:href="@{/css/style.css}"，不能写死路径，否则带项目上下文时资源会 404。

表单提交后中文乱码：先确认数据库本身字符集是 utf8mb4，再确认 JDBC URL 有 characterEncoding=utf8，最后确认前端页面有<meta charset="UTF-8">。这三层有一层不对，都可能在某个环节变成问号。

做完修改刷新后页面还是旧内容：看两处，第一是 Thymeleaf 缓存没关，第二是浏览器缓存。开发阶段把spring.thymeleaf.cache=false配上，浏览器按 Ctrl+F5 强刷。

还有一种非常常见的场景：改了 Controller 代码，重启后功能不生效。大多数时候是类没重新编译。IDEA 里执行Build -> Rebuild Project，或者执行mvn clean compile再重启，基本能解决。

5.3 项目文档与论文写作的衔接建议

这个项目带了一万字以上的论文，论文结构一般按“绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结”来写。这一节给你的建议是：代码和文档最好同步做，而不是代码写完了再补论文。

具体做法是，在开发过程中随时记录：

• 数据库表的设计截图和说明，放在“系统设计”章节。
• 核心功能页面的截图，放在“系统实现”章节。
• 登录、评价、统计这些主要接口的测试用例和结果截图，放在“系统测试”章节。
• 启动部署步骤的文字描述，放在“系统运行环境说明”章节。

论文里的技术介绍部分，重点写 Spring Boot 的自动装配原理、MyBatis 的映射机制、MySQL 的索引和事务隔离级别，这些是答辩时老师常问的点。不要直接复制官方文档，最好结合教师评价系统的实际场景来解释，比如“本项目在评价记录表上建立了联合唯一索引，以保证同一学生对同一课程只能提交一次评价”，这句话比空谈索引概念有力得多。

答辩演示时也要准备一套完整的数据流演示脚本：管理员建指标、设置批次、导入学生教师信息、学生评教、教师查看结果、管理员导出统计。按这个顺序走一遍，基本能覆盖系统的所有核心功能，评审老师的印象也会好很多。

6. 一些觉得值得说的实战心得

最后分享几个实际做这类项目时积累的经验，不一定写进文档，但对真正动手做的人来说可能更有用。

第一，先跑通最简链路，再逐步加功能。我第一次做这个项目时就犯过贪多的错误，一开始就把评价指标、权重计算、图表统计全部做完，结果代码写到一半，发现评价流程没跑通，到处找问题找到了半夜。正确做法是先用最简单的单表逻辑把“学生登录、提交一条评价记录、教师查到结果”这条链路跑通，再在这个基础上加指标明细、权重、统计报表这些外围功能。每加一个功能都跑一遍回归测试，确保主干一直可用。

第二，前端表单校验别只放在后端，但也别只放在前端。比如指标的得分，合理范围是 1 到 5 分或 0 到 100 分，前端用 HTML 的 min/max 属性限制输入范围，后端用参数校验注解（@Min、@Max）或手动判断再拦截一次。只做一层校验的后果是，要么学生可以绕过前端直接提交非法数据，要么后端代码被各种非法参数拖垮健壮性。

第三，这是一个可以继续往外扩展的项目。如果做完基础功能还有余力，可以考虑几个方向：用消息队列（比如 ActiveMQ 或 RabbitMQ）把评价记录的保存改成异步削峰，模拟选课高峰期大批学生同时提交评价场景；给系统加上 API Key 校验机制，让第三方教务系统可以安全地调用你的接口同步教师和学生数据；或者用 Redis 缓存评价指标配置，减少数据库压力。这些扩展点虽然不会大幅改变功能，但写在论文的“未来展望”里，会让整个课题的深度上一个台阶。

教师评价系统这类项目，真正做完你会发现，它不复杂，但很完整。通过它把 Spring Boot 的开发流程、数据库的设计与优化、权限控制的基本思路、项目部署的常见方式全部串了一遍，这才是这个项目最大的价值。按照上面这套设计、开发、部署、排查的流程走一遍，你拿到的就不只是能跑的程序，而是一整套可复用、可扩展的开发方法论。