企业官网建设流程全解析

做毕设选题那阵子，我在一堆“XX管理系统”里刷到“jsp'书香羲园'最美笔记展评管理系统”这个题目，多看了两秒。这个题目确实比普通的管理系统要“有得写”：核心词落在“展评”上——展，是展示优秀笔记；评，是评分和评审。一套系统下来，既要管用户、管作品、管图片上传，又要处理打分、排榜、公示，技术点覆盖得正好，适合用 JSP + Servlet + MySQL 这一套经典栈来做。

这篇文我就以毕设实施过程为主线，把选题拆解、数据库设计、核心功能实现、论文答辩准备，还有部署时那些容易让人折腾到半夜的坑，一次性讲清楚。如果你正在做或准备做这个题，可以直接照着这个思路往下推。

1. 选题值不值得做：从“展评”两个字反推系统本质

1.1 展评系统不等于“笔记版增删改查”

很多同学拿到这种题目，第一反应是：不就是一个笔记表加一个用户表吗？做完登录注册、加个上传、加个列表，收工。真按这个思路做完，答辩时大概率被老师问住，因为普通管理系统的业务逻辑太单薄，撑不起一场完整的毕设陈述。

这个题目的重点不在“笔记”，而在“展评”这两个字背后隐藏的业务闭环。拆开看是什么：

• 展，是作品展示。背后需要活动发布、作品提交、图片处理、状态审核、公开展示。
• 评，是评审打分。背后需要评委账号、评审日期限定、评分维度、分数汇总、排行榜生成。

所以它实际上是“活动组织 + 作品管理 + 在线评分 + 结果公示”四个子系统拼起来的一个综合性平台。你多拆出一层，功能列表就比别人多一页，论文里的需求分析就比别人扎实一截。

1.2 为什么这套技术栈正好匹配

标题里点名了 JSP，那技术选型基本就是经典 JavaWeb 三层结构：JSP 负责页面展示，Servlet 负责请求处理，JavaBean/DAO 负责数据访问，MySQL 做持久化。

JSP 做这类展示型系统有一个天然优势：笔记展评页面的核心是大量图片和文字的结构化展示，用 JSP 的 EL 表达式加 JSTL 标签可以非常自然地把数据库里的作品记录渲染成卡片列表。相比前后端分离的 Vue/React 方案，这套技术栈在毕设场景下有不可替代的优势——它简单、直白，老师翻代码时能一眼看明白逻辑，不需要引入 Node、Maven 多模块等额外复杂度。

当然，纯 JSP + Servlet 确实有点“复古”，但这正是毕设要求的可控性所在：把基础技术写扎实，比堆一堆自己都说不清的框架要稳妥得多。

1.3 三种角色与权限边界

从业务场景出发，系统至少要有三类使用者。权限边界必须在需求阶段就定清楚，这直接决定后面 Filter 怎么写、菜单怎么控制。

这三类角色铺开之后，系统的权限控制需求一下就清晰了：管理员能进后台管理页，评委只能进评审页，学生只能操作自己的作品。落实到代码上，就是一个 Session 角色字段加上一个 Filter 拦截，逻辑不复杂，但必须做，否则老师一问“你怎么防止学生给自己打分”就答不上来。

2. 需求拆解：把“最美笔记”做成一条完整业务线

2.1 从使用场景倒推功能模块

做需求分析最忌讳对着键盘硬想。我的习惯是先描述一个真实使用场景，再倒推系统要具备什么能力。

假设学院要举办“最美笔记”展评活动，流程是这样的：管理员在系统里创建一个活动，设置报名和评比时间；学生在活动期间登录系统，填写笔记标题、简介，上传笔记照片；管理员审核作品是否合规；评委登录系统，对审核通过的作品逐份打分；活动结束后，系统按规则计算排名并公示，学生可以看到榜单和优秀作品展示墙。

顺着这个场景，功能模块自然浮现：

• 用户模块：注册、登录、个人信息查看与修改、密码更新。
• 活动模块：活动的创建、编辑、上下架，活动时间的校验。
• 作品模块：笔记的上传、在线预览、草稿保存、提交审核、被驳回后修改。
• 评审模块：评委的作品列表、分维度打分、文字评语、评分提交。
• 展示模块：优秀笔记公示墙、排行榜、作品详情页。
• 后台模块：用户管理、作品审核、活动数据统计、公告发布。

其中“个人信息展示页面”在毕设里也是一个不可省略的点，对应到功能上就是系统的用户中心——个人头像、参赛作品数、作品得分、历史活动记录都汇总在一个页面里。这块做起来不难，但页面信息组织得清晰，能给答辩演示加分。

2.2 作品和活动的状态流转：系统的灵魂所在

普通管理系统只有增删改查，数据状态基本是死板的。展评系统不一样，它的作品和活动都有明确的生命周期，把这套状态机理清楚，论文里的系统设计部分就直接有内容可写。

作品状态可以定为：草稿、待审核、已通过、已驳回、已评分。流转逻辑如下：

活动状态则简单一点：未开始、进行中、评审中、已结束。管理员创建时是“未开始”，到开始时间自动进入“进行中”，学生可提交作品；活动截止后管理员手动切到“评审中”，此时只允许评委打分；评分结束后切到“已结束”，公示榜单。

这套状态机不是花架子。实现时只需在 notes 表里加一个 status 字段，在 activities 表里加一个 status 字段，然后用 Java 的枚举或常量类统一管理状态值。答辩时如果老师问“并发下状态会不会乱”，你能答出“通过数据库字段进行状态判断，提交时校验当前活动状态是否允许该操作”，就足够说明你考虑过这个问题。

2.3 功能优先级怎么排：把差异化亮点放前面

毕设不是商业项目，没必要把所有模块都做成 100 分。我的建议是把功能分成三档：

• P0 核心功能（必须完整实现）：登录注册、活动管理、作品上传与审核、评委评分、排行榜。
• P1 加分功能（能体现工作量）：用户中心、公告管理、活动报名限制、统计图表。
• P2 亮点功能（用来讲差异化故事）：图片坐标批注、多维度加权评分、自动生成公示榜单 PDF 或海报。

你在开题报告里就可以按这个优先级安排计划，既能保证底线完工，又能在论文里写出“系统的特色功能”。后面我会单独讲 P2 里的图片坐标批注怎么做，因为这是让评委眼前一亮、同时网上资料又比较分散的一个点。

3. 数据库建模：让评分数据经得起答辩老师的追问

3.1 五张核心表的设计逻辑

数据库设计是毕设答辩的高频区，老师会盯着你的表结构问“为什么这样设计”“字段冗余了吗”“能保证数据一致吗”。所以建表不能随手来，每张表都要能说出理由。

我按最小可用且扩展性较好的方案，设计了以下五张核心表。

users 用户表：

activities 活动表：

notes 作品表：

ratings 评分表：

notices 公告表用于发布活动通知和结果公示，字段类似 title、content、publish_time，不需要多解释。

作品表里我没直接放一个 total_score 字段，是因为总分应该在统计排行时计算，而不是在修改时维护。理由很简单：如果评委改分了，存了冗余总分就可能忘记更新，程序 bug 率直线上升。

3.2 评分表的唯一约束：数据库级的防重复保险

防止同一个评委对同一份作品评两次，是展评系统最核心的数据一致性需求。

最直接的实现是给 ratings 表加联合唯一索引：

ALTER TABLE ratings ADD UNIQUE KEY uk_note_judge (note_id, judge_id);

这条约束的意义非常大。哪怕你的代码逻辑漏判了、重复提交了，数据库也会直接给你报 Duplicate entry 错误，二次提交根本插不进去。我在测试时故意用两个浏览器窗口同时提交评分，其中一个必然失败，效果立竿见影。

写论文时这也是一句可以写进“系统健壮性设计”的话：不仅在业务层校验，更在数据库层设置唯一约束，实现双重保障。

3.3 外键与 E-R 图：论文里怎么表述

建议物理外键能加就加，MySQL 的 InnoDB 引擎支持外键，加了之后数据一致性更有保障；如果担心操作麻烦，至少保证逻辑外键清晰。E-R 图里需要明确这几条关系：

• 一个用户（学生）可提交多份笔记，用户与笔记是 1:N。
• 一个活动包含多份笔记，活动与笔记是 1:N。
• 一份笔记可被多个评委评分，笔记与评分是 1:N。
• 一个评委可给出多条评分，用户与评分是 1:N。

数据库设计章节就是把这几句话展开，配上 E-R 图，再附上一段核心建表 SQL。这段 SQL 建议你整理好直接放进论文附录，老师很吃这一套——说明你确实建过表，而不是纸上谈兵。

4. 三块硬核功能：图片上传、坐标批注与评分防刷

4.1 多图上传：Part API 与外部存储目录

JSP 项目做图片上传，老教程里一般讲 Commons FileUpload。如果你用的是 Servlet 3.0 以上版本，其实可以直接用原生 Part 接口，少引一个 jar。核心代码是这样的：

@WebServlet("/uploadNote") @MultipartConfig(maxFileSize = 5 * 1024 * 1024, maxRequestSize = 20 * 1024 * 1024) public class UploadNoteServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); Part cover = request.getPart("cover"); String fileName = extractFileName(cover); // 生成随机文件名防止覆盖，保留扩展名 String newName = UUID.randomUUID().toString().replace("-", "") + fileName.substring(fileName.lastIndexOf(".")); String uploadDir = getServletContext().getInitParameter("uploadDir"); cover.write(uploadDir + File.separator + newName); // 把 newName 入库，同时保存笔记标题、简介等字段 } }

这里最值得注意的就是@MultipartConfig(maxFileSize...)，它直接限制单次上传大小。比如单张笔记图限制 5MB、单次总请求限制 20MB，既能满足需求，又能预防超大文件拖垮服务器。上传目录也不要放在 Tomcat 部署目录里，具体原因我在第七章展开。

4.2 图片坐标定位：用相对坐标解决“批注在哪”的问题

这一块是很多人搜索“jsp 图片如何对坐标定位”的真正原因。场景是这样的：评委看到一幅笔记图片，想指出“这一页的字迹特别工整”，或者“这段逻辑图有问题”，需要在图片某个位置打个点、写句评语。

如果直接把鼠标点击的像素坐标存进数据库，那基本是错的。原因很简单：同一张图在评委电脑上的显示宽度、在学生手机上的显示宽度都不一样，等学生在手机上看你打的那个点时，点就跑到别处去了。

正确做法是存相对坐标。前端在页面里监听图片上的点击事件，算出点击位置相对于图片左上角的比例：

img.addEventListener('click', function (e) { const rect = img.getBoundingClientRect(); const x = (e.clientX - rect.left) / rect.width; // 0 到 1 之间 const y = (e.clientY - rect.top) / rect.height; // 通过 AJAX 提交到后台 fetch('saveAnnotation', { method: 'POST', body: new URLSearchParams({ noteId: currentNoteId, annX: x.toFixed(4), annY: y.toFixed(4), remark: document.getElementById('annRemark').value }) }); });

后端把 annX、annY 存成 DECIMAL(5,4)，展示时再根据容器宽度还原坐标：

displayImg.addEventListener('click', ...) // 同理还原位置标记 const left = annX * displayImg.clientWidth; const top = annY * displayImg.clientHeight; // 在 (left, top) 处显示一个小坐标点标记

这是个既能写进论文特色功能、又能在答辩现场演示的亮点。代码量不大，但体现出的思考深度远超普通 CRUD。

4.3 评分防刷：别让重复提交毁了你的数据

评分模块最容易出的问题有两个：重复评分和越权评分。

重复评分，我前面说的唯一索引已经挡在数据库层了。越权评分，则要靠业务层校验。所谓越权评分，包括三类：非评委身份打分、活动还没进入评审阶段就打分、评委给已提交多次的作品重复打分。

实现思路是在评分 Servlet 里做三层校验：

1. 从 Session 拿当前用户，检查 role 是否为评委。
2. 根据 noteId 查出活动，检查当前时间是否在 review_start 和 review_end 之间。
3. 按 note_id + judge_id 查 ratings 表，已有记录则直接拦截。

一些同学还想用 IP 限制做防刷，我的建议是别把精力花在这上面。同一个办公室的评委可能共用出口 IP，IP 判断既会误伤，也不能解决问题。核心场景下，用户登录身份 + 数据库唯一约束才是正解。

4.4 排行榜计算：平均值、去极值、并列规则

排行榜一般有三种口径，你可以在论文里都分析一遍，实现时选一个：

• 简单平均分：每份作品所有评委打分的总分除以人数。实现最简单，但一个评委手一抖打了极端低分，作品排名就被带偏。
• 去掉最高最低再平均：每个作品剔除一个最高分和一个最低分，剩下取平均。对异常值更稳健，适合评委数量较多的场景。
• 加权平均：不同评委权重不同，比如院系老师权重比学生评委高。扩展性强，但需要额外维护权重表，毕设慎用，容易把简单系统复杂化。

实际操作推荐第二种，Java 实现思路也很清晰：查出一份作品的全部评分，用 Collections.sort 排序后，去掉 index 0 和最后一位，中间求和除以个数。如果一张作品评分人数太少，比如不到 3 人，可以做特殊处理，直接取平均分，或者标记为“暂未参与排名”。

并列排名的规则也提前想好：综合得分相同，按提交时间早者优先；再相同，按作品 ID 小者优先。这个规则写进论文，显得你连边角问题都处理到位了。

5. 核心代码怎么写才像“自己做的”

5.1 登录、Session 与 Filter 三件套

登录逻辑不难，但关系到整个系统的安全基底。密码不要明文存储，至少做一次 MD5 加盐处理：

public class MD5Util { public static String md5WithSalt(String raw, String salt) { String target = raw + salt; try { MessageDigest md = MessageDigest.getInstance("MD5"); byte[] bytes = md.digest(target.getBytes("UTF-8")); StringBuilder sb = new StringBuilder(); for (byte b : bytes) { sb.append(String.format("%02x", b)); } return sb.toString(); } catch (Exception e) { throw new RuntimeException(e); } } }

登录成功后把 userId、role 等关键信息放进 Session，然后写一个统一的权限过滤器：

@WebFilter("/admin/*") public class AdminFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; HttpSession session = request.getSession(false); Object role = session == null ? null : session.getAttribute("role"); if (role != null && Integer.valueOf(1).equals(role)) { // 评委权限 chain.doFilter(req, resp); } else { response.sendRedirect(request.getContextPath() + "/login.jsp"); } } }

用 Filter 统一管权限，JSP 页面里就不要每个页面都去判断 Session 了。这是代码风格上的一个分水岭，也是老师看你代码时比较认可的一种结构。

5.2 作品上传后如何与页面联动

上传完成后，Servlet 存好文件路径，再把作品基本信息插入 notes 表。这里注意一个字段：cover_url 存放的是“文件名”，而不是完整路径。原因和上一节说坐标定位一样的道理——部署路径会变，存相对文件名最稳。

JSP 页面展示时再拼接完整访问路径，配合第七章说的虚拟路径映射方案。比如：

<img src="${pageContext.request.contextPath}/upload/${note.coverUrl}" alt="${note.title}" />

EL 表达式${note.coverUrl}取值，JSTL 的c:forEach循环遍历作品列表，整个展示页完全不需要写一行 Java 脚本。这也是 JSP 在这个题目下的正确打开方式——展示逻辑交给标签库，业务逻辑留在 Servlet。

5.3 评分提交的事务处理

评分涉及两个动作：插入评分记录、更新作品已评分状态。这两个动作必须放在同一个事务里：

public boolean addRating(Rating rating) { Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 1. 插入评分记录 String insertSql = "INSERT INTO ratings " + "(note_id, judge_id, content_score, neat_score, layout_score, remark, created_at) " + "VALUES (?, ?, ?, ?, ?, ?, NOW())"; PreparedStatement ps1 = conn.prepareStatement(insertSql); // ... 设置参数，执行 // 2. 更新作品状态 String updateSql = "UPDATE notes SET status = 4 WHERE note_id = ? AND status = 3"; PreparedStatement ps2 = conn.prepareStatement(updateSql); ps2.setInt(1, rating.getNoteId()); // 执行后检查 affected rows，如果为 0，说明作品状态不对，回滚 conn.commit(); return true; } catch (Exception e) { try { if (conn != null) conn.rollback(); } catch (Exception ex) {} return false; } finally { DBUtil.close(conn); } }

注意UPDATE notes SET status = 4 WHERE note_id = ? AND status = 3这个写法，它用条件更新防止“作品已被删除或状态已变化”时仍然评分成功。这条 SQL 影响行数为 0 时直接回滚，比先查询再更新更安全。

5.4 排行榜的 SQL 写法

一次查询算出排名，核心 SQL 大概长这样：

SELECT n.note_id, n.title, u.real_name, ROUND((SUM(r.content_score + r.neat_score + r.layout_score) - MAX(r.content_score + r.neat_score + r.layout_score) - MIN(r.content_score + r.neat_score + r.layout_score)) / (COUNT(*) - 2), 2) AS final_score FROM notes n JOIN users u ON n.user_id = u.user_id JOIN ratings r ON n.note_id = r.note_id WHERE n.activity_id = ? GROUP BY n.note_id, n.title, u.real_name HAVING COUNT(*) >= 3 ORDER BY final_score DESC, n.submit_time ASC LIMIT 50;

这条 SQL 把去极值平均分逻辑直接在数据库里做了，代码简洁，性能也能接受。如果评委人数不足 3 人的作品，用 HAVING COUNT(*) >= 3 直接跳过排名，逻辑清晰。说明一点：WHERE 里过滤指定活动，再按 note_id 分组，每组去掉最高最低分再平均，这就是排行榜的核心计算。

前端页面用 JSTL 遍历展示，加上一个名次序号，一个榜单页面就完整了：

<c:forEach items="${rankList}" var="item" varStatus="st"> <tr> <td>${st.index + 1}</td> <td>${item.title}</td> <td>${item.realName}</td> <td>${item.finalScore}</td> </tr> </c:forEach>

6. 论文写法与答辩准备：把系统讲成一个有亮点的故事

6.1 论文章节顺序怎么安排

论文不必一开始就沉浸在技术细节里。推荐这样一个思路：

• 第一章绪论：从“课堂笔记是学风建设的缩影”切入，说明最美笔记展评的意义，引出现有线下评比效率低、反馈慢的问题。
• 第二章相关技术：JSP、Servlet、MySQL、JSTL，每项技术做什么用，写两到三句话即可，不要大段抄教材。
• 第三章需求分析：画出系统用例图，列出功能需求和非功能需求（安全性、并发性、易用性）。
• 第四章系统设计：包括总体架构图、功能结构图、数据库 E-R 图、核心流程时序图。
• 第五章系统实现：按模块讲，每个模块配页面截图和核心代码片段。
• 第六章系统测试：功能测试用例表 + 部分性能测试数据，比如上传 5MB 图片的响应时间、100 条评分数据的排行查询耗时。
• 结束语：总结系统完成情况，客观说明不足和后续改进方向。

这套结构和系统实际开发过程是对得上的，老师看下来会觉得你的论文是“先做了事再写的”，而不是纯凑字。

6.2 论文里最值得画的三张图

第一张是功能结构图，按用户端、评委端、管理端三个区域把功能列成树状图。第二张是 E-R 图，直接由第三章的表结构生成。第三张是评分时序图，把评委打分请求经过“登录校验 → 活动状态校验 → 重复评分校验 → 事务写入 → 返回结果”的完整路径画出来。

这三张图基本覆盖了系统设计、数据库、核心流程三个维度，每一张都能在答辩 PPT 里讲上两三分钟。

6.3 答辩高频追问与应答口径

根据我见过的毕设答辩场景，这个题目大概率会被问到下面几类问题：

1. 为什么不直接用前后端分离？回答重点：毕设选题要求突出 JSP 经典架构的学习成果，且展评系统以服务端渲染为主，JSP 天然擅长；后续如需扩展，可将展示层逐步替换为 RESTful API。
2. 怎么防止一个评委重复给一份作品打分？回答重点：数据库唯一约束 + 业务层前置校验。
3. 图片上传大小如何控制？回答重点：@MultipartConfig限制单文件 5MB、总请求 20MB，同时用 UUID 重命名防止恶意覆盖。
4. 如果并发请求比较多，系统扛得住吗？回答重点：登录和评分走数据库连接池，核心表都加了索引；同时说明毕设已做基础压力测试，后续可用 Redis 等方案进一步优化。
5. 你的系统有什么创新点？回答重点：图片坐标批注、去极值评分算法、状态机驱动的活动管理。

提前把这些答案组织好，答辩时心里就有底。最重要的一条经验是：老师不要求你系统做得多么商业化，但要求你自己写的代码自己讲得清清楚楚。

7. 部署和排错：那些测试时折腾我一晚上的坑

7.1 中文乱码三处位置一次性解决

JSP 项目中文乱码是最常见的问题，而且经常在本地开发时没事、部署到服务器就乱。原因是编码问题散落在三个地方：JSP 页面声明、请求字符集、数据库连接参数。

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

Servlet 里每次处理 POST 请求前加：

request.setCharacterEncoding("UTF-8");

也可以用 Filter 统一处理，我习惯在 CharSetFilter 里集中设置。JDBC 连接串必须显式带上编码参数：

jdbc:mysql://localhost:3306/shuxiang?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai

三个位置全对上，中文基本不会乱。如果有一次乱了，按这个顺序排查，一分钟定位。

7.2 图片“上传成功但页面显示不出来”的原因

这个问题十有八九出在上传目录选择上。如果你把图片直接存到项目部署目录里，比如${catalina.home}/webapps/MyProject/upload，那么每次重新部署项目时，这个目录会被清空，数据库里的记录还在，但文件已经没了，页面自然显示破图。

正确做法是把上传目录放在外部固定位置，比如D:/shuxiang_upload/或者 Linux 下的/data/shuxiang_upload/，然后在 Tomcat 的 server.xml 的 Host 节点下加虚拟目录映射：

<Context path="/upload" docBase="D:/shuxiang_upload" />

这样/upload/xxx.jpg就能映射到物理目录，重新部署项目时图片不会丢。页面里拼接路径时保持/upload/文件名的形式，部署在哪台机器都不需要改代码。

7.3 MySQL 连接失败的三个隐藏原因

环境不同，连接报错信息也不同，但有几个高频坑是共通的：

• MySQL 8.x 的驱动是com.mysql.cj.jdbc.Driver，不是 5.x 时代的com.mysql.jdbc.Driver。
• MySQL 8 必须指定时区，连接串里加serverTimezone=Asia/Shanghai，否则报时区错误。
• 本地 Tomcat 的端口和本机其他程序冲突时，会直接在启动日志里报Port 8080 required by Tomcat ... is already in use。Windows 下用netstat -ano | findstr 8080找到占用 PID，再在任务管理器里结束进程，十秒解决。

7.4 JSP 改动不生效的小技巧

调试阶段最烦的就是改完 JSP 刷新页面没变化。Tomcat 对 JSP 默认开了热更新，但如果你用的是未编译的 jsp 文件，偶尔会因浏览器缓存导致旧页面残留。这时可以强制刷新（Ctrl+F5），或在 server.xml 里确认<Context reloadable="true">。如果确实改了 Java 类，那就得重启 Tomcat，不要指望热部署百分百可靠。

这些坑看着琐碎，但每个都能让人卡上小半天。提前知道，至少能省下连续两三个晚上的排错时间。

结尾

做完这套“书香羲园”最美笔记展评管理系统，我最大的感受是：毕设的差别从来不在“用了多新的框架”，而在“有没有把业务逻辑想清楚”。这个题目表面上是 JSP 加管理系统，但当你把“展评”拆成活动、作品、评审、展示四块，并且把评分防刷、坐标定位、去极值算分这些小功能一个个落地之后，论文内容、答辩素材、代码结构都会自然而然地丰满起来。

最后分享一个小技巧：把每个模块涉及的 SQL 语句在开发时就整理到单独文件中，论文写系统设计章节时直接对照着描述表结构，答辩时随身带着演示脚本。这些看似不起眼的准备工作，往往就是最后拿到一个不错评价的关键。希望这篇经验能让你少走一些弯路，做完之后你会发现，JSP 做展示型系统这件事，比想象中要顺手得多。