企业官网建设流程全解析

1. 项目整体设计与技术选型

做考研互助交流平台这个项目，我最初的想法其实很简单：考研人群的需求非常集中，无非是找资料、找学长学姐答疑、看经验分享、找研友一起打卡。但这些需求目前散落在各类论坛、QQ群、公众号里，信息非常割裂。QQ群里翻聊天记录找资料效率低到令人抓狂，公众号里的经验贴经常被删，论坛上问答又半天没人回复。把这些核心场景集中到一个平台上来，就是一个考研互助交流平台最朴素的出发点。

从标题上就能看出，这套系统用了SpringBoot+Vue作为前后端主框架，数据层是MySQL+MyBatis。这不是随便搭配的。SpringBoot负责后端服务的快速构建，开发效率高，一套标准的RESTful API下来非常省事；Vue负责前端的页面渲染和交互，配合Element Plus这类组件库，后台管理页面和数据展示页面的开发速度能提升不少；MySQL作为最普及的关系型数据库，处理用户、帖子、资料这些结构化数据绰绰有余；MyBatis则负责数据库访问层，它的灵活SQL控制力和与Java实体类的直接映射，比那些自动生成SQL的框架更适合这种业务逻辑多变的项目。

这个项目的定位是“设计与实现”，所以从毕业设计或者全栈练手的角度看，这四件套的组合可以说覆盖了现阶段国内高校和初级开发者最常接触的技术栈要求。整套系统需要实现用户登录注册、资料上传下载、社区发帖与评论、问答互动、管理员后台等模块，属于典型的“中小规模全栈应用”。

1.1 从“互助交流”这个需求倒推系统功能

考研互助交流平台的核心不是做个论坛，而是把“互助”和“交流”落到实际使用场景里。我在设计功能时先把用户分成了两类：普通学生用户和管理员。学生用户的行为路径无非是注册登录、浏览资料、下载资料、发帖求助、回帖答疑、收藏感兴趣的帖子；管理员负责用户管理、内容审核、分类维护、数据统计。这也是这类系统最常见的角色权限划分。

围绕用户行为路径，我拆出了几个核心模块：

• 用户模块：注册、登录、个人信息修改、密码重置、头像上传
• 资料模块：考研资料的分类上传、详情展示、下载记录、后台审核
• 帖子模块：经验分享帖的发布、编辑、删除，多条件检索
• 评论与点赞模块：对帖子进行评论回复，帖子点赞
• 问答模块：提问、回答、采纳最佳答案
• 后台管理模块：用户状态管理、帖子审核、资料审核、数据看板

模块拆到这个粒度，前后端的开发量刚好控制在一个合理范围内，又能完整跑通一条业务链路。这里需要特别说一句，很多初学者在确定功能时容易犯一个毛病——想要的功能特别多，结果开发到后面连核心链路都没完成。好的做法是先保证主线功能的完整流畅，比如用户发帖到审核到评论展示这条路能走通，再去扩展边角功能。

1.2 技术栈组合为什么是SpringBoot+Vue+MySQL+MyBatis

这四件套的组合，我做了好几轮的选型对比，最后敲定下来是因为它们正好覆盖了全栈开发的完整链路，而且每一环都有足够的社区资源支持。

SpringBoot的好处不用多说，它省掉了Spring MVC时代大量的XML配置。不过这里要提醒一句：SpringBoot 2.7.x和3.x之间的取舍很关键。如果学生党还在用JDK8，老老实实选2.7.x版本，别追新。SpringBoot 3.0强制要求JDK17，而且部分第三方starter对3.x的适配还不完善，万一后续集成某一个组件出现兼容性问题，排查起来非常消耗精力。我实测下来，2.7.x配JDK8几乎不会踩版本坑。

Vue这边，我选择的是Vue 3配合Vite构建。Vite的冷启动速度和热更新体验比webpack时代的Vue CLI强很多，对开发调试是实打实的效率提升。组件库用Element Plus，它提供了一整套现成的表格、表单、弹窗组件，后台管理页面基本不需要自己写CSS布局，这对前端基础比较薄弱的开发者非常友好。但要注意，Vue 3的响应式原理和Options API写法都跟Vue 2不完全一样，如果你之前学的是Vue 2，建议先把setup语法和组合式API快速过一遍再动手。

MySQL选择了8.0版本，这也是当前数据库的主流分支。MyBatis虽然没有MyBatis-Plus那么“懒人”，但优点恰恰在于SQL完全自己掌控，写出什么样的SQL就执行什么样的SQL，排查慢查询时看得明明白白。实际项目里我还在MyBatis工具类配置上重点加了驼峰映射和SQL日志打印，这两个配置对于调试阶段影响很大。另外热点词里提到TypeHandler、缓存这些点，在这个项目里虽然没有复杂到用自定义TypeHandler，但理解MyBatis是怎么把Java对象和数据库字段做转换的，对理解整个数据层的工作流程很有帮助。

版本参考建议如下：

这个组合还有一个隐性优势：它和主流招聘JD里“熟悉SpringBoot/MyBatis/Vue”正好对上。做完这个项目，你对Mapper接口开发、动态SQL、Vue组件通信、axios请求封装这些面试高频考点的理解，会比简历上写“了解”要扎实得多。

2. 数据库设计与核心业务表

数据库是一套信息管理系统的地基。业务纠缠不清，往往第一步就是表设计出了问题。考研互助交流平台涉及的数据对象比较清晰：用户、帖子、评论、资料、点赞关系。但在表设计阶段还是有几个容易忽略的点，我详细展开一下。

2.1 数据库设计思路与ER关系梳理

建表之前，我建议先在纸上把业务关系捋一遍，这一遍省下来，后面重构表的成本就高了。这个项目的核心数据关系大致是这样：

用户在平台里有两重身份关系：普通用户和管理员。用户与帖子是发布关系，一个用户可以发多个帖子，一个帖子属于一个用户。用户与评论是发布与被评论关系。帖子与评论是一对多关系。用户与资料的关联表现在上传资料和下载资料。点赞关系比较特殊，它本质上是用户与帖子之间的多对多关系，需要一个中间表来解耦。

这里要特别提醒多对多关系的处理。如果直接在主表里用一个字段去存点赞用户ID列表，比如用逗号分隔的字符串，当时写起来确实省事，但是一旦需要统计某个用户都给哪些帖子点过赞、或者做“取消点赞”这类逆操作时，SQL写起来很别扭，正确姿势是单独建一张中间表，用复合唯一索引控制重复点赞。

2.2 关键表结构设计与字段说明

用户表是系统的基础，我设计了以下核心字段：

CREATE TABLE `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` tinyint(4) NOT NULL DEFAULT '0' COMMENT '角色：0学生，1管理员', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1正常，0禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码字段长度建议设置为100，因为你大概率会用BCrypt加密，BCrypt生成的结果是60个字符左右的定长字符串，留点余量，避免某次加密策略升级后字段存不下。用户名加唯一索引，这是登录的检索条件，命中唯一索引的效率比全表扫描高一个数量级。

帖子表的结构需要覆盖“经验分享”和“问答求助”两种场景。我用了type字段做区分，考研经验帖可以设置category字段分类到政治、英语、数学、专业课等标签下：

CREATE TABLE `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` tinyint(4) NOT NULL DEFAULT '0' COMMENT '帖子类型：0分享帖，1求助帖', `category` varchar(50) DEFAULT NULL COMMENT '分类：政治/英语/数学/专业课等', `view_count` int(11) NOT NULL DEFAULT '0' COMMENT '浏览量', `like_count` int(11) NOT NULL DEFAULT '0' COMMENT '点赞数', `comment_count` int(11) NOT NULL DEFAULT '0' COMMENT '评论数', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：0待审核，1已发布，2已屏蔽', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_category` (`category`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

content字段用text类型而不是varchar，原因很简单：经验帖或者求助帖的正文长度可能超过varchar的默认上限。另外几乎所有统计类操作都离不开创建时间，主表必须有一律的create_time字段。这也是我复盘很多学生项目时发现最普遍的问题——列设计少、字段类型抠抠搜搜，结果跑起来才发现不够用。

评论表相对简单，但一个关键点在于需要用parent_id支持评论的回复嵌套。如果只做一级评论，处理起来轻松得多，但用户很容易在前端界面上看到某楼层的“回复”操作，如果表结构没有预留parent_id，后面要加就非常痛苦。

资料表用于承载考研资料上传、审核、下载，字段设计时要为“文件类型”做区分，比如PDF、Word、视频链接。视频播放这个场景有必要多说一句：很多网课资料是以m3u8格式分片的，如果平台往后要支持在线播放，建议在资料表预留一个video_url字段，前端用vue插件只做兜底，目前比较通用的方案是hls.js或者flv.js做播放，这些都是免费开源库，不需要特殊处理，往后扩展时很方便。

完整表结构可以根据上面的思路，在Navicat里一次性建好表再逐步调整。

2.3 为什么按这个顺序建索引

索引设计不是建得越多越好。我给所有表的create_time都建了索引，因为后台管理页面基本都要按时间倒序展示，这个字段是一个天然的排序值。帖子表的category字段建索引的原因是前台首页会有分类筛选操作，这个字段的选择性算不上特别高，但加上索引后分类搜索的响应速度有明显改善。

反过来，像status这种只有两三个取值的字段就不适合单独建索引了，选择性太低，走了索引反而不如全表扫描快。这一点是最容易在MySQL面试题里翻车的细节——面试官很喜欢问“索引失效场景”和“低选择性索引值不值得建”，实操中踩过一次就知道为什么拿status做索引列是下策。

3. 后端实现要点与关键代码

后端架构我采用的是经典的三层结构：Controller接收请求、Service处理业务逻辑、Mapper操作数据库。项目包名按技术分层来组织，controller、service、mapper、entity、dto、config、common各司其职。这种结构看着中规中矩，但非常稳定，适合中小团队协作和后续维护。

3.1 认证授权方案：为什么用JWT而不是Session

登录认证是管理系统的第一道门。我见过不少初学者直接用Session存储用户状态，SpringBoot里引入Servlet依赖后往session里set一个user对象，拦截器里getSession来判断登录状态。这个方案在单体项目里能跑，但有一个很现实的问题：前后端分离场景下，Session的跨域处理和集群共享非常麻烦，而且对移动端调用API的场景天然不友好。

我最终选择的是JWT自包含令牌方案。JWT的本质是把用户身份信息经过签名加密后生成一段字符串，服务端不保存会话状态，后端只需要在拦截器里校验令牌的签名和过期时间，就能确认当前请求的用户身份。这样做的好处至少有三个：服务端无状态，部署时可以随意横向扩展；前后端彻底解耦，同一个后端可以同时服务Web端和后续可能的App端；令牌本身可以携带少量非敏感信息，减少数据库查询频率。

JWT的工具类核心代码如下：

public class JwtUtil { // 密钥，实际项目中建议放在配置文件中，不要硬编码 private static final String SECRET_KEY = "your-secret-key"; // 过期时间：24小时 private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000; public static String generateToken(Long userId, String username, Integer role) { Date now = new Date(); Date expireDate = new Date(now.getTime() + EXPIRE_TIME); return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody(); } }

拦截器里对白名单路径放行，比如登录注册接口、首页的帖子列表接口，其余接口一律校验token。令牌从请求头的Authorization字段中取，格式为“Bearer xxxxx”，取出后去掉“Bearer ”前缀再解析。如果解析失败或者过期，返回401状态码和一个统一的JSON结构，前端收到401后自动跳转到登录页。整体链路非常简单，但足够支撑系统前期的安全需求。

这里给出一个关键提示：将密钥硬编码在代码里只能用于演示项目。如果是想真正部署上线的产品，密钥要放到应用配置文件里，并通过环境变量动态注入，否则代码一泄露，别人的恶意用户自己给自己签发token，瞬间就能拿到管理员权限。这个风险极其真实，不要心存侥幸。

3.2 统一返回结果与全局异常处理

前后端分离开发时要约定一套统一的数据响应格式。我定义的返回结构包含四个字段：code（状态码）、message（提示信息）、data（数据主体）、timestamp（时间戳）。成功时code为200，业务异常时code分别为400、401、403、500等。这层设计看起来占不了几行代码，但能省去前端大量繁琐的异常判断逻辑。

全局异常处理我用了@RestControllerAdvice，把所有可能抛出的异常统一拦截，避免异常堆栈直接返回给前端。这里有个细节：不要把所有异常都笼统地返回“服务器错误”，最好细分出业务异常类。我在项目中自定义了一个BusinessException，比如资料不存在、帖子已删除、参数校验失败等场景主动抛出，由全局处理器捕获后返回对应的错误提示。这样前端能直接拿到具体原因并展示给用户，而不是看到一个莫名其妙的500。

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(BusinessException.class) public Result handleBusinessException(BusinessException e) { return Result.error(e.getCode(), e.getMessage()); } @ExceptionHandler(Exception.class) public Result handleException(Exception e) { log.error("系统异常", e); return Result.error(500, "系统异常，请稍后重试"); } }

在实际项目中，这个全局异常处理的能见度很高。前端拿到“系统异常”这类通用提示时，至少不会让用户体验崩塌。

3.3 MyBatis动态SQL与核心SQL优化

MyBatis的看家本领是动态SQL，这个项目里最典型的应用场景是帖子列表的筛选条件。前端传过来可能带分类、带关键词、带时间范围，甚至可能什么都不传，后端需要根据条件动态拼接SQL。用MyBatis的<where>标签和if判断，写起来非常顺畅，完全不需要手动拼接字符串。

<select id="selectPostList" resultType="com.example.entity.Post"> SELECT * FROM post <where> <if test="category != null and category != ''"> AND category = #{category} </if> <if test="keyword != null and keyword != ''"> AND (title LIKE CONCAT('%', #{keyword}, '%') OR content LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="type != null"> AND type = #{type} </if> AND status = 1 </where> ORDER BY create_time DESC </select>

注意几个细节。status = 1是硬性条件，因为前台只能看到审核通过的帖子，所以放到<where>里而不是<if>里。模糊查询用CONCAT拼接百分号，这是一个很常见的MySQL面试题考点——用#{keyword}而不是'%${keyword}%'，可以有效避免SQL注入。ORDER BY create_time DESC直接写在SQL里，让数据库层完成排序，不要在前端通过for循环排序。POST列表接口用了PageHelper分页插件，并明确每页最多20条，防止一次拉取全表数据拖垮数据库。

关于MyBatis的resultType与resultMap选择：字段名和Java属性名完全一致用resultType就够了，SpringBoot配置里开启下划线转驼峰，数据库字段create_time自动映射成createTime属性。但如果遇到多表关联查询，比如帖子列表要关联查出发布人的昵称和头像，resultMap更合适，可以明确每个字段的映射关系，避免出现“列名找不到”这种低级报错。

3.4 文件上传与下载的实现细节

资料模块必然涉及到文件上传。我的实现思路是：上传接口接收MultipartFile，先将文件写入服务器本地磁盘目录，再将文件访问路径存入资料表。文件存储路径不要直接用用户上传的原始文件名保存到数据库，因为存在重名覆盖风险。处理方案很简单：用UUID重新生成文件名，扩展名保留。

public String uploadFile(MultipartFile file) { String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID().toString().replace("-", "") + ext; String filePath = uploadPath + "/" + newFileName; file.transferTo(new File(filePath)); return "/files/" + newFileName; }

这里有一个我在真实项目中踩过的坑：file.transferTo()方法在文件较大时，如果目标路径不存在或者服务器的/tmp目录空间被占满，会抛异常。解决的方案是非常简单的——在保存前先判断目录是否存在，不存在则先创建。生产环境上传大文件时，服务器静态文件目录根路径最好大到足够避开系统盘空间不足的问题，另外用定时任务定期清理无主文件也是一个值得考虑的后续扩展点。

4. 前端实现要点与前后端联调

前端工程我用Vite从零搭建的Vue 3项目，配合Element Plus做UI组件，Pinia做用户状态管理。项目标题里只写了Vue，但实际开发中如果连状态管理工具都没有，复杂度一上来组件间通信就会变得混乱。

4.1 前端工程结构与页面规划

前端目录结构大致如下：

• views：路由对应的页面组件，比如login、register、home、postDetail、postEdit、admin、userManage等
• router：路由配置文件和权限守卫
• store：Pinia的store定义，目前只需要一个userStore管理登录态
• api：axios实例封装和各模块的接口调用函数
• components：可复用组件，比如帖子卡片、评论列表、分页组件

路由配置是前端的骨架。我定义了两种路由：不登录也能访问的公共路由和必须携带合法token才能访问的受保护路由。这是一层非常关键的前端权限控制，和后端的JWT校验共同形成纵深防御体系，不能再走回“前端隐藏按钮就当没人看得到”的老路。

const routes = [ { path: '/login', component: Login }, { path: '/register', component: Register }, { path: '/', component: Home }, { path: '/post/:id', component: PostDetail }, { path: '/admin', component: AdminLayout, meta: { requiresAuth: true, requiresAdmin: true } } ]

Element Plus最大的价值在于后台管理模块，数据表格用el-table，配一个el-pagination分页组件，再套一个el-dialog做新增编辑弹窗，三个组件的组合就能覆盖后台管理80%的功能页面。做这类管理系统，定位就是“快速搭建、功能规范”，不要花大量时间去手写复杂样式。

4.2 路由守卫与用户状态管理

路由守卫在Vue Router 4中是通过beforeEach实现的。每次路由跳转前，先检查目标路由是否标记了requiresAuth，如果标记了且当前没有登录态，就跳转到登录页并带上redirect参数。管理员路由多一个角色判断，非管理员直接跳首页。

用户状态管理我放在Pinia的userStore中，登录成功后把token保存到localStorage，同时把用户基本信息存一份到store中。刷新页面时路由守卫会重新触发，此时从localStorage读取token，再调用一次获取用户信息的接口，恢复登录态。这里要注意，刷新应用时header里已经有token了，所以不要把token存到Pinia里当作唯一登录依据，否则一刷新就丢了。

axios请求拦截器是联调阶段的核心。我在axios实例的request拦截器里统一设置Authorization头，response拦截器里统一处理错误码。401时清除本地token，跳转到登录页。这个拦截器逻辑如果不在最初就搭好，后面开发时每个请求都要重复写登录校验代码，将会非常痛苦。

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { if (res.code === 401) { localStorage.removeItem('token'); router.push('/login'); } return Promise.reject(new Error(res.message)); } return res; }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); router.push('/login'); } return Promise.reject(error); } );

4.3 跨域问题与Vite代理配置

前后端分离开发时，跨域问题几乎必现。前端跑在localhost:5173，后端跑在localhost:8080，端口不同，跨域就出现了。这里要用一个很顺手的方案，就是在Vite devServer里配置代理，把所有/api开头的请求转发到后端地址：

server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端代码里的请求地址全部写/api/user/login，不会出现http://localhost:8080/api/user/login这种带完整域名的写法。代理解决了开发阶段的跨域，生产环境部署时前后端通常放在同一个域下，或者用Nginx配置反向代理，跨域问题就不存在了。

这个方案比在后端写@CrossOrigin注解去放开某个Controller要稳得多。因为@CrossOrigin只能解决局部接口的跨域，而且一旦放开全部接口，又等于给攻击者打开了一个可以提交跨域请求的合法口子。安全第一原则下，能够用服务端代理的对开发才是舒服的。

5. 常见问题与排查经验实录

这是我从搭建到调通整个项目过程中，踩过的最典型的坑。写下来的时候，我对这些坑的印象已经很深刻了——如果你也在独立开发的过程中遇到了类似问题，可以立刻对照定位。

5.1 高频问题速查表

速查表里最实用一条的当属允许公钥检索参数allowPublicKeyRetrieval=true，因为MySQL 8在本地连接时确实有一个公钥检索环节，如果不配这个参数直接报错。很多新手折腾半天以为是密码错了，实际跟密码毫无关系。

5.2 一次典型的“数据查不出来”排查记录

有一次测试人员在后台管理页面反馈，筛选“待审核”帖子时列表一直为空。我当时的第一反应是SQL条件写错了，因为前台按状态1（已发布）查询是正常的。打开控制台，发现请求返回的data确实是空数组，说明后台接口执行成功了，问题大概率出在SQL条件上。

打开MyBatis的日志打印配置，看到实际执行的SQL后立刻找到了原因：MyBatis的<where>标签中，我写了status = #{status}，但后台传参时status字段名写成了postStatus，实体类属性名不匹配，MyBatis传入了null，导致拼出来的SQL是WHERE status = null，直接查不到记录。这里其实涉及一个MyBatis小知识点——if标签判断的是Java属性非空，不会自动把属性名映射成数据库列名。前后端参数名不统一是联调问题的一大来源，从头对一次参数名，很多时候就能避免这种查不到数据的假故障。

这个排查过程前后只花了七八分钟，但如果没有日志打印，纯靠肉眼审查代码，可能得折腾半小时以上。

5.3 避免后端SQL性能隐患的技巧

项目是毕设或练手的规模，不需要过度优化，但有两点应该在开发过程中就养成习惯。

第一，列表查询接口不要直接用SELECT *。帖子内容字段用的是text类型，如果把正文全部查询出来，列表页只需要展示标题和摘要，等于白查了一大堆数据。用SELECT id, title, category, view_count, like_count, comment_count, create_time这样只取必要字段，MySQL能把加载到内存的数据量压缩到一个很可观的水平。

第二，必须创建必要索引。帖子表按user_id查询时没有索引就是全表扫描。测试数据量少时感觉不出来，一旦生产环境的帖子量级上来，慢查询日志里几乎每天都会出现这类语句。这也是MySQL面试中反复提到的“索引最左前缀”和“索引失效场景”，真正的体会得在自己项目出过慢查询后才会深刻。

6. 项目部署与扩展建议

项目开发完成只是第一步，能不能让同学或者测试人员真正访问到，取决于部署环节顺不顺利。

6.1 前端打包与后端本地启动流程

前端执行npm run build之后，dist目录就是编译产物。有两种部署上线的路径可选：独立部署和合并部署。独立部署是前端dist的静态文件丢到Nginx的html目录，Nginx配置一个location /api请求转发到Java后端；合并部署更简单，把dist目录下所有文件直接复制到SpringBoot项目的src/main/resources/static目录，然后打包成一个Jar包运行。

合并部署对毕设演示来说非常省事，因为只需要启动一个进程，不需要额外安装Nginx。前面提到的Vite代理是解决开发环境跨域，到了合并部署阶段就没有跨域问题了，因为静态资源和API接口在同源下。有一点一定要调整：开发环境的前端请求地址写的是/api开头，而后端接口的Controller路径如果不带这个前缀，合并部署后就要通过Nginx做rewrite或者统一映射，否则404。

6.2 从毕设到上线需要考虑的增强

如果想让这套系统更有竞争力，我建议从下面三个方向中的任一个切入，都会让思路完整度上一个台阶。

• 智能推荐：把帖子表和资料表的浏览记录、下载记录汇总，用协同过滤算法给用户推荐可能感兴趣的考研内容，算法不一定要复杂，基于标签的统计推荐就能有不错的效果。
• 数据看板：后台管理加几个ECharts图表，展示每日新增用户数、帖子发布趋势、热门分类占比，技术含量不高但是产品完成度提升非常明显。
• 团队协作与自动化部署：用Git管理代码，前后端仓库分开，配置CI/CD流程，提交代码后自动构建和部署到测试环境。这一套流程写进简历，在求职面试时的加分效果非常明显。

根据我做这类全栈项目的经验，把基础链路跑通最要花心思的永远不是某一个单独的组件，而是跨端问题的排查。前后端联调时，如果某个接口的数据和预期不一致，先打开浏览器F12看Network里的具体request和response，再定位到后端日志，这个方法能高效解决掉的联调问题占了整个项目的绝大部分。

最后再分享一个我调试阶段的实际体会：开发这种全栈项目时，最好从“最小可用闭环”起步，比如第一个迭代就做“用户注册→登录→发帖→帖子列表展示”，把这四步跑通，前后端的骨架就已经建立，之后的模块都是在此基础上复制粘贴加修改。反过来如果一上来就去写完后台管理的所有页面，再回过来调核心业务链路，很容易在联调时发现后端接口和前端页面不适配，推倒重来的代价会很高。这个顺序上的取舍，说起来简单，但真按这个思路执行的效率提升是很明显的。

这套技术栈的组合方式，无论未来是做毕业设计，还是想往全栈开发的方向深入学习，都可以作为第一步的完整参考，后续再逐步加入Redis缓存、消息队列或者微服务相关内容，扩展路径也足够清晰。