Java SSM 整合 Flask 电影推荐系统设计与实现

开始做这个题目之前，我以为"经典电影推荐网站"就是做个电影列表页加个搜索框，把后台的增删改查写完就能交差。真正上手之后才发现，基于 Java+SSM 把业务主站做出来只是第一步，后面用 Flask 写推荐引擎、让两个技术栈能在一个项目里稳定协作，才是整套系统里最容易翻车也最值得写进论文的地方。这篇文章就是我在完成这个项目过程中沉淀下来的完整路线，包括架构选型、数据建模、推荐算法实现、跨语言接口联调、调试文档和论文写作的经验。如果你也在做同题的毕业设计、课程设计，或者单纯想搞明白"Java 网站怎么和 Python 算法服务配合"，可以直接照着这条路走。

1. 一个非典型架构：SSM 管业务、Flask 管算法，这样的分工合理吗

1.1 这个题目的真正难点不在页面，而在"推荐"两个字

我见过不少同学拿到"电影推荐网站"这个题目之后，直接把重心放在页面美化上：换模板、改 CSS、调轮播图，觉得自己做了一个挺漂亮的网站，结果答辩时老师一句"你的推荐算法在哪里体现"，整个人就愣住了。

说实话，电影信息展示、用户注册登录、后台管理这些功能，任何一个 CRUD 框架都能做，SSM 里有 Spring 管对象、SpringMVC 管路由、MyBatis 管数据库，这套组合完成这些需求实在太成熟了。但这个题目的名字里写着"推荐"，就意味着系统必须有一个能根据用户行为产出个性化结果的模块。如果只是按评分倒序展示，那叫排行榜，不叫推荐网站。

所以我一开始就给自己定了一个原则：业务功能用 SSM 做扎实，推荐算法必须独立成模块，而且要有完整的计算链路——用户看过的电影、打过的分数、收藏过的片单，这些数据要被算法真正用起来。这样一来，论文里有算法模型可以写，系统里有真实的数据流可以讲，演示的时候也有亮点可以展示。

1.2 技术栈分工：Java 处理用户与内容管理，Python 处理算法

选型的时候，我确实纠结过要不要全程用 Java，因为大部分课程设计都是一套技术打到底。后来算了一笔账：如果用纯 Java 做协同过滤，意味着要手动实现矩阵运算、相似度计算、排序，这些在 Python 里用 pandas 加 numpy 几行就搞定了，在 Java 里却要写大量样板代码，而且调优起来非常费劲。

最终定下的方案是双引擎结构：

• SSM（Spring + SpringMVC + MyBatis）负责主站：电影展示、用户登录、收藏、评分、后台管理、页面渲染；
• Flask 作为独立的推荐服务：读取用户行为数据，运行推荐算法，对外暴露 RESTful API，返回推荐结果列表；
• 两者通过 HTTP 接口通信，Java 主站收到请求后调用 Flask 的接口，拿回推荐电影 ID 列表再去数据库查明细。

这种架构最大的好处是职责清晰。算法模型可以单独测试、单独部署，不用每次改一个相似度公式都要重新编译整个 Java 项目。而且答辩的时候，老师问到"你了解微服务吗"，你可以说这个项目就是一次轻量级的服务拆分实践，这在课程设计里是很加分的点。

1.3 环境与版本选型，踩过的坑先从版本说起

双引擎结构听起来不错，但版本搭配如果不注意，后面全是连锁问题。我的环境是这样的：

• JDK 8 + Maven 3.6 + Tomcat 8.5，这是个非常稳的组合，网上资料最多，出了问题最好搜答案；
• Spring 4.3.18，SpringMVC 4.3.18，MyBatis 3.4.6，mybatis-spring 1.3.3，这个组合和 JDK 8 配合很成熟；
• MySQL 5.7，连接驱动 mysql-connector-java 5.1.49；
• Python 3.8 + Flask 2.0.3 + pandas 1.5.3 + numpy 1.24.4。

有两点想特别提醒。第一，不要一上来就用 Spring Boot，虽然市面主流已经到了 Boot，但经典 SSM 项目的课本和论文结构基本都是围绕配置文件展开的，用 Boot 反而写不出那种"我理解 Spring 容器"的感觉。第二，Flask 2.x 之后有些配置写法变了，比如返回 JSON 时中文的处理方式从app.config['JSON_AS_ASCII'] = False改成了app.json.ensure_ascii = False，这个问题在第四部分我会专门讲，当初我在这里卡了很久。

2. 经典片库与数据建模：想要推荐结果像样，数据表先得像样

2.1 数据来源：公开数据集为主，手工补充片库信息

经典电影推荐网站最怕的是什么？是数据太少、太假。如果数据库里只有二三十部电影，协同过滤算法根本跑不出有意义的结果，因为用户之间的共同评分项太稀疏。所以数据这部分值得下功夫。

我采用的是公开数据集为主、手工整理为辅的方案。公开数据集方面，MovieLens 是最合适的，它有完整的用户评分数据，包含用户 ID、电影 ID、评分、时间戳，历史上被大量论文使用，拿来做课程设计的数据支撑非常有说服力。我导入了它的部分数据，然后把电影详情——片名、导演、主演、类型、年份、简介、海报——通过整理补充到自己的数据库里。

这里有一个关于"经典"的筛选逻辑。经典电影不等于任何高分电影，它通常有两个特征：一是上映时间较长但评分保持稳定，二是在各大影史榜单中反复出现。我实际采用的是"高分 + 年份 + 榜单交叉"的规则，简单来说就是评分大于等于 8.0、上映年份在 2005 年之前、且出现在 IMDb Top 250 或同类公开榜单里的电影优先录入。这样整个片库自带"经典"属性，而不是随便堆一批热门新片。

2.2 核心表结构设计（附字段说明）

数据建模阶段我设计了四张核心表，下面直接给出字段和说明，后续写代码的时候你也少走弯路。

另外我还建了 user_comment 表和 admin 表，评论区让页面更完整，后台管理则是课程设计需求分析里必不可少的功能。不过推荐算法主要依赖前三张表，尤其是 user_rating。

写 SQL 的时候注意给 user_rating 加联合唯一约束UNIQUE KEY uk_user_movie (user_id, movie_id)，这样同一个用户对同一部电影不会插入重复评分，业务层也不需要额外判重。这个约束我在第一次测试时就踩到了，代码里没判重，手动重复点击评分导致数据出现两行，推荐结果一度变得很奇怪。

2.3 热门榜单背后的 SQL 逻辑

排行榜数据在首页和"高分电影"频道都要用。最简单的实现是：

SELECT id, title, rating, rating_count, poster_url FROM movie ORDER BY rating DESC, rating_count DESC LIMIT 20;

这个 SQL 看起来没问题，但实际体验会有偏差：一部只有三个人打分、分数 9.9 的小众电影会排在两万人打分 9.3 的经典电影前面，用户一看榜单会觉得这个系统不靠谱。所以我加了评分人数门槛：

SELECT id, title, rating, rating_count, poster_url FROM movie WHERE rating_count >= 1000 ORDER BY rating DESC, rating_count DESC LIMIT 20;

这就是所谓的 "IMDb 加权公式"的简化版思路：平均分高但评分人数太少的数据要被过滤掉。如果你想让论文更有深度，可以把评分人数阈值写成一个可配置参数，甚至引入贝叶斯平均，比如(avg_rating * min_votes + rating * rating_count) / (min_votes + rating_count)这样的加权公式。这部分内容放到论文里，既能体现你懂工程，又能体现你懂基础算法。

3. 推荐引擎在 Flask 侧的落地：从冷启动到协同过滤

3.1 先做热度榜：让系统第一版就能用

Flask 服务在项目里的定位是"算法服务"，但一开始我并没有直接上协同过滤，而是先把热度榜接口做出来。原因很实际：推荐服务要配合 Java 主站联调，如果第一版就上复杂模型，出了问题根本分不清是算法问题还是接口问题。先把最简单的接口跑通，确认 Java 能调到 Flask、JSON 能正常解析，再往里面换更复杂的算法，调试成本会低非常多。

热度榜接口就是一个纯粹的 SQL 查询加 JSON 返回：

@app.route('/api/hot', methods=['GET']) def hot(): rows = db.query( "SELECT id FROM movie " "WHERE rating_count >= 1000 " "ORDER BY rating DESC, rating_count DESC LIMIT 20" ) return jsonify({'code': 0, 'data': [r['id'] for r in rows]})

这个接口只返回电影 ID 列表，不返回电影完整信息。原因后面说，完整信息由 Java 主站去数据库里拿，推荐服务只负责"推荐什么"，不负责"长什么样"。这个约定在联调阶段省了我大量功夫。

3.2 基于物品的协同过滤：用 Python 写出核心算法

热度榜跑通之后，我开始实现真正体现"推荐"价值的基于物品协同过滤（Item-based Collaborative Filtering，简称 ItemCF）。思路一句话就能讲清楚：如果一个用户喜欢 A 电影，而 A 电影和 B 电影在大量用户的评分行为中表现相似，那就把 B 推荐给这个用户。你把它理解成"物以类聚"，协同过滤就是通过全体用户的行为来计算这种聚类关系。

核心步骤分成两步：第一步计算电影之间的相似度矩阵，第二步根据用户历史评分，用相似度加权算出候选推荐列表。

先写相似度计算：

import pandas as pd import numpy as np def load_rating_data(): df = pd.read_csv('data/ratings.csv') # 字段: user_id, movie_id, rating return df def compute_item_similarity(df): # 构造用户-电影评分矩阵，行为用户，列为电影 pivot = df.pivot_table(index='user_id', columns='movie_id', values='rating') pivot = pivot.fillna(0) # 转置后，每一行是一部电影的评分向量 item_matrix = pivot.T.values # 计算余弦相似度 norm = np.linalg.norm(item_matrix, axis=1, keepdims=True) norm[norm == 0] = 1e-6 item_sim = (item_matrix @ item_matrix.T) / (norm @ norm.T) return item_sim

注意几点。第一，填零这种处理方式对课程设计完全够用，但严格来说它会把"用户没看过"当作"用户不喜欢"，在真实工程里要用均值填充或者不填直接算，不过对演示效果影响不大。第二，矩阵维度是电影数量 x 电影数量，几百部电影的时候毫无压力，但如果导入 MovieLens 完整数据上万部电影，这个内存就会膨胀，所以我实际只保留了评分人数多的电影再算相似度矩阵，既减少计算量，也过滤掉噪声。

然后是推荐函数：

def recommend_by_user(user_id, top_n=12): sim = item_sim # 预先计算好的相似度矩阵 movie_ids = list(pivot.columns) # 与矩阵索引对应 # 取用户评分记录 user_ratings = pivot.loc[user_id] rated = user_ratings[user_ratings > 0].index.tolist() scores = user_ratings[user_ratings > 0].values.tolist() score_dict = {} for i, mid in enumerate(rated): mid_idx = movie_ids.index(mid) for j in range(len(movie_ids)): if movie_ids[j] in rated or movie_ids[j] in score_dict: continue score_dict[movie_ids[j]] = score_dict.get(movie_ids[j], 0) + sim[mid_idx][j] * scores[i] ranked = sorted(score_dict.items(), key=lambda x: x[1], reverse=True) return [int(mid) for mid, _ in ranked[:top_n]]

这个版本的逻辑非常直观：用户给高分电影权重越大，相似电影就越容易被推荐。它的效果在数据量小的时候会有一些粗糙，但正因为逻辑简单，论文里好解释，答辩时老师问每一步在干什么，你能把公式和代码对得上，这一点比堆一个花哨的深度学习模型重要得多。

3.3 冷启动、稀疏矩阵与算法降级

算法上线后第一个要面对的问题是冷启动。一个刚注册的新用户，没有任何评分记录，pivot 表里自然也没有他的行，pivot.loc[user_id]直接抛 KeyError。我的处理方式很简单：接口内部先判断用户是否有评分记录，如果没有，就返回热度榜结果。

@app.route('/api/recommend', methods=['GET']) def recommend(): user_id = int(request.args.get('user_id')) if user_id not in pivot.index.tolist(): result = hot_ids() # 回退到热度榜 else: result = recommend_by_user(user_id) return jsonify({'code': 0, 'data': result})

这就是"算法降级"，先保证接口永远有数据返回，再保证数据是个性化的。演示的时候这也是一个很好的讲解点：你不是只会写算法，你还知道算法在什么情况下会失效，并且设计了兜底策略。

稀疏矩阵的问题也要提一下。如果用户数少、电影数多，评分矩阵里大部分是零，相似度会偏向那些"恰好被同一个人看过"的电影，推荐结果十二部里可能八部都是同一个类型。我实际解决的办法是给相似度加权：相似度乘以"共同评分人数"的对数。sim = sim * np.log1p(co_rated_count)，原理是共同评分的人数越多，余弦相似度越可信。这个细节写进论文，会显得你是真正调过模型的。

4. Java 与 Flask 的接口对接：把推荐结果变成页面上的一排卡片

4.1 接口契约：路径、参数与返回结构的约定

跨语言联调最忌讳的就是两边各写各的，等到对接口的时候才发现字段名对不上。我做的第一件事是先把接口契约写在一个文档里，Java 和 Flask 两边都照着这个文档开发。

这里我踩过一个值得说的坑：第三版接口本来想直接让 Flask 把电影详情、海报、评分全都返回，Java 端直接渲染页面。后来发现不对，海报和简介这些数据在 MySQL 里，如果 Flask 也要查这些数据，等于要为 Flask 单独配一套数据库访问逻辑，服务之间的边界一下就乱了。后来我把接口收敛成"Flask 只返回电影 ID 数组"，电影详情统一由 Java 主站查询数据库填充。事实证明这个设计让两边都变得非常干净。

4.2 Java 侧调用推荐接口的三种方式与推荐选择

SSM 项目里调用外部 HTTP 接口，常见的有三种：原生 HttpURLConnection、Apache HttpClient、Spring 的 RestTemplate。我最早用 HttpURLConnection 写了一个工具类，代码又长又容易漏关连接，后来换成 RestTemplate，清爽多了。

先配置一个 RestTemplate Bean：

<bean id="restTemplate" class="org.springframework.web.client.RestTemplate"> <property name="requestFactory"> <bean class="org.springframework.http.client.SimpleClientHttpRequestFactory"> <property name="connectTimeout" value="3000"/> <property name="readTimeout" value="5000"/> </bean> </property> </bean>

再写一个调用推荐的 Controller：

@Controller @RequestMapping("/recommend") public class RecommendController { @Autowired private RestTemplate restTemplate; @Autowired private MovieMapper movieMapper; @RequestMapping("/list") public String recommendList(Integer userId, Model model) { String url = "http://127.0.0.1:5000/api/recommend?user_id=" + userId + "&top_n=12"; RecommendResult result = restTemplate.getForObject(url, RecommendResult.class); List<Integer> movieIds = result.getData(); List<Movie> movies = movieMapper.selectByIds(movieIds); model.addAttribute("movies", movies); return "recommend"; } }

这里有两个细节。第一个是超时配置，默认 RestTemplate 的读取超时是无限等待，如果 Flask 服务没启动，Java 请求会一直挂着，页面白屏几分钟，答辩现场遇到这种状况非常尴尬。设了 3000 毫秒连接超时和 5000 毫秒读取超时之后，最坏情况是页面报一个"推荐服务暂不可用"，而不是一直转圈。第二个是失败兜底，我在真实项目里还加了一个 catch 逻辑，一旦调用 Flask 失败，就自动降级为查数据库热度榜，页面始终有内容展示。

4.3 联调中绕不开的三个经典错误

第一个是中文乱码。Flask 2.x 返回 JSON 时默认会把中文转成\u7535\u5f71这样的 Unicode 转义序列，Java 端解析后其实是正常的，问题不大。真正出乱码的是 Java 端调用时，如果两边都用 UTF-8，正常不会乱。出问题更常见的场景是 MySQL 连接 URL 没带编码参数。我最终的 JDBC 连接是：

jdbc:mysql://localhost:3306/movie_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

少了 characterEncoding 这一项，电影简介里的中文插入数据库再查出来就全是问号，这个问题很隐蔽，因为代码层面完全看不出问题，只在数据层面烂了。

第二个是端口与跨域问题。Tomcat 跑在 8080，Flask 跑在 5000，如果前端页面里的 JavaScript 直接去请求 Flask 的接口，会因为端口不同产生跨域问题。我绕开了这个坑：前端只跟 Java 后端打交道，Flask 是被 Java 后端在服务端调用的，服务端请求不存在跨域限制。如果你非要做纯前端直连 Flask，记得装 Flask-CORS 插件，但课程设计建议走服务端转发，简单可靠。

第三个是 Flask 服务没有随系统启动的问题。开发环境还好，Tomcat 一启动你手动开一下 Flask 就行，但答辩的时候两台电脑来回切换，很容易忘记哪台机器没起 Flask。我的解决办法是写一个 start.bat 启动脚本，里面依次启动 MySQL、Flask、Tomcat，答辩演示前双击一次就行，这个小细节在关键时刻非常救命。

5. 调试文档、LW 论文与答辩演示：项目做完并不等于能拿高分

5.1 调试文档的写法：记录现象、根因与验证

题目带了"调试文档"，很多人不知道这东西到底要写什么。我的理解是：调试文档不是操作日志，而是面向"重新走查"的记录，要能回答三个问题——出了什么问题、为什么会出、怎么证明它解决了。

我实际用这种格式记录：

这个例子很有代表性，N+1 问题是 SSM 项目里最容易出现也最好讲的性能问题。答辩时你把这张表往 PPT 上一放，老师立刻知道你具备了基本的性能调优意识。纯功能演示谁都能做，但能把一个具体问题的来龙去脉讲清楚，才真正拉开差距。

5.2 LW（论文）的写作顺序与核心图表

LW 论文最忌讳的是从第一章开始写，写到最后一章发现系统功能变了，前面全部要改。我的习惯是：先写数据库设计和接口设计，再写系统实现和测试，最后回头写绪论和相关技术。因为系统实现才是你真正做过的内容，先把确定的内容写扎实，绪论里引用什么、背景怎么写都变得很自然。

论文里必放的三类图：系统架构图、数据库 ER 图、推荐算法流程图。系统架构图重点展示 SSM 和 Flask 的分工；ER 图把 movie、user、user_rating、user_favorite 之间的关系画清楚；推荐算法流程图画的是请求进来之后怎么判断冷启动、怎么查相似度、怎么排序返回。这三张图放上去，整篇论文的骨架就立住了。

有些同学会担心，基于物品的协同过滤算法会不会太简单，显得论文没分量。实际上这个算法在工业界也是长期使用的基础方案，比它复杂的模型未必在几千条数据上表现更好。你可以在论文里加一段"算法适用性分析"：小规模数据集上矩阵计算开销小、结果可解释性强，这恰恰是经典项目的优势。

5.3 答辩演示的数据准备与讲解节奏

系统做完了，讨论最容易被忽略的是演示数据。你直接用自己测试时的账号登录，推荐结果可能是一堆你看过测试过程中随手打的分数，效果不直观。我特意准备了两个演示账号：

• 账号 A：只给老片、文艺片打了高分，刷新推荐页，出来的应该是以这类电影为主的列表；
• 账号 B：只给科幻、动作片打了高分，推荐结果类型特征要非常明显。

这两个账号的数据是我精心构造的，评分数量在十部左右。演示的核心目的是让老师一眼看出"不同用户看到的推荐结果是不同的"，所以对比演示优于单个演示。先登账号 A 拍一张推荐页截图，再登账号 B 再拍一张，两张图放在 PPT 里进行对比，比现场切账号更快、更直观。

讲解节奏上，我建议按"架构说明 -> 数据库 -> 算法 -> 页面走查"来走，但算法部分不要一上来就讲公式，先讲一个具体例子：这个用户给《肖申克的救赎》打了高分，系统通过相似度矩阵发现《阿甘正传》和它被大量相同用户喜欢，于是把后者推荐了出来。先讲直觉，再补公式，评审老师更容易跟上。

最后再分享一个小技巧，调试的时候一定养成看日志的习惯，Flask 端用 print 打印关键中间结果，Java 端在 MyBatis 的配置里打开 SQL 日志输出。我很多次排查问题，最后都是靠两边日志时间戳对比定位出来的——比如 Flask 明明算出了结果，Java 却报超时，一看是 RestTemplate 配置问题；比如推荐结果出现重复电影，一看是去重逻辑写在了排序之后。日志不会骗人，它比任何调试工具都直观。这个项目做完之后，我自己最大的体会是：双技术栈并没有增加多少工作量，反而让算法和业务边界变清晰了。希望这条路线能让你少走几步弯路。