简介本资源是一套完整的基于Spring Boot与Vue的新闻推荐系统毕业设计项目面向计算机专业本科生及Java全栈初学者解决新闻内容个性化分发与用户兴趣建模的实际问题适用于课程设计、毕设开发与技术实践。压缩包共748个文件涵盖90个Java后端核心类、38个Vue前端组件、153个JavaScript交互逻辑、44个CSS样式文件、79个GIF动效资源及162个SVG图标辅以SQL建库脚本、YML配置、BAT启动批处理等工程化文件整体大小为15.15MB。资源包含从需求分析、数据库设计含实体关系与12张表结构、管理员与用户双模块功能实现含新闻管理、收藏、排行榜、首页推荐等到系统测试全流程的详细论文共22页目录层级清晰代码与文档严格对应便于理解推荐逻辑落地与前后端协同机制。 做毕业设计选型的同学大概率都见过这个标题“基于Spring Boot的新闻推荐系统设计与实现”后面往往还跟着“.7z源码论文”。这类项目在各大资源站非常常见但很多人下载之后发现要么缺数据库脚本要么论文和代码对不上要么本地根本启动不起来。我前前后后帮人看过、改过、重新搭过好几套类似的系统今天这篇就把整个项目从架构设计、算法实现到论文组织一次讲透你拿去无论是自己复现、二次开发还是应付毕业答辩应该都能省下不少力气。先说这个项目到底是干什么的。它本质上是一个带推荐功能的新闻内容平台用户能注册登录、浏览新闻、搜索内容同时系统会根据用户的历史行为点击、收藏、点赞等自动计算并推送用户可能感兴趣的新闻。它和普通新闻网站最大的区别不在内容管理而在后台那套推荐逻辑——这也是论文的核心亮点没有这个推荐模块整个系统就是一套普通的CRUD答辩时根本撑不起场面。适合谁看两类人一类是正在选毕设题目、准备复现类似项目的在校学生另一类是刚接触Spring Boot整合推荐算法、想搞清楚“推荐到底怎么落地到Web系统”的初学者。我会把技术选型、推荐算法实现、数据库设计、论文章节安排以及那些资源包里头绝不告诉你的坑全部摊开来讲。1. 项目整体思路拆解新闻推荐和普通商品推荐有什么不一样1.1 核心需求分析新闻推荐系统要处理的核心问题有三个用户想看什么、新闻怎么推荐合适、推荐结果怎么跟上用户兴趣的变化。很多初学者第一反应是照搬电商推荐系统直接上协同过滤结果做出来的东西体验很差。原因在于新闻这种内容形态有三个非常明显的特性时效性极强、用户兴趣漂移快、冷启动问题特别突出。一条新闻的生命周期可能只有几个小时到几天今天的热点明天就没人看了。所以算法上不能只按历史行为推必须把时间衰减因子加进去。同时用户今天关注科技明天可能因为一条娱乐热搜就点进去看了半天如果系统还在拼命推昨天的科技新闻用户大概率会流失。这意味着推荐模块需要同时处理静态偏好长期兴趣和动态兴趣短期点击行为。这个项目如果用最简单的方式落地功能上应该包含用户模块注册、登录、个人信息、新闻模块分类展示、新闻详情、搜索、行为采集模块记录用户对新闻的点击、收藏、点赞、评论、推荐模块基于内容的推荐、基于用户的协同过滤、热门推荐兜底、以及后台管理模块新闻发布、分类管理、用户管理。1.2 技术栈为什么是“Spring Boot 轻量级算法”很多同学会问新闻推荐系统是不是得上大数据平台、Spark、TensorFlow这些我明确说本科毕设和中小型项目完全没有必要。推荐算法本身的计算逻辑用Java完全能写数据量在万级、十万级的时候单机MySQL加Redis缓存完全扛得住。Spring Boot在这套系统里的角色是核心后端框架它解决了大部分繁琐的配置问题。传统的SSH或SSM框架要做大量XML配置而Spring Boot通过自动配置和起步依赖基本能做到零XML跑通一个Web项目。对于毕设来说这能让你把精力集中在推荐算法本身和系统逻辑上而不是浪费在环境配置和框架调试上。具体技术选型我很推荐这一套组合组件选型说明后端框架Spring Boot 2.7.x稳定、资料多、兼容性好不要上来就追3.4.xORMMyBatis-Plus单表CRUD不用写SQL推荐结果落库很方便数据库MySQL 5.7或8.0存用户、新闻、行为记录缓存Redis存热门新闻、推荐列表减少重复计算前端Vue 2 / 普通HTMLThymeleaf前妻分离不是必须的看时间安排分词HanLP或Jieba做基于内容推荐时的中文分词算法内容相似度 用户协同过滤 热度加权混合推荐策略这套组合的好处是每一层都有成熟生态出了问题网上随便搜都有答案。Spring Boot负责接口和业务编排MySQL落数据Redis解决缓存和性能问题算法部分在Service层用Java实现不引入额外重量级中间件逻辑直白论文里也容易解释清楚。2. 推荐算法怎么落地三种核心策略和一段能跑通的Java逻辑2.1 算法选型为什么优先做“基于内容推荐”新闻推荐最常用的算法有三种基于内容的推荐Content-based、基于用户的协同过滤User-based CF、基于物品的协同过滤Item-based CF。对于新闻场景我建议优先做基于内容的推荐。原因特别简单新闻物品更新太快协同过滤基于“谁和谁看了同样的东西”来推荐如果用户行为数据稀疏协同过滤效果会很差。而基于内容的推荐不依赖其他用户的行为只需要分析用户自己看过的新闻内容特征然后用相似度找新新闻天然适合新闻这种高实时性的内容。基于内容的推荐流程拆解下来是这几个步骤对用户浏览过的新闻做分词和关键词提取形成用户的兴趣特征向量然后对所有候选新闻做同样的内容分析再计算用户兴趣向量和新闻向量的相似度按得分排序取TopN。分词这一步很有讲究。中文文本不像英文天然用空格分词必须用工具处理。我测试过HanLP和Jieba的Java版本HanLP在新闻领域的分词准确率更高而且支持自定义词库可以把“新冠疫情”“新能源汽车”这类专有名词加进去避免被拆开。2.2 基于内容的推荐实现分词 → TF-IDF → 余弦相似度这块是整个推荐模块最核心的代码我给出一个可以跑通的最小实现思路。先用HanLP对新闻标题和正文做分词再提取关键词计算TF-IDF权重最后用余弦相似度做匹配。新闻实体类可以简化定义为id、title、content、categoryId、publishTime、keywords。后面存的时候可以把keywords字段单独存一份避免推荐时每次都要重新分词。核心的相似度计算逻辑是这样的// 计算两个文本向量的余弦相似度 public double cosineSimilarity(MapString, Double userVector, MapString, Double newsVector) { // 取两个向量键的并集 SetString unionKeys new HashSet(userVector.keySet()); unionKeys.addAll(newsVector.keySet()); double dotProduct 0.0; double userNorm 0.0; double newsNorm 0.0; for (String key : unionKeys) { double userWeight userVector.getOrDefault(key, 0.0); double newsWeight newsVector.getOrDefault(key, 0.0); dotProduct userWeight * newsWeight; userNorm userWeight * userWeight; newsNorm newsWeight * newsWeight; } if (userNorm 0 || newsNorm 0) { return 0.0; } return dotProduct / (Math.sqrt(userNorm) * Math.sqrt(newsNorm)); }实际项目中用户兴趣向量怎么构建最简单的一种做法取用户最近浏览/收藏的N篇新闻比如20篇每篇新闻的关键词权重做归一化然后累加生成一个用户主题向量。关键词权重可以通过一个工具类从新闻文本中提取。public MapString, Double extractKeywords(String text, int topN) { // 调用HanLP提取关键词 ListString keywordList HanLP.extractKeyword(text, topN); MapString, Double weightMap new HashMap(); for (String keyword : keywordList) { weightMap.merge(keyword, 1.0, Double::sum); } return weightMap; }然后推荐Service层做的事情就是拿到用户的兴趣向量遍历候选新闻集合可以按分类过滤计算相似度排序后取前20条返回。这一步听起来简单但性能上需要注意如果新闻表有几十万条记录每次遍历全部新闻肯定扛不住。工程上一定要做降维先按照用户感兴趣的分类过滤再加上时间范围限制比如只推最近7天发布的新闻候选集从几十万降到几千条内存计算就很轻松了。2.3 协同过滤什么时候用、怎么落到代码里基于内容的推荐有个明显的缺陷就是推荐结果“太像了”。用户看了苹果的新闻系统只会推更多苹果相关的内容容易造成信息茧房。这时候协同过滤的价值就出来了它通过找“和你兴趣习惯相似的其他用户”把他们看过而你没看过的新闻推荐给你能有效扩展推荐的多样性。User-based CF在这个项目里可以这么实现维护一张用户行为表userId, newsId, actionType, createTime当某个用户的浏览记录足够多时定期计算用户之间的相似度把最相似的K个用户比如10个浏览过且当前用户没看过的新闻提取出来按热度或行为次数排序推荐。相似度的计算这里用杰卡德相似系数比较直观用户A和用户B的相似度 两人共同看过的新闻数 / 两人看过新闻的并集数。public double jaccardSimilarity(ListLong userAItems, ListLong userBItems) { SetLong setA new HashSet(userAItems); SetLong setB new HashSet(userBItems); SetLong union new HashSet(setA); union.addAll(setB); if (union.isEmpty()) { return 0.0; } int intersectionSize 0; for (Long item : setA) { if (setB.contains(item)) { intersectionSize; } } return (double) intersectionSize / union.size(); }但这里我必须提醒你协同过滤在毕设项目中容易踩一个逻辑陷阱。如果用户量少、行为数据稀疏算出来的相似用户根本没意义。所以这个模块适合作为辅助推荐策略不是主力。在论文里描述成“混合推荐策略以基于内容推荐为主协同过滤作为补充解决内容推荐多样性不足的问题”这个表述在答辩时非常加分。2.4 冷启动问题新用户和新新闻怎么推荐冷启动是推荐系统永远绕不开的问题。所谓冷启动说白了就是系统对新用户、新物品一无所知没有历史数据可以依赖。两个场景要分开处理新用户冷启动用户刚注册没有任何浏览记录。这时候最简单的方案就是按分类热度推送。统计每个分类下近24小时浏览/点赞量最高的新闻排序默认给用户展示全站热门。用户一旦产生点击行为行为采集模块马上记录下来下次推荐就可以开始计算用户画像了。理论上行为数据越多推荐效果越准这是可以做渐进式优化的点论文里写“基于实时行为反馈的兴趣冷启动策略”会显得研究深度更足。新新闻冷启动刚发布的新闻没有用户行为数据内容和推荐模块要配合。新闻入库后立即做分词和关键词提取写入关键词字段这样基于内容的推荐就能立刻把它推给相关兴趣的用户。同时赋予新发布新闻一个时间权重加成比如得分乘以一个衰减系数让新内容有机会冲进推荐列表避免新新闻长期被热门旧新闻压制。// 时效性加权发布时间越近得分越高 double timeFactor computeTimeDecay(news.getPublishTime()); double finalScore contentScore * 0.7 hotScore * 0.1 timeFactor * 0.2;这个得分公式是混合推荐的核心思想。contentScore是内容相似度hotScore是新闻热度基于浏览量、点赞量计算timeFactor是时效性因子。三者的加权比例可以根据实际情况调整我最初用的是0.5 / 0.2 / 0.3后面调成0.7 / 0.1 / 0.2发现内容相关性更强之后点击率更好看。这个调参过程写进论文比堆一堆公式更让人信服。2.5 新闻热度计算避免推荐列表变成“一潭死水”新闻热度计算看似简单但要注意时间衰减。如果直接用总浏览量排序那老新闻永远压在头部新内容很难出来。一个可用的热度分公式是hotScore (viewCount * 1.0 likeCount * 3.0 favoriteCount * 5.0 commentCount * 4.0) / pow((hoursSincePublish 2), 1.5)这个公式的曲线可以用Excel先模拟一遍。当新闻发布后第1小时热度分被放大24小时后热度衰减明显7天后的新闻基本自然退出热门榜单。这种策略模拟了真实新闻场景中“热点发酵-爆发-冷却”的完整生命周期。我第一次调参时没加时间衰减结果推荐页连续一周被同一条老新闻霸榜后来加上衰减因子才正常。3. Spring Boot工程结构与核心实现3.1 工程目录怎么分布别把所有代码塞进Controller下载过网上那些资源包的同学都知道很多源码质量一言难尽统一把业务逻辑写在Controller里一个Controller七八千行看着就头皮发麻。一个正确的Spring Boot项目结构应该是分层的。建议按功能模块分包而不是按技术层分包对于这种中小型系统更好维护。com.example.news ├── controller // 接口层只负责接收参数和返回结果 │ ├── UserController.java │ ├── NewsController.java │ ├── RecommendController.java │ └── AdminController.java ├── service // 业务层推荐算法、用户逻辑都在这里 │ ├── RecommendService.java │ ├── UserService.java │ ├── NewsService.java │ └── BehaviorService.java ├── mapper // 数据层MyBatis-Plus的Mapper接口 │ ├── UserMapper.java │ ├── NewsMapper.java │ └── BehaviorMapper.java ├── entity // 实体类对应数据库表 ├── dto // 数据传输对象接口入参和出参 ├── config // 配置类 └── common // 统一结果封装、异常处理、工具类Controller层只做参数校验和Result封装推荐算法全部下沉到Service层这样单元测试也好写。论文里画分层架构图的时候这个结构也更能体现工程化能力。3.2 行为采集模块推荐系统的“眼睛”这个模块是整个系统里面最容易被忽略、但最要命的部分。很多同学把精力放在推荐算法上却没好好设计行为数据采集结果算法写得再好也是无米之炊。用户行为数据至少包含userId、newsId、behaviorType、createTime。behaviorType我用的是枚举值1-浏览2-点赞3-收藏4-评论。每次用户点击或操作新闻时前端通过Ajax异步请求后端的行为记录接口不影响正常的页面跳转体验。这个接口用Spring Boot写非常简单PostMapping(/behavior) ApiOperation(记录用户行为) public ResultVoid recordBehavior(RequestBody BehaviorDTO behaviorDTO, RequestAttribute Long userId) { behaviorService.recordBehavior(userId, behaviorDTO.getNewsId(), behaviorDTO.getBehaviorType()); return Result.success(); }BehaviorService里要注意的是同一条新闻短时间内重复浏览的处理。用户可能因为手抖或刷新页面连续点了多条记录这些脏数据会污染推荐算法的输入所以要对同一用户同一新闻的相同行为做去重或时间窗口限制比如5分钟内的重复浏览只算一次。3.3 推荐结果的缓存策略Redis在这里不是摆设推荐算法如果是实时计算每次请求接口都要做分词、相关性计算、排序效率低得惊人。实际项目中一定要加缓存。我的思路是第一层缓存推荐结果按userId存Rediskey设计为recommend:{userId}:{page}过期时间20分钟。第二层兜底用户第一次请求或者缓存过期时同步计算推荐结果然后异步写入缓存。对于非登录用户游客不用算个性化推荐直接从Redis取热门榜key为news:hot:recent7这个缓存数据每10分钟更新一次。spring: redis: host: localhost port: 6379 password: timeout: 3000ms lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0Redis操作代码建议用RedisTemplate封装StringRedisTemplate序列化器用String序列化value直接存JSON字符串方便Debug。千万别用JDK默认序列化器存进去的二进制数据在可视化工具里看着就是天书排查问题极为痛苦。3.4 数据库表设计核心是“用户-新闻-行为”三张王牌数据库表设计是系统设计的基石。我推荐至少设计以下6张表表名关键字段用途userid, username, password, create_time用户信息newsid, title, content, category_id, keywords, publish_time新闻内容categoryid, name新闻分类behaviorid, user_id, news_id, behavior_type, create_time用户行为记录user_similarityid, user_id, similar_user_id, similarity用户相似度计算结果adminid, username, password管理端账号behavior表要重点关注它是推荐系统的数据来源。查询频率极高必须加上联合索引(user_id, create_time)和单列索引(news_id)。数据量大之后建议按时间定期归档保留最近3个月的行为数据用于推荐计算历史冷数据可以备份后清理否则表越来越大查询性能会明显下降。user_similarity表是协同过滤的优化点把用户相似度预先算好落到表里避免每次推荐都在线计算大规模的相似度矩阵。这个定期计算定时任务的思路论文里描述成“离线计算相似度矩阵、在线快速召回推荐”的混合架构专业感立刻上来一个档次。4. 论文怎么写从开题到答辩的完整章节脉络4.1 为什么系统设计要跟着论文章节走很多人做毕设是先写完代码再写论文顺序颠倒导致论文写得极其空洞。我建议拿到这个题目之后先通过论文结构来反推你要做的事这样每一项工作都能在论文里找到对应章节写的时候非常顺。本质上这是“以终为始”的思路先想清楚评审老师想看到什么再决定系统怎么做。论文结构可以按这个框架来搭第一章绪论研究背景与意义国内外研究现状主要工作内容。 第二章相关技术介绍Spring Boot框架、MyBatis-Plus、MySQL、Redis、推荐算法概述。 第三章系统需求分析可行性分析功能需求分析非功能需求分析用例图、业务流程。 第四章系统设计总体架构设计功能模块设计数据库设计E-R图、数据表结构推荐算法设计。 第五章系统实现给出每个核心模块的前后端效果截图和核心代码片段重点展示推荐模块的实现过程。 第六章系统测试功能测试用例表格、性能测试结果、推荐效果评估体验式评测或离线指标。4.2 需求分析和特色设计怎么写需求分析这部分最容易写成流水账。常规的“用户可以注册登录、管理员可以管理新闻”这种表述既没有难点也没有亮点。要往系统特色去深挖推荐写这几点一是用户画像的动态构建强调系统能基于行为变化实时调整推荐策略二是新新闻的内容时效性加权说明这是新闻领域区别于普通内容系统的关键特征三是混合推荐策略解释为什么单靠一种算法无法满足推荐效果的需求。4.3 推荐效果评估用一个表格证明你的系统真“有用”这是论文和答辩中最容易被提问的环节。你光说“系统能推荐新闻”没用评委会问“你怎么证明你的推荐效果好”。本科毕设通常不要求做完整的大规模离线评测但至少要有对比实验。推荐效果对比可以用一个简单表格来呈现推荐策略测试用户数点击率平均浏览时长纯热门推荐5018.6%42秒基于内容推荐5025.2%58秒混合推荐5031.4%76秒测试方法是找10-20个同学每人使用不同推荐策略各一周统计行为数据。这个样本量虽然不算大但在毕设阶段足够说明问题。把表格放进论文第六章再补一段测试环境说明评委会觉得你的工作完整度高有说服力。5. 从零复现这个项目实操步骤和避坑指南5.1 环境准备与版本选择复现第一步先确认环境版本一致。Java要求JDK 1.8或11Maven要求3.6以上IDEA随便一个版本都行。Spring Boot版本我推荐用2.7.18这个版本资料全、生态稳、和MyBatis-Plus的兼容性最好。现在很多人启动失败就是死在版本上。比如Spring Boot 3.x默认使用Jakarta EE命名空间把javax改成jakarta很多老教程的依赖和代码复制过来直接编译报错。网上资源包里的源码大部分基于Spring Boot 2.x如果你非要用3.x跑光是改包名就够折腾一阵子。毕设项目求稳为上不要为了“用新版本”给自己挖坑。创建项目的方式IDEA内置Spring Initializr、start.spring.io官网、阿里云镜像三选一。国内用阿里云镜像最稳start.aliyun.com生成速度快不会卡在下载。依赖选择Spring Web、MyBatis-Plus手动引入、MySQL Driver、Redis、Lombok、Spring Boot DevTools。5.2 核心配置文件的完整参考application.yml是Spring Boot的“总指挥”我贴一份可以直接参考的配置server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/news_recommend?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这里有一个高频踩坑点数据库url必须带serverTimezoneAsia/Shanghai否则MySQL 8连接时会报时间时区错误。map-underscore-to-camel-case这个配置也很重要开了之后数据库字段user_name能自动映射到实体类的userName属性否则MyBatis查出来全是null怎么查都查不出来。5.3 跑通一个最小闭环注册 → 登录 → 浏览 → 推荐第一次复现建议先跑通最小闭环再逐步添加功能。具体步骤可以这样操作第一步新建数据库news_recommend执行项目里的sql脚本确认6张表都建好。如果资源包里没有sql脚本就反射看实体类自己建表这种情况很常见下载的源码经常漏脚本。第二步改配置文件的数据库用户名密码启动项目后台日志不报错并能看到Tomcat started on port 8080。第三步用Postman或前端页面注册一个测试账号调用注册接口数据库user表出现新记录。第四步正常浏览十篇左右新闻行为表behavior出现对应的浏览记录。第五步调用推荐接口/recommend/list如果返回值不是你浏览过的那几篇而是相关的其他新闻说明推荐链路已经通了一小半如果返回了一堆无关新闻检查关键词提取和相似度计算逻辑里有没有bug或空值问题。5.4 前端调用和后端联调跨域问题处理很多毕设采用前后端分离Vue跑在8081端口Spring Boot跑在8080端口联调时第一个吃到的异常就是跨域。浏览器控制台报的错通常是Access-Control-Allow-Origin解决办法是后端写一个CorsConfig配置类。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有个细节allowCredentials(true)之后allowedOrigins不能用而是用allowedOriginPatterns()否则部分浏览器还是会报跨域错误。我最初就是卡在这个点上前端明明发了请求后端也没报错但浏览器就是拦着不放行。5.5 管理端功能怎么补管理端是新闻系统的基础设施涵盖新闻发布、分类维护、用户管理等。这个模块本身没有技术难点但在Spring Boot里值得强调一点权限控制。即便不做Spring Security这种重量级框架也应该用拦截器做管理员身份校验。写一个AdminInterceptor实现HandlerInterceptor接口在preHandle方法里判断session里是否有adminId没有就重定向到登录页。否则任何用户都能直接访问/admin/news/add接口发布新闻答辩演示的时候如果被问到这一点非常被动。6. 我踩过的坑和经验教训6.1 Maven依赖下载慢或失败国内Maven默认中央仓库慢到让人崩溃第一件事就是改阿里云镜像。在~/.m2/settings.xml里加镜像配置。很多资源包自带的pom.xml里可能有老版本的依赖冲突比如mybatis-plus-boot-starter和spring-boot-starter-parent版本不兼容启动时报创建Bean失败优先检查这几个核心依赖版本是否都兼容。6.2 推荐列表为空或一直返回同一批新闻推荐列表为空主要查三种情况用户没有任何行为数据本身就走热门推荐逻辑但热门数据没生成候选新闻时间范围过滤太严格比如只查最近2天的新闻但测试数据都是一个月以前的Redis里缓存的空值没有被及时清理接口一直返回缓存中的空列表。我当初就犯过第三种错用Redis缓存空列表并且设置了过期时间但每次请求都会刷新过期时间导致空结果一直存在用户无论怎么访问都是空。后来改成在写入缓存之前判断集合是否为空空集合不做缓存问题才消失。6.3 MyBatis-Plus分页插件配置如果在新闻列表里用MyBatis-Plus自带的分页查询一定要配置分页插件否则分页不生效直接查出全表数据。配置方式是在Spring Boot启动类上注册MybatisPlusInterceptor。Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }有很多资源包的源码里没有这一行你照着写就会发现分页参数Page的current和size完全不生效查出来的永远是全表。这也是排在前几的高频问题。6.4 分词处理在Spring Boot里的性能问题如果每次推荐都在请求线程里同步分词接口响应会非常慢。我测试过一条新闻的标题加正文分词大概需要40-100毫秒如果有200篇候选新闻一次推荐请求就要算好几秒体验极差。解决方式有两个新闻发布的时候就把分词结果和关键词存进数据库推荐时直接读取不用动态分词用户兴趣向量可以定期异步构建比如每分钟批量处理一次而不是每次请求实时计算。6.5 关于“源码论文”资源包的一个忠告最后说点掏心窝的话。这类网上下载的“源码论文”资源包平均水平真的参差不齐。很多论文写的时间早里面的技术版本还是JSP、Struts2代码则被人为改成了Spring Boot导致两者压根对不上。你如果真打算用它务必先做一件事跑通最小闭环然后自己亲自把推荐模块的每一行代码读一遍搞清楚相似度计算、热度排序的每个变量是什么意思。答辩的时候老师最喜欢问的问题就是“这里为什么这样写”“这段代码的作用是什么”你如果答不上来场面会非常尴尬。我的体会是这套“Spring Boot 轻量级推荐算法”的毕设方案根本没必要完全依赖网上的资源包你完全可以自己动手搭一个难度并没有想象中高。核心算法部分掌握2.2节那套余弦相似度代码就够了难点主要在于数据怎么收集、候选集合怎么降维、缓存怎么设计。把这些工程细节想清楚系统自然就比大多数网上的模板项目扎实得多。如果时间紧张要直接参考别人的项目也要把“推荐链路”完整走一遍行为记录进来了、算法算出来了、结果展示出来了、缓存更新了任何一个环节断了都会影响最终的答辩效果。本文还有配套的精品资源点击获取
基于Spring Boot的新闻推荐系统设计与实现：算法落地与工程实践
简介本资源是一套完整的基于Spring Boot与Vue的新闻推荐系统毕业设计项目面向计算机专业本科生及Java全栈初学者解决新闻内容个性化分发与用户兴趣建模的实际问题适用于课程设计、毕设开发与技术实践。压缩包共748个文件涵盖90个Java后端核心类、38个Vue前端组件、153个JavaScript交互逻辑、44个CSS样式文件、79个GIF动效资源及162个SVG图标辅以SQL建库脚本、YML配置、BAT启动批处理等工程化文件整体大小为15.15MB。资源包含从需求分析、数据库设计含实体关系与12张表结构、管理员与用户双模块功能实现含新闻管理、收藏、排行榜、首页推荐等到系统测试全流程的详细论文共22页目录层级清晰代码与文档严格对应便于理解推荐逻辑落地与前后端协同机制。 做毕业设计选型的同学大概率都见过这个标题“基于Spring Boot的新闻推荐系统设计与实现”后面往往还跟着“.7z源码论文”。这类项目在各大资源站非常常见但很多人下载之后发现要么缺数据库脚本要么论文和代码对不上要么本地根本启动不起来。我前前后后帮人看过、改过、重新搭过好几套类似的系统今天这篇就把整个项目从架构设计、算法实现到论文组织一次讲透你拿去无论是自己复现、二次开发还是应付毕业答辩应该都能省下不少力气。先说这个项目到底是干什么的。它本质上是一个带推荐功能的新闻内容平台用户能注册登录、浏览新闻、搜索内容同时系统会根据用户的历史行为点击、收藏、点赞等自动计算并推送用户可能感兴趣的新闻。它和普通新闻网站最大的区别不在内容管理而在后台那套推荐逻辑——这也是论文的核心亮点没有这个推荐模块整个系统就是一套普通的CRUD答辩时根本撑不起场面。适合谁看两类人一类是正在选毕设题目、准备复现类似项目的在校学生另一类是刚接触Spring Boot整合推荐算法、想搞清楚“推荐到底怎么落地到Web系统”的初学者。我会把技术选型、推荐算法实现、数据库设计、论文章节安排以及那些资源包里头绝不告诉你的坑全部摊开来讲。1. 项目整体思路拆解新闻推荐和普通商品推荐有什么不一样1.1 核心需求分析新闻推荐系统要处理的核心问题有三个用户想看什么、新闻怎么推荐合适、推荐结果怎么跟上用户兴趣的变化。很多初学者第一反应是照搬电商推荐系统直接上协同过滤结果做出来的东西体验很差。原因在于新闻这种内容形态有三个非常明显的特性时效性极强、用户兴趣漂移快、冷启动问题特别突出。一条新闻的生命周期可能只有几个小时到几天今天的热点明天就没人看了。所以算法上不能只按历史行为推必须把时间衰减因子加进去。同时用户今天关注科技明天可能因为一条娱乐热搜就点进去看了半天如果系统还在拼命推昨天的科技新闻用户大概率会流失。这意味着推荐模块需要同时处理静态偏好长期兴趣和动态兴趣短期点击行为。这个项目如果用最简单的方式落地功能上应该包含用户模块注册、登录、个人信息、新闻模块分类展示、新闻详情、搜索、行为采集模块记录用户对新闻的点击、收藏、点赞、评论、推荐模块基于内容的推荐、基于用户的协同过滤、热门推荐兜底、以及后台管理模块新闻发布、分类管理、用户管理。1.2 技术栈为什么是“Spring Boot 轻量级算法”很多同学会问新闻推荐系统是不是得上大数据平台、Spark、TensorFlow这些我明确说本科毕设和中小型项目完全没有必要。推荐算法本身的计算逻辑用Java完全能写数据量在万级、十万级的时候单机MySQL加Redis缓存完全扛得住。Spring Boot在这套系统里的角色是核心后端框架它解决了大部分繁琐的配置问题。传统的SSH或SSM框架要做大量XML配置而Spring Boot通过自动配置和起步依赖基本能做到零XML跑通一个Web项目。对于毕设来说这能让你把精力集中在推荐算法本身和系统逻辑上而不是浪费在环境配置和框架调试上。具体技术选型我很推荐这一套组合组件选型说明后端框架Spring Boot 2.7.x稳定、资料多、兼容性好不要上来就追3.4.xORMMyBatis-Plus单表CRUD不用写SQL推荐结果落库很方便数据库MySQL 5.7或8.0存用户、新闻、行为记录缓存Redis存热门新闻、推荐列表减少重复计算前端Vue 2 / 普通HTMLThymeleaf前妻分离不是必须的看时间安排分词HanLP或Jieba做基于内容推荐时的中文分词算法内容相似度 用户协同过滤 热度加权混合推荐策略这套组合的好处是每一层都有成熟生态出了问题网上随便搜都有答案。Spring Boot负责接口和业务编排MySQL落数据Redis解决缓存和性能问题算法部分在Service层用Java实现不引入额外重量级中间件逻辑直白论文里也容易解释清楚。2. 推荐算法怎么落地三种核心策略和一段能跑通的Java逻辑2.1 算法选型为什么优先做“基于内容推荐”新闻推荐最常用的算法有三种基于内容的推荐Content-based、基于用户的协同过滤User-based CF、基于物品的协同过滤Item-based CF。对于新闻场景我建议优先做基于内容的推荐。原因特别简单新闻物品更新太快协同过滤基于“谁和谁看了同样的东西”来推荐如果用户行为数据稀疏协同过滤效果会很差。而基于内容的推荐不依赖其他用户的行为只需要分析用户自己看过的新闻内容特征然后用相似度找新新闻天然适合新闻这种高实时性的内容。基于内容的推荐流程拆解下来是这几个步骤对用户浏览过的新闻做分词和关键词提取形成用户的兴趣特征向量然后对所有候选新闻做同样的内容分析再计算用户兴趣向量和新闻向量的相似度按得分排序取TopN。分词这一步很有讲究。中文文本不像英文天然用空格分词必须用工具处理。我测试过HanLP和Jieba的Java版本HanLP在新闻领域的分词准确率更高而且支持自定义词库可以把“新冠疫情”“新能源汽车”这类专有名词加进去避免被拆开。2.2 基于内容的推荐实现分词 → TF-IDF → 余弦相似度这块是整个推荐模块最核心的代码我给出一个可以跑通的最小实现思路。先用HanLP对新闻标题和正文做分词再提取关键词计算TF-IDF权重最后用余弦相似度做匹配。新闻实体类可以简化定义为id、title、content、categoryId、publishTime、keywords。后面存的时候可以把keywords字段单独存一份避免推荐时每次都要重新分词。核心的相似度计算逻辑是这样的// 计算两个文本向量的余弦相似度 public double cosineSimilarity(MapString, Double userVector, MapString, Double newsVector) { // 取两个向量键的并集 SetString unionKeys new HashSet(userVector.keySet()); unionKeys.addAll(newsVector.keySet()); double dotProduct 0.0; double userNorm 0.0; double newsNorm 0.0; for (String key : unionKeys) { double userWeight userVector.getOrDefault(key, 0.0); double newsWeight newsVector.getOrDefault(key, 0.0); dotProduct userWeight * newsWeight; userNorm userWeight * userWeight; newsNorm newsWeight * newsWeight; } if (userNorm 0 || newsNorm 0) { return 0.0; } return dotProduct / (Math.sqrt(userNorm) * Math.sqrt(newsNorm)); }实际项目中用户兴趣向量怎么构建最简单的一种做法取用户最近浏览/收藏的N篇新闻比如20篇每篇新闻的关键词权重做归一化然后累加生成一个用户主题向量。关键词权重可以通过一个工具类从新闻文本中提取。public MapString, Double extractKeywords(String text, int topN) { // 调用HanLP提取关键词 ListString keywordList HanLP.extractKeyword(text, topN); MapString, Double weightMap new HashMap(); for (String keyword : keywordList) { weightMap.merge(keyword, 1.0, Double::sum); } return weightMap; }然后推荐Service层做的事情就是拿到用户的兴趣向量遍历候选新闻集合可以按分类过滤计算相似度排序后取前20条返回。这一步听起来简单但性能上需要注意如果新闻表有几十万条记录每次遍历全部新闻肯定扛不住。工程上一定要做降维先按照用户感兴趣的分类过滤再加上时间范围限制比如只推最近7天发布的新闻候选集从几十万降到几千条内存计算就很轻松了。2.3 协同过滤什么时候用、怎么落到代码里基于内容的推荐有个明显的缺陷就是推荐结果“太像了”。用户看了苹果的新闻系统只会推更多苹果相关的内容容易造成信息茧房。这时候协同过滤的价值就出来了它通过找“和你兴趣习惯相似的其他用户”把他们看过而你没看过的新闻推荐给你能有效扩展推荐的多样性。User-based CF在这个项目里可以这么实现维护一张用户行为表userId, newsId, actionType, createTime当某个用户的浏览记录足够多时定期计算用户之间的相似度把最相似的K个用户比如10个浏览过且当前用户没看过的新闻提取出来按热度或行为次数排序推荐。相似度的计算这里用杰卡德相似系数比较直观用户A和用户B的相似度 两人共同看过的新闻数 / 两人看过新闻的并集数。public double jaccardSimilarity(ListLong userAItems, ListLong userBItems) { SetLong setA new HashSet(userAItems); SetLong setB new HashSet(userBItems); SetLong union new HashSet(setA); union.addAll(setB); if (union.isEmpty()) { return 0.0; } int intersectionSize 0; for (Long item : setA) { if (setB.contains(item)) { intersectionSize; } } return (double) intersectionSize / union.size(); }但这里我必须提醒你协同过滤在毕设项目中容易踩一个逻辑陷阱。如果用户量少、行为数据稀疏算出来的相似用户根本没意义。所以这个模块适合作为辅助推荐策略不是主力。在论文里描述成“混合推荐策略以基于内容推荐为主协同过滤作为补充解决内容推荐多样性不足的问题”这个表述在答辩时非常加分。2.4 冷启动问题新用户和新新闻怎么推荐冷启动是推荐系统永远绕不开的问题。所谓冷启动说白了就是系统对新用户、新物品一无所知没有历史数据可以依赖。两个场景要分开处理新用户冷启动用户刚注册没有任何浏览记录。这时候最简单的方案就是按分类热度推送。统计每个分类下近24小时浏览/点赞量最高的新闻排序默认给用户展示全站热门。用户一旦产生点击行为行为采集模块马上记录下来下次推荐就可以开始计算用户画像了。理论上行为数据越多推荐效果越准这是可以做渐进式优化的点论文里写“基于实时行为反馈的兴趣冷启动策略”会显得研究深度更足。新新闻冷启动刚发布的新闻没有用户行为数据内容和推荐模块要配合。新闻入库后立即做分词和关键词提取写入关键词字段这样基于内容的推荐就能立刻把它推给相关兴趣的用户。同时赋予新发布新闻一个时间权重加成比如得分乘以一个衰减系数让新内容有机会冲进推荐列表避免新新闻长期被热门旧新闻压制。// 时效性加权发布时间越近得分越高 double timeFactor computeTimeDecay(news.getPublishTime()); double finalScore contentScore * 0.7 hotScore * 0.1 timeFactor * 0.2;这个得分公式是混合推荐的核心思想。contentScore是内容相似度hotScore是新闻热度基于浏览量、点赞量计算timeFactor是时效性因子。三者的加权比例可以根据实际情况调整我最初用的是0.5 / 0.2 / 0.3后面调成0.7 / 0.1 / 0.2发现内容相关性更强之后点击率更好看。这个调参过程写进论文比堆一堆公式更让人信服。2.5 新闻热度计算避免推荐列表变成“一潭死水”新闻热度计算看似简单但要注意时间衰减。如果直接用总浏览量排序那老新闻永远压在头部新内容很难出来。一个可用的热度分公式是hotScore (viewCount * 1.0 likeCount * 3.0 favoriteCount * 5.0 commentCount * 4.0) / pow((hoursSincePublish 2), 1.5)这个公式的曲线可以用Excel先模拟一遍。当新闻发布后第1小时热度分被放大24小时后热度衰减明显7天后的新闻基本自然退出热门榜单。这种策略模拟了真实新闻场景中“热点发酵-爆发-冷却”的完整生命周期。我第一次调参时没加时间衰减结果推荐页连续一周被同一条老新闻霸榜后来加上衰减因子才正常。3. Spring Boot工程结构与核心实现3.1 工程目录怎么分布别把所有代码塞进Controller下载过网上那些资源包的同学都知道很多源码质量一言难尽统一把业务逻辑写在Controller里一个Controller七八千行看着就头皮发麻。一个正确的Spring Boot项目结构应该是分层的。建议按功能模块分包而不是按技术层分包对于这种中小型系统更好维护。com.example.news ├── controller // 接口层只负责接收参数和返回结果 │ ├── UserController.java │ ├── NewsController.java │ ├── RecommendController.java │ └── AdminController.java ├── service // 业务层推荐算法、用户逻辑都在这里 │ ├── RecommendService.java │ ├── UserService.java │ ├── NewsService.java │ └── BehaviorService.java ├── mapper // 数据层MyBatis-Plus的Mapper接口 │ ├── UserMapper.java │ ├── NewsMapper.java │ └── BehaviorMapper.java ├── entity // 实体类对应数据库表 ├── dto // 数据传输对象接口入参和出参 ├── config // 配置类 └── common // 统一结果封装、异常处理、工具类Controller层只做参数校验和Result封装推荐算法全部下沉到Service层这样单元测试也好写。论文里画分层架构图的时候这个结构也更能体现工程化能力。3.2 行为采集模块推荐系统的“眼睛”这个模块是整个系统里面最容易被忽略、但最要命的部分。很多同学把精力放在推荐算法上却没好好设计行为数据采集结果算法写得再好也是无米之炊。用户行为数据至少包含userId、newsId、behaviorType、createTime。behaviorType我用的是枚举值1-浏览2-点赞3-收藏4-评论。每次用户点击或操作新闻时前端通过Ajax异步请求后端的行为记录接口不影响正常的页面跳转体验。这个接口用Spring Boot写非常简单PostMapping(/behavior) ApiOperation(记录用户行为) public ResultVoid recordBehavior(RequestBody BehaviorDTO behaviorDTO, RequestAttribute Long userId) { behaviorService.recordBehavior(userId, behaviorDTO.getNewsId(), behaviorDTO.getBehaviorType()); return Result.success(); }BehaviorService里要注意的是同一条新闻短时间内重复浏览的处理。用户可能因为手抖或刷新页面连续点了多条记录这些脏数据会污染推荐算法的输入所以要对同一用户同一新闻的相同行为做去重或时间窗口限制比如5分钟内的重复浏览只算一次。3.3 推荐结果的缓存策略Redis在这里不是摆设推荐算法如果是实时计算每次请求接口都要做分词、相关性计算、排序效率低得惊人。实际项目中一定要加缓存。我的思路是第一层缓存推荐结果按userId存Rediskey设计为recommend:{userId}:{page}过期时间20分钟。第二层兜底用户第一次请求或者缓存过期时同步计算推荐结果然后异步写入缓存。对于非登录用户游客不用算个性化推荐直接从Redis取热门榜key为news:hot:recent7这个缓存数据每10分钟更新一次。spring: redis: host: localhost port: 6379 password: timeout: 3000ms lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0Redis操作代码建议用RedisTemplate封装StringRedisTemplate序列化器用String序列化value直接存JSON字符串方便Debug。千万别用JDK默认序列化器存进去的二进制数据在可视化工具里看着就是天书排查问题极为痛苦。3.4 数据库表设计核心是“用户-新闻-行为”三张王牌数据库表设计是系统设计的基石。我推荐至少设计以下6张表表名关键字段用途userid, username, password, create_time用户信息newsid, title, content, category_id, keywords, publish_time新闻内容categoryid, name新闻分类behaviorid, user_id, news_id, behavior_type, create_time用户行为记录user_similarityid, user_id, similar_user_id, similarity用户相似度计算结果adminid, username, password管理端账号behavior表要重点关注它是推荐系统的数据来源。查询频率极高必须加上联合索引(user_id, create_time)和单列索引(news_id)。数据量大之后建议按时间定期归档保留最近3个月的行为数据用于推荐计算历史冷数据可以备份后清理否则表越来越大查询性能会明显下降。user_similarity表是协同过滤的优化点把用户相似度预先算好落到表里避免每次推荐都在线计算大规模的相似度矩阵。这个定期计算定时任务的思路论文里描述成“离线计算相似度矩阵、在线快速召回推荐”的混合架构专业感立刻上来一个档次。4. 论文怎么写从开题到答辩的完整章节脉络4.1 为什么系统设计要跟着论文章节走很多人做毕设是先写完代码再写论文顺序颠倒导致论文写得极其空洞。我建议拿到这个题目之后先通过论文结构来反推你要做的事这样每一项工作都能在论文里找到对应章节写的时候非常顺。本质上这是“以终为始”的思路先想清楚评审老师想看到什么再决定系统怎么做。论文结构可以按这个框架来搭第一章绪论研究背景与意义国内外研究现状主要工作内容。 第二章相关技术介绍Spring Boot框架、MyBatis-Plus、MySQL、Redis、推荐算法概述。 第三章系统需求分析可行性分析功能需求分析非功能需求分析用例图、业务流程。 第四章系统设计总体架构设计功能模块设计数据库设计E-R图、数据表结构推荐算法设计。 第五章系统实现给出每个核心模块的前后端效果截图和核心代码片段重点展示推荐模块的实现过程。 第六章系统测试功能测试用例表格、性能测试结果、推荐效果评估体验式评测或离线指标。4.2 需求分析和特色设计怎么写需求分析这部分最容易写成流水账。常规的“用户可以注册登录、管理员可以管理新闻”这种表述既没有难点也没有亮点。要往系统特色去深挖推荐写这几点一是用户画像的动态构建强调系统能基于行为变化实时调整推荐策略二是新新闻的内容时效性加权说明这是新闻领域区别于普通内容系统的关键特征三是混合推荐策略解释为什么单靠一种算法无法满足推荐效果的需求。4.3 推荐效果评估用一个表格证明你的系统真“有用”这是论文和答辩中最容易被提问的环节。你光说“系统能推荐新闻”没用评委会问“你怎么证明你的推荐效果好”。本科毕设通常不要求做完整的大规模离线评测但至少要有对比实验。推荐效果对比可以用一个简单表格来呈现推荐策略测试用户数点击率平均浏览时长纯热门推荐5018.6%42秒基于内容推荐5025.2%58秒混合推荐5031.4%76秒测试方法是找10-20个同学每人使用不同推荐策略各一周统计行为数据。这个样本量虽然不算大但在毕设阶段足够说明问题。把表格放进论文第六章再补一段测试环境说明评委会觉得你的工作完整度高有说服力。5. 从零复现这个项目实操步骤和避坑指南5.1 环境准备与版本选择复现第一步先确认环境版本一致。Java要求JDK 1.8或11Maven要求3.6以上IDEA随便一个版本都行。Spring Boot版本我推荐用2.7.18这个版本资料全、生态稳、和MyBatis-Plus的兼容性最好。现在很多人启动失败就是死在版本上。比如Spring Boot 3.x默认使用Jakarta EE命名空间把javax改成jakarta很多老教程的依赖和代码复制过来直接编译报错。网上资源包里的源码大部分基于Spring Boot 2.x如果你非要用3.x跑光是改包名就够折腾一阵子。毕设项目求稳为上不要为了“用新版本”给自己挖坑。创建项目的方式IDEA内置Spring Initializr、start.spring.io官网、阿里云镜像三选一。国内用阿里云镜像最稳start.aliyun.com生成速度快不会卡在下载。依赖选择Spring Web、MyBatis-Plus手动引入、MySQL Driver、Redis、Lombok、Spring Boot DevTools。5.2 核心配置文件的完整参考application.yml是Spring Boot的“总指挥”我贴一份可以直接参考的配置server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/news_recommend?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这里有一个高频踩坑点数据库url必须带serverTimezoneAsia/Shanghai否则MySQL 8连接时会报时间时区错误。map-underscore-to-camel-case这个配置也很重要开了之后数据库字段user_name能自动映射到实体类的userName属性否则MyBatis查出来全是null怎么查都查不出来。5.3 跑通一个最小闭环注册 → 登录 → 浏览 → 推荐第一次复现建议先跑通最小闭环再逐步添加功能。具体步骤可以这样操作第一步新建数据库news_recommend执行项目里的sql脚本确认6张表都建好。如果资源包里没有sql脚本就反射看实体类自己建表这种情况很常见下载的源码经常漏脚本。第二步改配置文件的数据库用户名密码启动项目后台日志不报错并能看到Tomcat started on port 8080。第三步用Postman或前端页面注册一个测试账号调用注册接口数据库user表出现新记录。第四步正常浏览十篇左右新闻行为表behavior出现对应的浏览记录。第五步调用推荐接口/recommend/list如果返回值不是你浏览过的那几篇而是相关的其他新闻说明推荐链路已经通了一小半如果返回了一堆无关新闻检查关键词提取和相似度计算逻辑里有没有bug或空值问题。5.4 前端调用和后端联调跨域问题处理很多毕设采用前后端分离Vue跑在8081端口Spring Boot跑在8080端口联调时第一个吃到的异常就是跨域。浏览器控制台报的错通常是Access-Control-Allow-Origin解决办法是后端写一个CorsConfig配置类。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有个细节allowCredentials(true)之后allowedOrigins不能用而是用allowedOriginPatterns()否则部分浏览器还是会报跨域错误。我最初就是卡在这个点上前端明明发了请求后端也没报错但浏览器就是拦着不放行。5.5 管理端功能怎么补管理端是新闻系统的基础设施涵盖新闻发布、分类维护、用户管理等。这个模块本身没有技术难点但在Spring Boot里值得强调一点权限控制。即便不做Spring Security这种重量级框架也应该用拦截器做管理员身份校验。写一个AdminInterceptor实现HandlerInterceptor接口在preHandle方法里判断session里是否有adminId没有就重定向到登录页。否则任何用户都能直接访问/admin/news/add接口发布新闻答辩演示的时候如果被问到这一点非常被动。6. 我踩过的坑和经验教训6.1 Maven依赖下载慢或失败国内Maven默认中央仓库慢到让人崩溃第一件事就是改阿里云镜像。在~/.m2/settings.xml里加镜像配置。很多资源包自带的pom.xml里可能有老版本的依赖冲突比如mybatis-plus-boot-starter和spring-boot-starter-parent版本不兼容启动时报创建Bean失败优先检查这几个核心依赖版本是否都兼容。6.2 推荐列表为空或一直返回同一批新闻推荐列表为空主要查三种情况用户没有任何行为数据本身就走热门推荐逻辑但热门数据没生成候选新闻时间范围过滤太严格比如只查最近2天的新闻但测试数据都是一个月以前的Redis里缓存的空值没有被及时清理接口一直返回缓存中的空列表。我当初就犯过第三种错用Redis缓存空列表并且设置了过期时间但每次请求都会刷新过期时间导致空结果一直存在用户无论怎么访问都是空。后来改成在写入缓存之前判断集合是否为空空集合不做缓存问题才消失。6.3 MyBatis-Plus分页插件配置如果在新闻列表里用MyBatis-Plus自带的分页查询一定要配置分页插件否则分页不生效直接查出全表数据。配置方式是在Spring Boot启动类上注册MybatisPlusInterceptor。Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }有很多资源包的源码里没有这一行你照着写就会发现分页参数Page的current和size完全不生效查出来的永远是全表。这也是排在前几的高频问题。6.4 分词处理在Spring Boot里的性能问题如果每次推荐都在请求线程里同步分词接口响应会非常慢。我测试过一条新闻的标题加正文分词大概需要40-100毫秒如果有200篇候选新闻一次推荐请求就要算好几秒体验极差。解决方式有两个新闻发布的时候就把分词结果和关键词存进数据库推荐时直接读取不用动态分词用户兴趣向量可以定期异步构建比如每分钟批量处理一次而不是每次请求实时计算。6.5 关于“源码论文”资源包的一个忠告最后说点掏心窝的话。这类网上下载的“源码论文”资源包平均水平真的参差不齐。很多论文写的时间早里面的技术版本还是JSP、Struts2代码则被人为改成了Spring Boot导致两者压根对不上。你如果真打算用它务必先做一件事跑通最小闭环然后自己亲自把推荐模块的每一行代码读一遍搞清楚相似度计算、热度排序的每个变量是什么意思。答辩的时候老师最喜欢问的问题就是“这里为什么这样写”“这段代码的作用是什么”你如果答不上来场面会非常尴尬。我的体会是这套“Spring Boot 轻量级推荐算法”的毕设方案根本没必要完全依赖网上的资源包你完全可以自己动手搭一个难度并没有想象中高。核心算法部分掌握2.2节那套余弦相似度代码就够了难点主要在于数据怎么收集、候选集合怎么降维、缓存怎么设计。把这些工程细节想清楚系统自然就比大多数网上的模板项目扎实得多。如果时间紧张要直接参考别人的项目也要把“推荐链路”完整走一遍行为记录进来了、算法算出来了、结果展示出来了、缓存更新了任何一个环节断了都会影响最终的答辩效果。本文还有配套的精品资源点击获取
