Spring Boot校园论坛系统设计与实现：从JWT到Redis全栈解析

1. 为什么拿“校园论坛”当毕业设计，性价比在哪里

1.1 这个选题的真实业务场景

每年毕业设计选题季，最容易看到的项目类型是XX管理系统、XX电商平台、XX预订小程序。这类题目不是不能做，但普遍有个问题：业务逻辑太薄，基本就是几张表的增删改查，写完答辩的时候很难讲出东西。导师问一句“你这个系统解决了什么实际问题”，自己心里都发虚。

校园论坛正好踩在一个比较理想的位置。从用户角度看，一个高校学生社区的核心诉求非常明确：学生要能发帖子交流、追问问题、看别人怎么回答、给有用的内容点赞、把好帖收藏起来；管理方要能审核内容、管理分类、处理违规帖子。这个场景大家每天都在用，几乎所有评审老师都能秒懂业务，不用你花五分钟解释“这个系统是干什么用的”。

从技术训练角度看，论坛涉及的内容生产、内容消费、内容治理链路是完整的：发帖涉及富文本和内容安全，评论涉及排序和分页，点赞收藏涉及关系数据，热度榜涉及计算和缓存，后台审核涉及权限控制。一个项目能把权限、事务、缓存、安全、文件上传、统计排行这些点全部串起来，比单独做十个管理系统学到的都多。

1.2 三种角色与功能清单

我把系统里的使用角色拆成了三类，不同的角色看到的界面和能做的事情完全不同。这里面的权限边界是答辩时很好讲的内容。

功能清单我控制在 15 个以内，因为毕业设计最怕的是功能列得很大，但每个功能都是空的。我当时按“必须做、选做、加分做”三个级别重新排列了一下：注册登录、分类发帖、评论、点赞收藏、搜索、后台管理是必须做的；关注、消息通知、头像上传是选做；热度排行、敏感词过滤、数据看板属于加分项，时间充裕再补。

1.3 工作量评估与时间分配

我给的参考时间是四周左右，每天保证三到四个小时。第一周做数据库设计和核心接口，第二周做前端页面，第三周把交互细节和权限逻辑补完，第四周留在部署、写文档和准备演示。这个时间节奏的前提是不要纠结于炫技，把主流稳定的方案用熟练，比反复折腾某个冷门框架要稳得多。

2. 技术选型：稳定压倒一切，别在毕业设计里冒险

2.1 后端技术栈组合

这个项目我用的后端组合是 Spring Boot 2.7 + Java 8 + MyBatis-Plus 3.5 + MySQL 8 + Redis 5。之所以用 Java 8 而不是更高的版本，是因为绝大多数高校的机房环境、老师使用的工具链、以及网上能找到的参考文档都是围绕 Java 8 展开的，出问题的时候排查成本最低。

Spring Boot 为什么是必选项，我不需要多解释，它内嵌了服务器，打成一个 jar 包就能跑，比传统的 SSM 项目少一大堆配置。MyBatis-Plus 的选择理由是：单表 CRUD 完全不需要写 SQL，内置的分页插件还能解决分页查询的通用问题；它不排斥手写复杂 SQL，多表查询需要优化时照样可以写。Redis 在这里主要承担两个职责：缓存登录 Token 对应的用户信息、缓存热度排行榜。如果本地没装 Redis，可以不作为启动必选，但我会建议你装，因为答辩时聊缓存聊性能，Redis 是个现成的加分话题。

2.2 前端方案与接口交互约定

前端我用的 Vue 3 + Vite + Element Plus + Axios，没有引太重的 UI 框架，也没有上 TypeScript。原因很简单：毕业设计阶段用 TS 会显著增加组件类型定义的工作量，但带来的收益在短时间内体现不出来。用 JS 写完，再加 JSDoc 注释，可读性就已经够了。

前后端接口约定统一走 RESTful + JSON。我设计了一个非常朴素的统一返回结构，所有接口成功失败都是一个模样：

{ "code": 200, "message": "操作成功", "data": {} }

Axios 的拦截器统一处理两件事：请求头自动带上 Token，响应里出现 401 时自动跳回登录页。这样后续写页面的时候不用每个接口都处理一遍登录失效的逻辑，省了非常多重复代码。

2.3 工程结构与开发顺序

后端工程我分成controller、service、mapper、entity、common、security六个包。common放统一返回结构、全局异常处理器、分页对象；security放 JWT 工具类、拦截器、当前用户上下文。这个结构很常规，但够清晰，后期加功能的时候不会找不到文件。

开发顺序我强烈建议按“数据库 -> 实体类 -> Service -> Controller -> 前端页面”来，不要先写页面。数据库是数据的根，实体类确定了字段命名规则，后面所有代码都会跟着这两个基础走。顺序反了，大概率会陷入改表、改实体、改前端字段的三方联动泥潭。

3. 数据库设计：核心表不翻车，整个项目就稳了一半

3.1 用户表设计

用户表是整个系统的地基，我在设计时把注册所需信息和扩展信息分开。注册只需要学号、姓名、密码、学院、专业、年级，这些字段在注册表单里直接收集。头像、个人简介、个性签名这些属于扩展信息，允许注册后修改，放在同一张表里，默认值给空。

密码存储我使用了加盐哈希，没有使用 MD5 这种弱散列算法。Spring Security Crypto 里自带的 BCrypt 就可以直接引入，它每次生成的哈希值带随机盐，即使两个用户密码一样，落库的密文也不同。这里有个非常常见的错误：很多同学把密码明文直接存进去，或者只做一层 MD5，这在答辩时是很容易被追问的软肋。

用户表里还有一个容易被忽视的字段是状态。正常 1、禁用 0。管理员禁用账号后，这个用户登录接口要直接拒绝，同时他以前发布的帖子可以在展示层标记为“该用户已注销”，避免直接删除造成数据混乱。

3.2 帖子表与评论表

帖子表的核心字段包括：标题、正文（富文本 HTML）、纯文本摘要、分类 ID、发布用户 ID、状态、浏览量、点赞数、收藏数、评论数、置顶标记、加精标记、创建时间、更新时间。这里我做了两个自认为很重要的决定。

第一个决定是冗余了浏览量、点赞数、收藏数、评论数这四个统计字段。很多教程喜欢让你实时 count，但帖子列表页、热度榜、后台管理到处都需要这些数，每次都实时 count 性能很差，而且 SQL 写起来很啰嗦。我的策略是：统计字段在业务发生时同步更新，列表页查询直接读冗余字段。

第二个决定是帖子状态设计成草稿、待审核、已发布、已拒绝四种。纯个人论坛不需要审核，但只要加上“内容审核”这一步，系统就多了一层业务深度，导师对这块的好感度很高。

评论表则需要特别设计“楼层号”。每条评论在所属帖子里有一个递增的floor_no，从 1 开始。用户看到“3 楼”就知道这是第三条评论，非常直观。楼层号怎么保证并发下不重复？我用的是 Redis 的 INCR 按帖子维度计数，没有直接用数据库自增。如果没有 Redis，也可以用该帖子最大的 floor_no 加一，配合唯一约束防重复。

3.3 点赞收藏与关注关系数据

点赞表、收藏表、关注表这三张关系表结构非常相似，都是“用户 ID + 目标 ID + 创建时间”，区别只是目标不同。我建了一个联合唯一索引（用户 ID，目标 ID）防止重复点赞，业务代码里再判断一次当前状态，决定是增加还是取消，要保证幂等。

有个细节：删除帖子时，帖子下的评论、点赞、收藏数据怎么处理？我用了逻辑删除方案。先给帖子表加一个deleted字段，删除时批量把所有关联的评论也标记为 deleted，而不是物理删除。这么做的原因是：后台统计报表需要知道历史上一共有多少条互动数据，物理删除会把这些痕迹抹掉。真正需要清理数据时，再用定时任务物理清理。

4. 核心功能实现：从登录到热度排行，逐段拆代码

4.1 JWT 登录鉴权：无状态会话的实现

登录流程并不复杂：用户提交学号和密码，后端查用户表、校验 BCrypt 密码，通过后生成一个 JWT 返回前端。JWT 里只携带用户 ID、角色、过期时间三个信息，不放其他任何敏感数据。

生成 Token 的核心逻辑大致是这样：

public String createToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey.getBytes(StandardCharsets.UTF_8)) .compact(); }

拦截器拿到请求头里的 Token 后先解析，解析失败直接返回 401；解析成功就把 userId 放进一个 ThreadLocal 上下文中，后续 Service 层通过上下文拿当前登录用户。这里有个我踩过的坑：密钥字符串长度不能太短，HS256 的密钥需要满足安全长度，否则某些环境下会报错，我后来统一配置为 32 位以上的随机串。

4.2 发帖与内容安全过滤

发帖接口的参数包含标题、正文 HTML、分类 ID。Controller 层只做参数绑定，Service 层实现完整流程。由于涉及帖子主表插入、分类统计更新、敏感词记录等多个操作，我在方法上加了@Transactional，任何一个步骤失败都要回滚。

富文本内容的安全过滤是我特意加进去的，因为像这类论坛项目只要允许用户输入 HTML，XSS 就是绕不开的问题。我用 Jsoup 的白名单机制对正文做清洗，把 script、iframe、事件属性等全部去掉：

String safeHtml = Jsoup.clean(content, Safelist.relaxed());

relaxed白名单保留基础的段落、图片、链接、加粗等标签，同时又不会放过脚本。做完清洗后再把纯文本摘要取前 100 个字符，用于列表页展示。

4.3 评论排序：一个笨办法解决九成场景

评论展示我采用先按楼层号升序排列，再做“子回复归属到父评论下”的组装。数据库里每条回复记录floor_no和parent_id，parent_id=0表示这是一条主评论。

查询时一次性取出当前页所有评论，包括子回复，然后在内存里组装树形结构。这个方案对毕业设计完全够用：一个帖子的评论量级在几百条以内，内存组装远比反复查询数据库快。如果未来评论量上万，再考虑用冗余路径字段或者专门的评论表设计。

组装逻辑的关键点是保留主评论本身的楼层号，子回复展示在对应主评论下面，并记录“回复了 xx 楼”。这样页面结构清晰，而且不需要递归查询。

4.4 热度排行：别让“浏览量”决定一切

热度排行如果只按浏览量排序，会出现一个老帖永远霸榜的结果。我用的热度分包含三个维度：浏览量权重 0.3，点赞数权重 0.5，评论数权重 0.9，再叠加一个发布时间衰减因子。

计算公式可以简化为：

score = view_count * 0.3 + like_count * 0.5 + comment_count * 0.9 - TIMESTAMPDIFF(HOUR, create_time, NOW()) * 0.1

每条帖子的分数不要求绝对精确，但必须能反映“互动越多越靠前，越是新帖越有机会”。这个计算我通过定时任务每天凌晨跑一次，把前 50 名写入 Redis 的hot:posts列表里，首页直接读缓存。新发的一篇帖子即使还没进入榜单，也会有一个基础分，这样新内容不会完全被老内容压制。

4.5 搜索与分页查询

搜索我用的是 MySQL 的LIKE '%关键词%'，配合标题、摘要、正文三个字段。可能有同学会说这个方案太原始，但实际情况是：毕业设计的数据量级通常只有几百条测试数据，全文索引的收益根本体现不出来，而LIKE方案写起来简单、可控、不会引入额外的中间件依赖。

分页查询我用了 MyBatis-Plus 内置的分页插件，前端传页码和每页大小，后端返回总条数、总页数、当前页数据。这里有个加分技巧：列表页接口要把帖子作者的昵称、头像一起查询出来，不要等前端拿到帖子列表后再逐个请求用户信息，否则会形成 N+1 请求。

5. 开发期踩过的坑：每一条都是拿熬夜换的

5.1 MyBatis-Plus 分页插件失效的真相

第一个让我卡了半天的坑是分页插件不生效。现象是：加了分页参数，返回结果却是全量数据。查了很久发现是 MyBatis-Plus 新版本的分页插件要求通过MybatisPlusInterceptor显式注册，而不是以前那种自己写一个PaginationInterceptor配置类就能用。

正确的配置是新增一个配置类，往拦截器链里添加分页插件：

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }

这个属于典型的“看老教程入坑”问题。网上大量文章还在用旧版配置，照着抄就容易出事。遇到类似问题，第一反应应该是去查当前版本对应的官方文档，而不是继续翻旧帖子。

5.2 LocalDateTime 序列化问题

前后端联调时发现，接口返回的LocalDateTime字段在前端显示成一个乱七八糟的对象结构，不是想要的“2024-05-20 14:30:00”。原因是 Jackson 默认对 Java 8 时间类型支持不全。

处理方式是在application.yml里做全局配置，统一时间格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

同时引入jackson-datatype-jsr310依赖。做完全局配置后，所有接口的时间字段都输出统一格式，前端不用再做二次处理。

5.3 富文本 XSS 与文件上传限制

发帖功能上线后遇到一个实际问题：富文本编辑器里的图片上传报错。查日志发现 Spring Boot 默认限制单次请求体大小，图片稍微大一点就被拦截。这个需要在配置里调大限制：

spring: servlet: multipart: max-file-size: 5MB max-request-size: 20MB

文件存储我没有接第三方对象存储，而是存到本地目录，再通过前端静态资源方式访问。虽然生产环境不推荐这么干，但毕业设计场景下足够，而且减少了一个外部依赖。图片路径存数据库时不要存完整 URL，只存相对路径，这样以后换服务器、换域名都不用改数据库。

5.4 事务失效与懒加载异常

我遇到过一次很隐蔽的 bug：在同一个类里，一个方法调用另一个带@Transactional的方法，事务居然没生效。原因是 Spring 的声明式事务默认基于代理实现，同类内部调用走的是this引用而不是代理对象，注解直接被绕过了。解决办法有几种，最直接的是把事务方法拆到另一个 Service 类里，或者通过代理对象调方法。

懒加载异常也出现过一次。当我用 MyBatis-Plus 查询帖子时，帖子关联的用户信息是懒加载的，结果在 Controller 层试图访问用户昵称时抛了LazyInitializationException。处理方式是在 Service 层完成数据的完整组装，从查询到返回 DTO，一次性把用户信息、分类信息、统计信息都填充好，Controller 层只负责把组装好的对象返回给前端。

5.5 缓存一致性问题

用 Redis 缓存热度榜后，出现了一个数据延迟问题：用户点赞后，热度榜在缓存过期前一直显示老数据。这是因为更新操作只改了数据库，没有主动更新缓存。缓存是 MySQL 前面的一个代理，不是备份，修改数据时必须主动让缓存失效或刷新。

我最后定下来的策略是：只要帖子发生点赞、评论、收藏等互动，就把该帖子的热度缓存标记删除，下一次访问时重新计算写入。这里有个取舍，删除缓存的准确率很好，但可能造成瞬间的高频穿透；考虑到这个项目的访问量，完全不用加复杂的设计。真要说优化，可以加一个短期本地缓存兜底，但毕业设计接不住这个复杂度就适得其反。

6. 部署、演示与答辩准备

6.1 一条命令跑起来

项目交付时，我把启动流程做成了尽量简单的三步。第一步，准备好 MySQL 和 Redis，执行项目附带的init.sql建库建表并导入演示数据；第二步，修改application.yml里的数据库账号密码、Redis 地址、文件上传路径；第三步，执行mvn spring-boot:run启动后端，前端执行npm install && npm run dev。

这一步看起来简单，但我确实在配置上吃了亏。网友下载的开源项目，大半跑不起来是因为数据库账号、字符集、时区配置不一致。我在 SQL 脚本里直接指定了数据库字符集为utf8mb4，并配置了serverTimezone=Asia/Shanghai，避免中文乱码和时间差八小时的问题。

6.2 现场演示路径设计

答辩演示是有讲究的，不要上来就随机点菜单。我给自己设计了一条闭环操作路径：注册一个新账号登录 -> 发表一篇带图片和标题的帖子 -> 在评论区回复 -> 点赞收藏 -> 切到管理员账号审核刚发的帖子 -> 查看热度榜变化 -> 最后打开后台数据统计页。这条路径从普通用户的使用流程一直延伸到管理端治理动作，展示的是整个系统的完整闭环，而不是零散的功能堆砌。

演示前一定要准备几条演示账号，并提前准备好测试数据。我看到不少同学答辩时当场注册账号、等验证码，网络一卡就冷场。自己提前把账号密码写在记事本里、把测试帖子发好，演示时才有底气。

6.3 导师最可能追问的几个问题

答辩问答环节，导师大概率会问这几个问题，我把当时的应答思路一起整理出来。

为什么用 Spring Boot 而不是 SSM？我的回答是：Spring Boot 自动配置能减少大量模板代码，内嵌服务器方便部署，同时核心的 IoC 和 AOP 机制与 Spring 一脉相承，没有逃出基础框架的范畴。

JWT 和传统 Session 有什么区别？我会说：Session 是服务端存储会话状态，集群部署需要做会话共享；JWT 是客户端持有状态，服务端无状态，适合前后端分离场景。同时也会坦诚地补充 JWT 存在无法主动服务端失效的问题，所以这里后台禁用用户时，还需要额外检查用户状态。

评论为什么这么设计？我会解释楼层号的意义，以及为什么采用内存组装树形结构而不是复杂递归查询。让导师听到的不是“我用了什么技术”，而是“我在多个方案里做了横向对比后选择了当前方案”。

项目还能怎么扩展？我准备了三个方向：引入消息通知，把点赞评论事件通过异步队列推送给用户；引入 WebSocket 做楼中楼的实时提醒；引入全文检索引擎替代 LIKE 搜索。每个方向我都想清楚了入口点和受影响表，不会被问倒。

在这里我想分享一个真实体会：把这个项目从头到尾做下来，最难的从来不是某个技术点，而是面对“差不多得了”的诱惑时能不能继续肝下去。比如评论树那个小功能，第一版只用了一个递归就解决了，但后来为了兼容分页和楼层号，重构了整整两天。那两天很痛苦，但正是这种逼迫自己把逻辑想清楚的过程，答辩时才能对每一个细节都答得上。如果你也正在做同样选题的毕业设计，建议把我的这套设计思路当成一个起点，不要满足于照抄结构，最好能自己再塞一个想做的功能进去。哪怕最后没有时间做到最完美，那个被认真对待过的模块，会成为你答辩时最有底气的地方。