企业官网建设流程全解析

每年毕设选题季，后台私信问我最多的问题就是“商城项目是不是太土了”“管理系统还能不能做”。说实话，“学生成绩管理”“图书借阅管理”这类题答辩现场撞车概率极高，评委一听开头就能猜到后面所有内容。相比之下，“学生对老师评分意见反馈平台”这个方向选的人少，业务逻辑贴近真实校园场景，而且天然带几个值得深挖的点：匿名反馈、防重复评分、统计聚合展示。它用的又是 Java + SpringBoot 这套最主流的 Web 技术栈，非常适合作为计算机毕业设计。

这篇文章我按自己实际带毕设、帮人改项目的经验，把这个“师生评价反馈平台”从需求定位、技术选型、数据库设计、后端接口到前端交互和答辩准备完整过一遍。不管你是正在选题纠结方向，还是已经开工卡在某个环节，照着这条思路走，至少能少踩一半的坑。

1. 选题价值与需求边界：这不是又一个“管理系统”

1.1 为什么是“师生互评”而不是购物商城

毕业设计选题有个不成文的评判标准：评委看的是你有没有把一个真实业务问题想明白，而不是堆了多少代码。购物商城类的题确实好凑功能——注册、登录、商品列表、购物车、下单，但它的问题也恰恰在这里，代码写的再多，业务逻辑就是增删改查，答辩时很难讲出亮点。

师生评价反馈平台不一样。它的核心业务是“一个学生在一门课的一个评价周期内，只能对老师提交一次评分，并且可以填写匿名文字意见；老师端只能看到统计分数和意见内容，不能看到是谁写的”。这句话里藏着三个真正值得讲的东西：防重复提交、匿名性设计、数据聚合统计。任何一个拿出来展开讲，都比“我用了 Redis 缓存热点商品”这种话实在得多。

另外从工作量角度说，这个题的规模非常合适。一个人开发周期六到八周，核心功能做完还能有余力做数据导出、可视化图表这类加分项，不至于像大型电商项目那样做到一半发现工期崩了。

1.2 三个核心角色与主流程

这个系统里只有三类用户，边界非常清楚：

• 学生：查看自己当前学期需要评价的课程，进入评分页给授课老师打分（分几个维度），填写文字意见，提交后不可修改。
• 老师：查看自己各门课程的评价结果，包括分项平均分、综合评价总分、学生的文字反馈列表。
• 管理员：维护学生、教师、课程、授课关系、评价周期等基础数据，查看全局统计和导出数据。

主流程一句话就能讲完：管理员发布一轮评价任务（比如“2024-2025学年第一学期评教”）并设置起止时间，学生在时间窗口内对每门课的老师完成评分，结束后老师登录查看结果。

这个流程最大的优点是它构成了一个完整闭环，从数据录入到业务处理再到结果展示，每一步都有真实的业务含义，答辩时顺着这个流程讲一遍，评委立刻就能明白你做了什么。

1.3 需求边界：什么该做，什么不该做

很多毕设项目做砸不是因为功能太少，而是因为需求失控。用户管理出来了还想做角色权限，权限做完了又想上消息通知，最后项目变成一团乱麻。

我给这个题划的需求边界是这样的：

• 该做：登录注册、课程与授课管理、评价任务管理、学生评分提交、防重复校验、教师端统计展示、基础的数据导出。
• 不该做：私信聊天、公告系统、复杂的审批流、移动端适配（能用但不能作为主推点）、权限框架深度定制。

边界划好之后，开发节奏就非常容易控制：前两周搭骨架和做用户/课程模块，中间三周啃核心的评分流程和统计展示，最后一周做导出和答辩材料。这样安排时间，即使中间出现意外也有缓冲。

2. 技术选型怎么定：SpringBoot 做主力，其他组件图省心

2.1 SpringBoot 版本选 2.7 还是 3.x

技术选型是答辩时评委必问的环节，你需要对每个选择都给出理由。SpringBoot 本身没什么悬念，它是目前 Java Web 开发事实意义上的标准方案，内嵌 Tomcat、自动配置、生态完善，毕设题目里也明确点了 Java+SpringBoot。

但版本上有个容易踩的坑。现在很多人一上来就装 SpringBoot 3.x，结果发现 JDK 版本要求 17 以上，有些老旧教程的代码和依赖还跑不起来，白白浪费时间。

我的建议是：如果你不是特别想展示新特性，直接选SpringBoot 2.7 + JDK 8 或 JDK 11。理由很简单——网上教程多、出问题搜得到答案、MyBatis 等配套组件兼容性稳。如果评委问为什么不用 3.x，你就回答“考虑到生态兼容性和稳定性，生产环境大量存量项目仍以 2.x 为主，我选择这个版本是为了贴近实际工程现状”。这个回答比“我不会”高级太多了。

2.2 数据层：MyBatis-Plus 与代码生成

数据持久层我推荐 MyBatis-Plus，没有第二个选项。官方文档全，中文社区活跃，而且内置的 CRUD 方法和分页插件能把开发效率拉高一截。

具体到开发方式，有一个经验分享给你：不要手写每张表的 Mapper 和 XML。用 MyBatis-Plus 的代码生成器（或者 Idea 插件，比如 EasyCode）根据数据库表一键生成实体类、Mapper 接口、Service 骨架，再把精力集中在业务逻辑复杂的查询上。

这样做的两个好处：一是避免无意义的重复劳动，二是生成的代码结构规范统一，评审老师看到你代码整洁度也会加分。

有一点要提醒：MyBatis 和 MyBatis-Plus 不要混用。你可能会在网上搜到一些老的 XML 写法教程，看了之后在自己的项目里又想手写 SQL 又用 Plus 的 API，最后搞得代码风格非常割裂。统一用 MyBatis-Plus 的 Wrapper 写法，复杂统计 SQL 再单独写在 XML 里，风格就能保持干净。

2.3 前端方案：Thymeleaf 还是前后端分离

这个问题我每年都要被人问一次。我的观点非常明确：毕设场景下，时间紧就选服务端渲染（Thymeleaf + Bootstrap + jQuery），想做亮点且有前端基础就选前后端分离（Vue 3 + Element Plus）。

前后端分离确实是目前企业的主流模式，但你得衡量自己的精力和排错能力。分离架构意味着你要同时维护两个项目、处理跨域、管理接口文档、最后还要打包部署联调。一旦前端某个环节出问题，排查链路会拉长很多。很多学生卡在 Vue 打包之后请求不到后端接口，白折腾两天。

如果你选了 Thymeleaf，页面渲染直接由后端控制，用一个浏览器就能完成全部开发调试，部署就是一个 JAR 包，非常符合毕设演示场景。而且 Thymeleaf 本身也能做出不难看的页面，配合 Bootstrap 的组件库和一点点自定义 CSS，视觉效果足够体面。

2.4 会话与权限：Spring Security 之外的轻量选择

权限控制是另一个容易过度设计的地方。很多教程一上来就是 Spring Security + JWT，配置写了一堆，结果自己被过滤器链绕晕，页面都特么跳不明白。

这个项目的角色只有三种，权限逻辑很简单，根本不需要引入重量级安全框架。用拦截器 + Session就能完美解决：

• 登录成功后把用户 ID 和角色放进 Session。
• 写一个拦截器，拦截所有需要登录的请求，检查 Session 里有没有用户。
• 再按角色判断访问权限：学生不能访问教师统计页，教师不能访问后台管理页。

这套方案代码量少、逻辑透明、本身就是标准 Java Web 技术，答辩完全站得住脚。别为了显得“高级”给自己挖坑。

3. 数据库设计：评分记录的防重与匿名是核心关卡

3.1 核心表结构一览

数据库设计是整个项目的地基，也是答辩时评委大概率深挖的地方。我的建议是不要过度设计，六张表足够覆盖这个项目所有业务。

用户表把三种角色合并成一张表，在很多人看来可能不习惯，但我认为这样最合适。评价系统里老师和学生的属性其实是重叠的（姓名、账号、密码），拆成两张表反而是冗余，而且登录逻辑还要做两次判断，纯属找麻烦。

evaluation_record表是这个系统的灵魂。四个评分字段分别对应四个维度，比如教学态度、教学内容、教学方法、课堂效果。如果你想让评分项可配置，可以拆出一个评分指标表，但毕设不建议做——配置化的复杂度比你想象中高，而且变化不大。

3.2 防止重复评分：唯一索引设计

“一个学生对一门课只能评一次”这个需求，是全文最重要的业务规则，也是评委必问的问题：“你怎么保证他不提交两次？”

很多人的第一反应是做业务层判断：提交前先查一下库里有没有这条记录。这个思路没有错，但它不够——在高并发场景下，两个请求同时进来都会先查库，发现没有记录，然后同时插入，结果就写入了两条。

正确做法是业务校验和数据库约束双保险。业务层查一次，给用户友好提示；数据库层面再加一个唯一索引兜底。SQL 如下：

CREATE TABLE evaluation_record ( record_id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id BIGINT NOT NULL, student_id BIGINT NOT NULL, teaching_id BIGINT NOT NULL, score1 INT NOT NULL, score2 INT NOT NULL, score3 INT NOT NULL, score4 INT NOT NULL, total_score DECIMAL(5,2) NOT NULL, comment VARCHAR(1000), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_task_student_teaching (task_id, student_id, teaching_id) );

加了唯一索引之后，数据库层面从原理上保证了同一个任务、同一个学生、同一个授课记录只能存在一条评价。即使业务代码出了 bug，第二条插入也会直接报 DuplicateKeyException 被拦下来。

这块内容写进论文和答辩 PPT 里，是实打实的技术含量。它涉及并发控制的思考，比“我会增删改查”有说服力得多。

3.3 匿名反馈：存储与查询分离

匿名性是这个项目最容易翻车的地方。逻辑上学生填写的文字意见，老师只能看到内容不能看到是谁写的。但这里有个矛盾：数据库里如果不存 student_id，你又怎么判断“某个学生是否已经评过这门课”？

我的方案是存储与查询分离：

• 存的时候照常存 student_id，它用于防重复校验、统计参评率，也算业务上的必要字段。
• 查的时候绝对不做任何用户的关联查询。教师端意见列表的 SQL 只查询 comment 和 create_time，不返回 student_id，也不 join sys_user 表取姓名。

有人会问：数据库 DBA 直接查库不就看到是谁写的了吗？这确实是个理论上的漏洞，但对毕设来说，做到“业务层完全不暴露对应关系”就已经达到了系统设计目标。如果你想让这个设计更严密，可以在论文里补充一句话：生产环境需要更高等级的匿名保护时，可以对评价记录和学生关系做物理隔离，比如用独立 ID 做关联映射，但本系统设计在应用层面保证了匿名性。

这块逻辑我建议你写成文档，答辩时主动讲出来，比评委追问之后被动回答的效果好得多。

4. 后端接口实现：从登录拦截到评分提交的核心链路

4.1 登录与角色权限控制

登录模块本身不复杂，但要注意密码存储不能用明文——这是评委眼里的基础红线。用 Spring 自带的 BCryptPasswordEncoder 加密，不要自己写加密算法，更不要用 MD5，理由一句话：BCrypt 自带随机盐，同类密码加密结果不同，更安全。

登录成功后的权限控制，前文说了用拦截器。核心代码结构大致这样：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { User user = (User) request.getSession().getAttribute("loginUser"); if (user == null) { // 未登录，跳转到登录页 response.sendRedirect("/login"); return false; } // 判断路径前缀与角色是否匹配 if (request.getRequestURI().startsWith("/teacher") && !"TEACHER".equals(user.getRole())) { response.sendError(HttpServletResponse.SC_FORBIDDEN); return false; } return true; } }

再在配置类里注册拦截规则，哪些路径放行（登录页、静态资源），哪些路径需要登录，一目了然。这种代码结构简单到没法出错，答辩现场改参数演示也游刃有余。

4.2 学生端“待评课程”列表的实现逻辑

学生登录后首页要展示“当前可以评价的课程”。这个查询不能是简单的全表查，它需要同时满足三个条件：这个学生选了这门课、这门课当前处于评价周期内、这个学生还没有提交过评价。

用 SQL 写其实很清晰，就是一个三层嵌套判断：

SELECT t.id, c.course_name, u.real_name AS teacher_name FROM student_course sc JOIN teaching t ON sc.teaching_id = t.id JOIN course c ON t.course_id = c.id JOIN sys_user u ON t.teacher_id = u.id JOIN evaluation_task et ON et.status = 1 AND NOW() BETWEEN et.start_time AND et.end_time WHERE sc.student_id = #{studentId} AND NOT EXISTS ( SELECT 1 FROM evaluation_record r WHERE r.task_id = et.id AND r.student_id = #{studentId} AND r.teaching_id = t.id )

这里用NOT EXISTS判断“还没评过”，逻辑准确而且性能不差。不要用LEFT JOIN ... WHERE 子查询 IS NULL的写法，虽然也能实现，但阅读性不如 NOT EXISTS 直观，答辩讲解时还要绕一下。

4.3 评分提交接口的校验链条

提交评分是后端最重要的一个接口。按我的经验，一个合格的提交接口至少要做四层校验：

• 登录状态校验：拦截器已经完成了。
• 任务状态校验：当前评价任务是否存在、是否在起止时间内。过期提交直接拒绝。
• 重复提交校验：根据 task_id、student_id、teaching_id 查是否已有记录。
• 参数合法性校验：四个分数必须在 1-5 之间（或你设定的范围），评语长度限制在 1000 字以内。

Service 层核心逻辑看这段伪码：

@Transactional public EvaluationRecord submitEvaluation(SubmitEvaluationDTO dto, Long studentId) { EvaluationTask task = evaluationTaskMapper.selectById(dto.getTaskId()); // 校验任务存在且处于进行中 if (task == null || task.getStatus() != 1) { throw new BizException("评价任务不存在或已结束"); } // 校验是否在时间窗口内 if (LocalDateTime.now().isBefore(task.getStartTime()) || LocalDateTime.now().isAfter(task.getEndTime())) { throw new BizException("当前不在评价时间内"); } // 校验是否已评过 Integer count = evaluationRecordMapper.selectCount( new LambdaQueryWrapper<EvaluationRecord>() .eq(EvaluationRecord::getTaskId, dto.getTaskId()) .eq(EvaluationRecord::getStudentId, studentId) .eq(EvaluationRecord::getTeachingId, dto.getTeachingId())); if (count > 0) { throw new BizException("您已评价该课程，请勿重复提交"); } // 插入记录（依靠唯一索引兜底并发问题） EvaluationRecord record = convertToRecord(dto, studentId); evaluationRecordMapper.insert(record); return record; }

注意 @Transactional 注解一定要加。虽然这里只有一次插入，但整个流程里有查询再插入的复合操作，加上事务能保证业务的一致性。评委如果问“事务你用在哪些地方”，这就是一个很好的真实案例。

4.4 教师端统计与意见列表的脱敏查询

教师端需要看两个东西：各维度的平均分、总分平均分，以及学生的文字意见列表。

平均分统计用一条聚合 SQL 就能完成：

SELECT ROUND(AVG(r.score1), 2) AS avg_score1, ROUND(AVG(r.score2), 2) AS avg_score2, ROUND(AVG(r.score3), 2) AS avg_score3, ROUND(AVG(r.score4), 2) AS avg_score4, ROUND(AVG(r.total_score), 2) AS avg_total FROM evaluation_record r JOIN teaching t ON r.teaching_id = t.id WHERE t.teacher_id = #{teacherId} AND r.task_id = #{taskId}

意见列表的查询，核心在于坚决不返回任何学生身份信息：

SELECT r.comment, r.create_time FROM evaluation_record r JOIN teaching t ON r.teaching_id = t.id WHERE t.teacher_id = #{teacherId} AND r.task_id = #{taskId} AND r.comment IS NOT NULL AND r.comment != '' ORDER BY r.create_time DESC

这条 SQL 只把评语和提交时间查出来，根本没有学生的影子。我在项目演示和论文里都专门圈出了这一块，告诉评委：匿名性是靠“查询边界”保证的，不是靠嘴上说。

5. 前端交互设计：打分页面、意见反馈和统计展示

5.1 学生打分页面：从星星到提交

评分页是学生最常看到的页面，交互体验直接决定项目给人第一印象。我建议用星级评分代替普通的数字下拉框——视觉反馈直观，代码也不复杂。

前端的逻辑非常简单：

• 四个评分维度，每个维度显示 5 颗星，点击选中后高亮对应数量的星星，同时把值写入隐藏域。
• 文字意见区是一个 textarea，实时统计字数，超过 1000 字就提示截断。
• 提交按钮点击后，用 Ajax 把数据 POST 到后端接口，成功后弹窗提示，然后刷新列表，该课程从“待评价”变成“已评价”。

Ajax 请求代码大致是：

function submitEvaluation(teachingId, taskId) { const data = { teachingId: teachingId, taskId: taskId, score1: $("#score1").val(), score2: $("#score2").val(), score3: $("#score3").val(), score4: $("#score4").val(), comment: $("#comment").val() }; $.ajax({ url: "/student/evaluation/submit", type: "POST", contentType: "application/json", data: JSON.stringify(data), success: function (res) { if (res.code === 200) { alert("评价提交成功"); location.reload(); } else { alert(res.msg); } } }); }

这里有一个交互细节值得做：后端返回“请勿重复提交”时，前端不要只弹一个生硬的 alert，而是同时把页面里该课程的按钮置灰。这个体验细节写在论文里，能体现你考虑到了系统边界情况。

5.2 教师端统计页：分数分布与意见展示

教师端统计页是展示亮点的地方，不要做一个朴素的数据表格。最少要包含两个模块：

第一个是分项平均分卡片——四个维度的均分用四个卡片展示，数字放大加粗，一目了然。第二个是总分变化趋势或分数分布条，如果评价任务只有一个周期，可以用柱状条展示“评分集中在 4-5 分”的分布情况。

分数分布的计算其实很简单，后端按分数段聚合数量再返回就好。视觉上可以用 Bootstrap 的进度条组件来模拟柱状图，不用引入 ECharts 也能做得不难看。当然如果你会 ECharts，这里引入一个折线图或饼图会更出彩——但一定只会用在前端展示，不要为了用图表而硬塞。

文字意见列表放在页面下方，每条意见用卡片或引用块样式展示，只显示内容和时间。这里要再次强调：页面上绝对不能出现学生姓名、学号、头像等信息，这是这个系统设计的原则底线。

5.3 管理端：任务、课程与用户管理

管理端说白了就是基础数据的 CRUD，但它的页面规划影响开发效率。我建议把管理端做成一个左侧导航、右侧内容的布局：用户管理、课程管理、授课管理、评价任务管理四个页面。

评价任务管理是里面最有业务含量的模块：管理员可以创建一个任务，设置名称、起止时间、状态（未开始/进行中/已结束）。这里有一个细节：创建任务时不需要和课程做复杂的绑定关系，只要任务状态是“进行中”，学生端待评课程列表就会自动显示所有选课记录。任务的状态字段起到了全局开关的作用，设计简单又合理。

如果你还有剩余时间，管理端加一个“导出 Excel”按钮会是很加分的功能。用 Apache POI 写一个简单的导出工具类，把评价记录查出来、逐行写入 Excel 即可。注意内存问题，几万条数据用 SXSSFWorkbook 流式写入，这是 POI 使用者的基本功。

6. 答辩现场最容易翻车的地方和我准备的应对

6.1 匿名性怎么向评委证明

前缀我提到过，匿名性是评委最感兴趣的点之一。他们大概率会问：“你说匿名，数据库里不是存了 student_id 吗？”

别慌，这就是你展示设计思路的机会。你可以这样回答：系统在数据库层面存储 student_id 的目的是业务需要，包括防止重复提交、统计参评率等。但在查询展示层面，教师端的所有接口和 SQL 都没有关联学生信息，也就是说，教师在系统里从任何入口都无法获得“谁评价了我”的信息。同时，我们通过唯一索引保证了数据可信，通过事务保证业务一致性。

这套回答里没有任何虚假承诺，它展示了“你理解匿名不等于不存数据，而是业务上不可反推”这个层次，足够让评委满意。

6.2 演示数据与演示流程设计

毕设翻车的第二大原因是临场演示准备不充分。评价系统有一个天然的演示难点：学生评完分之后，教师端才看得到结果。如果你现场先演示学生端再演示教师端，评委看着你在两个账号之间切换，体验会很乱。

我的建议是提前准备两组数据：一组是已经完成评价的（用脚本或者手动造 20 条左右模拟数据），用于直接展示教师端统计结果；另一组是真实的“当前登录学生账号”的待评课程，用于展示完整评分提交流程。演示时先讲整体流程，再重点展示教师端统计页和意见列表，最后用真实账号走一遍提交过程，证明“这条新记录马上就能出现在教师端”。这套流程顺畅且有说服力。

另外强烈建议你演示前把浏览器窗口缩放到正常演示比例，字体调大，提前登录好所有账号，不要让评委看你现场输密码。

6.3 评委爱问的几个问题

根据我带毕设的经验，这类题的评委通常集中在以下问题上：

• “防重复提交除了数据库唯一索引，还能怎么做？”——可以答：前端置灰按钮、幂等性设计、Redis 分布式锁（只要你能把原理说清楚，都是加分点）。
• “如果学生评分之后发现填错了，要不要支持修改？”——这是个开放题。答案是设计上故意不支持，保证评教的严肃性和结果可追溯性。
• “评价结果对老师有什么影响？”——说明这个项目只做反馈展示，不做奖惩决策，把业务边界交代清楚。诚实承认系统的功能边界比硬吹强一百倍。
• “分数怎么计算和存储？”——四个维度各占 25% 简单平均，总分在插入时就算好存字段，不依赖实时计算。这条准备好之后基本不会被追问垮。

这些问题你提前想好答案，答辩现场就会显得对项目理解很深，对比那些只会背代码的学生，高下立判。

6.4 一个容易被忽视的细节：代码规范

最后说一个很实在的问题：代码规范。许多毕设项目功能做完了，但代码一打开就是两千行写在一个 Controller 里、类名全是拼音缩写、没有日志。就算功能再好，评阅印象也会大打折。

代码规范不需要你做得像企业级那么高标准，只要做到这几点就足够：

• 分层清楚：Controller 只接参数和返回结果，业务逻辑全在 Service。
• 命名有意义：getStudentEvaluationList而不是getList。
• 统一返回结构：定义一个Result类，包含 code、msg、data，所有接口统一用它返回。
• 关键操作打日志：登录、提交评分、导出等操作，用 Slf4j 记录关键信息。

这些细节不花多少时间，但在评阅环节能实实在在拉高印象分。写代码的时候养成习惯，不要最后堆在一起再改，改起来更痛苦。

我在实际带项目的过程中，负责造数据、帮学生排查重复评分问题、调整统计 SQL 的次数比写业务代码还多。这个题真正难的不是哪个单独的技术点，而是把“评价”这个闭环业务想透，把防重、匿名、统计这些边界处理干净。你只要把这条主线理清楚，代码量不需要堆到夸张，也能做出一份让评委点头的毕业设计。