企业官网建设流程全解析

1. 项目骨架与核心需求分析

做短剧推荐系统这个选题的时候，老实话讲，是大数据专业的毕设名单里比较讨巧的一个方向。为什么？因为短剧本身就是近两年的风口，一集两三分钟，节奏快，用户刷起来根本停不下来。用 Java 系的 SSM 框架去做推荐系统，比纯机器学习路线的课题难度低不少，又比普通的 CRUD 增删改查管理系统显得有内容，两头都能顾上。我开始动工前，先把这个项目到底要解决什么问题想透了，而不是上来就建表写代码。

先说说这个系统最核心的定位。短剧推荐系统，本质上是解决一个信息过载的问题：短剧平台上的内容数量太多，用户没时间一个个翻，系统需要根据用户的行为记录（看过的剧、停留时长、点赞收藏动作），给用户推一批他大概率会感兴趣的短剧。很多人做这种推荐系统项目的时候容易陷入一个误区，就是觉得必须上协同过滤算法、深度学习模型才显得高级，结果数据量只有几千条，模型训练出来的效果还不如一个简单的排序规则好用。

我当时给自己划定的边界是这样三条：

1. 系统要走完整的 SSM 技术栈流程，Spring + Spring MVC + MyBatis 三层架构清晰，MySQL 存数据，Maven 管理依赖。
2. 推荐逻辑要有"行为依据"，不只是单纯按播放量排序，要能根据用户看过的短剧标签做内容相似度匹配。
3. 前端要有可演示的页面效果，因为最终要面对的是答辩老师，一个能现场点开看的 Web 界面，比一堆接口测试截图有说服力得多。

整个系统的受众人群，说白了就是两类人：一是正在选毕设题目的计算机相关专业学生，需要一篇完整的技术实现参考；二是想自己搭一个短视频推荐类网站练手，但不想从零开始踩坑的开发者。我的目标就是写清楚我从设计到落地的全过程，包括那些别人不太会在文档里讲明白的细节。

2. 数据库设计与推荐策略选择

2.1 表结构到底怎么设计才够用

这个项目我设定了三个核心实体：用户、短剧、行为记录，再加上一个管理员表做后台登录。很多人第一次做这种项目会犯一个错误，就是表设计得过于分散，恨不得把每部短剧的播放量、点赞数、评论数全都单独建表，结果后期联表查询的时候 SQL 写得脑袋大。

我最终的落地方案是六张表：

• user（用户表）：存放用户 ID、用户名、密码、注册时间。注意密码的存储必须加密，我用的是 MD5 加盐的方式，虽然不算最安全，但作为课程级别项目完全够用。
• admin（管理员表）：独立的后台登录账号表，跟普通用户区分开，避免权限混淆。
• drama（短剧表）：核心内容表，字段包括剧名、封面图 URL、分类标签、总集数、单集时长、简介、热度值。分类标签这个字段特别关键，这是后面做推荐的基石，我用的是"古装、甜宠、赘婿、战神、重生、穿越"这类够细分、又能体现短剧特色的标签。
• episode（分集表）：保存每部短剧下的集信息，包括集数、视频 URL、时长、播放量。分集表的好处是以后哪怕要接视频播放页面，数据基础都有了。
• user_favorite（用户收藏表）：记录用户 ID、短剧 ID、收藏时间，做"猜你喜欢"的一个行为来源。
• user_history（观看历史表）：记录用户 ID、短剧 ID、观看时间、观看进度。这张表是推荐系统行为数据的核心来源，观看进度这个字段能用来区分用户是真看完还是划了几秒就退出。

我画图论证表关系的时候，用的说法是"用户-短剧"的多对多关系，通过行为表来关联。保持简单直接，写 ORM 映射的时候就少些麻烦。

2.2 为什么我没选协同过滤算法

推荐系统的经典算法无非两种主流路线：基于用户的协同过滤（User-Based CF）和基于物品的协同过滤（Item-Based CF）。基于用户的协同过滤核心思想是找口味相似的人，把别人喜欢而你还没看过的内容推给你；基于物品的协同过滤则是找内容相似的物品，你在看 A，系统就把和 A 相似的 B 推给你。

我一开始确实动过用 User-Based CF 的心思，但很快发现一个非常现实的问题：冷启动。用户注册进来的时候没有任何行为数据，系统根本没法判断他跟谁相似，推荐列表是空的。短剧项目的真实场景里，新用户比重很高，这个缺陷是致命的。

相比之下，基于内容标签的推荐策略要稳得多。核心逻辑就是根据用户看过的短剧所带的标签，分析出"用户偏好向量"，再跟每部未看短剧的标签向量做相似度计算，按相似度从高到低排序输出推荐。这个方案的好处是：

• 天然解决冷启动问题，用户只要看了一部剧，就能立刻产出推荐。
• 算法逻辑完全可控，用 SQL 配合 Java 代码就能实现，不依赖外部 Python 服务。
• 暴力计算的可解释性强，展示推荐理由的时候可以直接写"因为你喜欢《XX》，推荐《XX》"。

所以最终我在系统里实现了混合策略：先用标签相似度做主要推荐排序，再用热度和播放量做补充权重，保证推荐列表既有针对性、又不至于全场都是同一类型的剧。这套思路在实际效果上其实比单纯跑一个协同过滤模型要更能说服答辩评委，因为你能清楚地说出每一步的逻辑。

3. 核心推荐逻辑的实现细节

3.1 标签相似度计算的具体算法

这里我分两步走，第一步是把用户的偏好向量算出来，第二步是算具体短剧跟用户的匹配度。

用户偏好向量的计算逻辑是这样的：先把用户看过的所有短剧的标签字段拿出来，做一个统计。短剧表里的标签我设计成用逗号分隔的字符串，比如"古装,甜宠,穿越"。统计完以后可以得到类似 {古装: 3, 甜宠: 2, 穿越: 1} 这样的映射，然后把次数归一化，就得到了一个 0 到 1 之间的兴趣权重。

短剧和用户的匹配度，我用的公式是余弦相似度（Cosine Similarity），公式不长：

similarity = (用户偏好向量 · 短剧标签向量) / (|用户偏好向量| × |短剧标签向量|)

我知道有些同学看到公式就头疼，用人话说就是：把两个向量往坐标系里一摆，算它们之间的夹角度数，角度越小，说明方向越接近，即越相似。举个例子，假设标签集合是 {古装, 甜宠, 战神}，某用户偏好向量是 {古装: 0.6, 甜宠: 0.3, 战神: 0.1}，一部待推荐的短剧标签是"古装,甜宠"，那么这部短剧的向量可以写成 {古装: 1, 甜宠: 1, 战神: 0}。代入余弦公式：

similarity = (0.6×1 + 0.3×1 + 0.1×0) / (sqrt(0.6²+0.3²+0.1²) × sqrt(1²+1²+0²)) = 0.9 / (sqrt(0.46) × sqrt(2)) ≈ 0.9 / (0.678 × 1.414) ≈ 0.94

这个 0.94 就是匹配度，接近 1 说明非常契合。把所有未看过的短剧都算一遍，按分数从大到小取前 N 条，就是推荐列表。

我在实际实现里把这段计算封装成了一个独立的工具类RecommendUtil.java，输入参数是用户 ID 和要排除的已看短剧 ID 列表，返回值为推荐短剧及其相似度分数的列表。这样哪怕后续要换成更复杂的算法，也只动这一个类就行。

3.2 行为权重怎么定才科学

纯看标签是不够的，因为用户可能只是随手点了一部剧，并不是真的喜欢。所以我在计算用户偏好向量的时候，引入了行为权重系数。不同的行为代表不同的兴趣强度：

• 完整观看（进度大于 80%）：权重 1.0，代表强烈兴趣。
• 部分观看（进度 20%-80%）：权重 0.5，代表一般兴趣。
• 刚点开就退出（进度小于 20%）：权重 0.1，代表兴趣极弱。
• 收藏操作：直接权重 1.2，收藏行为有主动意愿，比观看更强烈。

也就是说，用户偏好向量的计算不是简单统计标签出现次数，而是统计"加权得分"。一部剧只看了五分钟和一部剧完整刷完，对偏好向量的贡献是完全不同的。这个设计埋了伏笔，答辩的时候评委如果问"你怎么避免短时播放对推荐结果的干扰"，这里就是一个现成的回答。

另外，这部短剧本身的标签不一定只有一个，我处理的方式是每个标签都单独累加权重。一部剧三个标签，完整看完，那么这三个标签每个都加 1.0。这样计算出来的用户兴趣画像会更均衡，不会因为某一部剧权重特别高而把推荐结果带偏。

3.3 数据库表结构对推荐性能的影响

推荐算法理论上不难，但如果表结构设计不合理，后面跑 SQL 会很痛苦。我举一个典型的反面教材：把用户的观看标签直接怼在一个字段里，比如用户表的 tag 字段直接存"古装,甜宠"，这样每次推荐都要去解析这个字符串，而且新增行为的时候还要拼接更新，性能很差。

我最终的做法是正向表和反向表结合。正向表就是 drama 表里的标签字段，方便展示；反向表是 user_history 表，通过用户关联短剧，再关联短剧标签去统计。SQL 大致长这样：

SELECT d.tag, SUM(h.weight) AS tag_score FROM user_history h LEFT JOIN drama d ON h.drama_id = d.id WHERE h.user_id = #{userId} GROUP BY d.tag

这段 SQL 拿到的结果，就是用户标签权重的原始数据集，拿到 Java 里再组装成向量就非常方便了。几张表之间的关联关系在 MyBatis 的 Mapper 文件里配好，用 resultMap 做映射，后期维护起来也不乱。

4. 后端接口开发与权限拦截

4.1 RESTful API 设计清单

这个项目我是按前后端分离的思路搭的，后端只负责提供 JSON 格式的接口，前端页面通过 Ajax 异步请求拉数据。接口设计遵循 RESTful 风格，核心接口清单如下：

• POST /api/user/login：用户登录，参数为手机号和密码。
• POST /api/user/register：用户注册。
• GET /api/drama/detail/{id}：获取短剧详情，包括基本信息、分集列表。
• GET /api/drama/recommend：获取推荐短剧列表，传 userId 参数，不传则按热度返回。
• GET /api/drama/category/{tag}：按分类标签浏览短剧。
• POST /api/favorite/add：添加收藏。
• POST /api/history/record：添加观看记录，传入短剧 ID 和当前进度。
• GET /api/history/list：获取用户最近观看记录。

接口设计有个小原则：一次请求尽量只做一件事，不要为了省事搞一个接口既返回详情又返回推荐又返回评论，那样排查 bug 的时候会非常痛苦。相反，也不建议拆得太碎，比如把短剧基本信息和分集信息拆成两个接口来回请求，前端就会多出很多拼接逻辑。我的做法是详情接口直接一次返回基本信息和分集列表，减少一次请求往返。

4.2 登录态管理与 JWT 的坑

课程设计项目最容易忽略的就是权限控制，很多同学把所有接口都做成公开的，前端页面谁都能直接访问。虽然系统本身不涉及支付和隐私数据，但是推荐系统必须依赖用户身份才能推荐个性化内容，所以我加了登录拦截。

采用的方案是 JWT（JSON Web Token）。服务端在用户登录成功后，签发一个 token 返回给前端，前端存储在 localStorage 里，后面每次请求在请求头带上Authorization: Bearer ${token}。后端写了一个拦截器（HandlerInterceptor），统一从请求头解析 token，用户 ID 直接放在请求上下文里，各 Controller 方法就能直接获取当前用户。

这块有一个非常容易踩的坑：JWT 的密钥不能写在代码里，至少也要放在配置文件jwt.properties中统一管理。我刚开始是把密钥直接写在拦截器的常量里，后来换密钥要重新编译整个项目，浪费了不少时间。另外，JWT 如果过期时间设置过短，前端会频繁收到 401 导致需要反复登录，我踩过这个坑之后把过期时间定为 7 天，足够课程演示使用。如果需要更加严谨，可以再额外做续签机制，但那是生产环境的事，课程里会让学生理解 token 拦截器的原理更关键。

4.3 MyBatis 动态 SQL 与分页查询

列表页的数据量取决于我的种子数据量，我造了 200 部短剧的数据，如果不做分页，一次请求返回全量数据，浏览器渲染会卡顿。分页是常规需求，我用的是 MyBatis 的 PageHelper 插件。配置很简单，引入依赖、在 applicationContext.xml 里配置分页插件拦截器，然后在 Service 层调用PageHelper.startPage(pageNum, pageSize)就能自动拦截下一条 SQL 做分页。

PageHelper 的使用有个细节值得提一下：startPage 方法必须在查询语句之前调用，而且两者之间不能隔着其他查询。如果中间插了别的 SQL，PageHelper 会影响下一次查询而非目标查询，导致分页错乱。这就是典型的"框架包装了太多细节，使用上出了偏差你都不知道问题在哪"的情况。

另外是动态 SQL 的场景。分类浏览短剧时，用户可能选了某个标签、又想按热度排序，几个筛选条件组合起来变数很多，我用<where>加<if>标签来做动态条件拼接，例如：

<select id="searchDramas" resultType="map"> SELECT * FROM drama <where> <if test="tag != null and tag != ''"> AND FIND_IN_SET(#{tag}, tag) </if> <if test="keyword != null and keyword != ''"> AND title LIKE CONCAT('%', #{keyword}, '%') </if> </where> ORDER BY hot_value DESC </select>

FIND_IN_SET 是专门用来查找逗号分隔字符串的 MySQL 函数，配合标签字段非常合适，这也是我把标签设计成逗号分隔字段的原因之一。

5. 前端页面搭建与联动调试

5.1 页面框架选择：为什么不选前后端分离的 Vue

很多现阶段的同学会默认用 Vue + Element UI 做前端，然后再写个 Nginx 反代把前后端串起来。这是一个主流方案没错，但坦白讲，如果我只做课程设计又没有额外时间搞前端工程化的东西，用传统方式反而更省事。

我的方案是用模板引擎直接渲染，页面放在 WebContent 下的 JSP 目录里，使用 JSTL 标签库做数据遍历和条件判断。理由是我选的这套 SSM 技术栈本来就跟 JSP 是搭配的，Spring MVC 天然支持 ViewResolver 解析 JSP 视图，省去跨域处理、Token 校验等一堆联调工作。

当然 JSP 这套老技术确实有它的局限，比如前端开发体验差、性能不如模板字符串拼接，但对我来说它的好处是稳定、调试直观。服务端渲染出来的 HTML 在浏览器里直接能看到效果，不像前后端分离动不动就白屏、接口报错半天查不出来。如果你自己写项目，完全可以保留我的后端接口设计，同时用 Vue 自己搭一个前端，接口都不用改，这就是接口设计规范的收益。

5.2 移动端体验模拟的打磨

短剧的用户场景基本都发生在手机上，所以我意识到纯做电脑端页面会显得和"短剧"这个调性不搭。虽然项目主页面做的是响应式布局，但我额外调了一个移动端的布局优化——将页面宽度根据浏览器窗口大小伸缩，封面图卡片自适应多列排列。在答辩现场用浏览器开发者工具切换成手机尺寸看页面，观感会比固定宽度页面好很多。

具体实现就是在 JSP 里引入 Bootstrap 的栅格系统，页面整体框架是：

col-md-8：左侧主要内容区（推荐列表、分类浏览） col-md-4：右侧用户区域（最近观看记录、收藏清单）

短剧卡片用的是卡片式布局，封面图加上剧名标签，点击封面进入详情页。详情页顶部放一个模拟播放器区域，下方排列分集按钮列表。这里的播放按钮实际上不需要真的接入视频流，只需要预留一个<video>标签并设置 src 地址即可，演示时放一个项目目录下的样片文件就行。我见过有同学试图接真视频数据流，反而在毕设阶段引入了过多不可控因素，自己把自己拖死了。

5.3 前后端联调时最容易忽略的编码问题

联调阶段我踩过一个很典型的坑，说白了这个坑无数人都会踩一遍。后端 MySQL 数据库的编码是 UTF-8，前端页面声明的也是 UTF-8，但通过 JSP 提交中文参数的时候，Spring MVC 接收到的还是乱码。原因在于 POST 请求默认用的不是 UTF-8。

解决方案是在 web.xml 里配置一个字符编码过滤器：

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <force-encoding>true</force-encoding> </filter>

加上之后，从前端过来的 POST 参数就会先被强制转为 UTF-8 再进入业务逻辑，乱码问题迎刃而解。另外还有个细节是 MySQL 的 JDBC 连接串上也要显式声明编码：

jdbc:mysql://localhost:3306/drama_db?useSSL=false&characterEncoding=utf-8

少任何一环，你都会在某个莫名其妙的地方出现中文乱码。

6. 部署上线与踩坑记录

6.1 本地环境搭建流程

这个项目需要的基础环境是四个：JDK 1.8、Maven 3.x、MySQL 5.7+、Tomcat 8.5+。版本尽量贴近，不要图新鲜用最新版，不然容易碰到兼容性问题。我用的是 JDK 1.8 和 Tomcat 8.5，这个组合非常成熟，网上资料也多，出问题了也好查。

搭建步骤可以照搬：

1. 装好 JDK，配置JAVA_HOME环境变量，命令行输入java -version验证。
2. 装好 Maven，改一下settings.xml里的本地仓库路径和镜像地址。
3. MySQL 新建数据库drama_db，设置字符集 utf8mb4，导入我准备的建表和种子数据脚本。
4. 在 IntelliJ IDEA 里导入 Maven 项目，等依赖下载完成。
5. 修改db.properties里的数据库连接信息，改成你自己的用户名密码。
6. 配置 Tomcat 运行，启动后浏览器访问http://localhost:8080/验证首页。

整个过程最耗时的是第一遍 Maven 拉依赖，建议如果本地网络不畅，直接用阿里云镜像，几十秒就能搞定拉取。反之如果你用默认中央仓库地址，等十分钟都可能没拉完。

6.2 项目导出为 WAR 包的流程

本地跑通只是第一步，课程设计往往要求能部署到服务器上。最常规的做法是把项目导出为 WAR 包，扔到服务器上的 Tomcat webapps 目录。

在 IDEA 里的操作是：项目右键 → Open Module Settings → Artifacts → 新增 → Web Application Exploded 和 Web Application Archive，后者就是可直接部署的压缩包。Build Artifacts 之后生成一个以项目名命名的 WAR 文件。

这个步骤我建议大家一定提前演练一次，不要等到答辩前夜才开始折腾。因为 WAR 包部署后访问路径会带上应用名，比如原来的http://localhost:8080/login会变成http://localhost:8080/项目名/login，前端页面上所有写死的相对路径都要提前处理好。用相对路径，还是绝对路径加 contextPath 前缀，要提前定好。我这次就是用的${pageContext.request.contextPath}统一处理前端路径，虽然写起来多敲几个字，但部署到任何环境都不会出问题。

6.3 上线后遇到的三个隐蔽问题

第一个问题是 MySQL 连接超时。服务器上的 MySQL 有个 wait_timeout 参数，默认是 1 小时到 8 小时不等，如果长时间没有请求访问数据库，连接池里的连接会被数据库服务器强行断开，但连接池并不知道，下次请求还在用这个失效的连接，就会报 Communications link failure。我一开始是重启 Tomcat 解决的，后来排查了一下，在数据源配置里加上testWhileIdle和validationQuery才根治。

第二个问题是邮件服务相关，但这个项目没有邮件功能，所以不太涉及。我要分享的第二个坑其实是静态资源路径问题。我把项目部署之后，CSS、JS、图片全部加载不出来，F12 一看全是 404。排查后发现问题出在 Spring MVC 的拦截器配置上，因为配置了很多接口拦截规则，静态资源也被 DispatcherServlet 拦掉了，必须额外放行：

<mvc:resources location="/static/" mapping="/static/**"/>

第三个问题是 Cookie 的 SameSite 属性。如果前后端不在同源下（比如前端是 80 端口、后端是 8080），浏览器默认会拦截 Cookie 的发送，导致登录状态没法保持。我采用的是同源部署方案，让前端与后端同用一台服务器的 Tomcat，Cookie 天然就是同域的，绕开了这个问题。如果是前后端分离架设，需要后端设置 SameSite=None 和 Secure，这一块对课程设计来说，属于加分项而不是必选项。

6.4 答辩前必须做好的五件事

到这里整个系统其实已经可以正常工作了，但根据我带过项目的经验，答辩环节翻车往往不是代码问题，而是准备问题。我总结了一下自测清单，按这个顺序过一遍基本稳了：

1. 登录注册流程走一遍，确认密码加密存储、错误密码有提示。
2. 新注册一个空账号查看推荐页，能看到基于热度的兜底推荐，而不是白屏。
3. 用测试账号观看几部"古装、甜宠"类短剧，再刷新推荐页，看前几条关联是否符合预期。
4. 管理员后台手动新增一部短剧，前端列表页能实时出现，证明后台 CRUD 有效。
5. 换一个浏览器或清空缓存重新登录，验证 JWT 登录态是否正常。

这几件事最多 20 分钟就能全部跑完，但能让你在答辩现场笃定很多。

7. 推荐效果的测试与调优笔记

7.1 什么样的数据才算推荐有效

系统开发完，得给自己讲讲清楚推荐效果到底怎么样。我没法像工业级产品那样做 A/B 测试，但至少可以利用种子数据做一个简单验证。

我的做法是准备两个测试账号。账号 A 只完整观看一部"战神"类的短剧；账号 B 完整观看了三部"甜宠、穿越"类的短剧。然后分别在两个账号下调用推荐接口，观察返回列表的差异。结果账号 A 的推荐列表中"战神"类占比明显高于账号 B，账号 B 的推荐列表则集中出现"甜宠""穿越"类的短剧。这个结果已经足够说明推荐算法在按用户行为做差异化输出。

更好的验证方法是把每一部待推荐短剧的推荐理由也返回给前端展示，比如"与你常看的古装剧相关度 92%"。这样评委一眼就能看出推荐不是乱来的，前端页面上也能增加可信度。

7.2 暴力计算导致响应变慢的优化思路

最初版本的计算逻辑是：每次请求推荐接口，都把线上所有的短剧和用户向量做一遍余弦相似度计算。200 部短剧一时半会儿看不出问题，但如果数据量放大到几万条，性能就会立竿见影地崩掉。

我做了一个简单的优化：先按用户偏好标签做一次初级过滤，比如用户偏好向量里权重最高的两个标签是"古装"和"甜宠"，那么在线查询只选包含这两个标签之一的短剧参与计算：

SELECT * FROM drama WHERE FIND_IN_SET('古装', tag) OR FIND_IN_SET('甜宠', tag)

这样做把候选集从全量缩小到跟用户兴趣相关的近似集合，查询量大幅下降。对应的思路就是电商系统里说的"召回（Recall）"阶段——先从海量商品里捞出一小撮候选，再做精细化排序。这个名词你可以直接用在答辩里，能显著拔高项目的技术上限观感。

另外，我还在用户表加了一个last_recommend_time字段，用来做简单的缓存控制。如果用户两次请求推荐的时间间隔小于 30 分钟，直接走缓存表返回上次结果，超过 30 分钟才重新计算并刷新缓存。推荐结果本来就不是时效性要求特别高的数据，这么做极其合理，也顺手减少了数据库的压力。

7.3 标签体系的设计经验

标签是整个推荐系统的灵魂，但很多项目都有意无意地忽略了它。如果一部短剧只打一个标签，用户的价值取向就不够细腻，推荐相似度拉不开差距；如果一部短剧打了七八个标签，等于没有标签，因为大量短剧的重叠度会太高。

我的建议是，标签体系控制在 10 - 15 个以内，每部短剧打 2 - 4 个标签，且确保标签之间有足够区分度。比如"古装"和"现代"是互斥的，"甜宠"和"虐恋"是近义的但侧重点不同，这种设计在计算余弦相似度时才能体现细微差别。

这个经验同样适用于未来往协同过滤方向扩展：如果以后有足够多的用户行为数据，可以在现有标签推荐基础上叠加协同过滤，形成混合推荐架构，两部分结果加权合并。那样系统从原理上来讲就是完整的两路召回加排序了，技术含量会更高。

8. 一套代码直接迁移到其他领域的思路

8.1 替换数据模型即可

这个项目的架构设计很大程度是围绕"物品"的标签和用户行为来组织数据的，因此具有天然的通用性。

比如说，你想做一个书籍推荐系统，只需要把 drama 表替换为 book 表，字段里的"剧名"变"书名"，"分类标签"变"书籍分类"，核心代码里跟短剧有关的名词改成书籍即可。推荐算法的逻辑一行都不用动。

同理，短视频推荐、文章推荐、商品推荐，只要业务上存在"用户 → 行为 → 物品 → 标签"这条链路，都能用这套骨架套上去。

8.2 推荐策略的可扩展性

当前的核心推荐逻辑集中在 RecommendUtil 类和一个定时清理缓存的 Service 里。如果想换算法，只需要改这一个类。比如 Youbube 早期用 Item-Based CF，你可以在这个类内部先按用户的观看历史找相似用户，再把相似用户看过的剧捞出来排序，只要接口层的输入输出不变，Controller 层面的代码完全不需要调整。这就是面向接口编程的好处。

我有一次在给一个课程项目做辅导时，建议对方把"推荐理由"做成可视化的贡献度条，比如显示"古装 +50%、甜宠 +30%、穿越 +20%"，前端展示效果立刻不一样，但后端代码几乎没动。这种思路对于任何做推荐类毕设的同学都是很实用的加分技巧。

9. 最后的实操经验与扩展建议

回到开头的场景，如果让我重新做一次这个项目，我会把重点放在三件事上：推荐算法的可解释性、数据量级下性能是否扛得住、以及部署环节是否真的跑通了。很多同学做的系统功能看起来很多，实际上是互不关联的功能堆叠，有的是后台增删改查、有的是图表展示、有的是用户前端，但相互之间不能构成完整的业务闭环。我的项目里用户的数据（收藏、观看行为）会反哺推荐结果，推荐结果又反过来引导用户点击，动态循环地改善个性化体验，这样才是一个有说服力的系统。

再分享一个实际的加分小动作：往数据库里注入一批有梯度差异的用户行为数据，然后在答辩现场演示"账号 A 和账号 B 看到完全不同的推荐首页"。这个对比效果远比你口头解释十分钟算法原理都要震撼，评委看到的就是"推荐系统真的起作用了"。

关于后续的演进方向，我的一个真实体会是：短剧这三个字本身就是一个风口，如果你能把系统的数据源接上视频号或者短剧平台的公开数据，让推荐结果实时更新，这个项目的应用价值会直接上一个档次。当然，那些需要外部依赖的对接，要提前评估时间和接口文档的完备度，不要贸然在截止日期之前引入重依赖。

如果这篇分享对你的项目有一点帮助，我后续还可以继续把 JWT 登录拦截的完整配置、标签推荐算法的详细代码以及数据库建表脚本整理成更细的文章，到时候评论区或者私信找我聊都行。