Spring Boot新闻推荐系统设计与实现全解析

简介：本资源是一套基于Spring Boot与Vue技术栈构建的新闻推荐系统完整实现方案，面向Java后端开发初学者、毕业设计学生及Web全栈学习者，解决个性化新闻内容分发与用户兴趣建模的实际问题。压缩包共748个文件，涵盖90个Java核心业务类、38个Vue组件、153个JavaScript交互逻辑、44个CSS样式文件、162个SVG图标资源及1个SQL建库脚本，前端采用B/S架构，后端依托Spring Boot快速开发框架，数据库使用MySQL，整体结构清晰、模块解耦明确。资源包大小为15.15MB，含完整论文文档（含系统分析、概要与详细设计、测试报告等章节）及可运行源码，支持管理员新闻管理、用户收藏与首页推荐等功能，且包含install/run/build三类批处理脚本，便于本地一键部署调试。目前已有34人学习下载，适合需要毕业设计参考、技术栈整合实践或推荐系统入门实战的学习者。 做毕设或者练手项目的人，十有八九都见过这种压缩包：基于springboot新闻推荐系统设计与实现.7z（源码+论文）。名字很长，一眼就知道里面装了什么——一套能跑的Spring Boot项目源码，加一份配套的毕业论文。这类项目在网上被下了无数次，但真正能从头到尾跑通、还敢说懂里面原理的人，其实不多。我前阵子刚好完整接手过一套类似的系统，从数据库设计到推荐算法，再一路调试到部署上线，踩了不少坑，也把整个逻辑理顺了。今天这篇就把这套新闻推荐系统从头到尾拆开讲清楚，包含核心设计、推荐算法落地、源码目录导读、常见问题排查，以及论文该怎么和代码对应起来写。无论你是准备拿它当毕业设计，还是想学Spring Boot实战，这篇文章应该都能帮到你。

先给还不了解的朋友一句话介绍：新闻推荐系统，就是让每个用户打开新闻App或者网站时，看到的不是千篇一律的编辑推荐列表，而是根据他看过的、点过的、停留过的内容，实时计算出一份“这个人可能会喜欢”的新闻流。Spring Boot则是目前Java后端最主流的开发框架，用它来搭这类系统，开发效率高、生态成熟、部署也简单。这套项目适合的人群很明确：计算机相关专业做毕设的学生、正在学Spring Boot想做完整项目的初级开发者、以及对推荐系统落地场景感兴趣的后端工程师。

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

1.1 为什么选Spring Boot而不是其他框架

我见过很多人在选型时纠结Spring Boot和Spring Cloud，甚至有人直接上来就套微服务架构。这里我必须说一句：新闻推荐系统这种规模的业务，用微服务纯属给自己找麻烦。Spring Boot最大的优势是“开箱即用”，内嵌Tomcat，不用单独部署容器，一个jar包就能跑起来，配合Spring Boot Starter体系，集成MyBatis、Redis、定时任务这些常用组件几乎都是加一个依赖、写几行配置的事。

对比一下就更清楚了：

毕设级别的新闻推荐系统，用户量就是几千人这个量级，单机部署完全顶得住。用Spring Boot做单体架构，既能保证系统功能完整，又能让论文里把“非功能需求”这块写清楚——性能、可维护性、可扩展性都有话说。现实中我也见过有人非要把推荐服务拆成单独模块用RPC调用，结果部署的时候光配置注册中心就配了一下午，这种弯路不建议走。

1.2 推荐系统的核心思路与数据流

新闻推荐和电商推荐虽然都叫推荐系统，但侧重点差别很大。电商重复购，用户买过一次手机，接下来一段时间还会看手机配件；新闻重时效，昨天那条热闻今天就没价值了，用户昨天的兴趣点今天可能就变了。所以新闻推荐系统在设计时，一般不会只依赖长期的兴趣画像，而是把近期行为权重拉高，冷启动和热门兜底的策略也必须做好。

这套系统的整体数据流是这样的：用户在前端产生行为，比如点击、浏览、点赞、收藏、评论。行为数据通过接口写入后端，后端先落库，同时更新Redis缓存里的用户最近行为。推荐模块定时拉取用户行为数据，结合新闻内容特征和用户画像，通过推荐算法计算出候选新闻列表，过滤掉已读的、时效性差的，再按分数排序返回给前端展示。

在这个流程里，Spring Boot承担的是数据接收、业务处理、推荐调度、接口输出这几个角色。推荐算法本身并不一定要在Java里纯手写，很多做毕设的同学会直接用简单的协同过滤公式配合SQL或者内存计算来实现，这样既能跑通流程，也能在论文里把算法推导过程写清楚，比调一个sklearn包更有说服力。

1.3 技术栈清单与版本选型

以我实际调试过的这套为例，技术栈大概是这样的：

• JDK 1.8 / JDK 17都可以，建议用1.8，兼容性最好
• Spring Boot 2.7.x，不建议一上来用3.x，因为3.x要求JDK17且部分旧教程不适用
• MyBatis-Plus 3.5.x，做单表CRUD非常省事
• MySQL 5.7 / 8.0，存储用户、新闻、行为数据
• Redis 6.x，缓存热点新闻、用户近期的阅读记录
• Spring Task，实现定时推荐任务的调度
• Maven 3.6+，项目构建管理
• 前端可以是一套简单的Thymeleaf模板页面，也可以配Vue前后端分离，看论文要求

很多人在网上搜“springboot版本太高”这类问题，本质就是版本匹配没做好。比如Spring Boot 3.4.3这种新版本，对应的MyBatis-Plus、Redis客户端、Swagger配置方式全变了，网上大部分教程还停留在2.x时代。所以我的建议很直接：做项目、做毕设，稳定第一，用Spring Boot 2.7.x这一代，资料多、坑少、跑起来快。

2. 核心功能模块与数据库设计

2.1 功能模块拆解

新闻推荐系统的功能不多，但必须完整。我从实际开发角度拆一下，一共是五个核心模块：

第一，用户模块。包含注册、登录、个人信息管理。注册时记录用户的基础属性，比如性别、年龄、职业，这些字段在后面做用户画像的时候很有用，特别是冷启动阶段，当用户还没有任何行为数据时，可以根据人口统计学特征推荐对应类别的新闻。

第二，新闻模块。包括新闻的发布、编辑、分类管理、上下架。后台管理员可以发布新闻，设置新闻所属的栏目（科技、体育、财经、娱乐等），维护新闻的标签关键词。前端用户端按分类浏览新闻，并查看新闻详情。

第三，行为采集模块。用户在浏览新闻时，前端会在合适的时机上报行为数据。包括点击、浏览时长、点赞、收藏、评论、分享等类型。这些行为数据是推荐算法的原材料，采集的完整度直接决定了推荐效果。

第四，推荐模块。核心部分，负责从所有新闻中筛选出当前用户可能感兴趣的新闻列表，输出排序结果并推送给前端。推荐模块会综合用户行为历史、新闻热度、新闻时效性、用户画像这几个维度来计算分数。

第五，管理后台模块。给系统管理员使用，包含用户管理、新闻审核、数据统计看板。统计看板可以展示新闻的点击量分布、分类偏好、用户活跃度等指标，这一块在论文里可以作为系统测试和效果分析的数据来源。

2.2 数据库表结构设计

数据库是这套系统的基础，表设计不好，后面写推荐算法会非常痛苦。我整理了一份可以直接参考的表结构：

用户表t_user：

新闻表t_news：

行为表t_user_behavior：

这三张表是最基础的，如果论文里要求更完整，可以再加一张t_recommend_log推荐记录表，用来记录每次给用户推荐了哪些新闻，以及用户是否点击了推荐内容。这张表在论文的效果验证部分特别好用，可以统计推荐点击率（CTR），证明系统推荐效果确实优于热门列表。

2.3 用户行为埋点的设计细节

很多初学Spring Boot的同学，在行为采集这个环节容易犯一个错误：把行为记录当成普通业务请求处理，用户每点击一次就同步落库。新闻详情页的请求量本来就大，同步落库会导致数据库压力陡增，页面响应变慢。

我实际项目里的做法是分为两步。第一步，前端在用户点击新闻时调一个轻量接口，比如/api/behavior/report，后端只做参数校验，然后直接写入Redis的Stream或者一个简单的消息队列中，接口立刻返回成功，用户无感知。第二步，通过Spring的@Scheduled定时任务，每隔30秒批量从队列中消费行为数据，再批量写入MySQL。这种异步削峰的处理方式，在论文里可以单独写一节，既体现系统设计能力，又说得通。

另外还有一个小细节：行为类型需要带权重。同样是“点击”，普通点击和“阅读时长超过60秒”的深度阅读，对用户兴趣的反映程度是完全不一样的。在行为表里增加duration字段，并设定不同行为类型对应的权重值，比如点击权重1、浏览权重2、点赞权重3、收藏权重4、评论权重5。这些权重值可以在系统的配置中心维护，推荐算法计算时直接读取。

3. 推荐算法落地与关键代码实现

3.1 基于物品的协同过滤（ItemCF）

新闻推荐系统最经典的做法是ItemCF，也就是基于物品的协同过滤。它的核心逻辑是：如果用户A喜欢新闻1，同时喜欢新闻2的用户也普遍喜欢新闻3，那新闻1和新闻3就是相似的，可以推荐给喜欢新闻1的用户。

为什么新闻场景更适配ItemCF而不是UserCF（基于用户的协同过滤）？原因很简单：新闻的更新速度极快，用户的兴趣变化也快。UserCF需要先找相似用户群，再找这个群体喜欢的新闻，计算链路长、时效性差。ItemCF可以直接计算新闻之间的相似度，用户一旦对某条新闻产生了交互，立刻就能找到与之相似的其他新闻推荐出去，响应更快。

ItemCF的实操步骤分成三步：

第一步，构建用户-新闻的交互矩阵。行为数据从t_user_behavior表中取，需要把多种行为加权合并成一个最终的交互值。

第二步，计算新闻之间的相似度。常用的计算方法有余弦相似度和杰卡德相似系数。

余弦相似度的公式是：

similarity(i, j) = sum(u_ai * u_aj) / (sqrt(sum(u_ai^2)) * sqrt(sum(u_aj^2)))

其中u_ai表示用户a对新闻i的评分值（加权行为分），u_aj表示用户a对新闻j的评分值。所有对新闻i和新闻j都有过行为的用户参与计算。

第三步，根据用户已交互的新闻，找出最相似的N条新闻，并按相似度加权排序，生成推荐列表。

如果用户对新闻1的行为分是3分，新闻1和新闻7的相似度是0.72，那么这条候选推荐的计算分就是 3 × 0.72 = 2.16。

3.2 基于内容的推荐与画像标签

ItemCF的问题是冷启动时新闻没有交互数据，相似度矩阵是空的。所以系统里不能只靠协同过滤，还要有基于内容的推荐作为补充。

基于内容的推荐，最核心的是构建“新闻-标签”映射和“用户-标签偏好”映射。新闻表里我设计了一个tags字段，存逗号分隔的关键词，比如“中美 科技 芯片”。管理员在发布新闻时维护标签，如果是爬虫批量入库的新闻，可以用简单的分词工具自动打标签。

用户对不同类型的标签偏好度，是从行为记录中累积的。比如用户最近读了5篇科技类新闻，每篇都点了赞，那“科技”这个标签在他画像里的权重就会不断上涨。计算用户对某个标签的偏好度，公式可以简单写成：

public double getTagPreference(Long userId, String tag) { return behaviorService.listUserBehavior(userId).stream() .filter(b -> newsService.getById(b.getNewsId()).getTags().contains(tag)) .mapToDouble(b -> getBehaviorWeight(b.getBehaviorType()) * (b.getDuration() / 60.0 + 1)) .sum(); }

基于内容的推荐会把用户偏好排名前K的标签找出来，拉取这些标签下的最新新闻，再按发布时间和热度排序作为候选集。

这套方案在论文里有很好的解释空间——协同过滤负责挖掘隐式关联，内容推荐负责覆盖新新闻和冷启动，两者加权融合，逻辑严谨又完整。

3.3 冷启动与热门兜底策略

冷启动是推荐系统里绕不开的问题。新闻推荐系统里冷启动分三种情况：

新用户没有任何行为数据，协同过滤和内容推荐全都无效。这时候系统会退回热门榜，推荐当前时段点击量最高的新闻。可以在数据库里加一个新闻热度的字段，每次定时任务根据近24小时的点击量、点赞数、收藏数计算热度值，比如hot_score = 0.6 * 点击量 + 0.3 * 点赞数 + 0.1 * 收藏数，再按热度降序取前50条。

新新闻没有任何用户行为，ItemCF算不出相似度。这个场景的处理是给新新闻一个时间衰减系数，上架前24小时内，在推荐候选池里给予一定的曝光加权。也就是说，即使这条新闻暂时没有交互数据，也会根据它所属的类目和标签，匹配给对该类目感兴趣的用户。

用户数据稀疏，只有少数几条行为记录。这时推荐系统可以将协同过滤和内容推荐的结果按比例融合，比如协同过滤占70%，内容推荐占30%。随着用户行为数据增多，协同过滤的权重逐渐上升。这个动态权重的逻辑，在系统里可以用一条配置控制，写论文时也容易图表化展示。

3.4 推荐接口的完整实现

推荐模块对外暴露的核心接口是：根据用户ID获取个性化推荐新闻列表。我建议把推荐流程拆成Service层的独立方法，方便代码调试和论文讲解。

public RecommendResult getRecommendList(Long userId, int page, int size) { // 1. 查缓存：如果有最近一次的推荐结果，直接返回 List<Long> cacheIds = redisTemplate.opsForList().range("recommend:user:" + userId, 0, -1); if (cacheIds != null && cacheIds.size() >= (page + 1) * size) { return buildResult(cacheIds.subList(page * size, (page + 1) * size)); } // 2. 获取用户行为数据 List<UserBehavior> behaviors = behaviorService.listRecentBehavior(userId, 30); // 3. 如果是新用户，返回热门新闻 if (behaviors.isEmpty()) { return buildResult(newsService.listHotNews(size)); } // 4. ItemCF结果 List<NewsScore> itemCfList = itemCfService.recommend(userId, behaviors); // 5. 基于内容推荐结果 List<NewsScore> contentList = contentRecommendService.recommend(userId, behaviors); // 6. 融合排序：按加权分数合并 List<NewsScore> merged = mergeScore(itemCfList, contentList); // 7. 过滤用户已读新闻，缓存结果，返回 List<NewsScore> filtered = merged.stream() .filter(score -> !behaviors.stream().anyMatch(b -> b.getNewsId().equals(score.getNewsId()))) .limit(size) .collect(Collectors.toList()); redisTemplate.opsForList().leftPushAll("recommend:user:" + userId, filtered.stream().map(NewsScore::getNewsId).collect(Collectors.toList())); return buildResult(filtered); }

这段代码的主要逻辑我已经在注释里写清楚了。第1步查缓存是为了性能，第2步到第5步是推荐计算主体，第6步是融合，最后一步过滤已读并缓存。注意第7步的缓存有效期最好设置为10~30分钟，避免推荐列表长时间不变导致用户产生审美疲劳。

4. 部署运行与源码导读

4.1 本地环境准备与启动流程

拿到一套源码之后，第一步永远是先把环境搭起来，项目跑通，再谈读代码。我按实际踩坑顺序整理一下：

第一步，安装JDK和Maven。JDK推荐用1.8，Maven用3.6以上。注意在IDEA的Project Structure里把Project SDK指定好，不要出现编译环境是17、运行环境是8这种前后不一致的情况，报错时排查起来非常烦。

第二步，配置MySQL。新建一个数据库，比如news_recommend，执行源码里自带的sql目录下的建表脚本。很多源码自带的SQL脚本需要手动调整字符集为utf8mb4，否则后面存中文新闻内容会出现乱码。

第三步，初始化Redis。Windows下可以用Memurai替代Redis服务端，端口默认6379，不需要修改。

第四步，修改配置文件。打开application.yml，设置数据源地址，改成你的MySQL地址和账号密码。很多同学在“springboot配置”这一步卡住，本质是一下子不知道哪里要改。其实Spring Boot的配置非常简单，只用看这几个核心模块：server端口、spring.datasource、spring.redis、mybatis-plus配置。

第五步，启动项目。在IDEA里面直接运行主类NewsRecommendApplication.java，控制台出现Spring Boot的Banner，再看到“Started NewsRecommendApplication”这行日志，就说明启动成功了。默认端口8080，浏览器访问http://localhost:8080就能看到系统首页。

4.2 源码目录结构导读

拿到源码包解压之后，典型的Maven工程结构是这样的：

news-recommend/ ├── src/main/java/com/example/newsrecommend/ │ ├── controller/ # 控制层，接收前端请求 │ ├── service/ # 业务层，核心逻辑都在这里 │ ├── mapper/ # MyBatis-Plus的Mapper接口 │ ├── entity/ # 实体类，对应数据库表 │ ├── config/ # 配置类，比如RedisConfig、MybatisPlusConfig │ ├── common/ # 公共类，统一返回结果、异常处理 │ ├── recommend/ # 推荐算法核心包 │ │ ├── ItemCF.java │ │ ├── ContentBased.java │ │ └── RecommendService.java │ └── NewsRecommendApplication.java ├── src/main/resources/ │ ├── mapper/ # MyBatis的XML映射文件 │ ├── static/ # 静态资源 │ ├── templates/ # 前端页面模板 │ ├── application.yml # 主配置文件 │ └── sql/ # 数据库初始化脚本 ├── pom.xml └── README.md

读源码的时候，建议按照入口controller → service实现 → mapper → 数据库这样一层层往下读，先跑通一条完整的“请求-响应”链路，再去看推荐算法的具体实现。不建议上来就扎进ItemCF的代码里，容易迷路。

4.3 配置文件中的关键参数

application.yml是这套系统最重要的配置文件，我摘几个核心片段说明一下：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/news_recommend?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 redis: host: localhost port: 6379 timeout: 5000ms

serverTimezone=Asia/Shanghai这个参数一定要加，否则连接MySQL 8.0时经常会报时区错误。useUnicode=true&characterEncoding=utf8确保数据库能正确处理中文，我见过太多人因为漏了这两个参数，最后中文乱码查了半天，结果就是URL参数问题。

MyBatis-Plus的配置也顺便说一下：

mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto

log-impl配置成StdOutImpl后，控制台会打印SQL日志，调试推荐算法时非常有用，可以直观看到每一条SQL的执行情况。生产环境可以关掉，但开发阶段开着能省大量排查时间。

5. 常见问题与排查技巧实录

5.1 项目启动失败问题清单

我调试这套系统的过程中，遇到的启动失败问题主要集中在下面几个场景，我整理成了表格，方便大家直接对照排查：

其中端口占用这个问题，我在开发中反复踩坑。Windows下用netstat -ano | findstr 8080找到PID，然后任务管理器结束进程是最直接的办法。如果不想结束，也可以改server.port，比如改成8081。

5.2 推荐结果为空或不准

推荐接口返回空列表，是这套系统最常见的运行期问题。大部分原因很简单：新注册的用户没有任何行为数据，而代码里的兜底逻辑只处理了“行为为空时返回热门榜”，如果热门榜也查不到新闻，结果自然为空。

我排查这类问题有一个固定套路：

第一步，看数据库中t_news表有没有数据，status字段是否为1（上架状态）。 第二步，看当前测试用户有没有行为记录，用SQL查一下t_user_behavior。 第三步，直接用Postman调推荐接口，看后端日志里推荐算法执行到了哪一步，有没有报错。 第四步，检查Redis里是否缓存了空列表。这是最容易忽略的点——接口第一次查出来是空，缓存了一个空列表，之后每次请求都直接返回缓存，永远都是空。解决办法是在缓存之前判断列表是否为空，为空就不缓存。

推荐结果不准的情况，就比较偏算法调优了。最常见的表现是热门新闻霸榜、个性化不明显。这通常是融合排序时权重没有调好，内容推荐和协同过滤的结果没有拉开差距。我的建议是先看一下ItemCF输出的分数分布，如果分数差异很小，说明用户交互行为太少，系统本质上还处于冷启动阶段，个性化效果自然会差一些。这种问题不是Bug，而是数据量不够，论文里可以如实记录为“系统在小规模数据下的效果局限”，反而显得诚实。

5.3 中文乱码问题

中文乱码是Spring Boot老生常谈的问题，我不止一次看到群友在项目交流群里问。通常分三种情况：

页面显示乱码，一般是HTML文件编码不是UTF-8，用IDEA右下角把文件编码改成UTF-8然后重新加载。

接口返回的JSON中文乱码，多数是Spring的HttpMessageConverter编码问题，但Spring Boot 2.x默认已经是UTF-8，如果还乱码就先检查数据库连接串里有没有characterEncoding=utf8。

数据库里中文正常，从数据库读出来再返回就变成问号，这个问题多数出在数据库字符集上。建库时用了latin1就会这样，需要在上面的建库语句里显式指定DEFAULT CHARACTER SET utf8mb4，已经建好的库可以执行ALTER DATABASE news_recommend DEFAULT CHARACTER SET utf8mb4;补救。

5.4 论文写作与源码如何对应

这套项目打包里带的论文，通常要覆盖系统分析、系统设计、系统实现、系统测试四个大章节。写论文时很多同学容易犯一个错误：光贴代码截图，不解释设计理由。论文和源码最理想的对应关系是：论文里每一个功能模块的描述，在源码里都能找到对应的类和接口；论文里每一个算法公式，在源码里都能找到对应的实现方法。

我建议按这个思路组织：

第二章“相关技术介绍”，写Spring Boot、MyBatis-Plus、Redis、推荐算法理论。不需要深入源码，重点写“为什么选它”。

第三章“系统分析”，写需求分析、可行性分析、用例图。要和功能模块对应起来，把用户、管理员两类角色做区分。

第四章“系统设计”，写总体架构图、数据库ER图、表结构。上面的三张表设计可以直接用。

第五章“系统实现”，按功能模块逐一描述实现过程。每个模块配1~2张核心代码截图，加一段文字说明实现逻辑。推荐算法部分要重点描述ItemCF的计算过程和融合策略，这是全篇最大的加分项。

第六章“系统测试”，写测试环境、测试用例、测试结果。最好有推荐效果对比表，比如“热门推荐点击率 vs 个性化推荐点击率”，用真实数据证明推荐系统有效。

写论文最忌讳的就是代码从头贴到尾，毫无设计说明。答辩老师问你“为什么用ItemCF而不用UserCF”，你要能答出“新闻场景通常要求实时性强和信息发现率高，ItemCF更合适”才算过关。

6. 个人实操心得与扩展建议

最后分享一点我自己的实操感受。这套新闻推荐系统，我完整跑下来最耗时的部分其实不是Spring Boot的CRUD，而是推荐算法的调优和异常数据的处理。第一次把推荐流程跑通时，我以为万事大吉，结果发现测试用户登录后推荐列表和热门榜几乎一模一样，个性化和没做一样。后来排查了行为日志，发现采集接口被前端调用得太频繁，行为数据虽然写进去了，但很多都是用户无意识的快速滑动，没有真实反映兴趣。后来我加了“浏览时长大于5秒才算有效浏览”的过滤逻辑，推荐效果才明显改善。

对于准备拿这套系统做毕设的同学，我强烈建议在完成基础功能后，至少做一个小创新点，比如引入时间衰减因子、改进冷启动策略、增加基于用户实时行为的实时推荐接口。这些改动在论文里的呈现效果会很突出，答辩的时候也有东西可以讲。还有一个思路是给系统增加一个简单的推荐效果监控页面，展示每天推荐点击率的变化曲线，这不仅让系统显得完整，还能让你的测试章节有数据支撑。

如果你打算在这个基础上继续深挖，可以考虑把推荐计算改成离线预计算模式，用定时任务在凌晨统一算好每个用户的推荐列表存入缓存，白天就直接读缓存，性能会好很多。想挑战一下的话，还可以把行为数据通过消息队列接入实时计算平台，做真正意义上的实时推荐。不过这些都是后话了，先把这套基础版本吃透，比什么都有用。

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