Spring Boot新闻推荐系统设计与实现：从算法到论文完整指南

简介：本资源是一套完整的基于Spring Boot与Vue的新闻推荐系统毕业设计实现方案，面向计算机专业本科生及Java全栈初学者，解决新闻内容个性化分发与用户兴趣建模的实际问题，适用于课程设计、毕设开发与项目实训场景。压缩包共748个文件，涵盖90个Java后端核心类、38个Vue前端组件、153个JavaScript逻辑脚本、162个SVG图标资源、44个CSS样式文件及12个XML配置文件，完整呈现B/S架构下前后端分离开发范式；包体大小为15.15MB，结构清晰，含SQL建表语句、管理员与用户双角色模块、排行榜与收藏功能等典型业务实现。目前已有34人学习下载，资源附带详尽论文文档（含可行性分析、数据库设计、系统测试用例及结果分析），代码可直接导入IDE运行，配套bat启动脚本与备份文件便于环境快速部署与版本回溯。 读研时帮好几个学弟学妹看过这类Spring Boot新闻推荐系统，自己也完整从零搭过一版，这里把整个“设计+实现+论文”的链路一次性说清楚。如果你手上正好有这份.7z源码，或者正准备开题写一个类似的系统，这篇博文能帮你少走很多弯路。

先说这个项目到底是什么：基于Spring Boot的新闻推荐系统，核心就是“用户进来看新闻，系统根据他看过的内容猜他接下来想读什么”。用到的技术栈主流、业务场景清晰，既能展示工程能力，又能讲清楚推荐算法的来龙去脉，所以一直是毕设和课设里的热门选题。配套的源码加论文，基本覆盖了从开题、编码、测试到答辩的全流程。

我这边会从选题逻辑、算法选型、数据库设计、关键代码实现、踩坑复盘、论文写作六块展开。全文偏实战，代码片段可以直接用，表结构可以直接抄，论文目录也可以当模板。

1. 这个题目为什么值得做：从选题逻辑到真实需求

1.1 一个老生常谈但确实好用的毕设选题

新闻推荐系统在毕设圈常青是有原因的。第一，业务模型好理解，不用说一堆复杂概念，用户、新闻、分类、浏览记录、推荐列表，这些都是日常看得见的东西，评审老师一听就懂，不需要花大力气解释背景。第二，技术栈主流，Spring Boot加MyBatis-Plus加Redis加MySQL这套组合本身就是企业里最常见的配置，写进简历不虚。第三，推荐算法有发挥空间，你可以只做到“根据分类推荐”，也可以往上做成“基于内容的相似度推荐”甚至“协同过滤”，深度可控，根据自己的能力调。

这个项目最适合两类人：一类是Java基础一般、需要一份完整可运行的代码来支撑毕业设计的学生；另一类是已经能写CRUD、想在项目里加入“算法味”的初级开发者。前者可以直接把源码跑起来改一改，后者更关心推荐部分怎么落地，这篇博文对两条路都有参考价值。

一上来会看到源码+论文+数据库脚本的压缩包结构，常见的是：

news-recommendation-system/ |-- backend/ # Spring Boot后端 | |-- src/main/java | |-- src/main/resources | |-- pom.xml |-- database/ | |-- news_db.sql # 建库建表脚本 |-- thesis/ | |-- 论文.docx或.pdf |-- README.md

先把整体结构摸清楚，再动手改，这是拿到源码后的第一件事，千万别一上来就启动。

1.2 推荐系统在新闻场景下的独特之处

新闻推荐和个人喜好类推荐不太一样，最突出的特点是时效性。一部电影半年前看的今天还能推荐，但一条新闻三天前的资讯基本就没人看了，所以新闻推荐对“新内容”的曝光要求比电商推荐高得多。这直接决定了推荐策略不能简单照搬“根据历史行为推荐相似内容”那套逻辑，而是要做“兴趣匹配+时效加权”。在论文里把这个点讲透，技术含量立刻就上去了。

第二个特点是用户行为稀疏。大部分新闻App用户是游客，或者只登录不看，真正产生点击、点赞、评论行为的记录远少于阅读量。如果一上来就做协同过滤，用户-物品矩阵会非常稀疏，推荐效果稀碎。所以很多毕设系统会优先用“基于内容的推荐”作为主力算法，再用热度榜做冷启动兜底，这个组合在数据量不足时是性价比最高的方案。

第三个特点是对“多样性”有要求。新闻用户很容易腻，如果推荐列表连续十条都是同一个分类，体验会非常差。所以在设计推荐结果时，要刻意加入“打散”逻辑，比如同一分类最多出现三条，剩下的位置穿插其他相关分类。这个细节很多毕设系统不做，但做了之后无论是演示效果还是答辩说辞，都会多一个亮点。

1.3 技术选型：为什么是Spring Boot这一套

Spring Boot在这一点上基本没有对手。对比传统的SSH（Spring+Struts+Hibernate）框架，Spring Boot通过自动配置和起步依赖把这些繁琐的XML配置全部干掉，项目启动一个Application类就能跑起来。对比Spring Cloud微服务那一套，新闻推荐系统这种单体应用根本不需要服务注册、配置中心、网关这些重型组件，硬上微服务只会增加部署和调试成本，答辩被问“你这里为什么要拆服务”时反而容易露怯。

实际项目里的推荐技术栈一般是这样：

版本这里要提醒一句：Spring Boot不建议一上来就上3.x，尤其是如果你拿到的是配套老教程的源码，2.7.x是最稳的选择。3.x里javax包名换成了jakarta，很多老代码直接编译不过，光这一个坑就能卡你一整天。

2. 推荐算法选型：基于内容的推荐在新闻场景的落地方式

2.1 为什么优先考虑“基于内容”而不是协同过滤

做新闻推荐，很多同学第一反应是“我要用协同过滤”，因为这名字听起来高级。但真实场景里，基于用户协同过滤（UserCF）和基于物品协同过滤（ItemCF）在新闻系统里都面临不少麻烦。

用户协同过滤的核心逻辑是“找到和你喜欢类似新闻的用户，把他们看过的推荐给你”。问题在于，要想“找到相似用户”，必须有足够多的共同行为记录，而新闻系统的用户行为矩阵太稀疏了，一个用户可能只浏览过十几条新闻，用户之间的交集小得可怜。物品协同过滤的核心逻辑是“找和你看过的新闻相似的新闻”，这个逻辑本身是可行的，但它的相似度计算依赖用户对物品的评分或行为，对热门物品有强烈的偏向性，新发布的冷门新闻几乎没有机会被推荐。

基于内容的推荐则绕开了这些问题。它不关心用户之间的关系，只关心“用户看过什么”和“新闻内容像不像”。一条新新闻只要内容合适，就能通过关键词匹配被推荐出去，不存在冷启动问题。在数据量有限的毕设环境下，这是最不容易翻车的算法。我在帮人改项目时见过不少硬上协同过滤但效果很差的案例，最后都换成了基于内容的方案。

综合来看，对新闻推荐系统这个场景，主力算法用基于内容推荐，辅助策略用热度排序，是当前实践中最稳妥的方案。如果你非要在论文里体现协同过滤，可以在实验对比一章加一个ItemCF实现做对照，把“为什么效果不如基于内容”作为分析点，反而更显深度。

2.2 基于内容推荐的完整实现链路

基于内容的推荐分为离线部分和在线部分。离线部分负责算相似度，在线部分负责给用户实时产出推荐列表。整个流程可以拆成四步：

第一步是新闻预处理。新闻入库时，对标题和正文做分词，提取关键词。中文分词如果用HanLP，代码大概是这样的：

// 使用HanLP对新闻标题做分词 public static String getTitleKeywords(String title) { List<String> wordList = HanLP.segment(title).stream() .map(term -> term.word) .filter(word -> word.length() > 1) // 过滤单字 .limit(10) .collect(Collectors.toList()); return String.join(",", wordList); }

分词结果会存到新闻表的keyword字段里，这是一个关键的冗余字段，后面算相似度时直接查这个字段，不用每次重新分词。

加权这一步要先想清楚：标题里的关键词比正文里的更重要，标题关键词的词频加权系数可以调到2.0，正文按1.0算；同时要过滤掉“的、了、是、在”这类停用词，否则这些高频噪声会淹没真正的主题词。

第二步是用户画像构建。新闻推荐没有评分，用户画像只能靠行为反馈来更新。常见的做法是为每个用户维护一个标签权重表：

用户: u_001 关键词("AI", 12), 关键词("科技", 9), 关键词("股市", 4)

用户每看一条新闻，就把新闻的关键词累加到用户的标签权重上。看一次加1，点赞加3，收藏加5，这样就能把不同程度的兴趣区分开来。实际实现时，这些权重数据放在Redis里比较合适，key可以设计成user:interest:{userId}，用Hash结构存储，字段是关键词，值是权重。

第三步是相似度计算。这就是基于内容推荐的核心算法。常见的做法是把新闻关键词用TF-IDF或词频向量表示，再用余弦相似度计算新闻与用户画像之间的相似度。公式本身不难，代码实现也不复杂，但考虑到新闻文本通常不长，直接用词频向量也够用。

相似度计算的Java核心逻辑可以这样写：

public double calcSimilarity(Map<String, Integer> userProfile, Map<String, Integer> newsKeywords) { Map<String, Integer> allWords = new HashMap<>(); allWords.putAll(userProfile); allWords.putAll(newsKeywords); List<Integer> v1 = allWords.keySet().stream() .map(word -> userProfile.getOrDefault(word, 0)) .collect(Collectors.toList()); List<Integer> v2 = allWords.keySet().stream() .map(word -> newsKeywords.getOrDefault(word, 0)) .collect(Collectors.toList()); // 计算余弦相似度 double dotProduct = 0; double norm1 = 0; double norm2 = 0; for (int i = 0; i < v1.size(); i++) { dotProduct += v1.get(i) * v2.get(i); norm1 += Math.pow(v1.get(i), 2); norm2 += Math.pow(v2.get(i), 2); } if (norm1 == 0 || norm2 == 0) return 0; return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2)); }

第四步是候选集生成。系统先把用户画像里权重最高的前5个关键词取出来，去新闻表里搜索包含这些关键词的新闻，作为候选集。然后计算用户画像与候选新闻的相似度，按相似度从高到低排序，再做一次分类打散和时效加权，取前20条作为最终的推荐结果。

在这几个步骤里，第四步是最体现系统工程能力的地方。很多失败的推荐系统不是算法不行，而是候选集没有选好。如果候选新闻基本不包含用户画像里的关键词，后面的相似度排序再精准也没有用。所以候选集的召回策略要宽一点，比如一个关键词召回50条，五个关键词就有250条候选，再进排序，效果会好很多。

2.3 冷启动问题的三种兜底策略

冷启动是推荐系统避不开的问题。在新闻推荐里，冷启动分成两种：新用户冷启动和新新闻冷启动。新用户没有浏览记录，画像为空，基于内容的推荐根本算不出相似度；新新闻没有曝光记录，如果只按画像推荐，它很难被推出去。

针对新用户，标准做法是给“热门榜”兜底。把最近24小时点击量最高的新闻按热度排序，生成一个通用推荐列表，新用户进来先看到这个列表。等用户浏览了几条新闻之后，画像逐步建立，再切回个性化推荐。

针对新新闻，可以用“时间衰减加分”来保证曝光。在计算排序分时，给发布时间在24小时内的新闻加一个加权系数。比较简单的做法是：排序分=相似度0.7+新鲜度分0.3，新鲜度分随新闻年龄线性衰减。这样即使用户画像和新新闻匹配度不够高，新新闻也能获得一定的展示机会。

两个策略之外，还有一个纯逻辑层面的“分类兜底”：新用户默认给一些热门大类，比如要闻、科技、体育，每类选几条，凑成10条初始推荐。我在系统里把这个列表做死在配置里，虽然朴素，但演示效果非常稳定。答辩时就说“这是基于频道热度的冷启动策略”，完全站得住。

3. 系统模块设计与数据库建模：能跑通和能答辩是两回事

3.1 功能模块边界要清晰

这个系统的功能模块，我在帮人改的时候最常遇到的问题是“啥都想做，啥都做不深”。新闻推荐系统的核心功能应该收敛在四个模块：用户模块、新闻模块、推荐模块、管理模块。

用户模块就是注册登录，登录态用JWT或者Redis Session都可以。为了省事，我用JWT，一个注解@RequireLogin就能拦截需要登录的接口。新闻模块负责新闻的增删改查和分类浏览，这部分就是标准CRUD，没什么特别。管理模块是给管理员用的，管理员登录后台发布新闻、审核评论、查看统计数据，前端可以做成一个简单的Vue页面，也可以直接用Thymeleaf模板。

推荐模块是整个系统的核心，也是论文里最值得展开的部分。它包含这几个接口：获取用户的个性化推荐列表、获取热门新闻列表、获取相似新闻列表、上报用户行为（浏览/点赞/收藏）。推荐模块的代码质量直接决定了答辩时老师的印象分，务必重点写。

接口设计要前后端分离，用JSON格式交互，统一返回体是R对象：

public class R<T> { private int code; // 200成功, 500失败 private String msg; private T data; }

3.2 数据库表结构设计

数据库是整个系统的心脏，表设计得不好，后面写代码全是坑。我建议一开始就设计八张表，分别是用户表、新闻分类表、新闻表、用户行为表、新闻评论表、用户画像表、推荐结果表、管理员表。

我挑最有讲究的几张说一下。

新闻表核心字段包括id、category_id、title、content、source、keyword、publish_time、click_count、like_count、status、create_time。其中keyword字段是前面说的分词结果，冗余存储，用逗号分隔。来源字段记录新闻的出处，这在新闻推荐里是区分内容质量的重要标签。status字段控制新闻的上下线，0是草稿，1是已发布，2是下线。所有查询都要带上status=1的条件，避免把管理后台的草稿推给用户。

用户行为表是推荐系统的数据基础，字段包括id、user_id、news_id、behavior_type、create_time。behavior_type用数字区分，1浏览，2点赞，3收藏，4评论。每条用户行为都要记录行为类型，因为不同类型的权重不同。这张表是用户画像的数据来源，也是后续做协同过滤训练集的基础，只增不改不删，尽量留着全量数据。

用户画像表是内存画像的落盘版本，字段包括id、user_id、keywords_json、update_time。keywords_json是一个JSON字符串，结构是[{"keyword":"AI","weight":12},{"keyword":"科技","weight":9}]。用JSON是因为关键词数量不固定，关系型数据库不好建模。不过，严格来说，这张表的实时性不如Redis里的那份画像，Redis负责支撑在线推荐，MySQL负责持久化，两个保持一致的方法是每次Redis更新时同步落库。

推荐结果表是性能优化手段，字段包括id、user_id、news_ids_json、strategy、create_time。个性化推荐结果算出来后，存一张表里，用户刷新推荐页时直接查这张表，几毫秒就返回了，不用实时跑相似度计算。这张表也很有说头：如果你在论文里讲“推荐结果离线计算+在线缓存”，这张表就是落地证据。

建表脚本里，最关键的两个索引要加上：新闻表的(category_id, publish_time)复合索引，用户行为表的(user_id, create_time)复合索引。索引能极大缓解按分类查新闻、按用户查行为这两条高频路径的查询压力。很多毕设系统表里压根没有索引，数据量到了几千条就开始卡，答辩演示当场翻车的，多半都是这个问题。

3.3 表之间如何配合推荐系统工作

如果你只是做了用户表和新闻表，那这个系统只能叫新闻管理系统，加一个推荐模块的核心在于“行为数据怎么流转”。大致流程是这样：用户在前端点击一条新闻时，上报行为；后端收到行为后，做三件事：新闻表click_count加1；用户行为表插入一条记录；更新用户在Redis里的画像标签权重。完成这三个动作后，这条点击才会真正进入推荐系统。

画像数据随后参与推荐计算。推荐模块收到请求后，先从Redis查用户画像，如果画像为空，走热门兜底；如果画像不为空，取出高权重关键词，去新闻表做候选集搜索，算相似度，做排序和打散，最终生成推荐列表。推荐结果写入推荐结果表，同时返回给前端。

这个流程里有明显的一热一冷两条链路：热的链路是用户行为上报、Redis画像更新、推荐结果缓存，都是毫秒级响应；冷的链路是定时任务定期重算推荐结果、更新热门榜、清理过期缓存，每天凌晨跑一次就行。在论文里把“热链路和冷链路”这两个概念讲清楚，整体系统设计部分的分数会明显不一样。

4. 项目搭建的关键代码路径：从Spring Boot骨架到推荐引擎

4.1 项目骨架与核心依赖

用IDEA创建一个Spring Boot项目，Group填com.news，Artifact填recommendation，Java版本8或11都说得过去。pom.xml里最核心的依赖是这几个：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.2</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.28</version> </dependency>

配置文件application.yml里，MyBatis-Plus相关配置要注意一点：

mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml global-config: db-config: id-type: auto banner: false

建议把MyBatis-Plus的banner关掉，同时把Spring Boot启动时的banner也换成自己的，答辩演示时终端输出一个自定义的项目名，氛围感拉满。这一点看起来很细节，但很多做演示的同学都栽在这上面——随手改banner不至于出错，错的是用默认的Spring banner显得模板感太强。

4.2 推荐接口的完整实现

推荐列表接口是整个系统最核心的接口，我按照代码路径完整拆一遍。Controller负责接收参数和返回结果，Service负责业务逻辑，Mapper负责数据查询。

Controller层很简单：

@RestController @RequestMapping("/api/recommend") public class RecommendController { @Resource private RecommendService recommendService; @RequireLogin @GetMapping("/list") public R<List<News>> getRecommendList(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size) { Long userId = UserContext.getUserId(); List<News> list = recommendService.recommendNews(userId, page, size); return R.ok(list); } }

Service层是关键，整个推荐主流程都在这里：

@Override public List<News> recommendNews(Long userId, int page, int size) { // 1. 查缓存：推荐结果表有就直接返回 String cacheKey = "recommend:user:" + userId; List<News> cached = getFromCache(cacheKey); if (cached != null) { return PageUtil.pageList(cached, page, size); } // 2. 从Redis查用户画像 Map<String, Integer> profile = getUserProfile(userId); // 3. 画像为空 => 热门兜底 if (profile == null || profile.isEmpty()) { return hotNewsService.getHotNews(page, size); } // 4. 取画像中权重最高的前5个关键词 List<String> topKeywords = profile.entrySet().stream() .sorted((e1, e2) -> e2.getValue().compareTo(e1.getValue())) .limit(5) .map(Map.Entry::getKey) .collect(Collectors.toList()); // 5. 搜索候选集新闻 List<News> candidates = newsMapper.selectByKeywords(topKeywords, 100); // 6. 相似度计算 + 排序 List<ScoredNews> scoredList = candidates.stream() .map(news -> new ScoredNews(news, calcSimilarity(profile, extractKeywordMap(news.getKeyword())))) .sorted((s1, s2) -> Double.compare(s2.getScore(), s1.getScore())) .collect(Collectors.toList()); // 7. 分类打散，最多保留前20条 List<News> result = diversify(scoredList, 20); // 8. 写入缓存，返回 saveToCache(cacheKey, result); return PageUtil.pageList(result, page, size); }

这句代码是排序的写法：

.sorted((s1, s2) -> Double.compare(s2.getScore(), s1.getScore()))

注意是s2.getScore()减s1.getScore()，降序排列，别写反了；写反了推荐列表就变成最不相关排序了，这种又是类型又难查的问题，很考验排查经验。

候选集搜索的SQL，如果用MyBatis-Plus可以这样处理：

// 方法一：使用QueryWrapper循环拼接，关键词之间OR QueryWrapper<News> wrapper = new QueryWrapper<>(); for (String keyword : keywords) { wrapper.like("keyword", keyword).or(); } wrapper.last("AND status = 1 LIMIT 100");

关键词在keyword字段中是用逗号分隔的字符串，直接LIKE '%关键词%'就能命中。这套逻辑对几千条数据完全够用，实际线上系统会引入Elasticsearch做全文检索，但毕设没必要，论文里可以提一句“后续可以升级为ES”作为展望。

4.3 新闻去重的实现方式

新闻去重是个容易被忽略但很重要的点。现在的新闻抓取和录入很可能会存在重复内容，标题不同的“换皮新闻”如果不去重，推荐列表里会出现好几条相似内容，体验很差。

最简单的去重方案是标题相似度去重：新新闻入库前，先和最近7天已入库的新闻算标题相似度，超过0.85就判定为重复，自动标记为草稿，不进入推荐池。这样比精确查重（一条SQL查标题完全相等）要实用得多，因为重复的新闻标题往往不是完全等值的。

实际实现时，如果数据量大，用Redis缓存最近7天新闻的标题列表，直接内存比对，速度快很多。如果数据量只有几千条，直接在SQL里拼一个IN条件也可以，但会有性能风险，数据量大后会明显变慢。这个逻辑我在系统里放了一个简单的版本，够演示和答辩用。

4.4 定时任务与缓存策略

推荐结果需要定期重算，特别是热门榜，不可能每时每刻都实时算。用Spring Boot自带的@Scheduled注解就能搞定，不用引入额外的调度框架：

@Component public class RecommendTask { @Resource private RecommendService recommendService; @Scheduled(cron = "0 0 2 * * ?") // 每天凌晨2点执行 public void refreshRecommend() { recommendService.rebuildAllUserRecommend(); } @Scheduled(cron = "0 */30 * * * ?") // 每30分钟刷新热门榜 public void refreshHotNews() { recommendService.refreshHotNewsCache(); } }

在启动类上别忘了加@EnableScheduling，不加的话定时任务不会生效。这个代码很常见但也很容易漏：有人把启动类上的注解漏了，跑起来发现热门榜半天不刷新，还以为是Redis连接问题。

缓存策略上，核心是“用过期的缓存换更快的响应”。推荐列表设置5分钟过期，热门榜设置30分钟过期，用户画像设置1小时过期。每次推荐请求进来，先查缓存，缓存没有才去算，这样高并发下也不会把数据库压垮。

4.5 日志埋点：看似不重要实则面试必问

推荐系统的另一个关键工程点是行为日志的埋点。没有日志数据，推荐系统就是无源之水。日志格式要有结构化字段：用户ID、新闻ID、行为类型、行为时间、新闻分类、来源渠道。这样才能方便做行为分析和画像更新。

日志写入如果为了性能，可以用Logback异步写盘，也可以直接写MySQL。毕设阶段写MySQL就够用了，因为数据量不大，但异步日志这条最好在论文里提一笔，说是“为应对高并发而做的优化”，技术广度就有了。

5. 过滤重复、冷启动与性能优化：推荐系统实战中的三个硬骨头

5.1 行为数据的采集与画像更新

推荐系统的根是行为数据，没数据推什么都不准。首先要分清，新闻推荐系统的行为数据有两种：一种是在线时实时上报的，一种是离线批量导入的。前者靠前端埋点，也好做，前端在用户点击新闻详情时，调一个POST /api/user/behavior接口；后者靠定时任务从日志里捞。

行为上报接口核心逻辑是幂等更新。用户对同一条新闻点赞后取消再点赞，不能重复计入权重。我用了Redis的Set集合做去重：set:like:{userId}_{newsId}，存在就代表点过赞，取消则移除。这样无论上报多少次，点赞权重只算一次。

画像权重的更新规则我前面提过一点，这里把完整规则列出来：

这个权重表写在配置里，防止答辩时被问“你凭什么这么设计权重”，你至少能说出依据：基于行为对兴趣表达的强度来排序，浏览最弱，收藏最强。这比拍脑袋给值有说服力得多。

5.2 高并发查询下的性能瓶颈与优化策略

推荐系统的性能瓶颈往往不在推荐算法本身，而在数据库查询。最常见的问题是N+1查询：比如在推荐列表里，每条新闻都要查一次分类名，10条新闻就是10次额外查询。解决方法是关联查询或一次性查出分类Map：

List<News> newsList = recommendService.recommendNews(userId, 1, 10); Set<Long> categoryIds = newsList.stream().map(News::getCategoryId).collect(Collectors.toSet()); List<Category> categories = categoryMapper.selectBatchIds(categoryIds); Map<Long, String> categoryMap = categories.stream() .collect(Collectors.toMap(Category::getId, Category::getName));

这样10条新闻只发1次分类查询。

第二个瓶颈是新闻列表查询不带分页，用户滑到第二页时，把全表数据都查出来再内存截断。MyBatis-Plus自带分页插件，配置一个拦截器就能用：

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

第三个瓶颈是Redis和MySQL缓存不一致。改了新闻内容后，推荐缓存里还是旧数据，用户看到的是过了期的推荐结果。这个问题的最简单解法是缓存过期时间不要设太长，推荐结果5分钟过期，热门榜30分钟过期，就算没做主动清理，用户感知也不强。但如果想做得更严谨一点，可以在新闻更新接口里主动删缓存，一行代码的事：

redisTemplate.delete("recommend:user:" + userId);

5.3 演示环境容易翻车的几个隐藏坑

这套系统演示时最容易翻车的坑，我整理一下。第一，MySQL时区问题，serverTimezone=Asia/Shanghai，不配的话日期字段会差8小时，新闻时间全乱了，推荐排序可能直接看得到未来。第二，前端静态资源跨域，本地起前端跑8080端口访问后端的8081端口，不加跨域配置直接全部被浏览器拦截，接口一个都调不通，后端日志却一切正常。第三，中文乱码，数据库连接URL要加characterEncoding=utf8，同时确保数据库表都是utf8mb4，否则推荐列表显示一堆问号，体验很差。

这三个坑都是配置级别的问题，但演示时任何一个出现都是灾难性的，轻则尴尬，重则直接被打回重做。建议你在答辩前一天把整个流程从零跑一遍，特别留意这三处。

5.4 推荐效果怎么评估——不用做用户实验也能闭环

推荐效果评估是论文的必备内容。你有两种可行的评估方式，都不需要做真正的用户实验。

第一种是离线指标，基于历史用户行为数据，把一部分行为当作训练集，一部分当测试集，计算推荐结果的准确率和召回率。由于新闻推荐的行为数据是自己造的，指标肯定不算好，但只要能算出来并给出趋势性分析，就已经能证明系统逻辑是通的。

第二种是满意度分析，做一个简单的后台统计页面，把每天推荐列表的点击率、人均阅读量、热门分类TOP10展示出来。论文里写“相比随机推荐，本系统的推荐列表点击率提升了XX%”，哪怕这个XX是你自己配的样例数据生成的，只要实验过程描述客观，也是站得住的。

实际上，如果你能把“推荐点击率”从0.8提升到2.1这样的数字变化展示成折线图，答辩时老师很容易被这个量化成果吸引，从而忽略你实验规模其实很小的这一事实。这套话术在实操中非常管用，但别编造论文里的真实实验过程，只是说用系统自带的统计页面积累几天数据即可。

6. 论文撰写与答辩展示：源码之外的“软实力”怎么补

6.1 论文目录怎么搭最稳

论文结构我强烈建议按学校模板来，在此基础上突出“推荐算法”这一核心亮点。一个比较通用的章节设置是：

• 第一章，绪论。写研究背景与意义、国内外研究现状、论文组织结构。绪论重点写新闻推荐在大数据时代的价值，以及主流推荐算法的分类。
• 第二章，相关技术介绍。写Spring Boot、MyBatis-Plus、Redis、推荐算法、分词技术的原理和应用场景，这是凑字数的重灾区，但要注意别纯抄，每段配上“为什么本系统选它”的理由。
• 第三章，系统需求分析。写功能需求、非功能需求、用例图。
• 第四章，系统设计。写总体架构图、功能模块设计、数据库设计、推荐算法设计。
• 第五章，系统实现。写核心功能代码、界面截图、关键流程说明。
• 第六章，系统测试。写测试用例、功能测试结果、性能测试结果。
• 第七章，总结与展望。写项目总结、不足与改进方向。

第三章到第五章是最核心的三章，加起来要占全文60%以上的篇幅。第三章别只写“用户能登录、能看新闻”，要把每个功能对应的用户故事写完整；第四章一定要有架构图、E-R图和表结构清单；第五章的每个模块截图都要配代码核心逻辑，别放一堆前端页面图不带说明。

6.2 画图和代码展示的技巧

论文里的图，优先用ProcessOn或draw.io画。架构图要注意分层，从下往上分别是数据层（MySQL+Redis）、中间层（Spring Boot各模块）、表现层（Vue页面+接口层），每层有什么组件写清楚。E-R图用数据库工具反向生成，MySQL Workbench就能做，比自己画规范得多。用例图用StarUML画，素材够用。

代码展示不要贴大段完整代码，只贴核心片段。比如推荐Service层的相似度计算段、HotNewsCache的缓存逻辑段、JWT拦截器的校验逻辑段，各贴10到20行就行。贴之前用Markdown或Word的代码块工具高亮，论文整体观感立刻不一样。

还有一个很实用的小技巧：论文中每个功能模块的标题下，第一句话就用“本模块实现了……”，第二句话开始讲业务流程，第三句话代入代码位置。这样老师都知道你在讲什么，也不用他自己猜。

6.3 答辩时最能打的问题清单

答辩时老师问得最多的问题，我归类一下，你可以提前把答案准备好。

“为什么选Spring Boot不用SSH/SSM？”标准回答是Spring Boot简化配置、自动装配、内嵌Tomcat、生态完善，对比SSH减少大量XML配置，开发效率高。

“推荐算法的原理是什么？”基于内容的推荐，核心是TF-IDF+余弦相似度，把用户行为转成关键词权重向量，再和新闻关键词向量计算相似度，相似度高的推荐出去。

“你的系统是怎么做冷启动的？”新用户给热门榜兜底，新新闻用时间衰减加分保证曝光，分情况回答，展示思考周全。

“怎么证明推荐效果好？”用点击率、推荐覆盖率等离线指标，结合系统内置的后台统计页面数据做对比分析。

“为什么不用协同过滤？”结合新闻场景说明数据稀疏和时效性两个痛点，再说协同过滤在新闻推荐里的局限，不如基于内容推荐稳定。

每个问题都要能脱口而出，最好在答案里加一句“这部分我论文里写了”，老师会觉得你对项目确实有掌控力。

7. 源码整理的最后一公里：把“.7z”变成你自己的作品

很多同学拿到压缩包第一反应是赶紧启动看效果，但我建议先做三件事。第一，检查压缩包完整性，确认包含源码、SQL脚本、论文和README，避免答辩前发现缺论文这种灾难。第二，阅读README，了解项目的启动步骤、默认账号密码、所需环境版本。第三，跑起来后按业务主线过一遍：注册登录、浏览新闻、点击查看详情、查看推荐列表、管理后台发布新闻、查看推荐统计。走完这条链路，整套系统才算真正上手。

接下来是“去重”问题。你拿到的源码和论文大概率是别人已经用过一轮的，直接原封不动交上去，查重和答辩都会出问题。至少要做这几步：项目名、包名、类名全面改名，比如把com.news改成com.yourname.news；新闻表和分类表的种子数据换成你自己感兴趣的领域，比如原来是科技+体育，你换成人工智能+财经，这样界面截图和论文截图都会不一样；前端页面的Logo和标题改成你自己的；论文里的“致谢”和“绪论”部分重写，这部分是查重的高风险区。

数据库脚本里的初始账号密码也要改，管理员账号别用admin/123456这种，改成你自己设计的一对，并在论文管理模块介绍里说明密码是加密存储的（实际用BCrypt加密），这样答辩时被问到安全性的概率也会小很多。

UI层面如果能力允许，建议换一套前端框架或主题色。原来用Bootstrap改Vue或Element UI，整体观感完全不一样，一眼看上去就不像模板项目。前端框架替换不需要重写业务接口，只是替换页面渲染层，工作量不算大，但辨识度极高。

如果你的时间比较紧张，至少把登录页面和首页改掉，因为答辩老师大概率只用几分钟看系统界面，这两屏最能先入为主。

最后再分享一个很多人忽略的经验：在系统里加上一条“人工推荐”规则。管理员在后台上传新闻时，可以勾选“置顶推荐”。置顶的新闻一定排在用户推荐列表的前面。这个功能看起来技术含量不高，但实战价值极高：演示时你可以提前把和自己论文主题相关的几篇新闻置顶，打开系统第一眼看到的就是与论文相关的推荐内容，整个答辩节奏会被这个小小的功能带得异常顺畅。这个彩蛋免费送给你，用过的都知道香。

本文还有配套的精品资源，点击获取