尧图网站建设 
简介这是一套基于SpringBoot与Vue实现前后端分离的热门文创内容推荐平台完整项目源码面向计算机相关专业的毕业设计、课程设计、大作业与工程实训人群也适合希望入门或进阶Java全栈开发的学习者参考借鉴。资源包内含可运行源码、SQL数据库文件及配套说明文档压缩包约36.31MB源码以Java后端与Vue前端工程文件为主配合MySQL脚本用于快速还原数据表结构与初始数据。项目采用JDK8、SpringBoot框架、Vue技术栈搭配Tomcat7、MySQL5.7与Maven3.3.9构建开发工具支持Eclipse、MyEclipse或IDEA前后端分离结构清晰便于理解接口设计与推荐逻辑实现。已有79人学习关注读者可据此掌握完整项目搭建流程、模块划分思路与二次开发方法也可作为初期项目立项的参考模板遇到问题可与作者沟通获取解答。1. 从「5b263基于springbootvue的热门文创内容推荐平台.zip」说起这套组合到底解决什么问题如果你手里正好有一个5b263基于springbootvue的热门文创内容推荐平台.zip第一反应大概率是这不就是又一套毕设模板吗但真正拆开看它其实踩中了两个很实际的需求点——一是文创内容博物馆周边、非遗手作、城市 IP、联名设计越来越多用户根本刷不完二是纯靠人工编辑首页推荐运营成本高、更新慢、还容易「千人一面」。这套平台要解决的就是用 SpringBoot 做后端服务与推荐逻辑用 Vue 做前台展示与交互把「内容入库 → 标签化 → 打分排序 → 前端曝光」这条链路跑通。它适合三类人想入门推荐系统但不想一上来就啃 Flink 的 Java 开发者、需要一套能改能跑的毕设/课程设计骨架的学生、以及想给自家文创小店做轻量推荐位的独立开发者。下面我按「先跑通、再调优、最后避坑」的顺序把这条链路拆开讲。2. 先把工程跑起来SpringBoot Vue 的最小可运行骨架2.1 后端 SpringBoot 工程结构与启动配置拿到压缩包后不要急着改代码先确认后端能不能独立启动。常见做法是把后端放在backend/目录前端放在frontend/目录。后端典型结构是controller / service / mapper / entity / config五层推荐逻辑一般落在service层的一个RecommendService里。先看application.yml里几个必须改的参数server: port: 8080 # 启动端口和前端代理保持一致 spring: datasource: url: jdbc:mysql://localhost:3306/wenchuang?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver 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这里server.port是后端启动端口前端vue.config.js里的proxy要指向同一个端口否则会出现跨域 404。serverTimezone必须显式指定否则 MySQL 8 会报时区错误。map-underscore-to-camel-case打开后数据库的cover_url能自动映射到实体类的coverUrl省掉大量Results注解。启动命令cd backend mvn clean package -DskipTests java -jar target/*.jar如果用的是 IDEA直接运行Application主类即可。启动成功后访问http://localhost:8080/doc.html如果集成了 Knife4j能看到接口文档说明后端通了。提示如果启动报Failed to configure a DataSource八成是application.yml没被加载检查resources目录是否被标记为资源根目录。2.2 前端 Vue 环境配置与接口联调前端部分先确认package.json里的依赖版本。Vue 2 和 Vue 3 的写法差异很大这套模板多数是 Vue 2 Element UI 或 Vue 3 Element Plus。安装依赖cd frontend npm install --registryhttps://registry.npmmirror.com npm run servevue.config.js里配置代理把/api转发到后端module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } }changeOrigin: true是为了让后端收到的 Host 头是localhost:8080避免某些安全校验拦截。pathRewrite把前端请求的/api/recommend/list重写成后端真实的/recommend/list。联调时打开浏览器 Network 面板如果看到 200 但数据为空先查数据库有没有种子数据再查RecommendService的查询条件是不是把status1写死了。2.3 数据库表设计与推荐字段预留文创内容推荐平台的核心表一般有四张user、content文创内容、category分类、user_behavior行为日志。推荐能不能做起来关键看content表和user_behavior表设计得够不够用。表名关键字段用途contentid, title, cover_url, category_id, tags, heat, create_time内容主表tags 存逗号分隔标签user_behaviorid, user_id, content_id, behavior_type, weight, create_time行为日志behavior_type 区分浏览/收藏/购买categoryid, name, parent_id分类树支持二级分类userid, username, interest_tags用户兴趣标签注册时或首次浏览后写入tags字段用逗号分隔是最省事的做法比如非遗,手作,国风。heat是热度分可以定时任务每天凌晨重算。user_behavior的weight字段很关键浏览给 1 分、收藏给 3 分、购买给 5 分后面算推荐分时直接乘权重比在代码里写 if-else 干净得多。3. 推荐逻辑怎么落地从标签匹配到热度加权排序3.1 基于标签与行为的混合推荐算法实现这套平台不太可能上深度学习最稳的做法是「标签匹配 行为加权 热度兜底」的混合策略。核心思路给每个用户算一个兴趣标签向量给每个内容算一个标签向量做余弦相似度再叠加行为权重和热度分最后排序取 TopN。public ListContent recommend(Long userId, int topN) { // 1. 取用户兴趣标签 User user userMapper.selectById(userId); SetString userTags splitTags(user.getInterestTags()); // 2. 取候选内容已上架、近30天 ListContent candidates contentMapper.selectRecent(30); // 3. 打分 for (Content c : candidates) { double tagScore cosine(userTags, splitTags(c.getTags())); double behaviorScore behaviorMapper.sumWeight(userId, c.getId()) * 0.3; double heatScore normalize(c.getHeat()) * 0.2; c.setScore(tagScore * 0.5 behaviorScore heatScore); } // 4. 排序取前 N return candidates.stream() .sorted(Comparator.comparingDouble(Content::getScore).reversed()) .limit(topN) .collect(Collectors.toList()); }cosine是标签集合的余弦相似度splitTags把逗号分隔字符串转成 Set。behaviorScore乘 0.3 是经验权重行为数据少的时候可以降到 0.1避免新用户被少量行为带偏。heatScore做归一化处理防止某个爆款内容热度值过大压过标签匹配。这套逻辑单表几万条数据完全够用响应在 100ms 以内。3.2 推荐接口的参数设计与分页处理推荐接口不能一次返回全部必须分页。常见做法是GET /recommend/list?userId1page1size10。后端用 MyBatis-Plus 的Page对象接收但注意推荐排序是在内存里做的不能直接用数据库分页。正确做法是先取候选集比如 500 条内存排序后手动截取(page-1)*size到page*size。public PageResultContent recommendPage(Long userId, int page, int size) { ListContent all recommend(userId, 500); // 候选池 int from Math.min((page - 1) * size, all.size()); int to Math.min(from size, all.size()); ListContent pageData all.subList(from, to); return new PageResult(pageData, all.size(), page, size); }500是候选池大小太小会导致翻几页就没数据太大会拖慢响应。subList返回的是视图如果后面还要序列化建议new ArrayList(pageData)包一层避免 JSON 序列化时出现意外。分页参数size建议限制在 20 以内前端做无限滚动比传统分页更贴合推荐场景。3.3 前端推荐列表渲染与「换一批」交互前端拿到推荐列表后用v-for渲染卡片。文创内容以图为主cover_url加载失败要有兜底图。Vue 里可以这样写// 推荐列表组件 data() { return { list: [], page: 1, size: 10, loading: false } }, methods: { async loadRecommend() { this.loading true const res await axios.get(/api/recommend/list, { params: { userId: this.userId, page: this.page, size: this.size } }) this.list res.data.data this.loading false }, refresh() { this.page 1 this.loadRecommend() } }refresh方法对应「换一批」按钮重置页码后重新请求。如果后端推荐结果每次一样可以在请求参数里加一个seed时间戳后端用seed做随机扰动让每次排序有细微差异。注意userId要从登录态里取不要写死否则所有用户看到的推荐都一样推荐就失去意义了。4. 避坑与排查这套平台最容易翻车的 5 个地方4.1 现象前端请求全部 404控制台报 CORS 错误原因vue.config.js的proxy没配或者配了但pathRewrite写错导致请求路径和后端接口对不上。另一种情况是后端没加跨域配置前端直接请求localhost:8080而不是走代理。解决确认前端请求地址是/api/xxx而不是http://localhost:8080/xxx检查pathRewrite是否把/api正确去掉后端加一个全局跨域配置类允许localhost:8081来源。4.2 现象推荐结果永远是同一批内容刷新也不变原因推荐算法里没有引入随机因子或者候选集查询条件写死了ORDER BY heat DESC导致每次取出来的都是热度最高的那几条。解决在打分公式里加一个Math.random() * 0.1的扰动项候选集查询不要排序交给内存排序如果用户行为数据为空走「热门 随机」兜底策略而不是直接返回空列表。4.3 现象MySQL 8 启动报Public Key Retrieval is not allowed原因MySQL 8 默认使用caching_sha2_password认证插件JDBC 连接时没有允许公钥检索。解决在 JDBC URL 后面加allowPublicKeyRetrievaltrueuseSSLfalse。生产环境不要用useSSLfalse应该配置正确的 SSL 证书。4.4 现象Vue 打包后放进 SpringBoot 的static目录刷新页面 404原因Vue 是单页应用路由用history模式时刷新/recommend这类路径SpringBoot 找不到对应的静态资源直接返回 404。解决要么把 Vue 路由改成hash模式URL 带#要么在 SpringBoot 里加一个转发配置把所有非/api开头的请求转发到index.html。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/**) .addResourceLocations(classpath:/static/); } }4.5 现象推荐接口响应越来越慢从 100ms 涨到 2s原因候选集查询没有加时间范围限制随着内容表增长每次推荐都全表扫描或者user_behavior表没有加(user_id, content_id)联合索引sumWeight查询走全表。解决候选集查询限定近 30 天或近 90 天user_behavior加联合索引如果数据量继续涨把推荐结果缓存到 Redis设置 5 分钟过期用userId page做 key。5. 进阶技巧用行为日志反哺推荐让「冷启动」不那么冷新用户第一次打开平台没有任何行为数据标签匹配也无从谈起这就是典型的冷启动。我一般会做两件事第一注册时让用户勾选 35 个感兴趣的分类国风、手作、插画、博物馆、联名直接写入interest_tags第二首页推荐位前 3 条固定走「全站热度 Top3」从第 4 条开始走个性化推荐。这样既保证了新用户有内容可看又不会让推荐位显得太「随机」。行为日志的采集也有讲究。前端不要每次点击都发请求而是攒一批比如 10 条或 5 秒再批量上报。后端用一个BehaviorController接收批量数据异步写入user_behavior表。Async public void batchSave(ListBehaviorDTO list) { for (BehaviorDTO dto : list) { UserBehavior ub new UserBehavior(); ub.setUserId(dto.getUserId()); ub.setContentId(dto.getContentId()); ub.setBehaviorType(dto.getType()); ub.setWeight(weightOf(dto.getType())); // 浏览1 收藏3 购买5 ub.setCreateTime(new Date()); behaviorMapper.insert(ub); } }Async需要在主类上加EnableAsync才生效。weightOf方法把行为类型映射成权重后续算推荐分时直接查SUM(weight)。如果行为数据积累到几十万条可以考虑用定时任务每天凌晨把用户兴趣标签重算一遍写回user表的interest_tags字段这样推荐接口就不用每次遍历行为表了。还有一个容易被忽略的点推荐结果要有「后悔药」。用户对某条推荐不感兴趣前端要提供一个「不感兴趣」按钮点击后把这条内容从当前列表移除同时往user_behavior写一条behavior_typedislike的记录权重设为负数。下次推荐时sumWeight自然会把这条内容排到后面。这个反馈闭环做起来成本很低但效果立竿见影。最后说个我自己的习惯每次改完推荐权重不要凭感觉调而是把userId1到userId100的推荐结果导出成 CSV人工看前 10 条是不是合理。推荐系统这东西玄学成分有但大部分问题都能通过「看数据」定位。希望帮到你。本文还有配套的精品资源点击获取 SpringBoot+Vue文创推荐平台：从标签匹配到热度加权的混合推荐实战
简介这是一套基于SpringBoot与Vue实现前后端分离的热门文创内容推荐平台完整项目源码面向计算机相关专业的毕业设计、课程设计、大作业与工程实训人群也适合希望入门或进阶Java全栈开发的学习者参考借鉴。资源包内含可运行源码、SQL数据库文件及配套说明文档压缩包约36.31MB源码以Java后端与Vue前端工程文件为主配合MySQL脚本用于快速还原数据表结构与初始数据。项目采用JDK8、SpringBoot框架、Vue技术栈搭配Tomcat7、MySQL5.7与Maven3.3.9构建开发工具支持Eclipse、MyEclipse或IDEA前后端分离结构清晰便于理解接口设计与推荐逻辑实现。已有79人学习关注读者可据此掌握完整项目搭建流程、模块划分思路与二次开发方法也可作为初期项目立项的参考模板遇到问题可与作者沟通获取解答。1. 从「5b263基于springbootvue的热门文创内容推荐平台.zip」说起这套组合到底解决什么问题如果你手里正好有一个5b263基于springbootvue的热门文创内容推荐平台.zip第一反应大概率是这不就是又一套毕设模板吗但真正拆开看它其实踩中了两个很实际的需求点——一是文创内容博物馆周边、非遗手作、城市 IP、联名设计越来越多用户根本刷不完二是纯靠人工编辑首页推荐运营成本高、更新慢、还容易「千人一面」。这套平台要解决的就是用 SpringBoot 做后端服务与推荐逻辑用 Vue 做前台展示与交互把「内容入库 → 标签化 → 打分排序 → 前端曝光」这条链路跑通。它适合三类人想入门推荐系统但不想一上来就啃 Flink 的 Java 开发者、需要一套能改能跑的毕设/课程设计骨架的学生、以及想给自家文创小店做轻量推荐位的独立开发者。下面我按「先跑通、再调优、最后避坑」的顺序把这条链路拆开讲。2. 先把工程跑起来SpringBoot Vue 的最小可运行骨架2.1 后端 SpringBoot 工程结构与启动配置拿到压缩包后不要急着改代码先确认后端能不能独立启动。常见做法是把后端放在backend/目录前端放在frontend/目录。后端典型结构是controller / service / mapper / entity / config五层推荐逻辑一般落在service层的一个RecommendService里。先看application.yml里几个必须改的参数server: port: 8080 # 启动端口和前端代理保持一致 spring: datasource: url: jdbc:mysql://localhost:3306/wenchuang?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver 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这里server.port是后端启动端口前端vue.config.js里的proxy要指向同一个端口否则会出现跨域 404。serverTimezone必须显式指定否则 MySQL 8 会报时区错误。map-underscore-to-camel-case打开后数据库的cover_url能自动映射到实体类的coverUrl省掉大量Results注解。启动命令cd backend mvn clean package -DskipTests java -jar target/*.jar如果用的是 IDEA直接运行Application主类即可。启动成功后访问http://localhost:8080/doc.html如果集成了 Knife4j能看到接口文档说明后端通了。提示如果启动报Failed to configure a DataSource八成是application.yml没被加载检查resources目录是否被标记为资源根目录。2.2 前端 Vue 环境配置与接口联调前端部分先确认package.json里的依赖版本。Vue 2 和 Vue 3 的写法差异很大这套模板多数是 Vue 2 Element UI 或 Vue 3 Element Plus。安装依赖cd frontend npm install --registryhttps://registry.npmmirror.com npm run servevue.config.js里配置代理把/api转发到后端module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } }changeOrigin: true是为了让后端收到的 Host 头是localhost:8080避免某些安全校验拦截。pathRewrite把前端请求的/api/recommend/list重写成后端真实的/recommend/list。联调时打开浏览器 Network 面板如果看到 200 但数据为空先查数据库有没有种子数据再查RecommendService的查询条件是不是把status1写死了。2.3 数据库表设计与推荐字段预留文创内容推荐平台的核心表一般有四张user、content文创内容、category分类、user_behavior行为日志。推荐能不能做起来关键看content表和user_behavior表设计得够不够用。表名关键字段用途contentid, title, cover_url, category_id, tags, heat, create_time内容主表tags 存逗号分隔标签user_behaviorid, user_id, content_id, behavior_type, weight, create_time行为日志behavior_type 区分浏览/收藏/购买categoryid, name, parent_id分类树支持二级分类userid, username, interest_tags用户兴趣标签注册时或首次浏览后写入tags字段用逗号分隔是最省事的做法比如非遗,手作,国风。heat是热度分可以定时任务每天凌晨重算。user_behavior的weight字段很关键浏览给 1 分、收藏给 3 分、购买给 5 分后面算推荐分时直接乘权重比在代码里写 if-else 干净得多。3. 推荐逻辑怎么落地从标签匹配到热度加权排序3.1 基于标签与行为的混合推荐算法实现这套平台不太可能上深度学习最稳的做法是「标签匹配 行为加权 热度兜底」的混合策略。核心思路给每个用户算一个兴趣标签向量给每个内容算一个标签向量做余弦相似度再叠加行为权重和热度分最后排序取 TopN。public ListContent recommend(Long userId, int topN) { // 1. 取用户兴趣标签 User user userMapper.selectById(userId); SetString userTags splitTags(user.getInterestTags()); // 2. 取候选内容已上架、近30天 ListContent candidates contentMapper.selectRecent(30); // 3. 打分 for (Content c : candidates) { double tagScore cosine(userTags, splitTags(c.getTags())); double behaviorScore behaviorMapper.sumWeight(userId, c.getId()) * 0.3; double heatScore normalize(c.getHeat()) * 0.2; c.setScore(tagScore * 0.5 behaviorScore heatScore); } // 4. 排序取前 N return candidates.stream() .sorted(Comparator.comparingDouble(Content::getScore).reversed()) .limit(topN) .collect(Collectors.toList()); }cosine是标签集合的余弦相似度splitTags把逗号分隔字符串转成 Set。behaviorScore乘 0.3 是经验权重行为数据少的时候可以降到 0.1避免新用户被少量行为带偏。heatScore做归一化处理防止某个爆款内容热度值过大压过标签匹配。这套逻辑单表几万条数据完全够用响应在 100ms 以内。3.2 推荐接口的参数设计与分页处理推荐接口不能一次返回全部必须分页。常见做法是GET /recommend/list?userId1page1size10。后端用 MyBatis-Plus 的Page对象接收但注意推荐排序是在内存里做的不能直接用数据库分页。正确做法是先取候选集比如 500 条内存排序后手动截取(page-1)*size到page*size。public PageResultContent recommendPage(Long userId, int page, int size) { ListContent all recommend(userId, 500); // 候选池 int from Math.min((page - 1) * size, all.size()); int to Math.min(from size, all.size()); ListContent pageData all.subList(from, to); return new PageResult(pageData, all.size(), page, size); }500是候选池大小太小会导致翻几页就没数据太大会拖慢响应。subList返回的是视图如果后面还要序列化建议new ArrayList(pageData)包一层避免 JSON 序列化时出现意外。分页参数size建议限制在 20 以内前端做无限滚动比传统分页更贴合推荐场景。3.3 前端推荐列表渲染与「换一批」交互前端拿到推荐列表后用v-for渲染卡片。文创内容以图为主cover_url加载失败要有兜底图。Vue 里可以这样写// 推荐列表组件 data() { return { list: [], page: 1, size: 10, loading: false } }, methods: { async loadRecommend() { this.loading true const res await axios.get(/api/recommend/list, { params: { userId: this.userId, page: this.page, size: this.size } }) this.list res.data.data this.loading false }, refresh() { this.page 1 this.loadRecommend() } }refresh方法对应「换一批」按钮重置页码后重新请求。如果后端推荐结果每次一样可以在请求参数里加一个seed时间戳后端用seed做随机扰动让每次排序有细微差异。注意userId要从登录态里取不要写死否则所有用户看到的推荐都一样推荐就失去意义了。4. 避坑与排查这套平台最容易翻车的 5 个地方4.1 现象前端请求全部 404控制台报 CORS 错误原因vue.config.js的proxy没配或者配了但pathRewrite写错导致请求路径和后端接口对不上。另一种情况是后端没加跨域配置前端直接请求localhost:8080而不是走代理。解决确认前端请求地址是/api/xxx而不是http://localhost:8080/xxx检查pathRewrite是否把/api正确去掉后端加一个全局跨域配置类允许localhost:8081来源。4.2 现象推荐结果永远是同一批内容刷新也不变原因推荐算法里没有引入随机因子或者候选集查询条件写死了ORDER BY heat DESC导致每次取出来的都是热度最高的那几条。解决在打分公式里加一个Math.random() * 0.1的扰动项候选集查询不要排序交给内存排序如果用户行为数据为空走「热门 随机」兜底策略而不是直接返回空列表。4.3 现象MySQL 8 启动报Public Key Retrieval is not allowed原因MySQL 8 默认使用caching_sha2_password认证插件JDBC 连接时没有允许公钥检索。解决在 JDBC URL 后面加allowPublicKeyRetrievaltrueuseSSLfalse。生产环境不要用useSSLfalse应该配置正确的 SSL 证书。4.4 现象Vue 打包后放进 SpringBoot 的static目录刷新页面 404原因Vue 是单页应用路由用history模式时刷新/recommend这类路径SpringBoot 找不到对应的静态资源直接返回 404。解决要么把 Vue 路由改成hash模式URL 带#要么在 SpringBoot 里加一个转发配置把所有非/api开头的请求转发到index.html。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/**) .addResourceLocations(classpath:/static/); } }4.5 现象推荐接口响应越来越慢从 100ms 涨到 2s原因候选集查询没有加时间范围限制随着内容表增长每次推荐都全表扫描或者user_behavior表没有加(user_id, content_id)联合索引sumWeight查询走全表。解决候选集查询限定近 30 天或近 90 天user_behavior加联合索引如果数据量继续涨把推荐结果缓存到 Redis设置 5 分钟过期用userId page做 key。5. 进阶技巧用行为日志反哺推荐让「冷启动」不那么冷新用户第一次打开平台没有任何行为数据标签匹配也无从谈起这就是典型的冷启动。我一般会做两件事第一注册时让用户勾选 35 个感兴趣的分类国风、手作、插画、博物馆、联名直接写入interest_tags第二首页推荐位前 3 条固定走「全站热度 Top3」从第 4 条开始走个性化推荐。这样既保证了新用户有内容可看又不会让推荐位显得太「随机」。行为日志的采集也有讲究。前端不要每次点击都发请求而是攒一批比如 10 条或 5 秒再批量上报。后端用一个BehaviorController接收批量数据异步写入user_behavior表。Async public void batchSave(ListBehaviorDTO list) { for (BehaviorDTO dto : list) { UserBehavior ub new UserBehavior(); ub.setUserId(dto.getUserId()); ub.setContentId(dto.getContentId()); ub.setBehaviorType(dto.getType()); ub.setWeight(weightOf(dto.getType())); // 浏览1 收藏3 购买5 ub.setCreateTime(new Date()); behaviorMapper.insert(ub); } }Async需要在主类上加EnableAsync才生效。weightOf方法把行为类型映射成权重后续算推荐分时直接查SUM(weight)。如果行为数据积累到几十万条可以考虑用定时任务每天凌晨把用户兴趣标签重算一遍写回user表的interest_tags字段这样推荐接口就不用每次遍历行为表了。还有一个容易被忽略的点推荐结果要有「后悔药」。用户对某条推荐不感兴趣前端要提供一个「不感兴趣」按钮点击后把这条内容从当前列表移除同时往user_behavior写一条behavior_typedislike的记录权重设为负数。下次推荐时sumWeight自然会把这条内容排到后面。这个反馈闭环做起来成本很低但效果立竿见影。最后说个我自己的习惯每次改完推荐权重不要凭感觉调而是把userId1到userId100的推荐结果导出成 CSV人工看前 10 条是不是合理。推荐系统这东西玄学成分有但大部分问题都能通过「看数据」定位。希望帮到你。本文还有配套的精品资源点击获取