基于SpringBoot的新闻推荐系统：从源码到论文的完整落地路径

简介：本资源为基于Spring Boot与Vue的新闻推荐系统完整项目包，面向计算机专业学生、Java初学者及需要课程设计或毕业设计参考的开发者，帮助解决推荐类系统从需求分析到落地实现的完整方案问题。压缩包共748个文件，约15.15MB，涵盖90个Java后端源码、38个Vue前端组件、153个JavaScript脚本、44个CSS样式及1个SQL数据库脚本，另含论文文档与Maven构建配置，前后端分离结构清晰。资源包含系统概述、可行性分析、数据库实体与设计表、管理员与用户双模块实现、系统测试等章节，涉及用户信息管理、排行榜管理、新闻信息管理、首页推荐、我的收藏等功能模块，并附有完整论文可供撰写参考。目前已有34人学习下载，适合需要掌握Spring Boot项目开发流程、理解推荐系统业务逻辑或准备答辩材料的学习者对照研读与二次开发。

1. 基于 SpringBoot 的新闻推荐系统：从源码到论文，一套能跑通的落地路径

很多同学做毕设或课程设计时，一看到“新闻推荐系统”就觉得要么是爬虫加协同过滤的玩具，要么是调个 API 拼凑的 Demo。但真正把基于 SpringBoot 的新闻推荐系统源码和论文完整跑通、并且能讲清楚推荐链路的人，其实不多。这个标题背后对应的是一个典型的 Java 后端工程：用 SpringBoot 做 Web 层和业务编排，用 MySQL 存用户、新闻、行为日志，用 Redis 做热点缓存，推荐算法部分常见做法是协同过滤加内容标签召回，再通过定时任务或消息队列更新推荐结果。它适合正在做毕设、需要交付源码和论文的本科生，也适合想从 CRUD 转向推荐系统入门的 Java 开发者。接下来我会按实际搭建顺序，把环境、表结构、推荐模块、论文写作和踩坑点逐一拆开讲。

2. 环境与工程骨架：SpringBoot 版本选型与 Maven 依赖怎么定

2.1 为什么我建议用 SpringBoot 2.7.x 而不是最新版

热搜里经常出现“springboot版本太高”这个关键词，这不是偶然。很多同学直接用 SpringBoot 3.x 起步，结果发现 JDK 必须 17 以上，而学校机房或自己电脑上装的是 JDK 8 或 11，一编译就报Unsupported class file major version。更麻烦的是，SpringBoot 3.x 把javax.*全部换成了jakarta.*，如果你参考的源码或论文里用的是旧版依赖，比如某些 MyBatis 插件、Swagger 2、旧版 Redis 客户端，整合时会大量报ClassNotFoundException。

我一般会选 SpringBoot 2.7.18 这个版本，它是 2.x 的最后一个稳定版，兼容 JDK 8 和 JDK 11，生态里的 MyBatis-Plus、Druid、Knife4j 都有成熟适配。如果你确实想用 SpringBoot 3.x，那 JDK 至少 17，并且所有javax.servlet相关的代码都要改成jakarta.servlet，这个工作量在毕设周期里不划算。

2.2 用 Maven 搭出可运行的最小骨架

下面这个pom.xml是我在多个新闻推荐系统项目里反复用过的依赖组合，去掉了不必要的重型组件，保留推荐系统必需的部分。

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <groupId>com.example</groupId> <artifactId>news-recommend</artifactId> <version>1.0.0</version> <properties> <java.version>1.8</java.version> <mybatis-plus.version>3.5.3.1</mybatis-plus.version> </properties> <dependencies> <!-- Web 层：提供 REST 接口和页面路由 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis-Plus：简化新闻、用户、行为表的 CRUD --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>${mybatis-plus.version}</version> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- Redis：缓存热点新闻和用户推荐结果 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!-- Lombok：减少实体类 getter/setter 代码量 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- 定时任务：用于离线更新推荐结果 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>

这段配置里，spring-boot-starter-web负责控制器和 JSON 序列化，mybatis-plus-boot-starter让你不用手写大量 XML 映射文件，spring-boot-starter-data-redis用来缓存推荐列表，spring-boot-starter-quartz用来跑定时推荐任务。参数上唯一需要你改的是java.version，如果你本机是 JDK 11，就改成11，其他不用动。

2.3 配置文件里必须写对的三个连接参数

application.yml里最容易翻车的是数据库时区和 Redis 序列化配置。时区不写对，新闻发布时间会差 8 小时；Redis 不配序列化器，缓存进去的对象读出来会报SerializationException。

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/news_recommend?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 timeout: 5000ms mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: id-type: auto

serverTimezone=Asia/Shanghai这个参数必须加，否则 MySQL 8 会报时区错误。map-underscore-to-camel-case: true让数据库的create_time自动映射到 Java 的createTime，省去手写@Results。Redis 部分如果你本机没设密码，password留空即可，但timeout建议保留，避免连接卡死时线程一直等。

3. 新闻推荐系统的数据层：表结构设计与行为日志采集

3.1 四张核心表撑起推荐链路

推荐系统能不能跑出效果，七成看数据。新闻推荐系统至少需要四张表：用户表、新闻表、用户行为表、推荐结果表。用户行为表是推荐算法的燃料，没有它，协同过滤就是空转。

-- 用户表 CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(100) NOT NULL, `interest_tags` varchar(255) DEFAULT NULL COMMENT '用户兴趣标签，逗号分隔', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 新闻表 CREATE TABLE `news` ( `id` bigint NOT NULL AUTO_INCREMENT, `title` varchar(200) NOT NULL, `content` text, `category` varchar(50) DEFAULT NULL COMMENT '新闻分类', `tags` varchar(255) DEFAULT NULL COMMENT '内容标签，逗号分隔', `publish_time` datetime DEFAULT NULL, `click_count` int DEFAULT '0', PRIMARY KEY (`id`), KEY `idx_category` (`category`), KEY `idx_publish_time` (`publish_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 用户行为表：记录点击、收藏、停留时长 CREATE TABLE `user_behavior` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL, `news_id` bigint NOT NULL, `behavior_type` tinyint NOT NULL COMMENT '1点击 2收藏 3分享', `stay_duration` int DEFAULT '0' COMMENT '停留秒数', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_news` (`user_id`,`news_id`), KEY `idx_create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 推荐结果表：离线计算后写入，前端直接查 CREATE TABLE `recommend_result` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL, `news_id` bigint NOT NULL, `score` double DEFAULT '0', `rec_type` varchar(20) DEFAULT 'cf' COMMENT 'cf协同过滤 cb内容推荐 hot热门', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_score` (`user_id`,`score` DESC) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

user_behavior表里的stay_duration很关键，它比单纯的点击更能反映用户真实兴趣。recommend_result表用rec_type区分推荐来源，方便你在论文里做对比实验。索引方面，idx_user_news加速查询某用户对某新闻的行为，idx_user_score让推荐结果按分数倒序取 TopN 时不用全表扫描。

3.2 行为采集接口怎么写才不丢数据

前端埋点上报行为时，最常见的坑是同步写库导致接口响应慢，用户连续点击时丢事件。我一般用异步方式：接口收到请求后先丢进内存队列或 Redis List，再由定时任务批量落库。

@RestController @RequestMapping("/api/behavior") public class BehaviorController { @Autowired private StringRedisTemplate redisTemplate; @PostMapping("/report") public Result report(@RequestBody BehaviorDTO dto) { // 拼接行为记录，格式：userId:newsId:type:duration:timestamp String record = dto.getUserId() + ":" + dto.getNewsId() + ":" + dto.getType() + ":" + dto.getDuration() + ":" + System.currentTimeMillis(); // 左侧推入 Redis 队列，避免阻塞用户请求 redisTemplate.opsForList().leftPush("behavior:queue", record); return Result.ok(); } }

leftPush把行为记录推进behavior:queue，接口立刻返回，用户无感知。后台用一个@Scheduled任务每隔 10 秒rightPop批量取出，攒够 100 条或队列空了就批量插入user_behavior表。参数上，stay_duration由前端在页面离开时通过navigator.sendBeacon上报，比beforeunload里的同步请求可靠得多。如果你不做异步，高并发下数据库连接池会被打满，这是血泪经验。

4. 推荐算法模块：协同过滤与内容标签召回怎么落地

4.1 用户协同过滤的核心计算步骤

协同过滤分 UserCF 和 ItemCF，新闻场景下 ItemCF 更稳定，因为新闻更新快，用户兴趣漂移也快，但 ItemCF 需要物品相似度矩阵，计算量大。毕设里我通常先用 UserCF 跑通链路，再用 ItemCF 做对比。UserCF 的核心是两步：算用户相似度，再根据相似用户的行为加权推荐。

@Service public class UserCFRecommender { @Autowired private UserBehaviorMapper behaviorMapper; /** * 计算目标用户与其他用户的余弦相似度 * @param targetUserId 目标用户 * @param topN 取相似度最高的前 N 个用户 */ public List<Long> findSimilarUsers(Long targetUserId, int topN) { // 1. 查出所有用户的行为向量：Map<userId, Map<newsId, score>> Map<Long, Map<Long, Double>> allVectors = buildUserVectors(); Map<Long, Double> targetVector = allVectors.get(targetUserId); if (targetVector == null || targetVector.isEmpty()) { return Collections.emptyList(); } // 2. 逐个计算余弦相似度 Map<Long, Double> similarityMap = new HashMap<>(); for (Map.Entry<Long, Map<Long, Double>> entry : allVectors.entrySet()) { if (entry.getKey().equals(targetUserId)) continue; double sim = cosineSimilarity(targetVector, entry.getValue()); if (sim > 0) { similarityMap.put(entry.getKey(), sim); } } // 3. 按相似度倒序取 TopN return similarityMap.entrySet().stream() .sorted(Map.Entry.<Long, Double>comparingByValue().reversed()) .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); } private double cosineSimilarity(Map<Long, Double> v1, Map<Long, Double> v2) { double dot = 0, norm1 = 0, norm2 = 0; for (Map.Entry<Long, Double> e : v1.entrySet()) { norm1 += e.getValue() * e.getValue(); Double other = v2.get(e.getKey()); if (other != null) { dot += e.getValue() * other; } } for (Double val : v2.values()) { norm2 += val * val; } if (norm1 == 0 || norm2 == 0) return 0; return dot / (Math.sqrt(norm1) * Math.sqrt(norm2)); } private Map<Long, Map<Long, Double>> buildUserVectors() { // 行为权重：点击=1，收藏=3，分享=5，停留时长每30秒加1 List<UserBehavior> behaviors = behaviorMapper.selectList(null); Map<Long, Map<Long, Double>> vectors = new HashMap<>(); for (UserBehavior b : behaviors) { double score = switch (b.getBehaviorType()) { case 1 -> 1.0; case 2 -> 3.0; case 3 -> 5.0; default -> 0.5; }; score += b.getStayDuration() / 30.0; vectors.computeIfAbsent(b.getUserId(), k -> new HashMap<>()) .merge(b.getNewsId(), score, Double::sum); } return vectors; } }

buildUserVectors里给不同行为赋了不同权重，收藏和分享的权重远高于点击，停留时长每 30 秒折算 1 分。这个权重表不是拍脑袋，是多次调参后比较合理的起点。cosineSimilarity用余弦相似度而不是欧氏距离，因为用户行为向量维度高且稀疏，余弦对绝对数值不敏感。topN一般取 10 到 20，太小推荐多样性差，太大引入噪声。

4.2 内容标签召回作为冷启动兜底

新用户没有行为数据，协同过滤直接失效。这时候用内容标签召回：从user.interest_tags和news.tags做匹配，按标签重合度打分。

public List<Long> recommendByTags(Long userId, int topN) { User user = userMapper.selectById(userId); if (user == null || user.getInterestTags() == null) { // 完全冷启动：返回热门新闻 return newsMapper.selectHotNews(topN); } Set<String> userTags = Arrays.stream(user.getInterestTags().split(",")) .map(String::trim).collect(Collectors.toSet()); List<News> candidates = newsMapper.selectRecentNews(7); // 近7天新闻 return candidates.stream() .map(news -> { Set<String> newsTags = Arrays.stream(news.getTags().split(",")) .map(String::trim).collect(Collectors.toSet()); long overlap = newsTags.stream().filter(userTags::contains).count(); // 标签重合数 * 2 + 热度分，热度分用点击量对数 double score = overlap * 2 + Math.log1p(news.getClickCount()); return new AbstractMap.SimpleEntry<>(news.getId(), score); }) .sorted(Map.Entry.<Long, Double>comparingByValue().reversed()) .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); }

selectRecentNews(7)只取近 7 天新闻，避免推荐过时内容。Math.log1p(news.getClickCount())用对数平滑点击量，防止一篇爆款新闻霸占所有推荐位。标签重合度乘以 2 是经验权重，你可以根据论文里的对比实验调整。这个方法的优点是解释性强，论文里写“基于内容的召回”很容易说清楚。

4.3 离线计算与在线查询的衔接

推荐结果不要每次请求都实时算，那样响应时间不可控。我一般用 Quartz 定时任务，每天凌晨 2 点跑一次全量推荐，把结果写入recommend_result表。在线接口只做一件事：查表取 TopN。

@Component public class RecommendJob { @Autowired private UserCFRecommender userCFRecommender; @Autowired private RecommendResultMapper resultMapper; @Scheduled(cron = "0 0 2 * * ?") public void generateDailyRecommend() { List<Long> userIds = userMapper.selectAllUserIds(); for (Long userId : userIds) { List<Long> similarUsers = userCFRecommender.findSimilarUsers(userId, 20); Map<Long, Double> newsScores = new HashMap<>(); for (Long similarUserId : similarUsers) { // 取相似用户最近的行为，加权累加到目标用户的候选新闻上 List<UserBehavior> behaviors = behaviorMapper .selectRecentByUserId(similarUserId, 50); for (UserBehavior b : behaviors) { newsScores.merge(b.getNewsId(), 1.0, Double::sum); } } // 写入推荐结果表，先删旧数据再批量插入 resultMapper.deleteByUserId(userId); newsScores.entrySet().stream() .sorted(Map.Entry.<Long, Double>comparingByValue().reversed()) .limit(50) .forEach(e -> resultMapper.insert( new RecommendResult(userId, e.getKey(), e.getValue(), "cf"))); } } }

cron = "0 0 2 * * ?"表示每天凌晨 2 点执行。deleteByUserId先清旧推荐再插新推荐，避免结果表无限膨胀。在线接口GET /api/recommend/{userId}直接select * from recommend_result where user_id=? order by score desc limit 10，响应时间在 10 毫秒以内。如果你数据量小，也可以把推荐结果缓存到 Redis，进一步降低数据库压力。

5. 避坑与排查：新闻推荐系统落地时最容易翻车的五个点

5.1 现象：推荐结果全是同一类新闻，用户反馈“看腻了”

原因：协同过滤只按相似度加权，没有做多样性控制，热门类别的新闻得分天然高，导致推荐列表被某一类垄断。解决：在最终排序前加一个类别打散逻辑，同一个category最多出现 3 条。具体做法是在写入recommend_result前，按类别计数，超过阈值的新闻降权或跳过。

5.2 现象：新用户登录后推荐列表为空

原因：user_behavior表里没有该用户记录，UserCF 返回空列表，而代码没有做冷启动兜底。解决：在推荐接口里判断，如果协同过滤结果为空，自动降级到内容标签召回或热门新闻。热门新闻查询用select * from news order by click_count desc limit 10，但记得加时间范围，比如近 3 天，否则会推荐几个月前的旧闻。

5.3 现象：Redis 缓存推荐结果后，用户行为更新了但推荐没变

原因：缓存没有设置合理的过期时间，或者更新行为后没有主动删除缓存。解决：推荐结果缓存过期时间设 1 小时，并且在行为上报接口里，如果行为类型是收藏或分享，主动删除该用户的推荐缓存 key。不要用keys *批量删，用delete("rec:user:" + userId)精确删除。

5.4 现象：论文里的实验数据对不上，准确率忽高忽低

原因：训练集和测试集划分时没有按时间切分，而是随机切分，导致未来行为泄露到训练集。解决：按create_time排序，前 80% 作为训练集，后 20% 作为测试集。推荐系统的评估指标用 Precision@K、Recall@K 和覆盖率，不要只用准确率，因为推荐场景下负样本远多于正样本。

5.5 现象：SpringBoot 启动时报Table 'news_recommend.user' doesn't exist

原因：MySQL 区分大小写，建表时用了反引号`user`，但 MyBatis-Plus 默认把实体类User映射成表名user，在某些 Linux 环境下表名大小写敏感导致找不到。解决：在application.yml里加mybatis-plus.global-config.db-config.table-underline: true，并且建表时统一用小写表名。如果已经建了大写表，用RENAME TABLE改成小写。

6. 论文写作与源码交付：把工程细节转成学术表达的三个技巧

6.1 论文框架怎么搭才不像实验报告

热搜里“论文框架怎么搭”出现频率很高。新闻推荐系统的论文，我一般按这个结构写：第一章绪论讲研究背景和国内外现状，第二章相关技术介绍 SpringBoot、协同过滤、Redis，第三章需求分析，第四章系统设计（架构图、表结构、推荐流程），第五章系统实现（关键代码和界面截图），第六章系统测试与推荐效果评估，第七章总结与展望。注意第二章不要抄百科，要写“为什么选 SpringBoot 而不是 SSM”“为什么用 UserCF 而不是 ItemCF”，把选型理由写进去，答辩时老师最常问的就是这个。

6.2 推荐效果评估怎么写才有说服力

不要只写“系统运行良好”。用表格对比 UserCF、ItemCF 和热门推荐三种策略的 Precision@10、Recall@10 和覆盖率。下面是我常用的评估表模板，数据来自你实际跑出来的结果。

覆盖率 = 推荐结果中不同新闻数 / 新闻总数。混合推荐就是把协同过滤和内容标签召回的结果按 7:3 加权融合。这张表能让你的论文从“做了个系统”变成“做了个有对比实验的系统”。

6.3 源码打包与运行说明的注意事项

交付源码时，.7z包里不要放target目录和.idea文件夹，体积能小一半。README.md里写清楚三件事：JDK 版本、MySQL 版本、Redis 是否必须启动。如果 Redis 不是必须的，在代码里加一个开关recommend.cache.enabled=false，让没装 Redis 的老师也能跑起来。数据库脚本单独放一个sql文件夹，建表语句和初始数据分开，初始数据里至少放 50 条新闻和 10 个用户，否则推荐算法跑不出结果。

我自己的习惯是，每次交付前在一台干净电脑上按 README 从头跑一遍，把遇到的报错记下来补进文档。这个习惯帮我省掉了无数次“在我电脑上能跑”的尴尬。希望帮到你。

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