Python协同过滤电影推荐系统：算法原理与课程设计全流程指南

简介：一套基于Python与协同过滤算法的电影推荐系统完整项目资料，针对计算机相关专业毕业设计、课程大作业及推荐系统入门学习者。后端采用Django框架，数据存储使用MySQL，按管理员与用户双角色设计，覆盖电影分类、信息管理、评分与个性化推荐等核心业务；管理员可处理个人中心、用户管理、电影分类与评分、系统管理等模块，用户侧支持注册登录及评分浏览。压缩包共690个文件、21.8MB，其中py/pyc为后端逻辑，vue/js/css/svg等构成前端界面，sql为数据库脚本，mp4为操作演示视频，doc为万字论文，bat脚本便于一键安装运行。项目已通过本地编译调试，可复现运行，并同时提供数据库、文档与演示视频，有助于理解协同过滤推荐流程、Django项目结构与完整开发思路。已有58人学习下载，适合需要完整可运行范例或高分大作业参考的读者。

1. 为什么课程设计都选python协同过滤电影推荐：先看懂这道题在考什么

期末周拿着“基于python和协同过滤算法的电影推荐系统”这个题目，多数人第一反应是去搜源码，但真正决定你能不能拿高分的是另一件事：你清不清楚这道题在考什么。它考的既不是python语法，也不是推荐算法本身，而是“数据、算法、工程、文档”四件事能不能串起来。用python做数据清洗和接口，用协同过滤算法做评分预测，用数据库存用户和评分，最后用论文和视频把过程讲清楚。

对做课程设计的学生来说，这个题目的价值在于它复杂度适中：不用GPU，不用深度学习的黑匣子，普通笔记本电脑就能跑完整流程；但又比单纯的管理系统多了一个算法核心，答辩时有的讲。对想转行做推荐方向的人来说，这是入门用户行为建模成本最低的实践路径。一句话：这个题能让你在一周内体验一个推荐系统从数据到上线的完整链路。

2. 协同过滤电影推荐的算法底子：相似度公式、UserCF与ItemCF怎么选

2.1 先把“协同过滤”这个词翻译成人话：评分预测公式

推荐系统里最朴素的一条假设是：相似的人会喜欢相似的东西。协同过滤就是把这个假设变成公式。你不用训练一堆参数，也不用反向传播，只需要把用户对电影的评分当成一个稀疏矩阵，然后在里面找“邻居”。

矩阵的每一行是一个用户，每一列是一部电影，交叉点是对应评分。问题是这个矩阵95%以上都是空的，用户不可能看完所有电影。协同过滤要做的，就是预测那些空格里的值，然后把预测分最高的N部电影推荐出去。

最常见的UserCF预测公式长这样：

pred(u,i) = r̄_u + (∑_{v∈N(u)} sim(u,v) × (r_{v,i} − r̄_v)) / (∑_{v∈N(u)} |sim(u,v)|)

这里 r̄_u 是用户u的历史平均分，N(u) 是用户u的最近邻集合，sim(u,v) 是用户u和用户v的相似度。为什么要减去各自的平均分？因为不同用户的打分尺度不一样：有人习惯给3分，有人习惯给5分。去掉均值之后，剩下的就是“这个人相对自己口味的态度”，可比性更强。

相似度的计算一般用皮尔逊相关系数或者余弦相似度。皮尔逊在稀疏矩阵上对打分偏态更鲁棒，适合评分数据；余弦相似度更适合隐式反馈场景，比如“看过/没看过”。写最小复现代码时，用pandas自带的corr方法就能算出皮尔逊相关系数，不需要自己一格格遍历：

import pandas as pd # rating_df 至少包含 user_id, movie_id, rating 三列 pivot = rating_df.pivot_table(index='user_id', columns='movie_id', values='rating') user_sim = pivot.T.corr() # 按用户两两求皮尔逊相关系数 user_sim = user_sim.fillna(0) # 无共同评分视为不相似

逻辑说明：pivot把长表转成宽表，行是用户，列是电影，空值就是没评分。T是转置，corr在转置后按列计算，也就是按用户计算皮尔逊相关系数。fillna(0)在这一步是必须的，因为两个用户可能没有任何共同评过的电影，pandas会给出NaN，后续加权时NaN会被污染到整个推荐结果。

参数说明：corr默认使用皮尔逊，如果你的数据里有大量极端的1分和5分，皮尔逊会偏向这些极端值；可以先对评分做一次clip，把范围限制在1到5之间再算。后续如果要切换余弦相似度，可以用sklearn的cosine_similarity，但需要先把空值填成0，这会在稀疏矩阵上引入假信号，一般不建议直接套。

2.2 UserCF和ItemCF该选哪个：电影场景的对比

同样是协同过滤，基于用户的UserCF和基于物品的ItemCF在推荐逻辑上是反的。UserCF找“和我口味相似的用户”，把他们喜欢的电影推给我；ItemCF找“和我看过的电影相似的其他电影”，把相似电影推给我。电影推荐系统里，主流方案是ItemCF，原因有两个：第一，电影是相对稳定的物品，内容特征变化很慢，物品之间的相似度可以离线算好；第二，用户数量往往远大于电影数量，UserCF的用户相似度矩阵规模更大，更新成本更高。

但大作业场景里，UserCF依然是很多源码模板的主力，因为它好讲、好画图、好答辩。你需要做的是两种都实现，在论文里放一张对比表，让评委看到你理解它们的差异，而不是只会跑通一个。

我的建议是：主代码用UserCF跑通全流程，在实验章节用ItemCF做对照组。两者共用同一套评分矩阵，只是把转置方向换一下。如果你的数据库里电影表只有几百条记录，ItemCF的计算代价会小很多，推荐结果也更稳定。

2.3 读python源码前先翻哪三个文件

标题里带“源码”，但很多同学下完源码先点开app.py看界面，这是顺序错了。这类大作业源码无论用Django、Flask还是纯命令行，结构上都高度统一，先按这三个文件读，能省掉一半调bug的时间：

第一个是数据加载模块，常见的文件名是data_loader.py或者db.py。它的职责是从数据库或CSV文件里读取评分数据，转成pandas的DataFrame，并且保证user_id、movie_id、rating三个字段的类型正确。我遇到过很多次别的地方没问题、就是推荐结果全乱的情况，最后发现问题出在user_id被读成了字符串，导致pivot时一个用户被拆成了多行。

第二个是相似度计算模块，可能叫cf.py或recommend.py。这里会生成用户相似度矩阵或者物品相似度矩阵。你读的时候不用从头看，直接找三点：相似度用哪种公式、是否做了均值中心化、近邻数量N是怎么控制的。这三个参数直接决定推荐质量，也是最容易被答辩老师追问的地方。

第三个是主流程或接口层，比如main.py、app.py。它负责把推荐结果包装成“用户可读”的形式。注意看它怎么把最终的预测分排序、怎么去掉用户已经看过的电影。很多源码在这一步偷懒，直接返回全局热门榜，这就是你答辩翻车的地方。读到这个文件时，顺手确认一下它有没有过滤掉用户已经看过的电影。

读这三个文件的时间控制在半小时左右，别逐行读。你要带着“它要解决什么问题”这个视角去读，而不是把它当小说。

3. 在本地把源码跑通：Python环境、MySQL导入、最小推荐演示

3.1 Python环境准备：虚拟环境里装哪些依赖

动手第一步不是直接跑源码，而是建一个干净的python环境。用系统全局环境跑这类项目会踩到很多莫名其妙的依赖冲突，最常见的是Flask老版本和较新Python版本不兼容。

python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install --upgrade pip pip install pandas numpy scikit-learn flask pymysql dbutils

虚拟环境装完之后，建议把依赖导出到requirements.txt，方便交作业时说明运行环境。如果你手头的源码里已经带了requirements.txt，那更简单，直接执行pip install -r requirements.txt。但要注意，requirements里如果有类似“tensorflow”这种跟推荐系统无关的重型依赖，可以临时注释掉再装，省得下载半小时。

这套依赖组合里，pandas负责数据清洗和透视表，scikit-learn用于可选的SVD和评估指标，flask是常见的Web展示层，pymysql加上dbutils是数据库访问层。min版本不写死，只要保证pip能解析成功即可。

3.2 建库和导入数据：电影推荐系统的三张核心表

这类电影推荐系统的数据库设计几乎没有悬念，就是用户表、电影表、评分表三张核心表。评分表是事实表，用户表和电影表都是维表。先建库再建表，别把顺序弄反。

CREATE DATABASE IF NOT EXISTS movie_recommend DEFAULT CHARACTER SET utf8mb4; USE movie_recommend; CREATE TABLE users ( user_id INT NOT NULL AUTO_INCREMENT, user_name VARCHAR(64), gender CHAR(1), age INT, PRIMARY KEY (user_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE movies ( movie_id INT NOT NULL AUTO_INCREMENT, title VARCHAR(128), genres VARCHAR(255), PRIMARY KEY (movie_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE ratings ( user_id INT NOT NULL, movie_id INT NOT NULL, rating FLOAT NOT NULL, timestamp INT, PRIMARY KEY (user_id, movie_id), KEY idx_movie (movie_id), CONSTRAINT fk_rating_user FOREIGN KEY (user_id) REFERENCES users(user_id), CONSTRAINT fk_rating_movie FOREIGN KEY (movie_id) REFERENCES movies(movie_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逻辑说明：ratings表使用了联合主键(user_id, movie_id)，这样同一个用户对同一部电影只能有一条评分记录，数据在源头就不会重复。外键约束保证评分表里不会出现不存在的用户或电影。如果只做算法演示，外键可以省略，但论文里的ER图有外键会显得更规范。

参数说明：评分表的rating字段用FLOAT而不是INT，因为算法预测出来是小数，存储时用浮点类型更自然；timestamp用INT存秒级时间戳，避免在导入阶段处理日期格式。电影表的genres字段是电影类型，可以是“|”分隔的字符串，不拆表也不影响协同过滤的核心计算。导入数据时不建议一条条INSERT，数据量一大就非常慢，用MySQL的LOAD DATA命令一次性导入效率更高：

LOAD DATA LOCAL INFILE 'ratings.csv' INTO TABLE ratings FIELDS TERMINATED BY ',' IGNORE 1 LINES (user_id, movie_id, rating, timestamp);

导入完成后，先用三条SQL验证数据：查评分总数、查缺失用户、查评分分布。评分总数如果和源文件行数一致，说明数据导入干净。我一般会再查一下每个评分分值的人数分布，比如5分有多少条、1分有多少条，这个分布写论文时也要用到。

3.3 最小复现命令：从原始数据到三条推荐结果

我不想一上来就把整套源码丢给你，因为源码文件多了，出了问题你反而不知道是哪一环崩的。我通常先写一个不依赖Web框架的最小脚本，把“读取数据、计算相似度、输出推荐”走通，然后再对照源码把数据库连接和Web层加回去。这个最小脚本大约四十行，所有同学都能跑。

import pandas as pd # 1. 读取评分数据 ratings = pd.read_csv('ratings.csv') # 只需 user_id, movie_id, rating 三列 # 2. 构建用户-电影评分矩阵，空值补0 pivot = ratings.pivot_table(index='user_id', columns='movie_id', values='rating') # 3. 计算用户相似度矩阵 user_sim = pivot.T.corr().fillna(0) # 4. 给某个用户做推荐 target_user = 1 scores = pd.Series(0.0, index=pivot.columns) for other_user in user_sim.columns: if other_user == target_user: continue sim = user_sim.loc[target_user, other_user] if sim <= 0: continue # 当前用户看过且评过分的电影，不重复推荐 watched = pivot.loc[target_user].notna() # 其他用户评过分的电影 candidate = pivot.loc[other_user].notna() & ~watched recent_ratings = pivot.loc[other_user][candidate] scores[recent_ratings.index] += recent_ratings * sim scores = scores[pivot.loc[target_user].isna()] # 只看没看过的 top3 = scores.sort_values(ascending=False).head(3) print(top3)

逻辑说明：这段代码的核心是拿目标用户和每个其他用户的相似度做加权，其他用户评分越高、相似度越大，目标用户对应的预测分就越高。watched用来过滤目标用户已经看过的电影，这一步非常关键，否则推荐会给出用户已经看过的内容。最后只保留评分矩阵里缺失的电影，也就是用户还没看过的候选集。

参数说明：只看sim大于0的邻居，避免负相似用户拉低预测分；如果数据集足够大，还应该限制邻居数量，比如只取相似度最高的20到50个用户。这里没有做均值中心化，实际预测会偏乐观，但对最小演示来说足够直观。跑通之后你可以手动把pivot.T.corr()换成pivot.corr()，就是ItemCF的雏形，其他代码几乎不动。

运行命令也很简单：

python min_reco.py

如果你的数据表在MySQL里，把第一行的read_csv改成从pymysql查询结果构造DataFrame即可。这一步跑通后，再回头跑完整源码，你就知道每一步在干什么了。

4. 数据库设计与文档配合：连接池、增删改查、万字论文写作结构

4.1 三张表的增删改查怎么设计接口

标题里有“数据库+文档”，论文要写数据库设计，答辩要演示增删改查，所以这三张表的CRUD不能只会用数据库工具点鼠标，得会写SQL。我按最常见的需求列一组能直接用的SQL：

-- 插入新用户 INSERT INTO users (user_name, gender, age) VALUES ('test_user', 'M', 23); -- 给用户添加一条评分（模拟用户刚看完一部电影） INSERT INTO ratings (user_id, movie_id, rating, timestamp) VALUES (1, 128, 4.5, UNIX_TIMESTAMP(NOW())) ON DUPLICATE KEY UPDATE rating = VALUES(rating); -- 删除一条评分记录 DELETE FROM ratings WHERE user_id = 1 AND movie_id = 128; -- 查询某个用户看过的所有电影，带上电影标题 SELECT m.title, r.rating, r.timestamp FROM ratings r JOIN movies m ON r.movie_id = m.movie_id WHERE r.user_id = 1 ORDER BY r.timestamp DESC LIMIT 20; -- 统计评分分布，这是实验部分最常用的查询 SELECT rating, COUNT(*) AS cnt FROM ratings GROUP BY rating ORDER BY rating;

逻辑说明：ON DUPLICATE KEY UPDATE是评分表最常见的写法，因为联合主键决定了同一条评分记录如果重复插入，会被更新而不是报错。这在模拟真实用户行为时很关键，用户可能改了评分，系统不能出现两条相互矛盾的数据。JOIN查询是推荐系统的核心读取方式，算法模块从rating表拿到评分，再关联movie表拿到标题，展示给用户的时候才不会是movie_id。

参数说明：UNIX_TIMESTAMP(NOW())把当前时间转成秒级时间戳，和表结构里的timestamp字段一致。如果你希望论文里写“时间戳可读性更好”，也可以把字段类型改成DATETIME，但那样导入数据时要多做一步时间格式转换，我一般保留INT，配合FROM_UNIXTIME()函数查询时可读。

4.2 MySQL连接池配置：为什么每次直连会卡死

很多源码在数据库访问上犯同一个错：每个请求都新建一个pymysql连接，用完就关。放在命令行演示里没问题，但一上Web页面刷新几次，MySQL连接就会被频繁创建销毁拖垮，轻则页面卡几秒，重则直接报Too many connections。这时要用连接池。

from dbutils.pooled_db import PooledDB import pymysql pool = PooledDB( creator=pymysql, maxconnections=10, mincached=2, maxcached=5, blocking=True, host='localhost', port=3306, user='root', password='123456', database='movie_recommend', charset='utf8mb4', cursorclass=pymysql.cursors.DictCursor ) def query_one(sql, params=None): conn = pool.connection() try: with conn.cursor() as cursor: cursor.execute(sql, params) return cursor.fetchone() finally: conn.close()

逻辑说明：连接池启动时就预建2到5个MySQL连接，业务代码每次只是“借”一个连接，用完归还，不会被销毁重建。maxconnections=10表示池里最多10个连接，超过这个数且有blocking=True时，请求会排队等待而不是直接报错。

参数说明：mincached是池中最少保持的连接数，适合频繁读取的推荐服务；maxcached是空闲时最多缓存的数量，超过这个值的空闲连接会被释放。charset必须写utf8mb4，否则中文电影标题在写入和读取时都可能出现乱码。cursorclass使用DictCursor后，查询结果直接是字典列表，flask里渲染模板时不用挨个下标取值。

4.3 万字论文和大作业文档的写作结构

评分表结构设计好了，文档也要跟上。标题里的“万字论文”听起来吓人，但其实有固定套路。我见过的高分论文，章节划分几乎都是下面这份表格的样子：

万字论文不是说你每句话都要写满，而是建议你在算法和实验这两章补齐内容。算法章把公式推导写清楚，实验章给出至少三组对比结果，比如K值取10/20/50时推荐准确率的变化。很多同学把论文写成源码说明书，这是低分的主要原因。评委更想看“为什么这么设计”“效果差多少”，而不是“这个函数调用了那个函数”。

文档部分通常是需求分析、数据库设计说明、接口文档三件套。接口文档哪怕只有一个页面，也要把请求参数和返回结果写清楚。视频演示脚本则可以按下面的节奏录制：前30秒展示数据表和评分分布，中间90秒演示用户登录后系统返回的推荐列表，最后60秒打开终端看日志，证明推荐结果是通过协同过滤算法计算出来的，而不是写死数据。

5. 避坑：协同过滤电影推荐系统最容易翻车的6个地方

5.1 冷启动：新用户一进来推荐列表为空

现象：在页面上切换登录用户，有的老用户能正常出推荐，新注册用户或者只注册没评分的用户，推荐区域一片空白，控制台报KeyError。

原因：协同过滤是纯行为驱动的算法，用户一条评分都没有，算法找不到它的相似用户，自然算不出预测分。这是协同过滤的先天缺陷，不是代码bug。

解决：在推荐主流程里加一个兜底逻辑。当目标用户的评分数量少于5条或者相似用户列表为空时，直接返回全局热门榜。热门榜可以用评分数和平均分的组合排序，比如score = avg_rating * log(count + 1)，避免只有少数人打了满分的小众电影排到最前面。这个方案不用改算法，只要在接口层判断一下即可。

5.2 相似度矩阵内存爆掉

现象：数据量从几百个用户涨到几千甚至几万用户时，程序运行到计算用户相似度这一步就卡死，然后报MemoryError。

原因：UserCF的相似度矩阵是用户数×用户数的矩阵，一万个用户就是1亿个浮点数，默认64位浮点大约占用800MB，这还不包括中间变量。如果直接对全量用户两两求相关度，本机内存很容易扛不住。

解决：有两个层次的做法。第一层，只保留有共同评分的用户对，这需要把评分矩阵转成稀疏格式，用scipy.sparse或csr_matrix。第二层，限制邻居数量，比如只对每个用户保留相似度最高的30个邻居，其余全部置0。实际工程里没人会算全量相似度矩阵，都是先粗筛候选邻居再精算相似度。大作业做到这一步够交了。

5.3 预测评分超出1到5分

现象：推荐结果里出现预测分7.8、甚至15.6这样的数值，页面展示出来很滑稽。

原因：加权公式里，相似度权重之和并不等于1。当几个高相似用户的评分都偏高时，加权结果自然可能超过5分。另一个常见原因是没做均值中心化，用户的绝对评分偏好没有被剔除。

解决：在输出层加一道规范化。最简单的是把所有预测值clip到[1,5]之间。稍微讲究一点的做法是让权重归一化，即每个邻居的相似度除以该用户所有邻居相似度之和。两个方案可以同时用，先在算法内部做均值中心化，再在输出时clip一次，保证展示的数据可用。

5.4 MySQL中文乱码出现在电影标题和用户名里

现象：数据库工具里查数据正常，但Web页面显示电影标题全是问号，或者在flask日志里看到“ascii codec can't decode”的错误。

原因：这是三个环节有一环没设对。建表时用了默认latin1字符集，或者pymysql连接参数没有指定charset=utf8mb4，还或者页面模板本身没声明UTF-8编码。

解决：三处全部统一。建表语句用DEFAULT CHARACTER SET utf8mb4，pymysql连接参数加charset='utf8mb4'，Web框架层确保flask的响应头是application/json; charset=utf-8。已经在latin1表里的脏数据导出重置，不建议在线改字符集，容易触发索引重建问题。

5.5 MySQL连接报“Public Key Retrieval is not allowed”

现象：运行源码时数据库连接直接抛异常，提示public key retrieval is not allowed。这个错误在使用MySQL 8.0以上版本时特别常见。

原因：新版MySQL客户端默认使用caching_sha2_password认证插件，而连接参数里没有允许客户端向服务端请求公钥，导致第一次认证时无法建立加密通道。

解决：在pymysql连接参数里加allow_public_key_retrieval=True和use_ssl=False即可。另一个更稳妥的做法是给项目创建一个专用账号并指定mysql_native_password插件，这样对源码改动最小。我之前为了省事直接在root账号上跑项目，结果折腾半天，后来改成专用账号后相关报错就再没出现。

5.6 推荐结果全是热门电影，个性化无从谈起

现象：不管切换到哪个用户，推荐列表前几名永远是《肖申克的救赎》《霸王别姬》这类高分片，两名不同用户的重合度高得吓人。

原因：协同过滤天然存在热门偏向。高分电影评分数多，更容易和很多用户产生相似度；同时其他用户评分高的热门片，在加权重叠后也被反复推荐。

解决：分两层处理。第一层，把目标用户已经看过的电影全部过滤掉，这是底线。第二层，在候选生成后加入热门惩罚，一个简单做法是预测分减去一个与电影评分数量正相关的惩罚项，比如popularity_penalty = lambda * log(rating_count)，lambda取0.1左右。这样热门片的预测分被压低，长尾内容才有机会进入TopN。如果论文里能写一句“通过归一化缓解马太效应”，评委看到这个点是会加分的。

6. 验收前最后一步：论文图表、演示视频和两个加分改动

很多同学代码跑通就认为结束了，其实答辩和文档才是课程设计拉开差距的地方。先说论文插图，相似度矩阵不要截全量，截前30个用户的子矩阵热力图，直接用seaborn的heatmap画，颜色越深代表两个用户口味越接近。再画一张TopN推荐的准确率曲线图，横轴是推荐的电影数量N，纵轴是Precision@N。两张图放进去，实验章的厚度立刻不一样。

演示视频按三段式录：先用Navicat或MySQL命令行展示三张表的数据量和评分分布，再切到python代码讲一遍UserCF的核心逻辑，最后运行系统，真实操作一个用户查看推荐结果。全程控制在5分钟以内，不要用PPT，不要录代码逐行讲解，过程比解说重要。

加分改动只做两个就够。第一个是UserCF和ItemCF的融合，推荐列表按权重合并，UserCF占0.7，ItemCF占0.3，能明显改善结果多样性；代码改动不超过10行，但论文里可以多写一个小节。第二个是冷启动兜底，新用户返回热门榜，新电影只出现在相似物品推荐里，把这个规则写进系统设计文档。

我每次交这类大作业之前，都会花二十分钟做一次“新环境演练”：删掉venv，从空环境开始装依赖、建库、导数据、跑演示脚本。这样能确保你交上去的文档里写的命令是真实可复现的，而不是只在你这台电脑能跑。这个习惯帮我避过好几次运行时版本不兼容的尴尬，也希望帮到你。

本文还有配套的精品资源，点击获取