SpringBoot校园资讯交流平台毕设实战：从数据库设计到审核状态机

差不多每到毕业季，就会有一批人卡在“基于SpringBoot的校园资讯交流平台”这个题目上。这个题目我做过多轮，也带学生落地过不少版本。说实话，它看起来像是个普通的新闻管理系统加个登录注册，但真正动手后会发现，从用户角色划分、资讯审核状态流转，到点赞评论这类交互数据的处理，每一步都藏着可深可浅的设计空间。这篇文章我打算把整个项目的源码结构、数据库设计、核心技术点、以及最容易翻车的地方一次性拆明白，给正在做毕设或者想拿这个题目练手的同学一条能直接走通的参考路线。

这个项目适合谁？刚学完SpringBoot基础、想找一个完整项目串联知识的初学者，以及毕业设计选了类似题目的同学。如果你已经把增删改查demo写得很熟，但不知道怎么组织多模块业务，不知道怎么处理登录权限和前后端联调，这篇文章应该能帮你把整个流程打通。

我在这里不会只贴代码，而是把每个设计决策的“为什么”也讲清楚。因为评委老师问问题，基本不会问“你这段代码怎么写的”，而会问“你为什么要这么设计”。

1. 项目到底要做什么，别一上来就写代码

很多同学拿到这个题目，第一反应就是问：这和我大二写的图书管理系统有什么区别？区别非常大。图书管理系统是单角色的CRUD，校园资讯交流平台至少包含三块核心业务：内容生产（资讯发布与审核）、社区互动（评论、点赞、收藏）、用户体系（学生、管理员、游客等多角色权限）。这三块业务单独拆开都不难，但要捏合成一个完整系统，就需要提前想清楚需求边界。

1.1 核心需求拆解

我建议先以“用户故事”的方式写需求，比如：

• 作为一个游客，我可以浏览资讯列表和详情，但如果我想点赞或者评论，我就需要先登录。
• 作为一个学生用户，我可以发布资讯，但发布后不是立刻展示，而是要等管理员审核通过。
• 作为一个管理员，我可以在后台对资讯进行审核、上下架，可以管理用户状态，可以查看资讯维度的统计数据。
• 作为一个系统，我需要记录用户的操作行为，比如谁在什么时候审核了哪条资讯，这个记录在答辩时非常有说服力。

把这几个用户故事落成功能清单，大概就是：

前台模块：用户注册登录、资讯列表（分类筛选、分页搜索）、资讯详情、评论列表与发表评论、点赞、收藏、个人中心（我发布的、我收藏的、我评论的）。

后台模块：管理员登录、资讯审核管理、资讯分类管理、用户管理、评论管理、数据统计。

功能看着不多，但这些模块之间是相互关联的。比如点赞需要校验用户是否登录，评论需要关联资讯和用户，资讯审核状态会直接影响前台是否展示。这种关联关系才是毕业设计真正要体现的东西。

1.2 技术选型为什么要用SpringBoot

你选SpringBoot，不是因为它时髦，而是因为它真的适合这个项目。

先说自动装配这件事。SpringBoot的自动装配原理，简单说就是Spring Boot在启动时会扫描META-INF/spring.factories（SpringBoot 2.7之前）或META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（2.7及之后）文件里配置的自动配置类，然后通过@ConditionalOnClass、@ConditionalOnMissingBean这一系列条件注解，来决定哪些配置类生效。你可以把它想象成一个餐厅的后厨：菜单上写了很多菜，但你点的那几个菜，厨师才真正开火做。同理，SpringBoot把很多常用配置写成了一套自动配置类，但只有你引入了对应的starter、并且满足条件时，这些配置才会真正加载。

这意味着什么？意味着你引入spring-boot-starter-web，不需要自己去配置DispatcherServlet，不需要去配置内嵌的Tomcat，SpringBoot通过ServletWebServerFactoryAutoConfiguration自动判断当前环境，然后创建一个内嵌容器。这对毕业设计来说节省了大量配置时间，能把精力放在业务代码上。

那为什么选MyBatis-Plus而不是JPA或者纯MyBatis？我的理由是：JPA的自动建表和Hibernate的ORM对初学者来说太像“黑盒”，出了问题不知道SQL到底长什么样；纯MyBatis又要把每个SQL都写在XML里，做联表查询时写起来很累。MyBatis-Plus正好卡在中间，单表CRUD可以直接用BaseMapper，复杂查询可以写Wrapper，实在需要多表联查时也能写自定义SQL。更重要的是，MyBatis-Plus自带分页插件、逻辑删除、乐观锁插件，这些功能在答辩时说出去很加分。

前端选择则推荐Vue + Element-UI，前后端分离开发，用Nginx做反向代理或者在SpringBoot里配CORS解决跨域。为什么前后端分离？因为毕设的重点在SpringBoot后端，前端用Vue可以组件化开发，写起来也快；如果只写模板引擎渲染的后端页面，整个系统的复杂度会集中到后端，页面逻辑和业务逻辑混在一起，后期维护很痛苦。

2. 数据库设计与模块边界

数据库设计是整个项目的地基，地基没打好，后面写代码会到处漏水。我见过太多同学把用户角色字段直接写进用户表，比如role字段存admin或者student，这种做法不是不行，但如果你有多个角色，或者后台希望动态分配权限，就非常被动。

2.1 核心表结构规划

这里给出一个我实际项目中使用的表结构，不用全部照搬，但核心字段建议保留。

这里特别要说一下info_content表的status字段，它是整个资讯模块的状态机核心。我习惯用整数表示法：

• 0：草稿（用户保存但未提交审核）
• 1：待审核（用户已提交，等管理员处理）
• 2：已发布（审核通过，前台可见）
• 3：已驳回（管理员驳回，带有驳回原因）
• 4：已下架（曾经发布过，但管理员后续下架）

这5个状态就构成了一个完整的审核闭环，前台展示的资讯永远只查询status = 2的数据。答辩的时候你可以指着这个字段说：审核功能不是简单的流于表面，而是用状态机保证了内容从生产到可见的完整链路。

2.2 模块边界与接口口径

划分模块有一个很实际的目的：多人协作时不用互相等，自己写的时候也清晰。我一般把后端分为以下几个包：

• controller：只接收参数、调用service、返回Result对象，不做业务逻辑。
• service：业务逻辑层，事务控制在这里。
• mapper：MyBatis-Plus的Mapper接口，数据访问层。
• entity：数据库实体类。
• dto：接收前端参数的传输对象，与entity分离的好处是前端传参变化时不用动实体类。
• vo：返回给前端的数据视图对象，比如资讯详情可能有额外的点赞数、评论数、当前用户是否已点赞这些字段。
• config：各类配置类，比如跨域配置、MyBatis-Plus分页插件配置。
• common：统一响应类、异常处理类、常量类。
• security：JWT工具类、拦截器、注解等。
• aspect：操作日志切面。

这个分包方式不是唯一的，但对SpringBoot毕设来说是够用且清晰的。评审老师问“你的项目结构怎么设计的”，你能答出分层思想和每一层的职责边界，比埋头写代码的效果好得多。

接口口径我用Result<T>统一封装。这个实体类长这样：

public class Result<T> implements Serializable { private Integer code; 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:"success"}、有的返回{status:1}。这种统一性在实际联调时非常关键，不然前端同学会想打人。

3. 核心功能实现细节走读

这一部分我挑几个真正花时间的核心功能来讲，不是把所有代码贴一遍，而是把关键设计讲透。

3.1 登录认证：JWT + 拦截器，简单可控

登录认证是几乎所有系统的入口。我这里推荐使用JWT（JSON Web Token） + 拦截器的方案，而不是引入Spring Security或Sa-Token这类重型框架。原因很简单：这个项目需要的权限控制其实只有两级——游客能做什么、登录用户能做什么、管理员能做什么。用轻量级的自定义拦截器完全可以实现，而且你能把原理讲得明明白白；Spring Security本身学习曲线陡，一个毕业设计做下来可能一半时间在调Security配置。

JWT的本质是签发一个加密的令牌，服务端不保存会话状态。令牌结构是Header.Payload.Signature三部分，Header存放加密算法，Payload存放用户id、用户名、过期时间等声明，Signature用密钥对Header和Payload做签名。每次请求时前端把它放在请求头Authorization: Bearer <token>里，后端拦截器校验签名，通过后从Payload中取出用户信息。

关键代码如下：

public class JwtUtils { private static final String SECRET = "your-secret-key"; private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000; // 24小时 public static String createToken(Long userId, String username) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("username", username) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

拦截器里要做的事是：放行登录接口和公开接口，其他接口校验token。校验通过后，把userId和username存到ThreadLocal里，这样在controller里随时可以取出当前用户。

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { Claims claims = JwtUtils.parseToken(token); UserContext.setUserId(Long.valueOf(claims.getSubject())); UserContext.setUsername((String) claims.get("username")); return true; } catch (Exception e) { throw new BusinessException(401, "登录状态已过期，请重新登录"); } } throw new BusinessException(401, "未登录，无法访问"); } }

还有一个容易忽略的点：密码为什么用BCrypt而不是MD5？因为MD5加不加盐都可以用彩虹表反查，BCrypt是自适应哈希算法，内部自动加盐并且计算速度可以被调整，同样的密码每次生成的哈希值都不同，安全性高出一个数量级。Spring Security的BCryptPasswordEncoder可以单独抽出来用，不需要引入整个Security框架。

3.2 资讯审核状态机实现

这是整个业务模块里综合价值最高的一块。它涉及状态流转、权限校验和消息提醒三个维度。

用户在发布资讯时，如果选择“保存草稿”，资讯进入status=0；如果选择“提交审核”，资讯进入status=1。管理员在后台看到的是status=1的资讯列表，点击审核通过，状态置为2，前台立刻可以看见；点击驳回，需要填写驳回原因，状态置为3。驳回后的资讯，只有发布者本人能在“我发布的”列表中看到，并可以修改后重新提交，重新提交后状态又从3转回1。

这个状态流的核心代码就是一个更新表达式：

@Override @Transactional(rollbackFor = Exception.class) public void auditInfo(Long infoId, Integer auditStatus, String rejectReason, Long adminUserId) { InfoContent info = infoContentMapper.selectById(infoId); if (info == null) { throw new BusinessException("资讯不存在"); } if (!info.getStatus().equals(1)) { throw new BusinessException("该资讯不在待审核状态，无法审核"); } InfoContent update = new InfoContent(); update.setId(infoId); update.setStatus(auditStatus); update.setAuditUserId(adminUserId); update.setAuditTime(new Date()); if (StringUtils.hasText(rejectReason)) { update.setRejectReason(rejectReason); } infoContentMapper.updateById(update); }

用@Transactional保证整个审核操作原子性，这个注解的语义是：方法内所有数据库操作要么全部提交，要么全部回滚。在审核场景里，处理审核状态和记录操作日志必须放在同一事务里，不然会出现状态更新了但日志没记录、或者反过来，排查问题的时候会非常痛苦。

3.3 评论点赞的缓存与数据库一致性

点赞是典型的读多写少场景。如果每次用户点个赞都直接操作数据库，数据库压力会比较大。我的方案是：点赞用Redis的Set结构，key为info:like:{infoId}，Set里存的是userId。点赞就是SADD，取消点赞就是SREM，判断是否已点赞就是SISMEMBER，获取点赞总数就是SCARD。这三个操作都是O(1)时间复杂度，性能极好。

但这里有一个经典问题：如果你想在资讯列表中展示点赞数，总不能每次都去Redis里查一遍。我的做法是：资讯表冗余一个like_count字段，点赞或取消点赞时先操作Redis，再通过异步方式更新数据库里的like_count。为了保证最终一致性，点赞接口执行完Redis操作后，会把一条更新事件放到一个内存队列中，后台有一个定时任务每10秒批量把队列里的点赞数更新到数据库。

这里要提醒一下，不用一上来就引入消息队列。Kafka、RocketMQ确实是热点，但在这个项目里用它们属于“杀鸡用牛刀”。你可以在部署扩展方案里提到“如果需要处理海量点赞请求，可以引入Kafka或者RocketMQ来削峰”，但核心逻辑用Redis定时刷新已经足够了。

评论的缓存策略则不太一样。评论需要分页展示，而且有楼中楼结构，不适合直接塞进简单的缓存。我的方案是：评论写入时直接落库，读取时走Redis缓存。缓存数据的格式是一个JSON字符串，包含评论列表和总数。当有人发表新评论时，删除对应资讯的评论缓存，下一次读取时重新从数据库加载并回填缓存。这一招叫Cache Aside Pattern，写操作更新数据库后删除缓存，读操作先读缓存、缓存未命中再查数据库并写缓存。它的好处是逻辑简单，不容易出现双写不一致的问题。

3.4 定时任务：定时归档与数据统计

校园资讯平台有一个容易忽略但很有亮点的功能：定时统计。比如每天凌晨统计每个分类的资讯数量、每天新增注册用户数、最近7天互动数据。这些数据可以直接给后台的“数据大盘”用。

SpringBoot里用@Scheduled注解做定时任务非常方便。

@Component public class DataStatisticsTask { @Resource private StatisticsService statisticsService; @Scheduled(cron = "0 0 1 * * ?") public void dailyStatistics() { statisticsService.generateDailyStatistics(); } }

那cron表达式的格式怎么记？一共6位，依次是秒、分、时、日、月、周。0 0 1 * * ?表示每天凌晨1点执行。*代表任意值，?只能用在日和周两个字段上，表示不指定具体值，因为日和周同时指定会有冲突。这里有个小坑：如果你写0 0 1 * * *直接套用别人给的模板，有可能在周字段上出错。

定时任务做统计时也要注意幂等性。万一服务器在凌晨1点没有正常运行，任务被漏掉了，怎么办？我的做法是：统计表里以statistics_date作为唯一索引，插入时如果发现当天数据已存在，就改为更新而不是重新插入。这样即使同一个任务被重复触发，也不会产生脏数据。

3.5 文件上传与访问路径规划

校园资讯的封面图、用户头像这些资源，我建议先用本地存储解决。方案是：配置文件里设置一个file.upload-path，比如/data/upload/， Controller接收MultipartFile后，用UUID生成文件名，避免中文名和重名问题，然后存储到指定目录。访问时通过SpringBoot的静态资源映射映射到虚拟路径。

上传时一定要做的三件事：

• 限制文件大小。在application.yml里配置spring.servlet.multipart.max-file-size: 5MB、max-request-size: 10MB，防止有人传超大文件把磁盘撑爆。
• 校验文件类型。不是看扩展名，而是看文件的Content-Type和Magic Number。比如图片文件的前几个字节是固定的JPEG头FF D8 FF或者PNG头89 50 4E 47，你可以用Apache Tika这个库来做文件类型探测。
• 生成缩略图。如果资讯列表要显示封面，原图太大加载会很慢。用thumbnailator这个库，上传图片后自动生成一个宽400像素的压缩缩略图，列表展示缩略图，详情页展示原图。

有同学喜欢直接把图片以Base64字符串存进数据库，这个真的不建议。一张几MB的图片转成Base64后体积会膨胀约33%，数据库很快就会被拖垮。文件就放文件系统，数据库只存路径。

3.6 MyBatis-Plus的实用技巧：自动填充与逻辑删除

项目里很多表都有create_time、update_time字段，每个地方手动设置太繁琐。MyBatis-Plus提供了MetaObjectHandler接口，实现了插入和更新的自动填充。

@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", Date.class, new Date()); this.strictInsertFill(metaObject, "updateTime", Date.class, new Date()); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", Date.class, new Date()); } }

实体类上对应的字段要加@TableField(fill = FieldFill.INSERT)或@TableField(fill = FieldFill.INSERT_UPDATE)注解。这样所有表的创建时间和更新时间都不用手动维护，而且逻辑统一。

关于逻辑删除，我觉得在这个项目里是可选的。如果你希望用户删除资讯后还能在后台看到记录并恢复，那就可以用MyBatis-Plus的@TableLogic注解，在status之外再加一个deleted字段，查询时自动过滤。但如果你根本不需要恢复功能，直接物理删除更简单，别为了炫技给每张表都塞个逻辑删除字段，徒增复杂度。

再说一个方案选择：SpringBoot + MyBatis 在表不存在时自动建表，这个热词不少人搜过。MyBatis-Plus本身不提供自动建表的能力，通常配合mybatis-plus-ddl这种三方工具来实现，或者用Spring的schema.sql+spring.sql.init.mode=always实现。但我的建议是，数据库表结构用SQL脚本手动维护，然后用flyway或liquibase做版本管理，这比自动建表可靠得多。自动建表适合单元测试或者快速演示环境，正式项目还是需要明确的表结构变更记录。

4. 做毕设最容易翻车的地方，提前帮你排掉

这部分我按照自己带项目时学生最常报错的问题来整理，每一个都是真实踩过的坑。

4.1 IDEA创建SpringBoot项目超时

用IDEA自带的Spring Initializr创建项目时，默认连的是Spring官网的接口，国内网络环境下经常超时。解决办法是在创建时把Server URL改到国内镜像，比如阿里的https://start.aliyun.com。如果镜像也不稳定，就直接去https://start.spring.io页面把压缩包下载下来，解压后用IDEA打开。

创建项目时SpringBoot版本选择也有讲究。尽量选2.7.x这个系列，原因有两个：一是2.7.x相关的教程和依赖版本最丰富，遇到问题基本上一搜就有答案；二是部分公司用的插件和中间件对3.x版本的兼容还不完善，比如一些老的MyBatis-Plus版本在SpringBoot 3.x下会报错。如果你想用JDK 17或者更高的版本，那就选SpringBoot 3.2.x，同时确认配套的依赖版本也升级到位。

4.2 版本太高导致依赖冲突

很多同学一上来就建了个SpringBoot最新版，然后引入自己熟悉的第三方依赖，结果启动时各种ClassNotFoundException、NoSuchMethodError。其实绝大对数这种问题都出在依赖版本不兼容上。

解决思路只有一个：以SpringBoot的BOM（依赖清单）为基准，不要手动去指定其他依赖的版本号。比如你在pom.xml里引入了mybatis-plus-boot-starter，手欠给它加了一个<version>3.4.0</version>，但MyBatis-Plus的starter内部需要匹配它自己对应的SpringBoot版本，就很容易冲突。正确的做法是：用MyBatis-Plus官方文档里说明的、与当前SpringBoot版本匹配的starter版本，其他依赖同理。

4.3 数据库连不上

最常见的报错是Access denied for user 'root'@'localhost'，或者Communications link failure。前者是密码或用户名不对，后者是MySQL服务没启动。还有一个非常隐蔽的坑：MySQL 8.x的连接驱动是com.mysql.cj.jdbc.Driver，不是旧的com.mysql.jdbc.Driver。如果你用旧版本驱动去连MySQL 8，控制台会报一串ClassNotFoundException。

另外URL里一定要带时区参数：jdbc:mysql://localhost:3306/campus_info?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8。不带serverTimezone，Java 8之后的时间类型和MySQL的datetime类型做映射时必报错。

4.4 前后端联调跨域问题

前后端分离开发时，前端跑在localhost:8080，后端跑在localhost:9090，前端请求后端就会被浏览器拦截，这就是跨域。

解决办法是后端配置一个CORS跨域过滤器，代码如下：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

需要注意的是，addAllowedOriginPattern("*")和setAllowCredentials(true)要配合使用。如果你用addAllowedOrigin("*")，同时又把allowCredentials设为true，在某些SpringBoot版本下会直接报错，因为是“不能使用通配符同时允许跨域和携带Cookie凭证”。

4.5 打包部署与服务器运行

项目写完后，在项目根目录执行mvn clean package -DskipTests，target目录下会生成一个jar包。把它上传到服务器，执行java -jar campus-info-platform.jar --spring.profiles.active=prod就能运行。要注意的是，如果服务器上已经有其他服务占用了8080端口，就需要通过--server.port=9090来指定新的端口。

生产环境我建议简单用Docker部署。写一个Dockerfile：

FROM openjdk:8-jre WORKDIR /app COPY target/campus-info-platform.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

构建镜像的时候有一个坑：Dockerfile里先把jar包COPY进去，每次代码更新都得重新构建整个镜像。更快的做法是分阶段构建，或者把jar包挂载到宿主机目录而不是打进镜像里。毕设阶段不追求极致的CI/CD，但你应该能说清楚“镜像和容器是什么关系”、“为什么jar包里的配置要外置”。

外置配置是指生产环境的application.yml不要打进jar包，而是在同目录下放一份application-prod.yml，通过--spring.config.additional-location指定外部配置文件路径。这样数据库密码、上传路径等环境相关配置可以独立修改，不用每次改个密码都重新打包。

5. 项目验收与可扩展方向

项目做完不是终点，能顺利通过验收才是目标。

5.1 答辩前建议准备的核心点

我参加过很多次答辩，评委一眼能看穿学生是不是真的自己做了。以下几个问题如果你能从容回答，效果会好很多：

SpringBoot的自动装配原理是什么？你可以从@SpringBootApplication、@EnableAutoConfiguration、条件注解、META-INF下的自动配置导入文件这几个点展开。

为什么用MyBatis-Plus而不直接写SQL？回答要点是：单表CRUD用内置方法减少重复代码，复杂查询用Wrapper构造条件避免拼接SQL，分页插件自动拦截SQL生成limit语句。

JWT和Session的区别是什么？Session是服务端存储会话，JWT是客户端持有令牌、服务端无状态校验，适合前后端分离和多端共享登录态。

你项目里的权限是怎么控制的？基于RBAC模型，用户关联角色，角色关联菜单或接口权限，实现方式上我用了拦截器做认证、用注解做接口级权限校验。

资讯审核状态是怎么设计的？这里就把我之前的状态机设计讲出来，从草稿到发布中间经历几个状态、每个状态谁可以操作、为什么这样设计。

为了准备这些，建议把你项目中用到的每个注解都搞清楚它的作用，比如@Transactional、@Async、@Cacheable、@Scheduled。不要求把源码背下来，但至少能说清楚“我为什么用这个注解，它帮我们解决了什么问题，如果不用会怎么样”。

5.2 这套平台还能往哪些方向扩展

如果你时间充裕，想让项目更有竞争力，有几个扩展方向可以选：

• 引入Redis哨兵模式替代单机Redis，提升高可用性。你可以在答辩时说清楚哨兵的作用：监控主节点状态、自动故障切换、通知客户端新的主节点地址。这不难，主要是配置文件改动加一个哨兵配置文件。
• 引入消息队列提高点赞统计的异步处理能力。这个场景其实非常适合Kafka或者RocketMQ：把每个点赞事件发到消息队列，消费者异步更新数据库。这样用户点完赞立刻返回，数据最终一致。前提是你要能把“为什么用消息队列而不是线程池”讲清楚。
• 接入全文搜索引擎，比如Elasticsearch。校园资讯量大后，数据库的like查询性能会下降，接入ES后可以实现毫秒级的站内全文搜索。
• 用WebSocket实现站内信和实时的评论通知。当有人评论你的资讯时，前端能实时收到提醒。这个功能很直观，演示效果好，评委也爱看。

但这里我要提个醒：扩展功能不是越多越好。如果你本身对Redis都不熟，就别为了加功能硬塞一个Redis哨兵，答辩时被问到细节反而露馅。选择一个你真正能讲透、能演示的功能加进去，比堆三个半吊子的功能强得多。

我个人在实际带项目的过程中最深的体会是，很多同学并不是不会写代码，而是不知道一个完整项目应该怎么组织、怎么衔接、怎么呈现。校园资讯交流平台这个题目之所以经典，就是因为它把内容管理、用户互动、后台统计这些非常标准的业务揉在了一起，做完一遍以后，你对SpringBoot生态的熟悉程度会提升一大截。

最后再分享一个小技巧：写项目日志，不管是开发日志还是操作日志，都认真写。SpringBoot里用Slf4j + Logback，每个关键操作都打一条日志，比如“用户ID:123 审核通过资讯ID:456”。这不仅帮你调试时快速定位问题，也是答辩时展示工程化能力的一个细节。评审老师看到日志规范，往往就会默认你是一个有真实开发习惯的人，而不是照着教程敲出来的。

如果你在落地项目的过程中碰到了具体的报错，优先去看控制台的异常堆栈第一行，它已经告诉了你80%的问题所在。SpringBoot的报错信息绝大多数是可读的，你只要不害怕看它，就已经赢过了大半的人。