基于SpringBoot与Vue的文创内容推荐平台设计与实现

1. 项目思路与整体设计1.1 这是个什么项目“热门文创内容推荐平台”这句话放网上可能有点抽象通俗点说把故宫文创、各地博物馆的周边、独立设计师的IP衍生品、非遗手作这类内容聚合到一起根据用户的浏览、收藏、点赞行为把用户可能感兴趣的文创产品推到他面前。听起来像是电商但又不完全是电商——重点在“内容推荐”不是做购物车和下单而是做“逛”的体验。技术选型落到了 SpringBoot Vue 这套组合上。后端用 SpringBoot 做接口服务前端用 Vue 做单页应用数据库用 MySQL 存核心数据Redis 做缓存和热门榜单中间再插一个简单的推荐逻辑。整体属于中小型 Web 项目的典型架构既不会像微服务那样重度到没法落地又比单纯的 SSMSpringSpringMVCMyBatis写起来舒服很多非常适合做毕业设计、课程项目或者一个小团队从零起步的文创内容聚合产品。我做这个项目时遇到的第一件事不是写代码而是理清楚“推荐”到底怎么做。真正的推荐系统可以非常复杂协同过滤、深度学习、向量召回、AB 测试一套下来没个半年搞不定。但对于一个小型文创内容平台“热门推荐”和“个性化推荐”可以简化成一套非常务实的方法标签匹配 行为加权 时间衰减。后面我把这套逻辑完整展开讲。1.2 为什么是SpringBoot Vue而不是其他组合先聊后端。SpringBoot 的核心优势在于“约定大于配置”一个启动类加几个注解就能跑起一个内嵌 Tomcat 的 Web 服务。相比传统的 SSM 项目不需要写一堆 XML 配置不用手动管理 Bean这对快速迭代项目非常关键。我当时用 Spring Initializr 生成基础工程选好 Web、MyBatis-Plus、Redis、MySQL 依赖十分钟内就能把基础的 REST 接口跑起来。如果换成 Python 的 Django 或 Flask写起来其实也快但在国内的技术生态、面试认可度、部署资料丰富程度上SpringBoot 明显更占优势。而且这个项目的核心是业务逻辑和接口设计Spring 家族对事务管理、缓存抽象、定时任务都有非常成熟的方案排查问题时网上的资料也多。前端选择 Vue 而不是 React理由很简单Vue 对新手更友好模板语法直观单文件组件SFC把 HTML、CSS、JS 放在同一个.vue文件里写页面时思路不用切换上下文。配上 Element Plus 组件库后台管理页面前两天就能搭完剩下的精力可以全花在推荐算法和内容展示上。Vue 生态的 Vite 构建工具也很快开发时热更新基本是秒级的体验比旧版 Webpack 舒服太多。SpringBoot Vue 的组合还有一个隐藏优势前端打包后可以直接扔进 SpringBoot 的src/main/resources/static目录由一个 Tomcat 统一对外提供服务前后端之间不存在跨域问题部署也简单一台小服务器就能搞定。这一点在后面的部署章节里我再细说。1.3 文创内容平台的功能范围一个文创内容推荐平台核心功能我拆成了四个模块第一个是用户模块包括注册、登录、个人信息维护。登录用 JWT 令牌实现无状态认证Redis 里再存一份令牌黑名单用户修改密码或退出登录时能让旧令牌失效。第二个是内容管理模块管理员在后台上传文创内容填写名称、分类、图片、描述、标签。这个模块是推荐系统的数据基础没有优质的内容数据后面一切推荐逻辑都是空中楼阁。第三个是用户行为模块用户在平台上可以浏览文创详情、收藏喜欢的内容、点赞、评分、分享。这些行为会被记录到行为日志表成为推荐系统的输入特征。第四个是推荐模块包括热门榜单、基于标签的内容匹配、基于用户行为的个性化推荐。系统每天凌晨通过定时任务更新一次推荐数据白天用户访问时直接读取 Redis 中的缓存结果保证接口响应速度。这四个模块切分下来整个项目的分工非常清晰前端根据页面拆组件后端根据业务拆 Controller、Service、Mapper各自开发效率都会高很多。2. 数据库设计与核心实现2.1 数据表结构规划数据库设计是这类项目最关键的一步表结构没想清楚后面写代码全是坑。我设计了三类核心表用户类、内容类、行为类。用户表t_user相对简单字段包括用户ID、用户名、密码哈希值、昵称、头像URL、个人偏好标签用逗号分隔的字符串存储比如“古风,手作,国潮”、创建时间。密码不要明文存储用 BCrypt 加密Spring Security 自带的BCryptPasswordEncoder可以直接用。文创内容表t_content是这个平台的根基字段这样设计字段类型说明idbigint主键titlevarchar文创名称categoryvarchar分类如文具/服饰/非遗cover_urlvarchar封面图地址detail_urlvarchar详情图地址descriptiontext内容描述tagsvarchar标签逗号分隔如“故宫,古风,限量”popularity_scoredouble热度评分定时任务计算view_count / like_count / collect_countint浏览/点赞/收藏数statustinyint上架状态0禁用1启用create_timedatetime创建时间行为表t_user_behavior记录用户的每个操作。这里不要把所有行为都放在同一张表里用“行为类型”字段区分虽然看起来简单但后续做数据统计时 SQL 会写得很绕。我最终用了一张宽表行为类型用枚举值区分1浏览、2点赞、3收藏、4评分评分值单独放在score字段中其他类型统一为0。这样一张表就能覆盖推荐算法需要的全部行为数据。还有一张推荐结果表t_recommend_result存储定时任务计算出来的推荐列表字段包括用户ID、推荐内容ID、推荐分值、推荐原因、生成日期。用户每次访问推荐接口时先查这张表再拉取对应的内容详情推荐过程对用户完全透明但后端能清楚地知道“为什么给这个用户推了这些东西”。对管理后台和运营人员来说这张表也是分析推荐效果的重要依据。2.2 用户行为采集机制行为采集是推荐系统的上游设计得好不好直接影响推荐数据的质量。我用了一个极其简单的方案前端在用户点击浏览详情、点赞、收藏时调用一个统一的接口POST /api/behavior/record请求体只传三个字段contentId、type、score。后端收到请求后先判断用户是否登录。未登录用户的行为同样记录只是userId为空这类行为只参与热门榜计算不参与个性化推荐。已登录用户的行为则会异步写入行为表同时更新 Redis 中的累计计数确保浏览数、点赞数在页面上能实时变化。这里有一个细节很容易被忽略浏览行为的记录要“去重”。如果每次进详情页都记一条浏览行为用户在页面间快速来回切换时会产生大量垃圾数据推荐算法会被这种噪声干扰。我的处理方式是在 Redis 中存一个{userId}:{contentId}:view的键设置10分钟过期时间过期以后再次访问才重新记录。用户在这10分钟内的反复进出只算一条浏览行为。2.3 热门推荐与个性化推荐算法推荐算法这块我选择的是“多策略组合”而不是盲目套用复杂模型。整个推荐模块分为三层第一层是热门榜单。热度分计算公式为popularity_score view_count * 0.3 like_count * 2 collect_count * 3这个公式看着简单但很有讲究。浏览门槛最低权重就给低一点收藏比点赞更能体现真实兴趣权重就再高一点。实际运营中发现单纯按这个公式算出来的榜单一周都不怎么变老内容永远霸榜新内容几乎没机会。所以我又加了时间衰减因子最终热度 基础热度 * e^(-0.03 * 距离发布的天数)这个衰减因子让新内容有机会冲上来老内容的热度随时间逐步降低行为榜单才真正“活”了。第二层是基于标签的推荐。用户在注册时可以选择偏好标签后台也可以手动给用户打标签。推荐时根据标签集合计算内容匹配度匹配度 内容与用户共同标签个数 / 内容标签总数候选内容池优先筛出“共同标签数 0”的内容按匹配度降序排列再结合热度做一次排名调整。这套逻辑简单直接但对冷启动阶段的用户效果很好因为用户还没产生足够的行为数据个性化推荐无从下手只能靠标签来猜。第三层是基于用户行为的协同过滤。这里我实现了一个“基于物品”的简化版本用户A和用户B都收藏了内容X那么用户A收藏的其他内容就可能是用户B感兴趣的。具体做法是把所有用户的收藏行为加载到内存中的Map里计算内容之间的共现矩阵然后为每个用户找到“最相似”的内容集合。由于是小规模项目用户量和内容量都在千级以内这套计算全部放在内存里没任何压力。三个层的推荐结果需要合并。我直接用加权方式热门榜占20%、标签匹配占50%、协同过滤占30%最终分值排序后取前20条写入推荐结果表。这个比例是我测试了多次之后确定的热门榜保证了基础的质量兜底标签匹配和协同过滤则负责“猜你喜欢”。3. 后端SpringBoot核心逻辑实现3.1 工程结构与实体对象设计用 Spring Initializr 生成工程时我建议直接选 Java 8 或 Java 11别追求太高版本。网上遇到过太多“SpringBoot版本太高导致兼容性问题”的情况稳定要优先于新鲜。SpringBoot 版本我选的是 2.7.x既支持 Java 8又能兼容 MyBatis-Plus 3.5.x非常稳妥。工程采用标准的controller-service-mapper三层结构com.example.culturalplatform ├── controller # 接口层 ├── service # 业务层 ├── mapper # 数据访问层 ├── entity # 实体类 ├── config # 配置类 ├── common # 通用类返回结果、异常处理、工具类 ├── recommendation # 推荐算法相关类 └── task # 定时任务实体类上我用了TableName指定表名TableId(type IdType.AUTO)用数据库自增主键。MyBatis-Plus 的 BaseMapper 提供了常用的单表 CRUD接口开发效率比手写 MyBatis XML 快很多。复杂一点的联表查询比如查询内容列表时把点赞数、收藏数关联进来我还是优先写在 Mapper XML 里SQL 可控性更强。返回结果统一使用ResultT对象封装包含code、message、data三个字段。这样做的好处是前端 Axios 拦截器可以统一处理响应码比如 401 时自动跳转登录页400 时直接弹出错误提示不需要在每个接口里重复写判断逻辑。3.2 登录认证与拦截器实现登录认证这块我用了 JWT Spring MVC 拦截器的方案没有引入 Spring Security原因是这个项目的权限模型只有“用户、管理员”两种角色Spring Security 的过滤器链对这种简单场景反而显得重。生成令牌的代码比较简单核心是先用 JJWT 库创建 JWTpublic String createToken(Long userId, String username, String role) { Date now new Date(); Date expireDate new Date(now.getTime() 7 * 24 * 60 * 60 * 1000); // 7天有效期 return Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(role, role) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }每次请求时前端在请求头Authorization: Bearer token中带上令牌拦截器中解析并校验签名和过期时间然后把userId存入ThreadLocal中的UserContext后续业务代码通过UserContext.getUserId()直接取当前用户避免在接口参数里到处传用户ID。拦截器只拦截/api/**路径放行登录注册接口和所有静态资源。再配合 CORS 配置允许前端开发服务器跨域请求。上线打包后前端静态文件和后端在同一端口下跨域问题不会出现。3.3 推荐结果的异步更新推荐结果不能用户在访问时才现算那样接口延迟会非常高。我的方案是用 SpringBoot 自带的Scheduled注解做定时任务每天凌晨2点执行一次推荐更新。更新逻辑分两步走。第一步加载全部内容到内存中算出每个内容的热度分更新到内容表。第二步遍历所有活跃用户最近30天内有行为记录的用户逐个计算个性化推荐列表批量写入t_recommend_result表写入之前先删除该用户昨天的推荐结果避免重复累积。计算过程中需要特别小心内存溢出问题。我把内容数据和用户行为数据都存放在内存的ConcurrentHashMap中几千条数据内存占用量其实很小但对一个资深后端来说数据量大了以后内存不够扩展是一个必须预判的问题。因此我保留了缓存接口和分页逻辑后续如果用户量增长到万级可以改用 Redis 的 Sort Set 存储候选内容再做滑动窗口计算。3.4 图片与对象存储方案文创平台最重要的展示内容就是图片所以图片处理方案必须提前定好。我的做法是前端直接把图片上传到后端的/api/upload接口后端把文件保存到本地磁盘的upload目录下并把访问 URL 返回给前端。本地存储只适合开发阶段测试用。真实部署时我会把磁盘路径更换为对象存储服务比如七牛云或阿里云 OSS。实现的思路是定义一个StorageService接口本地实现类和云存储实现类都实现同一个接口通过配置项动态切换。这样部署到服务器时只需改一行配置不需要改动任何业务代码。图片格式建议统一用 WebP压缩率高且浏览器兼容性好。图片尺寸方面封面图建议固定为 600x600 的方形比例详情图可以保持宽图前端展示时用object-fit: cover裁切界面会显得统一整洁。4. 前端Vue页面构建4.1 前端工程初始化前端我用的 Vite 构建工具初始化了 Vue 3 工程。为什么选 Vite它天生快创建工程命令简单热更新比 Webpack 快一个数量级Vue 3 Vite 是当前社区的主流配置遇到问题更容易查到答案。初始化命令npm create vitelatest frontend -- --template vue然后安装依赖cd frontend npm install npm install vue-router4 element-plus axios pinia --save安装依赖时经常遇到npm install报错常见原因有两个一是 node_modules 残留了旧版本二是 Node 版本和依赖不匹配。建议优先用 Node 16 以上的 LTS 版本出问题时删掉package-lock.json和node_modules重新安装。4.2 路由设计与页面框架文创平台的前端页面我规划了四个核心路由首页推荐列表、文创详情页、个人中心、管理后台。首页和详情页是用户看得最多的体验要做好管理后台单独走一套布局。路由懒加载是一个不能省的点const routes [ { path: /, name: Home, component: () import(/views/Home.vue) }, { path: /content/:id, name: ContentDetail, component: () import(/views/ContentDetail.vue) }, { path: /user, name: User, component: () import(/views/UserCenter.vue) }, { path: /admin, name: Admin, component: () import(/views/admin/AdminLayout.vue) } ]按需加载页面组件可以减少首屏加载体积。Vue Router 4 中createWebHistory模式让 URL 更加美观不需要带#号但部署到 SpringBoot 时要配置前端路由的 fallback 逻辑否则刷新页面时后端会找不到路由返回 404。这个坑在部署时一定会遇到后面单独说解决方案。路由守卫方面管理后台的路由加一个前置守卫router.beforeEach((to, from, next) { const token localStorage.getItem(token) const role localStorage.getItem(role) if (to.meta.requiresAuth !token) { next(/login) } else if (to.path.startsWith(/admin) role ! admin) { next(/) } else { next() } })4.3 核心组件实现与交互细节首页推荐列表是整个平台的核心页面我使用的布局是顶部导航栏加一个整页瀑布流。瀑布流用 CSS 的columns属性实现可以让不同高度的卡片自动排列不需要引入额外的 JS 库.recommend-list { column-count: 3; column-gap: 16px; } .recommend-item { break-inside: avoid; margin-bottom: 16px; }每个推荐卡片展示内容封面、标题、标签、热度值。点击卡片跳转到详情页详情页展示完整的文创信息以及收藏、点赞、评分三个操作按钮。这三个操作按钮不仅要有 UI 交互还要通过 Axios 把行为数据传给后端这是推荐系统收集信号的关键入口。评分功能我用 Element Plus 的el-rate组件实现允许用户打1到5星。评分对于推荐算法价值很高因为“喜欢”这个信号比“浏览”和“点赞”都强代表用户明确的兴趣程度。我在前端限制每位用户对同一内容只能评一次分防止刷分。Vue 中实现数据的跨组件共享我没有用复杂的 Pinia store 去存所有业务状态只用它存了用户信息、token 和主题偏好。推荐列表的数据请求直接写在页面组件里面通过onMounted加载首页数据再用ElLoading做加载状态。这样写起来最简单代码可维护性也足够。4.4 前端打包放进SpringBoot开发完成后前端需要构建产物并放进 SpringBoot 工程步骤如下第一步构建前端npm run build构建产物默认生成在dist目录包含index.html、assets目录等静态文件。第二步将dist目录下的文件全部复制到 SpringBoot 工程的src/main/resources/static目录。第三步处理前端路由问题。由于 Vue Router 用的是createWebHistory模式访问/content/1这类路径时SpringBoot 内部没有对应的 Controller会默认返回 404。解决办法是添加一个路由 fallback 配置Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addViewControllers(ViewControllerRegistry registry) { // 除静态资源和接口以外的路径统一返回前端入口页面 registry.addViewController(/{path:[^\\.]*}) .setViewName(forward:/index.html); } }这样除了带文件后缀的路径和/api/接口路径所有请求都会转发到前端的index.html由 Vue Router 接管路由。这个配置我一开始没加部署后刷新详情页直接 404排查了好一阵子。整体打包也可以用 Maven 的maven-resources-plugin把构建好的前端产物自动复制到target/classes/static目录一步到位省时间。需要小小注意这种打包方式让前端资源统一由后端端口提供但也在前端的index.html中禁止引用绝对路径的外部资源否则静态文件路径会接错。最简单的做法是在vite.config.js中设置base: ./让所有资源都走相对路径。5. 系统上线部署与常见问题排查5.1 部署方案与服务器环境部署前端到 SpringBoot 之后整个项目其实就是一个可执行的 JAR 包。我建议用宝塔面板来装服务器环境简单省事也不影响底层起服务。服务器配置 2核2G 的入门机就够用MySQL、Redis 都装在本地不分开远程连接。部署流程服务器安装 JDK 8配置环境变量验证java -version。安装 MySQL创建数据库并导入 SQL 初始化脚本。安装 Redis默认端口启动即可。本机执行mvn clean package -DskipTests打出 JAR 包。JAR 包上传到服务器放到自定义目录例如/opt/springboot-app。编写启动脚本用nohup命令在后台启动服务nohup java -jar cultural-platform.jar --spring.profiles.activeprod server.log 21 生产环境的配置通过 Profile 区分application-prod.yml中数据库地址改为服务器本机 IPRedis 同样设置为本机地址。上传到服务器前记得改一下数据库密码和 JWT 密钥别把开发环境的弱密码直接带到线上。大概会遇到一个很经典的问题服务器安全组没放行 8080 端口外部访问不到。如果是云服务器需要在安全组规则中允许 TCP 8080 端口的访问。宝塔面板也需要在“安全”中放行端口。5.2 踩过的高频问题与排查方法开发这个项目时我遇到的九成技术问题都可以在搜索引擎中找到对应解决方案其中的典型问题有这些跨域问题。开发时前后端分离运行前端占 5173 端口后端占 8080 端口前端调接口一定会有跨域报错。我一开始用的是在 Controller 上加CrossOrigin注解后来发现接口一多就写得很散改成统一用 WebMvc 的全局 CORS 配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true); } }allowedOriginPatterns(*)与allowCredentials(true)同时存在时不要用allowedOrigins(*)否则浏览器会拒绝携带 Cookie 的跨域请求。这是 SpringBoot 2.4 以后的一个行为变化。JSON 序列化问题。后端返回的时间字段默认是 Date 格式会输出成时间戳数字前端处理麻烦。解决办法是在application.yml中配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8配置完成后前后端交互的时间字符串格式统一省去一堆前端dayjs格式化代码。依赖版本冲突。npm install后启动 Vite 有时会报“Cannot find module vitejs/plugin-vue”原因多半是 package.json 中依赖版本与企业内网镜像不一致。删掉node_modules和package-lock.json重新执行npm install基本能解决。前端播放本地视频或音频资源时如果无法直接访问需要在后端的静态资源配置中将多媒体文件路径加入映射Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); }这样/upload/xxx.jpg就能直接通过浏览器访问。需要注意多媒体文件的 URL 路径要规范统一前端的图片标签和视频标签才能无缝对接。5.3 推荐效果验证与策略调优推荐系统上线后不能只是“有推荐”就完事还需要关注推荐效果。我用两个指标来评估一个是内容点击率曝光卡片被点击的比例一个是操作率详情页出现收藏或点赞行为的比例。实际操作中发现初始版本的推荐结果太依赖热门榜点击率高但收藏率偏低用户看到的热门内容多真正让人惊喜的“猜你喜欢”少。后来我调整了加权比例把协同过滤的权重从30%提高到40%收藏率明显上升。另一个细节是推荐结果中要避免连续出现同一分类的内容。比如用户连续刷到四五个文具类的文创视觉疲劳会非常重。我加了一个简单的打散规则排名前20的内容中同一分类最多连续出现2个如果出现连续3个同分类就自动交换相邻候选内容的位置。这个操作代码只有十几行但对用户体验的提升非常明显。5.4 定时任务中的隐患处理定时任务的实现虽然简单但有几个隐患要提前预防。第一任务执行时间不要和用户高峰访问时间重叠凌晨2点到5点执行最合适。第二如果计算过程中发生了异常不能让异常状态留在数据库中推荐结果表的数据要么不更新要么整体重新计算不能在表格里留下一半新数据一半旧数据。我给更新逻辑的外部包了一层事务失败则整体回滚。第三定时任务要加“重复执行保护”。如果服务器重启时任务计划重新加载同一时刻可能会有两个实例都在跑推荐计算互相干扰。我的方案是在 Redis 中存一个recommend_task_lock的键利用 Redis 的SETNX命令加锁谁抢到锁谁执行执行完删除锁。这样即使多实例部署也不会重复计算。定时任务的日志也很重要TaskLogger工具类记录每次任务开始时间、结束时间、计算用户数、失败原因。运营时如果发现推荐榜单异常先查日志判断是算法的问题还是数据源的问题排查效率会高很多。6. 管理后台与运营支撑功能6.1 后台功能设计思路管理后台是运营人员维护文创内容、查看平台数据的入口。页面放在 Vue 前端工程下的/admin路由布局用侧边栏导航加右侧内容区。后端按操作粒度拆出内容管理、标签管理、用户管理、数据统计四个子模块。内容审核是一个必要的流程管理员上传的新内容必须先经过“审核通过”状态才能在前台展示。这个设计初看有点繁琐却在真实运营中帮了大忙。比如某条内容图片不清晰、标题格式不对如果直接上线展示用户点进去看到的是劣质内容对推荐系统的反馈信号也会是千人千面的反面教材。审核机制的实现就是在内容表中增加status字段前端列表展示时只查status 1的内容后台可先置为 0 审核中。6.2 用 Vue 组件提升后台开发效率后台管理页面的核心组件有两个一个是数据表格一个是表单弹窗。Element Plus 的el-table组件配合el-dialog就够用但列表的筛选条件、分页处理、批量删除操作值得做成可复用的组合式函数。我抽象了一个useCrudList组合式函数传入 API 地址和筛选参数返回列表数据、加载状态、分页参数、刷新函数export function useCrudList(api, defaultParams {}) { const list ref([]) const loading ref(false) const total ref(0) const params reactive({ page: 1, pageSize: 10, ...defaultParams }) async function loadList() { loading.value true try { const res await api(params) list.value res.data.records total.value res.data.total } finally { loading.value false } } return { list, loading, total, params, loadList } }所有后台管理页面只要调用这个组合式函数加上各自的 API 接口表格的基本能力就都有了。这让每个管理页面的代码量少了一半维护成本也大幅降低。6.3 数据可视化的加分项后台的数据统计页面如果想做得更直观可以用 ECharts 画几张统计图每日新增用户数、内容点击量 TOP10、收藏榜 TOP10、分类分布饼图。用 Vue 中 ECharts 的常见方式是封装一个ChartContainer.vue组件接收option属性在onMounted中初始化图表并在watch中更新图表const chartDom ref(null) let chartInstance null const props defineProps({ option: { type: Object, required: true } }) onMounted(() { chartInstance echarts.init(chartDom.value) chartInstance.setOption(props.option) }) watch(() props.option, (newOption) { chartInstance?.setOption(newOption) }, { deep: true })图表数据不用实时查询统计页的接口直接返回聚合后的 JSON 结构减少数据库压力。ECharts 的体积比较大建议按需引入只注册用到的柱状图、饼图组件。7. 性能优化与经验总结7.1 缓存策略的落地细节缓存策略的核心是“热点数据才值得缓存”。推荐结果列表是典型的读多写少数据非常适合放在 Redis 中。每次用户访问推荐接口时先查 Redis 中是否存在recommend:{userId}这个键存在就直接返回缓存数据不存在再查询推荐结果表并回填到 Redis。热门榜单同样使用 Redis 缓存缓存键设为hot:recommend定时任务在每天凌晨更新推荐数据时同时重建热门榜单缓存。内容详情页的数据因为管理员可能随时编辑我用的是短缓存策略缓存时间 30 分钟后台编辑内容后主动删除缓存键保证前台能较快看到更新。Redis 的 key 命名需要带着业务前缀和区分信息避免不同业务间的键冲突。比如user:{userId}:profile、content:{contentId}:detail、recommend:{userId}:list这样即使将来引入分布式链路追踪也能直接通过 key 判断数据归属。7.2 接口响应时间优化接口慢是一个必须优化的痛点。推荐列表接口早期版本每次请求都要从数据库查推荐结果表再逐条查询内容详情一个推荐列表要执行近 20 次 SQL。优化方案是先在推荐结果表的查询中拿到内容ID集合再用 SQL 的IN查询一次性把所有内容详情查询出来减少网络往返。其次是前端懒加载。首页的图片主要是文创内容的封面图通常都比较高清加载很慢。我对封面图启用了懒加载机制下面代码是图片懒加载的一种优雅实现img v-lazyitem.coverUrl classrecommend-card-img /用v-lazy指令延迟加载非首屏图片配合封面前端做一次图片压缩把名片图大小控制在 200KB 以内首屏加载体验明显改善。还有一个容易被新手忽略的点前端请求要统一做防抖。用户在瀑布流中快速上下滑动时每次滚动都会触发加载行为如果没有防抖一瞬间可能打进来几十个请求后端明明做了缓存也被打穿。我采用了滚动距离判断加时间防抖的双重策略只有滚动到底部超过 300px 并且距上次加载超过 300ms 时才触发下一次请求实测非常稳定。7.3 项目后续演进方向当前这个平台已经能跑通完整的推荐流程。后面如果要升级有几个方向可以继续深入第一个方向是引入更精细的用户画像。现在用户标签是手动选择的后续可以根据用户行为反推兴趣标签比如用户频繁浏览“非遗”分类的内容就可以自动给用户补一个“非遗爱好者”标签。这套逻辑可以用很轻量的规则引擎实现。第二个方向是做内容语义化处理。给每条内容打标签目前是管理员手动填的虽然人工准确率高但扩展性差。后续可以引入 NLP 分词工具对内容描述自动抽取关键词再通过关键词匹配辅助生成标签。当然这一步要考虑成本和收益前期还是人工为主。第三个方向是增加榜单的热更新机制由日级更新变为小时级更新配合 Redis 的过期重建机制让热门榜单更加实时。运营数据表明用户对新鲜的文创内容响应率明显高于旧内容榜单的实时性直接影响留存。这些演进方向的共同特点是都需要持续观察用户行为数据。所以从项目开始时就要把用户行为日志记录好维度越细越好。推荐系统的每一步优化归根结底都建立在高质量数据的基础上。把这个底座打牢后面用多复杂的模型都不愁没数据可喂。