背景痛点为什么你的毕设平台总感觉“差点意思”很多同学在做“信息发布平台”这类毕业设计时往往只关注功能实现忽略了背后的架构和性能问题。结果就是一个看似功能齐全的平台一旦面临稍微复杂的场景比如多用户同时发布、内容需要审核、或者数据量稍大就变得卡顿、不稳定甚至直接崩溃。回想我当初做毕设时也踩过不少坑。最常见的几个问题包括架构简陋扩展性差很多项目采用单体架构前后端代码混在一起修改一个功能可能牵一发而动全身。数据库直接裸奔没有任何缓存每次查询都去读库页面加载慢得像蜗牛。并发能力弱发布信息时如果多个用户同时点击提交后台处理逻辑如果没做好并发控制很容易导致数据错乱比如同一条信息被插入两次。安全性堪忧用户输入的内容直接拼接 SQL 语句或者直接渲染到页面上很容易遭遇 SQL 注入和 XSS 攻击。用户认证可能就是简单的 Session在前后端分离的场景下不好管理。可维护性低代码结构混乱没有清晰的分层业务逻辑、数据访问、控制逻辑搅在一起。想加个新功能或者找 Bug 都非常困难。技术选型为什么是它们为了解决上述痛点我选择了下面这套技术栈。这里也简单说说为什么选它们以及备选方案是什么。后端Spring Boot为什么选它Spring Boot 是 Java 领域构建微服务和独立应用的事实标准。它“约定大于配置”的理念让我们能快速搭建项目无需在繁琐的 XML 配置上浪费时间。内嵌 Tomcat一键启动非常适合快速开发和部署毕设项目。它强大的生态Spring MVC, Spring Data JPA, Spring Security能覆盖我们绝大部分需求。替代方案Node.js Express/Koa、Python Django/Flask、Go Gin。选择 Spring Boot 主要是考虑到 Java 在高校教学中的普及度资料多社区活跃遇到问题容易找到解决方案。前端Vue 3为什么选它Vue 3 的 Composition API 让逻辑组织更灵活响应式系统也做了重大升级性能更好。相比于 ReactVue 的学习曲线更平缓模板语法对新手更友好能让我们把更多精力放在业务逻辑而非框架本身上。配合 Vite 构建工具开发体验极佳。替代方案React、Angular。选择 Vue 3 是因为其生态丰富Element Plus、Vant 等 UI 库且更适合快速构建管理后台类应用。持久层MySQL为什么选它关系型数据库事务支持完善ACID 特性保证数据一致性。对于信息发布平台这种结构化数据用户、文章、分类、评论存储非常合适。开源、免费、社区强大是经久不衰的选择。替代方案PostgreSQL、SQLite。PostgreSQL 功能更强大但 MySQL 的简单易用和广泛认知度在毕设场景下更有优势。缓存Redis为什么选它高性能的内存数据存储。我们用它主要做两件事一是缓存热点数据如首页文章列表、热门分类极大减轻数据库压力二是存储用户登录的 Token实现快速鉴权。它的数据结构丰富String, Hash, Set 等还能用来做分布式锁、消息队列简单场景。替代方案Memcached。Redis 功能更全面数据结构更多样因此成为首选。消息队列RabbitMQ为什么选它用于系统解耦和异步处理。例如用户发布信息后主流程只负责落库和发送一条消息到队列。然后由独立的消费者异步去执行耗时操作比如内容敏感词过滤、生成文章摘要、更新相关统计信息、发送通知邮件等。这样用户的发布操作会得到即时响应体验更好。替代方案Kafka、RocketMQ。RabbitMQ 协议成熟AMQP管理界面友好对于毕设级别的吞吐量完全足够且易于理解和上手。核心实现细节把“好用”落到实处1. 信息发布接口的幂等性设计“幂等性”是指同一个操作执行一次或多次产生的结果是一样的。对于发布接口我们必须防止用户因网络延迟、重复点击等原因导致同一篇文章被提交多次。实现思路客户端在请求时生成一个唯一的“请求令牌”requestId通常可以用 UUID。服务端借助 Redis 的SETNXSET if Not eXists命令来实现。核心代码Spring Boot ControllerRestController RequestMapping(/api/article) public class ArticleController { Autowired private RedisTemplateString, String redisTemplate; Autowired private ArticleService articleService; PostMapping(/publish) public Result publishArticle(RequestBody ArticleDTO articleDTO, RequestHeader(X-Request-Id) String requestId) { // 1. 幂等性校验 String redisKey req_id: requestId; // setIfAbsent 就是 SETNX成功返回true失败返回false Boolean isFirstRequest redisTemplate.opsForValue().setIfAbsent(redisKey, 1, 5, TimeUnit.MINUTES); if (Boolean.FALSE.equals(isFirstRequest)) { return Result.error(请勿重复提交); } try { // 2. 执行业务逻辑创建文章 Long articleId articleService.createArticle(articleDTO); return Result.success(发布成功, articleId); } catch (Exception e) { // 3. 业务处理失败可以考虑删除这个key允许用户重试根据业务决定 // redisTemplate.delete(redisKey); throw e; // 或返回错误信息 } // 4. 如果成功key会在5分钟后自动过期。也可以选择在成功后立即删除。 } }要点X-Request-Id由前端在每次请求时生成并放在请求头中。Redis Key 设置一个合理的过期时间如5分钟防止无效数据堆积。根据业务需求决定在业务失败后是否删除 Key 以允许重试。2. 敏感词过滤机制为了保证平台内容的合规性需要对用户发布的信息进行敏感词过滤。实现思路使用前缀树Trie 树算法构建敏感词库实现高效的多模式匹配。我们将过滤逻辑放在消息队列的消费者中实现异步处理不影响主发布流程。核心代码敏感词工具类与消息消费者首先定义一个敏感词过滤器简化版Component public class SensitiveWordFilter { private TrieNode root new TrieNode(); // 初始化敏感词库 PostConstruct public void init() { // 这里可以从数据库或文件加载敏感词 ListString sensitiveWords Arrays.asList(敏感词1, 不良信息, 测试); for (String word : sensitiveWords) { this.addWord(word); } } private void addWord(String word) { TrieNode node root; for (char c : word.toCharArray()) { node node.getChildren().computeIfAbsent(c, k - new TrieNode()); } node.setEnd(true); } // 过滤文本将敏感词替换为* public String filter(String text) { if (StringUtils.isBlank(text)) return text; char[] chars text.toCharArray(); StringBuilder result new StringBuilder(); TrieNode tempNode; int start 0, end 0; while (start chars.length) { tempNode root; end start; while (end chars.length tempNode.getChildren().containsKey(chars[end])) { tempNode tempNode.getChildren().get(chars[end]); end; if (tempNode.isEnd()) { // 发现敏感词将[start, end)区间替换为* for (int i start; i end; i) { chars[i] *; } start end - 1; // 调整start继续循环 break; } } start; } return new String(chars); } // 内部类Trie节点 static class TrieNode { private MapCharacter, TrieNode children new HashMap(); private boolean isEnd; // getter/setter 省略 } }然后在 RabbitMQ 消费者中调用过滤逻辑Component Slf4j public class ArticlePublishConsumer { Autowired private SensitiveWordFilter wordFilter; Autowired private ArticleService articleService; RabbitListener(queues article.publish.queue) public void handlePublishMessage(ArticleMessage message) { log.info(收到文章发布消息开始处理: {}, message.getArticleId()); try { // 1. 根据文章ID从数据库获取原始内容 Article article articleService.getById(message.getArticleId()); if (article null) { log.error(文章不存在: {}, message.getArticleId()); return; } // 2. 过滤标题和内容 String filteredTitle wordFilter.filter(article.getTitle()); String filteredContent wordFilter.filter(article.getContent()); // 3. 更新过滤后的内容可以设置一个filtered_content字段或直接更新原字段 article.setTitle(filteredTitle); article.setContent(filteredContent); article.setStatus(已过滤); // 更新状态 // 4. 保存回数据库 articleService.updateById(article); log.info(文章 {} 敏感词过滤完成, message.getArticleId()); } catch (Exception e) { log.error(处理文章发布消息失败: {}, message.getArticleId(), e); // 这里可以加入重试逻辑或死信队列处理 } } }3. 前后端分离下的 Token 鉴权流程JWT前后端分离后传统的 Session 方式不再方便。我们采用 JWT (JSON Web Token) 进行无状态鉴权。流程用户登录服务端校验用户名密码。校验通过后生成一个 JWT Token包含用户ID、角色等信息签名后返回给前端。前端将 Token 存储在 localStorage 或 Cookie 中并在后续请求的Authorization请求头中携带如Bearer token。服务端通过一个拦截器Filter/Interceptor对所有需要权限的接口进行拦截验证 Token 的签名和有效期并解析出用户信息存入请求上下文。控制器中可以直接获取当前登录用户信息。核心代码JWT 工具类与拦截器Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expiration}) private Long expiration; // 生成Token public String generateToken(Long userId, String username) { Date now new Date(); Date expiryDate new Date(now.getTime() expiration); return Jwts.builder() .setSubject(userId.toString()) .claim(username, username) .setIssuedAt(now) .setExpiration(expiryDate) .signWith(SignatureAlgorithm.HS512, secret) .compact(); } // 解析Token public Claims getClaimsFromToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); } // 验证Token public boolean validateToken(String token) { try { getClaimsFromToken(token); return true; } catch (Exception e) { return false; } } }Component public class JwtAuthenticationInterceptor implements HandlerInterceptor { Autowired private JwtUtil jwtUtil; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 从请求头中获取token String authHeader request.getHeader(Authorization); if (authHeader ! null authHeader.startsWith(Bearer )) { String token authHeader.substring(7); if (jwtUtil.validateToken(token)) { Claims claims jwtUtil.getClaimsFromToken(token); Long userId Long.valueOf(claims.getSubject()); String username (String) claims.get(username); // 将用户信息存入请求属性方便后续使用 request.setAttribute(currentUserId, userId); request.setAttribute(currentUsername, username); return true; } } // token无效或缺失返回401未授权 response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\: 401, \msg\: \未授权或Token已过期\}); return false; } }记得在 Spring MVC 配置中注册这个拦截器并配置需要拦截的路径。性能与安全考量性能压测使用 JMeter 或 Apache Bench 对核心接口如首页文章列表查询、文章发布进行压测。首页列表接口在引入 Redis 缓存文章列表后缓存时间60秒QPS每秒查询率从直接查库的 ~50 提升到了 ~1200响应时间 P99 从 200ms 降低到 10ms 以下。文章发布接口得益于 RabbitMQ 异步处理接口本身落库发消息的响应时间稳定在 50ms 以内用户体验流畅。真正的耗时操作过滤、通知由消费者后台承担。安全防护SQL 注入坚持使用 MyBatis-Plus 等框架的预编译参数绑定或者使用 JPA 的 Criteria API绝对不要手动拼接 SQL 字符串。XSS 攻击后端在将内容存储到数据库或返回给前端前使用库如org.jsoup.Jsoup进行 HTML 标签过滤和转义。或者在模板引擎如 Thymeleaf中默认开启转义。前端Vue使用{{ }}插值会自动转义 HTML。如果确实需要渲染富文本使用v-html指令时要确保内容来源可信已经过后端过滤。CSRF 攻击由于采用无状态的 JWT 且 API 为 RESTful 风格受 CSRF 攻击的风险较低。但对于仍有表单提交且使用 Cookie 的场景应考虑使用 CSRF Token。接口防刷对登录、注册、短信发送等接口使用 Redis 记录 IP 或用户频率例如limiter:login:127.0.0.1设置过期时间达到阈值则拒绝请求。生产环境避坑指南环境差异本地用localhost生产环境用域名。所有配置数据库地址、Redis地址、文件上传路径必须使用配置文件如application-prod.yml管理通过spring.profiles.activeprod激活。切忌在代码中写死。静态资源缓存前端 Vue 项目打包后文件名会带哈希值如app.abc123.js。部署后需要配置 Nginx 等 Web 服务器对这些带哈希的文件设置长期缓存如一年。同时要确保index.html文件不被缓存或缓存时间极短以保证用户总能获取到最新的页面入口。数据库连接池Spring Boot 默认使用 HikariCP性能很好。但在application.yml中需要根据实际压力调整配置特别是spring: datasource: hikari: maximum-pool-size: 20 # 根据数据库性能和并发量调整不是越大越好 connection-timeout: 30000 # 连接超时时间 idle-timeout: 600000 # 空闲连接存活时间 max-lifetime: 1800000 # 连接最大生命周期日志管理生产环境务必把日志级别调到INFO或WARN避免DEBUG日志刷屏。使用Logback或Log4j2配置按天滚动日志文件并定期清理旧日志。消息队列可靠性消息持久化确保队列和消息本身都设置为持久化防止服务器重启导致消息丢失。消费者确认Ack手动确认消息只有在业务处理成功后才basicAck失败则basicNack并让消息重回队列或进入死信队列便于排查问题。设置死信队列DLX处理失败多次的消息最终进入死信队列可以人工干预或进行报警。总结与展望通过这套架构和技术实践我们构建的信息发布平台毕设项目不仅满足了基本的功能需求更在扩展性、并发性、安全性和可维护性上达到了一个较高的水准。从需求分析、技术选型、模块设计到编码实现、测试部署这整个过程本身就是一个极佳的软件工程实践。这个项目还有很多可以深化和扩展的方向审核工作流目前的敏感词过滤是自动的。可以引入一个工作流引擎如 Flowable、Activiti实现“用户提交 - 自动过滤 - 转人工审核 - 审核通过/驳回”的完整流程并给审核人员一个管理后台。接入 CDN 加速如果平台有大量的图片或视频资源可以考虑将文件存储到对象存储如阿里云 OSS、腾讯云 COS并接入 CDN让用户从最近的节点获取资源极大提升加载速度。全文搜索当文章量很大时数据库的LIKE查询效率低下。可以集成 Elasticsearch实现标题和内容的全文检索、高亮显示、相关度排序等高级功能。微服务化改造如果想把项目做得更深入可以尝试将用户服务、内容服务、审核服务拆分成独立的微服务使用 Spring Cloud 生态Nacos, Gateway, OpenFeign进行治理体验更复杂的分布式系统架构。希望这篇笔记能为你完成一个出色的信息发布平台毕设提供清晰的路径和实用的代码参考。动手去实现吧过程中遇到问题、解决问题的经历才是最宝贵的收获。