企业官网建设流程全解析

1. 项目概述与需求拆解

1.1 这个题目到底在做什么

考研互助交流平台，这几个字拆开看其实就是三件事：考研人群的刚需信息聚合、基于院校和专业纬度的用户连接、以及学习资料和经验的共享流转。作为计算机毕业设计题目，它的价值在于——需求明确但不复杂、模块边界清晰、技术栈覆盖全面，是一个能同时体现数据库设计能力、后端接口设计能力、前端页面开发能力和基础安全意识的优质选题。

这类平台的真实使用场景是这样的：一个普通本科生准备考研，他需要查目标院校的报录比、找直系学长学姐的经验贴、下载专业课真题、寻找同校同专业的研友一起打卡监督、甚至在冲刺期问一些“现在换学校还来得及吗”之类的焦虑问题。如果把这些需求全部数字化，就是一个典型的社区型Web应用。

从毕设的角度看，这个题目最吸引人的点是——它既有常规CRUD的“保底功能”，又有几个可以拿出来做技术亮点的“加分功能”。比如研友智能匹配、热门帖子热度计算、私信即时通讯这些模块，做得深入一点完全可以作为毕业设计答辩时的亮点展示。而就算只做最基础的版本，只要功能闭环完整、代码规范、文档齐全，也能稳稳达标。

1.2 目标用户与核心角色定义

在设计任何系统之前，先搞清楚谁在用，这比写代码重要得多。我把这个平台的用户分成三类：

第一类是普通考生。这是平台的核心用户群体，他们注册进来是为了获取信息、找研友、下载资料。他们的操作路径通常是：注册登录 → 搜索目标院校 → 查看经验帖 → 下载资料 → 发起私信咨询。

第二类是上岸学长学姐。他们是内容的主要贡献者，发布经验帖、上传专业课资料、回答学弟学妹的提问。这类用户需要一些激励机制才会持续贡献内容，所以后台需要给“优质创作者”做一些标识或等级体系。

第三类是管理员。负责用户管理、内容审核、数据统计。虽然这类平台在真实运营中管理员非常重要，但在毕业设计中，管理员的角色往往做得比较简略，我建议还是把管理端做扎实一点，因为这是答辩时老师最容易追问的地方。

这三类角色对应到系统权限上就是三种角色：普通用户（ROLE_USER）、创作者（ROLE_AUTHOR）、管理员（ROLE_ADMIN）。权限控制在接口层面用拦截器加注解实现，角色集成在JWT令牌中，登录后每次请求携带令牌，后端解析角色并校验是否有权访问。

1.3 功能模块的边界划分

我见过很多毕设项目最大的问题就是——功能面面俱到，但每个功能都浅尝辄止。考研互助交流平台的功能划分要克制，围绕“互助”二字做深，把核心闭环打通就够了。

我的模块划分方案如下：

• 用户模块：注册、登录、个人资料维护、密码修改、头像上传
• 帖子模块：发布经验帖、帖子列表（分页+排序）、帖子详情、点赞、收藏、评论
• 问答模块：发布问题、回答问题、采纳最佳答案、悬赏积分（可选）
• 资料模块：资料上传、资料列表、资料下载、资料分类（按学科/院校）
• 研友匹配模块：按目标院校+专业筛选用户、关注/粉丝关系、学习打卡动态（可选加分项）
• 私信模块：一对一聊天、会话列表、未读消息数
• 管理后台：用户管理（禁用/启用）、帖子审核（删除/置顶）、资料审核、数据看板

这样划分的好处是，每个模块都能自圆其说，模块与模块之间有真实的业务关联（用户发帖 → 帖子被评论 → 评论用户之间可以私信 → 私信后可能成为研友），形成了一个完整的业务故事线，答辩时能讲得很清楚。

2. 技术选型与架构设计决策

2.1 后端框架选择：为什么我建议用Spring Boot

市面上主流的后端方案有Spring Boot、Django、Flask、Node.js Express、Go Gin等。对于计算机毕业设计来说，我首推Spring Boot，理由如下：

第一，就业市场认可度高。Java后端在国内需求量最大，Spring Boot几乎是后端岗位的必备技能，做这个技术栈的项目对找工作有直接帮助。

第二，生态成熟，资料丰富。遇到问题搜一下基本都有答案，对于毕设这种时间紧、容错低的项目来说非常友好。

第三，Spring Boot的自动配置特性让开发效率很高，一个简单的Web项目几乎不需要写XML配置，注解驱动的方式对初学者也很友好。

我建议使用Spring Boot 2.7.x版本，不要用3.x。原因很简单：3.x基于Jakarta命名空间，部分教程和第三方依赖的兼容性容易出问题，2.7.x是稳定且被验证过的版本，用到毕业设计完全足够。

2.2 前端方案：三种选择，各有利弊

前端方案是很多同学纠结的地方，我给出三个选项供选择：

方案A：Vue 3 + Element Plus + Axios，前后端分离。这是当前的主流做法，界面美观、组件丰富、开发效率高。缺点是需要同时掌握前后端两套技术，对前端基础薄弱的同学有一定学习成本。

方案B：Thymeleaf服务端渲染。这是Spring Boot的原生方案，不用单独启动前端项目，部署简单。缺点是页面交互能力弱，做不出太复杂的动态效果，而且前后端代码混在一起不利于维护。

方案C：Vue 3 + Vite + 组件库（如Vant或NutUI），做成移动端风格的H5应用。这个方案在视觉上比较新颖，但适配PC端时会有一些问题，需要注意响应式布局。

我在实际项目中推荐方案A。虽然前后端分离会带来跨域问题、部署更复杂等额外工作量，但这也是目前真实企业项目的标准形态，做出来以后无论是答辩还是写进简历，含金量都高很多。跨域问题用后端配置CORS即可解决，部署上把前端打包成静态文件扔到Nginx里，由Nginx做反向代理转发API请求，这是非常成熟的标准做法。

2.3 数据库设计：核心表结构讲解

数据库设计的好坏直接决定项目的上限。很多毕设项目表建得随意，字段命名混乱，逻辑外键都没有，答辩时被老师一问就问出问题。

我设计的核心表如下（以MySQL为例，字符集用utf8mb4）：

用户表（t_user）：

CREATE TABLE `t_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT '加密后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `role` varchar(20) DEFAULT 'ROLE_USER' COMMENT '角色', `target_school` varchar(100) DEFAULT NULL COMMENT '目标院校', `target_major` varchar(100) DEFAULT NULL COMMENT '目标专业', `status` tinyint(1) DEFAULT '1' COMMENT '状态 1正常 0禁用', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

帖子表（t_post）：

CREATE TABLE `t_post` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '发布人ID', `title` varchar(200) NOT NULL COMMENT '标题', `content` text COMMENT '正文内容', `type` varchar(20) DEFAULT 'experience' COMMENT '类型：experience经验/qa问答', `like_count` int(11) DEFAULT '0' COMMENT '点赞数', `collect_count` int(11) DEFAULT '0' COMMENT '收藏数', `view_count` int(11) DEFAULT '0' COMMENT '浏览数', `comment_count` int(11) DEFAULT '0' COMMENT '评论数', `status` tinyint(1) DEFAULT '1' COMMENT '状态 1显示 0隐藏', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_type_status` (`type`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='帖子表';

除了这两张核心表，还需要关注表（t_follow）、点赞表（t_like）、收藏表（t_collect）、评论表（t_comment）、资料表（t_resource）、私信表（t_message）、会话表（t_conversation）等。点赞收藏这些关系表设计成只存主键的关联关系即可。

有一个我在设计时踩过坑的点：评论表虽然是树形结构（有父子评论），但我在毕设中只做了一级评论，不给它搞递归树。原因很简单——做一级评论代码量少一半，且用户用起来并不觉得缺了什么。如果想要加分，可以在评论表中加一个parent_id字段，用SQL递归查询实现二级评论，但我的建议是先把基础功能做稳定再考虑这些。

2.4 接口风格与统一响应结构

后端接口我全部采用RESTful风格，使用JSON格式传输数据。所有接口的响应统一封装为一个Result对象：

public class Result<T> { private Integer code; // 200成功 500失败 401未登录 403无权限 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

这个统一响应结构非常重要，它能让前端在处理返回值时非常简单——只需要判断code是否为200，然后取data字段即可，不需要在每一个接口的返回结构上做适配。

接口设计上我还做了一层规范：所有需要登录才能访问的接口路径都以“/api/user/”开头，需要管理员权限的以“/api/admin/”开头，完全公开的以“/api/public/**”开头。这样在编写拦截器做权限控制时只需要配置路径规则即可，逻辑非常清晰。

3. 核心功能模块实现详解

3.1 登录注册与JWT权限认证

登录模块是每一个项目的门面，也是答辩时被问得最多的模块之一。我在项目中使用了JWT（JSON Web Token）来实现无状态登录认证。

JWT的原理可以这样理解：用户登录成功后，服务器生成一个经过签名的令牌发给前端，前端每次请求都把这个令牌放在请求头里带上，后端验证令牌的签名是否正确、是否过期，从而确认用户身份。它不需要在服务器端存储会话信息，天然适合前后端分离和集群部署的场景。

具体实现步骤如下：

第一步，引入依赖：

<dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency>

第二步，编写JWT工具类，封装生成令牌和解析令牌的方法：

public class JwtUtils { // 签名密钥，实际项目中应放在配置文件中并使用更复杂的值 private static final String SECRET = "exam-platform-secret-key"; // 过期时间：24小时 private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000; public static String generateToken(Long userId, String role) { Date now = new Date(); Date expireDate = new Date(now.getTime() + EXPIRE_TIME); return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

这里要注意一个关键点：JWT的密钥SECRET不能硬编码在代码中，而且不能太简单。在实际项目中我会从application.yml配置文件中读取，并且在答辩时要能说明这个安全隐患。另外HS256算法的密钥长度有要求，太短的密钥会抛出异常，字节长度建议不少于32字节。

第三步，编写拦截器（HandlerInterceptor）实现登录校验：

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if ("OPTIONS".equals(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { try { token = token.substring(7); Claims claims = JwtUtils.parseToken(token); Long userId = Long.valueOf(claims.getSubject()); String role = (String) claims.get("role"); // 将用户信息放入请求属性中，后续接口可以直接获取 request.setAttribute("userId", userId); request.setAttribute("role", role); return true; } catch (Exception e) { // 令牌验证失败 } } // 返回401状态码 response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"message\":\"未登录或登录已过期\"}"); return false; } }

这里我需要特别强调一个实操细节：很多初学者会忘记处理OPTIONS预检请求。在前后端分离模式下，前端发送POST、PUT等请求时浏览器会先发送一个OPTIONS请求来探测服务器是否允许跨域，如果拦截器直接把OPTIONS请求拦截了，前端就会报跨域错误。所以拦截器中一定要先放行OPTIONS请求。

3.2 帖子发布与列表展示：热门排序的“算法”可以很简单

帖子模块是内容社区的核心，包括发布、列表、详情、评论、点赞、收藏这一套完整链路。

发布帖子时，前端提交标题和正文，后端将当前登录用户ID作为作者，插入t_post表，并把正文中的图片做安全处理。这里有一个很多同学会忽略的点——XSS攻击防护。用户在帖子正文中插入一段JavaScript代码，如果后端原样存储并在前端渲染，就可能被浏览器执行，造成安全隐患。解决方法是后端对全文做HTML标签过滤，只允许安全的文本格式。我用的是简单的HTML标签白名单过滤方式，配合前端Vue的插值表达式渲染（Vue默认会将内容转义，不会作为HTML执行），双重防护基本足够了。

帖子列表的排序规则我定义为：

• 默认排序（综合）：综合得分 = 浏览量×0.3 + 点赞数×0.4 + 评论数×0.2 + 收藏数×0.1，按综合得分倒序
• 最新：按创建时间倒序
• 最热：按点赞数+评论数之和倒序

这个排序逻辑很简单，但能体现“数据驱动”的思维。更科学的做法是引入时间衰减因子，类似Hacker News的排序公式：

Score = (P - 1) / (T + 2)^G

其中P是点赞数，T是发帖后经过的小时数，G是一个重力系数（通常取1.5）。这个公式的好处是新帖子不会被老帖子永远压在下面。但考虑到毕设项目的体量，用简单的加权综合得分是更务实的选择，不用过度设计。

帖子详情页还需要处理浏览量。有同学这样实现：每次获取详情时就把view_count加1。这样会导致一个问题——用户自己刷新一下页面浏览量就+1，数据会失真，而且频繁点击会带来压力。我建议用一个过滤器：同一个IP或者同一个登录用户在一定时间内（如10分钟）对同一个帖子的访问只计一次数，用集合或Redis做去重。如果没有Redis环境，用一个HashMap加过期清理也行，但要注意并发问题，可以用一个简单的带时间戳的ConcurrentHashMap来记录。

评论功能相对简单，插入评论记录到t_comment表，同时把帖子的comment_count字段加1即可。但要注意在删除评论时同步把计数减回去，否则会出现数据不一致。

3.3 资料上传与下载：文件存储的安全细节

资料模块是考研平台的核心特色。用户上传PDF、Word、PPT等格式的学习资料，其他用户下载使用。

资料上传的后端实现包括：

1. 文件类型校验。只允许设置后缀白名单（.pdf, .doc, .docx, .ppt, .pptx, .zip, .rar等），并在校验时不能只看文件后缀，还要检查文件的Content-Type。如果是Java开发，可以用Apache Tika来识别真实的文件类型，防止有人把恶意脚本改成PDF后缀上传。

2. 文件大小限制。Spring Boot的multipart配置中设置max-file-size和max-request-size，例如设置单个文件最大50MB，总请求最大100MB。

spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB

3. 文件存储路径。在Linux服务器上通常存储在“/data/upload”目录下，然后在配置文件中用变量指定。文件命名不要用原始文件名，容易冲突，应该用UUID或时间戳生成新文件名。

String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = System.currentTimeMillis() + "_" + UUID.randomUUID().toString().replace("-", "") + ext;

4. 访问映射。如果是单体项目，可以用WebMvcConfigurer实现虚拟路径映射，将本地磁盘目录映射为URL路径：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${upload.path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler(uploadPath); } }

如果使用了Nginx部署，更优的做法是直接在Nginx配置一个静态资源路径，API层只负责记录文件元数据，不经过Java应用读取文件内容。

下载功能的实现需要注意：如果只是给前端一个文件URL让浏览器直接打开，那下载量统计功能就不好做。更推荐的方案是使用Spring的ResponseEntity做文件流输出，这样可以在下载时验证用户登录状态、更新下载计数：

@GetMapping("/download/{id}") public ResponseEntity<Resource> download(@PathVariable Long id) throws IOException { // 1. 从数据库查询资源记录，获取存储路径 // 2. 更新下载量 count + 1 // 3. 将文件包装为Resource返回 Path path = Paths.get(resource.getFilePath()); Resource resourceFile = new UrlResource(path.toUri()); return ResponseEntity.ok() .contentType(MediaType.parseMediaType("application/octet-stream")) .header(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename=\"\"") .body(resourceFile); }

3.4 研友匹配：简单而高效的用户筛选方案

研友匹配功能是这个题目的一个亮点功能，也是区别于普通论坛系统的核心差异。但注意不要把“匹配”做得太复杂——什么协同过滤算法、用户画像聚类，在毕设阶段容易给自己挖坑。

我的方案很简单但有效：基于目标院校和目标专业做筛选。用户可以设定自己的目标院校和目标专业（在个人资料中维护），研友匹配页展示所有目标院校相同或目标专业相同的其他用户，支持按院校筛选、按专业筛选、按关注状态筛选。再配合一个“关注”功能，让用户可以收藏感兴趣的研友，形成关注关系。

更进一步，可以做学习打卡功能：用户每天发布一条打卡动态（文字+图片），展示在个人主页上，形成一个类似积分的激励机制。连续打卡天数用Redis的过期键或者数据库查询判断——今天是否有记录、昨天是否有记录，从而计算连续天数。这个功能的实现逻辑很清晰，而且演示效果好，答辩时展示起来比干巴巴的帖子列表有说服力得多。

匹配逻辑的核心SQL：

SELECT * FROM t_user WHERE status = 1 AND ( (target_school = #{targetSchool} AND target_major = #{targetMajor}) OR target_school = #{targetSchool} OR target_major = #{targetMajor} ) ORDER BY CASE WHEN target_school = #{targetSchool} AND target_major = #{targetMajor} THEN 0 WHEN target_school = #{targetSchool} THEN 1 ELSE 2 END

这条SQL用CASE表达式做了匹配优先级的排序——完全匹配（院校+专业都相同）排在最前面，只匹配院校的次之，只匹配专业的排最后。不需要写复杂的算法就能让用户感到“匹配结果是智能的”。

3.5 私信模块：WebSocket还是轮询

私信是用户间交流的通道，实现方式有两种：

方式一：HTTP轮询。前端每隔几秒调用一次接口，获取新的消息。实现简单，但实时性差，请求量大。

方式二：WebSocket。浏览器与服务器建立长连接，服务器有新消息时主动推送给客户端。实时性好，是真正的“即时通讯”，但实现复杂度高不少。

折中建议：毕设阶段用轮询即可。为什么这么说？因为WebSocket在Spring中的配置虽然不完全难，但要处理心跳、断线重连、会话管理等一系列问题；而轮询方式只需要一个查询接口加前端setInterval定时器，代码量少，出错率低。这个回答可能有很多人不赞同，但我认为在“答辩展示”这个场景中，轮询效果并不差——因为演示时依然是即时弹出来的，用户感知不到具体延迟。

如果导师明确要求WebSocket，或者你想把这个项目作为简历中的亮点项目展示，那么用Spring的WebSocket实现也是完全可行的。核心步骤如下：

1. 引入spring-boot-starter-websocket依赖
2. 实现WebSocketHandler接口，重写afterConnectionEstablished、handleTextMessage等方法
3. 用一个ConcurrentHashMap维护 userId 到 WebSocketSession 的映射
4. 在发送私信的业务方法中，获得接收方的session并推送消息

需要提醒的是：WebSocket和Spring的拦截器体系是分开的，WebSocket握手阶段需要单独做身份认证，可以在握手拦截器中解析URL参数中的token来获取用户ID。

3.6 后台管理：数据看板的统计SQL

管理后台我设计了四个核心页面：

第一个是用户管理。表格展示所有用户，支持按用户名搜索、禁用/启用用户、重置密码。禁用用户的实现可以在t_user表中增加status字段，当status=0时拦截器校验令牌通过后还要检查用户状态，被禁用用户直接拒绝访问。

第二个是内容审核。帖子列表和资料列表都显示待审核状态的内容，管理员可以审核通过或删除。对于毕业设计，这里做一个简单的两态审核就够用了，不需要做复杂的审核流。

第三个是数据看板。展示总用户数、今日新增用户、帖子总数、资料总数等统计指标。这几个数字用SQL聚合函数直接统计即可：

SELECT COUNT(*) FROM t_user WHERE create_time >= CURDATE();

如果想让图表好看一点，可以接一个ECharts的柱状图显示最近7天每日新增用户数，这段SQL是：

SELECT DATE(create_time) AS d, COUNT(*) AS cnt FROM t_user WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time) ORDER BY d;

ECharts在前端渲染折线图或柱状图非常方便，接入成本低，但是视觉上能让整个后台提升一个档次。

第四个是举报管理（可选）。用户可以举报违规内容，管理员在后台处理。这个模块本身不是什么新技术，但能体现项目的完整性——有用户反馈、有管理员处理、有业务闭环，讲故事的时候很加分。

4. 关键难点与性能优化方案

4.1 并发场景下的计数问题

点赞、浏览量这些操作在高并发场景下会遇到数据库瓶颈。虽然毕设项目很难出现真正的并发压力，但老师会在答辩时提问：“如果100个人同时给一个帖子点赞，你的系统能扛住吗？”

这个问题要能答上来。我的方案是分两层次：

第一层，用数据库的乐观锁更新。更新语句带上版本号或者直接做条件更新：

UPDATE t_post SET like_count = like_count + 1 WHERE id = #{id}

这样的原子更新语句天然防并发，因为数据库会锁行。不需要先SELECT再UPDATE，两条SQL分开写就会产生并发覆盖问题。

第二层，对于点赞行为本身用唯一约束防重复。t_like表建立(user_id, post_id)唯一索引，重复点赞直接报错，在代码中捕获DuplicateKeyException即认为是重复操作，返回友好提示。同理，取消点赞就是删除这个记录。如果点赞操作和数据计数更新同时执行，还有一个小问题——用户点赞接口调了两次，计数加了两遍。我的解决办法是用一个事务将“插入t_like记录”和“更新like_count字段”绑定在一起，保证原子性。

4.2 搜索功能：MySQL的LIKE与全文索引

考研平台的核心需求之一就是搜索——搜索帖子、搜索资料、搜索用户。毕设阶段不需要引入Elasticsearch这种重型搜索引擎，用MySQL就够了。

精确匹配场景：用户按用户名搜索，使用“=”。模糊搜索场景：按标题搜索帖子，使用LIKE '%关键词%'。要注意的是，以%开头的LIKE查询无法使用普通索引，会导致全表扫描。对于数据量少的毕设项目这不是问题，但答辩时被问到性能优化时，要能说出“如果需要优化，可以使用倒排索引或全文索引”这个思路。

如果用户量在万级以下、帖子在十万级以下，MySQL的全文索引就够用了。如果数据量再大，就需要考虑Elasticsearch，但这不是毕业设计讨论的范畴了。

还有一个小功能值得做——搜索历史。把用户最近的搜索关键词存入Redis（List结构，只保留最近10条），在搜索框下方展示。这个功能不复杂但是演示效果好，体现“贴近真实产品”的设计思维。

4.3 数据一致性与事务边界设计

一个容易被忽视的问题：点赞表插入成功，但帖子表的like_count更新失败，数据就不一致了。解决的根本办法是使用事务。

@Transactional public void likePost(Long userId, Long postId) { // 1. 校验帖子存在且未删除 // 2. 插入点赞记录 // 3. 更新帖子的like_count字段 }

在Service层方法上标注@Transactional即可，Spring会为该方法开启数据库事务。要注意的是，事务失效的三大经典场景：

第一，同类内调用。同类中一个方法调用另一个标注了@Transactional的方法，事务不回滚。因为@Transactional基于代理机制，同类内调用不会经过代理。解决办法是把需要事务的方法拆分到不同的Bean中，或者注入自己的代理。

第二，异常被捕获。方法内try-catch捕获了异常但没抛出，事务框架感知不到异常就不会回滚。正确做法是捕获异常后基于业务逻辑决定是否抛出RuntimeException，通过throw new RuntimeException("xxx")触发回滚。

第三，非RuntimeException。默认情况下只有RuntimeException和Error会触发回滚，如果抛出了CheckedException不会回滚。需要在@Transactional上设置rollbackFor = Exception.class。

4.4 前端性能与体验优化

前端层面的优化主要做三件事：

第一，列表页使用分页组件。我用的是MyBatis-Plus的Page插件，前端配合Element Plus的el-pagination组件。每页大小设为10条，避免一次加载大量数据导致页面卡顿。

第二，图片懒加载。帖子列表中如果包含图片，使用Vue的v-lazy指令实现懒加载，只有滚动到可视区域时才加载图片。这个对页面首屏速度的提升非常明显。

第三，接口防抖。用户搜索时，设置一个300ms的防抖，用户停止输入300ms后才发请求，防止每次敲击键盘都请求一次接口。

这些优化单独看都是小技术点，但组合起来能让项目的完成度和专业感明显提升。答辩时的评价不是只看某个功能多复杂，而是整体给人“像个正经项目”的感觉。

5. 常见问题与排查技巧实录

5.1 前后端分离项目跨域问题

我几乎可以确定每个做前后端分离毕设的同学都会遇到跨域问题。现象是：前端请求后端接口时，浏览器控制台报错“Access to XMLHttpRequest has been blocked by CORS policy”。

原因很简单：前端运行在localhost:5173（Vite默认端口），后端运行在localhost:8080，浏览器认为这是两个不同的源，遵循同源策略拒绝跨域请求。

解决方案一：后端配置全局CORS：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意这里用allowedOriginPatterns代替allowedOrigins是因为当allowCredentials为true时，allowedOrigins不能使用“*”，这是Spring的一个安全限制。

解决方案二：前端配置代理。Vite的vite.config.js中配置：

export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

这样前端请求“/api/post/list”会由Vite开发服务器转发到后端，不存在跨域问题。部署时再用Nginx做一层代理就行。

我推荐的方案是配置前端代理，因为这样后端的CORS配置可以去掉，更贴近生产环境的真实做法。但两套方案都掌握比较好，因为部署时如果前后端不在同一台服务器，还是需要后端开启CORS。

5.2 部署时页面刷新404问题

前后端分离部署完成后，如果前端路由用了Vue Router的History模式，直接访问“/post/123”这样的地址会404。原因：Nginx没有找到对应的物理文件，把请求转发给了静态文件服务，但没有“post/123.html”这个文件。

解法一（推荐）：Nginx配置try_files将所有非文件请求重定向到index.html：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

解法二：改为Hash模式路由。Vue Router中把createWebHistory()换成createWebHashHistory()，URL中会带“#”号，不再依赖服务器配置。视觉效果稍差，但配置简单。我的建议是部署环境用try_files方案，开发环境用History模式。

5.3 数据库连接与字符集问题

有几个常见问题我列出排错步骤：

问题一：项目启动后中文乱码。排查顺序是：检查MySQL表是否为utf8mb4字符集，检查jdbc连接URL是否加了characterEncoding=utf8mb4参数，检查文件保存编码是否为UTF-8（IDEA在右下角可以设置）。

spring: datasource: url: jdbc:mysql://localhost:3306/exam_db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false

问题二：MySQL连接失败“Public Key Retrieval is not allowed”。在连接URL中添加allowPublicKeyRetrieval=true即可。

问题三：数据库表字段是关键字。这是写SQL时容易踩的坑，比如字段名用“rank”“status”等。在SQL中如果必须使用这些词，用反引号包裹可以规避，但最好的办法是建表时就避开这些名字。

5.4 文件上传失败排查手册

文件上传是资料模块的命门，也是最容易出问题的地方。我整理了几个高频原因：

第一，大小超限。Spring Boot默认上传限制是1MB，超过就报错。按前述配置调大max-file-size和max-request-size即可。

第二，文件为空。前端没有设置请求头Content-Type为multipart/form-data，或者FormData中append的文件字段名和后端的@RequestParam("file")不一致。这类问题需要同时检查前端代码和后端接口签名。

第三，路径不存在。上传代码中用到了“/data/upload”目录，但服务器上没有这个目录。JavaFile API的mkdirs方法只在父目录不存在时才创建，但要注意运行时用户权限问题。建议在项目启动时通过ApplicationRunner初始化目录。

@Component public class InitRunner implements ApplicationRunner { @Value("${upload.path}") private String uploadPath; @Override public void run(ApplicationArguments args) { File dir = new File(uploadPath); if (!dir.exists()) { dir.mkdirs(); } } }

5.5 接口压力下数据库连接池耗尽

这是一个进阶问题。毕设项目一般不会有大量并发，但如果同时跑着多个查询，默认的HikariCP最大连接数是10，可能被慢查询占满导致报错“Connection is not available, request timed out”。

排查方法：开启MySQL慢查询日志，找出执行时间超过1秒的SQL，看看是不是缺索引。

优化思路：给所有查询条件字段（外键、创建时间、类型）加上索引。如果业务上经常按帖子类型和时间排序，可以建立联合索引（type, create_time）。这是成本最低且效果最明显的优化方式。

索引不是越多越好，每个索引在插入和更新时都要维护，但毕业设计阶段的索引缺失问题远多于索引冗余，该加就加。

6. 部署、文档与答辩准备的实战心得

6.1 项目部署的完整流程

毕业设计交付时通常要求能现场演示，部署方案我用的是最简单可靠的三层结构：

第一层：前端静态文件。将Vue项目执行“npm run build”后生成dist目录，将这个目录上传到服务器Nginx的html目录中。

第二层：后端服务。执行“mvn clean package”打成jar包，使用java -jar命令启动，或者更规范一点用systemd服务方式托管：

[Unit] Description=Exam Platform Backend After=network.target [Service] Type=simple User=root WorkingDirectory=/opt/exam-platform ExecStart=/usr/bin/java -jar /opt/exam-platform/exam-platform.jar --server.port=8080 Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target

一条systemd配置说明了项目后续的生命周期管理方式，在面试或答辩时提到这些细节会让老师觉得你真正理解部署这个事情。

第三层：Nginx反向代理配置。

server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /upload/ { alias /data/upload/; } }

这三段配置解决了所有问题：前端页面访问、API请求转发、上传文件访问。同时，Nginx层还顺手处理了跨域问题，因为浏览器访问的是同一个域名，由Nginx分发到不同服务。

6.2 部署文档与操作手册的写法套路

很多同学的部署文档写得像流水账，装个软件写一步，启动项目写一步。我更推荐写成“从零开始的环境搭建到项目运行验收”的完整流程。核心内容是：

• 环境要求：列出JDK版本（1.8）、MySQL版本（5.7+）、Node版本（14+）、Nginx版本，并说明为什么要这些版本，软件的安装步骤可以前置。
• 配置说明：application.yml中的数据库账号密码、上传路径、JWT密钥等，哪些可以保持默认，哪些必须修改，最好给一个配置项对照表。
• 部署步骤：按序号写清楚从获取代码到页面访问成功的每一步，遇到可能出错的地方要配截图。操作手册的核心是“照着做就能成功”，截图的缺失会让读者卡在某些环节完全无法继续。
• 验收测试：给出几个验收用例，比如“模块一用户注册登录”“模块二发布帖子”这样的，每一条说明操作和数据预期，这既是部署验证，同时也是答辩测试用例。

6.3 答辩讲解的重点话术

答辩时老师关注的核心是——这个系统是不是你自己做的、你怎么理解这个系统的设计。我的建议是准备一段3分钟的讲解逻辑：

开场30秒讲背景定位，说明项目的选题动机和用户群体。

中间90秒讲技术架构，从前后端分离讲到数据库设计，从JWT讲到事务控制，期间穿插1-2个技术难点的解决思路。

最后60秒做功能演示，按一条完整链路来演示：注册账号 → 修改个人资料（填目标院校） → 发布经验帖 → 查看帖子列表 → 上传资料 → 下载资料 → 查看个人主页。这条链路的优点是每个操作之间都有逻辑连接，而不是零散地逐个点击菜单。

被老师追问得最多的三个问题，提前准备好答案：

第一个问题是“为什么选这个课题”。不要只回答“导师给的题目”，要有自己的想法，比如“考研是很多大学生的刚需，信息不对称是痛点，这个平台能帮助考生高效获取信息和找研友”这类有分析深度的话。

第二个问题是“系统的安全性怎么考虑的”。要能说出密码加密（BCrypt）、JWT防篡改、XSS过滤、SQL注入防御（使用MyBatis的预编译#{}占位符）、文件类型校验，这样回答就会比较全面。

第三个问题是“系统的瓶颈和扩展方向”。可以有层次的回答：当前用的是MySQL单库，百万级数据量没问题；如果未来用户量增大，可以对帖子表做分库分表，引入Redis做缓存，静态资源上云存储，搜索引入Elasticsearch。话术准备好不代表要背，目的是让心里不慌。

7. 实操总结与避坑清单

我做了这个完整项目的落地实操之后，最大的体会是：很多人做毕业设计，一开始想得很大，最后连最基本的功能都没做完，开始前把目标定小一点，做完再逐步加功能。这里我把最核心的几条经验整理成清单，供后来者参考：

第一，数据库设计先行，先把表结构画明白再动手写代码。表之间的关系没理清就开发，中途加字段、改字段名会害死自己。我用的是先把7张核心表全部定义好，确认字段和索引之后才开始写后端代码。

第二，后端接口先假数据联调再写业务。把Controller和Service的骨架搭好后，用模拟数据把前后端跑通，再逐个模块填充真实业务逻辑。这样可以避免“开发到一半才发现前端接口字段对不上”的大规模重构。

第三，常用的代码片段要模板化。分页查询、统一响应、异常处理、参数校验这些代码，写一次后面所有模块直接复制改改，效率提升显著。我用的是MyBatis-Plus，它的分页插件和条件构造器把很多重复代码都省掉了。

第四，开发过程中别频繁换技术栈。看到别人用某个新技术就想把自己的项目重构一遍是大忌，以“能稳定跑通”为首要目标，技术亮点可以作为后续迭代的备选项。

第五，抽出时间提前部署和测试。很多同学直到答辩前一天才第一次把项目部署上线，手忙脚乱是常态。按我的经验，至少提前一周完成全部部署和功能回归测试。

最后分享一个小技巧：项目运行日志一定要保留。答辩时如果现场出了问题，日志中记录的报错能帮助快速定位，从容应对。就算一切顺利，日志里积累的运行数据也是证明系统真实可用的有力论据。