基于Java SSM的短剧推荐系统设计与实现

做短剧推荐系统这个选题，最开始其实是冲着“短剧”这个当下最热的内容形态去的。三五分钟一集的剧，通勤看完一整部，用户刷起来是真的上头。但我真正把整个项目做完之后发现，最值得说的反而是技术选型：Java + SSM。这套组合在现在看着不算新潮，可它把Spring的IOC/AOP、SpringMVC的请求流转、MyBatis的SQL操作串在一起，是一个非常完整的Web开发闭环，几乎覆盖了Java后端岗位日常开发的所有基础能力。这篇就完整拆一下这个短剧推荐系统的设计思路、数据库结构、推荐逻辑、核心代码实现、部署流程，以及我踩过的坑和面试时怎么讲。

1. 项目定位与整体设计思路

1.1 短剧推荐要解决的三个核心问题

推荐系统的本质是帮用户做内容筛选。放到短剧场景里，核心痛点有三个：第一，短剧数量增长极快，一部剧的标签五花八门，用户光靠分类页翻，效率太低；第二，短剧用户大多是碎片化观看，兴趣变化快，上周爱看甜宠，这周可能就转向悬疑，系统得能跟着行为变化调整；第三，新用户刚进来时没有任何行为记录，这时候推荐什么直接决定他留不留得下来。

这三个问题对应到系统设计上，就是三个模块：内容标签体系负责给短剧打标，用户行为采集负责记录播放、点赞、收藏、评分等操作，推荐引擎负责把用户行为和短剧标签做匹配。整个项目往前走，逻辑都是围绕这三条线展开的。

1.2 为什么选Java+SSM而不是直接上Spring Boot

我知道很多人第一反应是：现在新项目谁还用SSM？直接Spring Boot不香吗？这么说没毛病，但我要说的是，SSM在这个项目里反而是一个更好的学习载体。Spring Boot把大量配置自动完成了，你很难理解背后发生了什么；而SSM要求你手写applicationContext.xml、spring-mvc.xml、mybatis-config.xml，每一层之间的调用关系、每个Bean的注入方式，都是显式可见的。做完这个项目，你对Spring容器的理解会比直接上手Spring Boot的人扎实得多。

从业务适配度来说，短剧推荐系统的核心也就是Controller接收请求、Service处理推荐逻辑、Mapper操作数据库这么一套流程，SSM的三层架构和业务结构天然匹配，不会出现框架过度设计的问题。而且如果你是做课程设计或者毕业设计，SSM可以说是一个稳妥的选择——技术难度适中、知识体系完整、可解释性极强，老师问到“为什么用这个框架”的时候，能讲的东西非常多。

1.3 功能模块怎么拆

整个系统我拆成了六个功能模块：

• 用户模块：注册、登录、个人信息维护，登录态用Session加拦截器处理
• 短剧模块：短剧信息展示、分类浏览、标签筛选、搜索
• 行为模块：记录用户的播放、点赞、收藏、评分行为
• 推荐模块：首页推荐、相似剧推荐，是系统的核心产出
• 管理模块：后台维护短剧信息、上下架管理
• 统计模块：播放量、评分数据的简单统计展示

功能边界按照这个拆，好处是每个模块的职责单一，后面写代码、写文档、做测试都清晰。我做项目的时候习惯先把模块图画出来，哪怕只是手画在草稿纸上，也能避免写着写着逻辑乱掉。

2. 数据库设计与推荐逻辑实现

2.1 五张核心表的字段与关系

数据库是一个推荐系统的基础。表结构设计得合理，后面写SQL和推荐逻辑都会顺手很多。我这边的核心表是五张，但推荐结果表和用户偏好表是后面为了推荐逻辑后加的，一开始只有用户、短剧、行为三张表。先看核心的三张表结构：

用户表非常简单，但用户名必须有唯一索引，这是注册接口防重的关键。密码用MD5加盐存储，不要存明文。

短剧表的设计是推荐系统的关键。字段里我要特别说一下tags这个字段，它存的是逗号分隔的标签字符串，比如“甜宠,都市,逆袭,爽剧”。用逗号分隔而不是单独建一张标签表，在数据量不大的场景下查询和计算最简单，后面的推荐逻辑可以直接基于字符串拆解来实现。但如果你预期短剧量会非常大，建议建独立的标签表和关联表，空间换规范化。

用户行为表是推荐系统最重要的数据来源。behavior_type字段我用1、2、3、4分别代表播放、点赞、收藏、评分，其中评分行为会额外在score字段写入1-10的数值。这个表一定要给user_id和drama_id建联合索引，因为推荐逻辑里最频繁的查询就是“这个用户对哪些剧产生了行为”，没有索引的话数据量上来会慢很多。

2.2 核心表字段说明

在写建表脚本时，我遇到过几个实际问题，值得拿出来说。第一个是MySQL 5.7和8.0对varchar排序规则的处理不同，如果需要在短剧名称上做排序，建议直接把表的默认字符集设置成utf8mb4，排序规则用utf8mb4_unicode_ci，省去很多乱码和排序异常的麻烦。第二个是create_time字段统一用datetime类型，不建议用timestamp，因为timestamp有2038年问题，而且datetime的可读性更好。第三个是短剧表的status字段，默认值是1表示上架，0表示下架，管理后台操作的就是这个字段，而不是物理删除数据，因为用户行为表里已经用到了drama_id，物理删除会导致关联数据悬空。

2.3 推荐逻辑怎么落地：从标签匹配到多因子打分

推荐算法是这个系统里最核心的部分，也是面试时最能讲出亮点的地方。我采用的是“基于标签偏好的内容推荐”，本质上是一个加权的多因子打分模型。核心思想是：先从用户历史行为中统计他最偏好哪些标签，然后对候选短剧按标签重叠度打分，最后叠加热度因子，排序后取前N个。

第一步，从行为数据中统计用户标签偏好。做法是把用户播放过的短剧的tags字段拆开，统计每个标签出现的次数。这个操作在SQL里就能完成，用SUBSTRING_INDEX函数来回拆字符串：

sql复制SELECT tag, COUNT(*) AS cnt
FROM (
    SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(d.tags, ',', n.n), ',', -1) AS tag
    FROM user_behavior ub
    JOIN short_drama d ON ub.drama_id = d.id
    CROSS JOIN (
        SELECT 1 AS n UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5
    ) n
    WHERE ub.user_id = #{userId} AND ub.behavior_type IN (1, 2, 3)
) t
GROUP BY tag
ORDER BY cnt DESC

这个SQL的关键在于CROSS JOIN一个数字序列，把tags字段按逗号拆成多行。注意如果标签可能超过5个，需要把UNION的序列扩展到足够大的数字。

第二步，在Java代码里计算候选剧的得分：

java复制public List<RecommendedDramaDTO> getRecommendList(Long userId, int limit) {
    // 1. 获取用户标签偏好
    Map<String, Integer> tagPref = behaviorMapper.selectTagPreference(userId);
    if (tagPref.isEmpty()) {
        // 冷启动策略：按热度推荐
        return dramaMapper.selectHotDramas(limit);
    }
    
    // 2. 取所有上架的短剧作为候选集
    List<Drama> candidates = dramaMapper.selectAvailableDramas();
    List<RecommendedDramaDTO> result = new ArrayList<>();
    for (Drama drama : candidates) {
        // 3. 计算标签匹配得分
        double matchScore = tagMatchScore(drama.getTags(), tagPref);
        if (matchScore <= 0) {
            continue;
        }
        // 4. 叠加热度因子
        double hotScore = normalize(drama.getPlayCount()) * 0.2;
        RecommendedDramaDTO dto = new RecommendedDramaDTO(drama, matchScore + hotScore);
        result.add(dto);
    }
    
    // 5. 按得分降序，截取 top N
    result.sort((a, b) -> Double.compare(b.getScore(), a.getScore()));
    return result.subList(0, Math.min(limit, result.size()));
}

tagMatchScore方法的实现如下：遍历短剧的每一个标签，如果命中用户偏好，就把对应的偏好权重累加。假设用户看了5部甜宠剧、3部悬疑剧，那么甜宠的权重就是5，悬疑是3，一部同时带甜宠和悬疑标签的剧，得分就是5+3=8。

java复制private double tagMatchScore(String tags, Map<String, Integer> tagPref) {
    if (tags == null || tags.isEmpty()) {
        return 0;
    }
    double score = 0;
    for (String tag : tags.split(",")) {
        tag = tag.trim();
        if (tagPref.containsKey(tag)) {
            score += tagPref.get(tag);
        }
    }
    return score;
}

热度因子用的是播放量归一化，目的是让那些播放量特别高的剧即使标签匹配度一般，也能有机会出现在推荐位。这里权重的选择我调过几次，最后发现标签匹配得分占80%、热度占20%的效果比较合理，纯标签匹配容易让推荐结果太窄，加上热度之后覆盖面更广。

2.4 冷启动问题的处理

冷启动是推荐系统绕不开的问题。新用户没有任何行为数据，直接跑上面的逻辑会得到空推荐列表，所以必须有一个兜底策略。我的做法是：用户行为表里查不到任何记录时，直接按播放量排序取热门剧推荐。这个策略简单有效，也符合用户预期——新用户进来看到的是大家都在看的剧，转化率不差。

还有一个容易忽略的点：短剧库里如果新增了剧但还没有播放量，热门推荐永远轮不到它，这会导致长尾内容没有曝光。我的处理是在SQL里加一个时间衰减因子，最近上架的剧在热度排序里给一个权重加成，代码里就是一个CASE WHEN语句：

sql复制SELECT * FROM short_drama
WHERE status = 1
ORDER BY play_count * 
    CASE WHEN create_time > DATE_SUB(NOW(), INTERVAL 7 DAY) 
         THEN 1.5 ELSE 1 END DESC
LIMIT #{limit}

2.5 推荐结果缓存表的作用

每次用户刷新首页都重新计算一遍所有候选剧的得分，在数据量小的时候没问题，但数据量大了性能会很差。我用了一张recommend_result表做缓存：推荐计算完成后，把结果按用户维度批量写入这张表，下次请求直接查表返回，只在行为发生变化或者缓存过期时才重新计算。这样既保证了响应速度，推荐链路也不会因为用户请求频繁而重复计算。这张表的reason字段很有用，它记录了推荐理由，比如“因为您喜欢甜宠”，前端可以直接展示，用户会觉得这个推荐系统“懂我”，体验感提升很多。

3. 核心代码实现与讲解思路

3.1 标准SSM项目结构

项目的包结构是按照三层架构拆的，这个结构在课程设计和毕业设计里也是最标准的写法：

code复制com.drama.recommend
├── controller
│   ├── UserController.java
│   ├── DramaController.java
│   ├── RecommendController.java
│   └── AdminController.java
├── service
│   ├── UserService.java
│   ├── DramaService.java
│   ├── RecommendService.java
│   └── BehaviorService.java
├── mapper
│   ├── UserMapper.java
│   ├── DramaMapper.java
│   ├── BehaviorMapper.java
│   └── RecommendMapper.java
├── entity
│   ├── User.java
│   ├── Drama.java
│   ├── Behavior.java
│   └── RecommendResult.java
├── common
│   ├── Result.java
│   └── PageResult.java
└── util
    ├── MD5Util.java
    └── RecommendUtil.java

各层之间严格单向依赖：Controller调Service，Service调Mapper，不让跨层调用。这个是SSM项目的铁律。你可能会觉得多写一层接口很麻烦，但一旦逻辑复杂起来，比如推荐模块既需要查行为表又需要查短剧表还要写缓存表，你就知道Service层拆业务、Mapper层管SQL这种分层方式有多好维护了。

3.2 推荐接口的完整调用链路

前端调推荐接口的时候，整个请求流转链路是这样的：

1. 浏览器发送 GET /recommend/list?userId=1
2. DispatcherServlet 根据请求路径找到 RecommendController 的对应方法
3. RecommendController 调用 RecommendService 的 getRecommendList
4. RecommendService 先查 recommend_result 缓存表，有就直接返回
5. 缓存没有就调 BehaviorMapper 查用户偏好，再调 DramaMapper 查候选集
6. 计算得分后批量写入缓存表，最后返回 JSON 给前端

这个过程中有一个关键点：推荐的触发时机。我没有选择每次请求都实时计算，而是做定时任务，在用户行为发生变化后异步更新推荐结果。具体实现是，用户产生播放行为时，BehaviorService 在记录行为之后发一个信号，RecommendService 单独线程重新计算该用户的推荐。这样用户感知不到计算耗时，体验好很多。

前端拿到的是封装好的Result对象，统一格式是：

json复制{
  "code": 200,
  "message": "success",
  "data": {
    "list": [
      {
        "dramaId": 12,
        "title": "重生之我在都市当大佬",
        "tags": "都市,逆袭,爽剧",
        "coverUrl": "/upload/cover/12.jpg",
        "score": 8.6,
        "recommendReason": "因为您喜欢都市、逆袭"
      }
    ]
  }
}

3.3 MyBatis动态SQL的几个实用写法

SSM项目里MyBatis的使用是重头戏。条件查询肯定要写动态SQL，用标签可以自动处理第一个条件前面的AND问题。比如管理后台分页筛选短剧：

xml复制<select id="searchDramas" resultType="com.drama.recommend.entity.Drama">
    SELECT * FROM short_drama
    <where>
        <if test="keyword != null and keyword != ''">
            AND (title LIKE CONCAT('%', #{keyword}, '%') 
                 OR tags LIKE CONCAT('%', #{keyword}, '%'))
        </if>
        <if test="status != null">
            AND status = #{status}
        </if>
    </where>
    ORDER BY create_time DESC
    LIMIT #{offset}, #{pageSize}
</select>

批量插入推荐结果时，用实现批量写，避免循环单条插入导致频繁提交：

xml复制<insert id="batchInsertRecommendResults">
    INSERT INTO recommend_result (user_id, drama_id, reason, score) VALUES
    <foreach collection="list" item="item" separator=",">
        (#{item.userId}, #{item.dramaId}, #{item.reason}, #{item.score})
    </foreach>
</insert>

这些写法看上去很基础，但实际写项目时会发现，动态SQL的好坏直接决定查询效率，而且面试时MyBatis动态SQL几乎是必问题，提前在项目里用熟了，面试时不用背都能讲出来。

3.4 代码讲解文档怎么组织

这个项目拿到手之后，代码讲解是一个大活。我的建议是代码讲解文档不要按“每一个类怎么实现”来写，那样读者和答辩老师都会晕。正确的组织方式是按业务链路讲：

• 登录注册链路：从UserController到UserService再到UserMapper，重点讲Session处理、密码MD5
• 推荐链路：从行为采集到偏好统计到得分计算，重点讲推荐算法
• 管理后台链路：从AdminController到DramaService，重点讲动态SQL和上下架状态

每一段要配合关键的代码片段、核心逻辑解释、为什么这样设计，这样读者才能真的理解，而不是只能照着抄。

4. 从源码到部署的完整流程

4.1 本地环境准备

部署用的是经典组合，这套版本组合已经经过大量验证，别轻易换版本组合，换了容易踩版本兼容的坑：

Maven安装后一定要检查一下settings.xml里的镜像源，国内环境建议配阿里云镜像，不然下载依赖会慢到怀疑人生。JDK安装后配好JAVA_HOME和PATH，在命令行执行java -version确认成功。

4.2 数据库初始化

部署时先把数据库和表结构建好。我项目里提供了一个db.sql脚本，包含建库、建表、插入测试数据三部分内容。执行顺序是：

bash复制mysql -u root -p < db.sql

这里最容易犯的错误是直接拿脚本去MySQL 8.0执行但脚本里带了MySQL 5.7的语法，导致报错。我的建议是脚本里避免使用MySQL 5.7和8.0差异较大的语法，如果用了，就要在部署文档里明确标注支持的版本。

4.3 配置文件修改要点

SSM项目的配置集中在几个文件里，部署时最常改的是数据库连接配置。我的db.properties里重点要注意这几点。

properties复制jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/drama_recommend?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
jdbc.username=root
jdbc.password=123456

第一个坑是MySQL 8.0的驱动类名变成了com.mysql.cj.jdbc.Driver，原来的com.mysql.jdbc.Driver会报错。第二个坑是8.0必须指定serverTimezone参数，否则会报时区错误。如果你用的是5.7，这两个配置都不需要改，但加上也不会有问题。第三个坑是密码如果有特殊字符，比如@、#之类的，一定要做URL编码，否则连接字符串会解析失败。

Spring配置文件里，事务管理器用的DataSource必须和MyBatis用的DataSource是同一个实例。这是很多SSM项目部署后出现事务不生效问题的根源，因为配置了多个数据源实例导致事务管理器管不到MyBatis的连接。

4.4 Maven构建与Tomcat部署

项目根目录下执行构建命令：

bash复制mvn clean package

如果执行失败，先检查Maven的JDK版本是不是1.8，再看pom.xml里有没有依赖下载失败。构建成功后，target目录下会生成war包，把war包复制到Tomcat的webapps目录下，启动Tomcat：

bash复制cp target/drama-recommend.war /path/to/tomcat/webapps/
cd /path/to/tomcat/bin
./startup.sh

Tomcat启动时会自动解压war包。访问地址是http://localhost:8080/drama-recommend/，注意这里的应用名就是war包的文件名。如果你想换一个访问路径，改war包名就行。

生产环境部署时，Tomcat默认的8080端口如果需要换，改conf/server.xml里的Connector端口号，同时注意把防火墙对应的端口放行。内存紧张时可以在catalina.sh里加JVM参数：JAVA_OPTS="-Xms512m -Xmx1024m"，避免短剧数据量大时出现OutOfMemoryError。

5. 部署中的高频问题与排查技巧

5.1 数据库连接类问题

这类问题占部署故障的一大半。报错信息里看到Access denied，90%是账号密码错误或者权限不够，去MySQL里GRANT授权就能解决。看到Unknown database 'drama_recommend'，就是库没建，建库再导入脚本。看到Communications link failure，先ping一下数据库服务器，再看3306端口通不通，最后确认jdbc.url里的IP和端口有没有写对。

5.2 404与请求映射类问题

Tomcat能启动、页面能打开，但点任何功能都404，这种问题我遇到过很多次。几个排查顺序：第一，看浏览器请求的URL路径，确认项目名有没有带对；第二，看Controller类上有没有@Controller注解、方法上有没有@RequestMapping注解；第三，看DispatcherServlet在web.xml里配置的url-pattern是不是/或*.do，别配成/*，/*会把JSP请求也拦截掉，导致页面全部404；第四，看SpringMVC配置文件的组件扫描路径有没有覆盖Controller所在的包。

5.3 中文乱码问题

页面中文乱码，排查三个地方：第一，数据库连接URL是否带了characterEncoding=utf8参数，这个是最常见的；第二，数据库表和字段的字符集是不是utf8mb4，可以在数据库里执行SHOW CREATE TABLE short_drama\G查看；第三，SpringMVC的字符集过滤器有没有配置，要在web.xml里加：

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>
</filter>

还有一个容易被忽略的：IDEA里面文件本身的编码如果不是UTF-8，编译后都是乱码，这种情况下需要在pom.xml里设置project.build.sourceEncoding。

5.4 推荐结果为空的排查

如果你发现首页推荐位是空的，多半不是代码逻辑问题，而是数据问题。按三步排查：第一，很可能是当前用户没有任何行为数据，走的是冷启动逻辑，确认一下用户行为表有没有数据；第二，检查候选短剧的status字段，推荐逻辑只查status=1的剧，全下架了自然没结果；第三，看tags字段是不是空字符串，所有剧的tags都为空的话，标签匹配得分全是0。这几种情况在日志里都会有迹可循，把日志级别调到DEBUG就能定位。

6. 这套项目在面试与答辩中的讲法

6.1 一分钟讲清楚项目亮点

面试或者答辩的自我介绍环节，很多人讲项目容易讲成流水账。我的建议是直接按这个框架说：项目背景一句话，我的职责一句话，核心技术点两到三句话，难点和解决思路两到三句话。比如：

“我做的这个短剧推荐系统，是给短剧平台做内容分发用的，核心功能是根据用户的观看行为推荐感兴趣的内容。我主要负责推荐模块的设计和实现，技术栈是SSM。整个系统最大的难点是推荐逻辑的设计，我采用基于标签偏好的内容推荐方案，结合热度因子做多因子打分，同时用缓存表解决了重复计算的问题，对新用户场景设计了按热度推荐的冷启动策略。”

这段一分钟能讲完，但信息量很足，面试官基本能判断出你有真实做过项目，而不是背了几道面试题就来。

6.2 面试官可能会追着问的问题

做这个项目，你要对下面这些问题心里有数：

• 为什么推荐逻辑用标签匹配而不是协同过滤？答案：协同过滤需要大量用户行为数据，冷启动问题更严重，标签匹配更简单直接，适合中小型项目；同时可以强调协同过滤是一个可以迭代的方向。
• 用户标签偏好多久更新一次？答案：行为产生后异步更新，平时直接读缓存表。
• 如果短剧数量到了百万级，你这个推荐逻辑还跑得动吗？答案：跑不动，我会加Redis缓存标签与热门榜单，推荐计算从全表扫描改成走索引范围查询，更进一步的方案是引入Elasticsearch做内容检索与评分。
• SSM的Controller是单例还是多例？答案：单例，这也是为什么不能在Controller里定义可变成员变量，因为线程不安全。

这些问题提前自己想清楚，面试时就不会被问住。

6.3 后续可以做的扩展方向

项目做完不意味着结束，扩展方向反而更能展示你的思考深度。最简单的扩展是把SSM升级成Spring Boot，配置方式变了，但业务逻辑不需要重写；推荐方面可以升级成基于用户的协同过滤，用和当前用户行为最像的人群来推荐；性能方面把热门榜和推荐结果缓存到Redis，查询响应能从百毫秒级降到个位数毫秒级；前端可以用Vue3重构成前后端分离，JSON接口已经都是现成的了，基本上不用改后端代码。

我个人在实操中最深的体感是：这类系统最容易翻车的地方其实不是代码，而是数据库和部署环境这两块。很多同学代码写得很溜，一到环境配置就各种连不上、起不来、跑不动。所以我每做一个项目都建议多写几遍部署文档，每一次从零开始部署都能帮你发现一堆之前没意识到的依赖关系。这个短剧推荐系统整体做完，你对SSM框架的认识、对推荐系统基本形态的理解、对部署运维的熟悉程度，都会明显上一个台阶。