我前前后后做过好几个推荐类的练手项目最后发现最能串起完整技术栈的还是“Python Vue 的电影推荐系统”。这个项目有一个非常典型的特点它不只是一个 CRUD 管理系统而是真正把“算法”和“业务”揉在了一起前端要展示推荐结果后端要算相似度、做预测评分整套流程走下来你对 Django/Flask、Vue 以及协同过滤算法的理解会一下子串成一条线。不管你是准备做毕业设计还是想给自己简历上加一个“推荐系统”相关的项目经历这套基于协同过滤的电影推荐系统都足够有分量。它既能体现后端接口设计能力又能展示前端交互水平更关键的是——它有一个可以讲清楚原理的算法内核。这篇文章我就结合自己实操过的完整流程从技术选型、算法实现、前后端联调到踩坑实录一次性讲透。1. 项目整体设计为什么选“协同过滤”做电影推荐1.1 推荐系统选型思路做电影推荐其实不是只有协同过滤一条路可走。最开始我也考虑过基于内容的推荐也就是给电影打标签、建特征向量然后算用户偏好和历史观看记录之间的相似度。但这类方法有个天然的短板新用户进来之后没有任何行为数据特征向量根本建不起来推荐效果基本靠猜。而协同过滤不一样它的核心逻辑是“物以类聚人以群分”只要你有一张用户对电影的评分表就能通过用户之间的行为相似性做推荐不需要任何电影的内容特征。选协同过滤还有一个非常现实的原因——数据集好找。MovieLens 数据集直接提供了用户 ID、电影 ID、评分、时间戳这几列关键数据拿过来就能用省去了爬数据、清洗内容特征的大量时间。对于个人项目来说数据是否容易获取直接决定项目能不能在有限时间内落地。我当时也对比过几种方案列个表大家就清楚了推荐方式核心依据优点缺点适合场景基于热度全局评分/播放量实现简单推荐结果千篇一律冷启动阶段基于内容电影标签/简介可解释性强特征工程工作量大内容库质量高时协同过滤用户行为矩阵不需要内容特征冷启动和新物品问题有历史行为数据的场景混合推荐多种策略叠加效果均衡复杂度高生产级系统考虑到项目周期和个人技术展示的需要协同过滤是性价比最高的选择。你既能讲清楚算法数学原理又能用 Django 把它做成一个接口服务配合 Vue 做交互展示整个项目的技术深度一下就上来了。1.2 数据链路与项目架构这个项目的整体架构我在动手前就定好了。前端用 Vue 3 Element Plus 做界面后端用 Django Django REST FrameworkDRF提供 API数据库先用 SQLite 开发调试后面再切 MySQL 也行。算法部分单独拆成一个 Python 模块不挂在 Django 的 Model 层里这样职责清晰也方便单独测试。整体数据流向是这样的Vue 页面发起请求 → DRF 的 ViewSet 接收 → 调用协同过滤算法模块获取推荐结果 → 从数据库查询电影详情 → 序列化返回 JSON → Vue 渲染展示。用户对电影的评分数据则反向流入Vue 评分组件 → POST 到 DRF 接口 → 写入数据库 → 下次计算推荐时最新评分会被纳入相似度计算。这套架构的好处是每个环节都能独立验证。算法模块可以脱离 Web 框架单独跑数据Django 接口可以用 Postman 测前端也可以先用 mock 数据开发最后再联调。项目出问题的时候排查链路非常清晰不会互相甩锅。2. 技术栈选型Django 还是 FlaskVue 还是别的2.1 Django 与 Flask 的选择对比我在这个项目里选的是 Django但不是因为它比 Flask 好而是看项目需求。Flask 非常轻量适合做小型 API 服务你要是只写一个推荐接口、不涉及后台管理、用户体系、ORM 这些东西Flask 确实更省事。但电影推荐系统跑起来之后你会慢慢发现用户注册登录、电影数据管理、评分记录查询这些需求都是“标配”如果用 Flask这些全都得自己搭或者找第三方扩展拼装时间成本比较高。Django 的优势在于“开箱即用”。admin 后台可以让你直接管理电影数据和用户评分记录ORM 让数据库操作变得非常清晰DRF 更是把序列化、认证、分页这些高频需求一次性解决掉了。我在开发中最直观的感受是Django 的 admin 后台帮我省了至少 5 天的管理界面开发时间。当然如果你非要纠结 Flask 和 FastAPI 的话我也稍微说两句。FastAPI 的异步性能确实强接口文档还能自动生成 Swagger UI做纯 API 项目很爽。但加上 Django 的生态配套FastAPI 目前还是不如 Django 全家桶方便尤其是你要用 admin 后台管理电影数据的时候。我个人的建议是如果重点是算法和前端展示选 Django 最稳如果你想把整个后端做成微服务架构Flask 或 FastAPI 可能更合适。2.2 Vue 前端框架与开发环境搭配前端选 Vue 3 是综合考虑了上手难度和生态成熟度的结果。Vue 的模板语法非常直观组件化思路清晰对于写 Python 后端的开发者来说切换成本很低。Element Plus 组件库直接提供了表格、卡片、评分、分页这些现成组件电影列表页和推荐页基本就是“组装组件”的过程。开发环境方面我强烈建议用 PyCharm Professional 而不是 Community 版本。Pro 版本自带 Vue 插件和数据库工具可以在一个 IDE 里同时编辑 Python 后端和 Vue 前端数据库连接、SQL 查询也都能直接在 IDE 里完成省去来回切换工具的麻烦。如果你用的是社区版前端代码建议用 VS Code 打开也能凑合但调试体验会差一些。前端项目初始化我有两点经验第一使用npm create vuelatest创建项目骨架时把 Vue Router 和 Pinia 都勾上后面做路由跳转和用户状态管理会方便很多第二安装依赖的时候尽量用npm install而不是cnpm虽然 cnpm 快但偶尔会出现路径解析问题尤其在 Element Plus 这种大型依赖上。2.3 开发环境搭建与依赖管理具体的环境搭建流程我帮大家梳理成了一份速查清单Python 版本建议 3.8 以上推荐 3.10 或 3.11太老的版本对新版 Django 支持不好。使用python -m venv venv创建虚拟环境Windows 下激活命令是venv\Scripts\activatemacOS/Linux 是source venv/bin/activate。安装 Django 时注意版本建议直接pip install django获取最新稳定版我当时用的是 Django 4.2 LTS。安装 Django REST Framework命令是pip install djangorestframework同时安装django-cors-headers解决前端跨域问题。算法部分需要numpy和pandas处理 MovieLens 数据集时会用到。前端 Vue 3 项目单独建一个目录用 npm 管理依赖。requirements.txt 里的核心依赖我列一下Django4.2.* djangorestframework3.14.* django-cors-headers4.* numpy1.24 pandas2.0有一点提醒大家不要图省事把数据库选成 MySQL 到生产再换。开发阶段我直接用 SQLite零配置跑起来方便等数据量大了再迁移到 MySQLDjango 的 ORM 层基本不用改代码切换成本很低。3. 协同过滤算法核心原理与实现3.1 基于用户还是基于物品场景决定选择协同过滤有两个分支一个叫 UserCF基于用户一个叫 ItemCF基于物品。我当时把两个都实现了也做了效果对比发现它们在电影推荐场景里各有各的味道。UserCF 的思想是“找和你口味相似的人看他们在看什么”。先算用户之间的相似度然后根据相似用户的评分记录预测你对某部电影的评分。这种算法在用户数量不太多、用户行为比较丰富的时候效果不错也很容易解释——“和你兴趣相同的人还喜欢《肖申克的救赎》”。ItemCF 的思想是“算物品之间的相似度推荐你喜欢的物品的相似品”。比如你给《盗梦空间》打了高分系统找到和《盗梦空间》最相似的《星际穿越》推荐给你。这类算法的优势是推荐结果更稳定能基于用户历史偏好做精细推荐也是电商平台常用的思路。两者对比来看维度UserCFItemCF适用用户规模用户少、物品多用户多、物品少实时性用户行为变化影响大物品关系相对稳定推荐解释“好友在看”“因为你喜欢某部电影”冷启动适应新物品友好新用户友好在电影推荐项目里我实际采用的是 ItemCF 为主、UserCF 辅助的混合策略。前期数据量小用户少UserCF 效果比较直观后期用户数量上来之后ItemCF 的稳定性优势会体现出来。做项目的话我建议至少把一个算法实现透彻另一个作对比展示面试的时候还能多聊一层算法选型的思考。3.2 相似度计算余弦相似度与皮尔逊相关系数相似度计算是协同过滤的核心。我用的两个最经典的指标余弦相似度和皮尔逊相关系数。余弦相似度把用户对物品的评分看成多维空间里的向量计算两个向量夹角的余弦值。公式是similarity(A, B) Σ(Ai * Bi) / (√Σ(Ai²) * √Σ(Bi²))如果只是“共同评分过某部电影”就算相似并不区分评分高低。比如 A 和 B 都给了《泰坦尼克号》3 分余弦相似度会比较高但两人一个对爱情片普遍给 1 分、一个普遍给 5 分实际口味完全不同。这个时候用皮尔逊相关系数更准。皮尔逊相关系数是在余弦相似度的基础上做了“中心化”先减去每个用户自己的平均评分再算相似度公式similarity(A, B) Σ((Ai - Ā) * (Bi - B̄)) / (√Σ(Ai - Ā)² * √Σ(Bi - B̄)²)这样算出来的相似度消除了个人评分习惯造成的偏差更真实地反映口味相似度。我实际实现时核心逻辑都用 NumPy 向量化处理了千万不能一个个循环去算数据量一大就慢到怀疑人生。下面是基本的相似度函数实现import numpy as np def cosine_similarity(user_matrix, user_a, user_b): common np.logical_and(user_matrix[user_a] 0, user_matrix[user_b] 0) if not np.any(common): return 0.0 vec_a user_matrix[user_a][common] vec_b user_matrix[user_b][common] return float(np.dot(vec_a, vec_b) / (np.linalg.norm(vec_a) * np.linalg.norm(vec_b) 1e-9)) def pearson_similarity(user_matrix, user_a, user_b): common np.logical_and(user_matrix[user_a] 0, user_matrix[user_b] 0) if not np.any(common): return 0.0 vec_a user_matrix[user_a][common].astype(float) vec_b user_matrix[user_b][common].astype(float) mean_a np.mean(vec_a) mean_b np.mean(vec_b) numerator np.dot(vec_a - mean_a, vec_b - mean_b) denominator np.linalg.norm(vec_a - mean_a) * np.linalg.norm(vec_b - mean_b) if denominator 0: return 0.0 return float(numerator / denominator)关键优化点是用np.logical_and拿到共同评分的索引然后直接切片运算把原本 Python 层的循环转移到了 NumPy 底层速度提升非常可观。3.3 构建评分矩阵与推荐生成流程相似度函数写完之后还需要把原始评分数据处理成算法能用的矩阵。我是这样做的从数据库里查出所有评分记录用 pandas 构建一个透视表行是用户 ID列是电影 ID值就是评分缺失的地方填 0。import pandas as pd # ratings_df columns: user_id, movie_id, rating rating_matrix ratings_df.pivot_table( indexuser_id, columnsmovie_id, valuesrating ).fillna(0)这里的 rating_matrix 存储的是所有用户的历史评价。构建 ItemCF 的物品相似度矩阵时需要对每一对物品计算相似度。理论上这是 O(N²) 的复杂度所以我只对“共同被评分过”的物品对计算相似度避免全量计算。同时只保留相似度 Top K 的邻居。推荐生成的关键步骤是这样找到用户已经评过高分的电影集合作为候选的来源依据。对于每个候选电影计算它和用户已评分电影之间的相似度加权评分。预测评分的公式是pred_score(u, i) Σ(sim(i, j) * rating(u, j)) / Σ(|sim(i, j)|)对预测评分排序剔除用户已经看过的电影返回 Top N。权重和归一化不能省不然推荐结果会被“评分高的电影”带偏失去个性化。我当时第一次做的时候省了分母归一化结果推荐列表基本被热门高分电影霸屏完全看不出协同过滤的效果。具体推荐代码可参考这个def itemcf_recommend(rating_matrix, user_id, top_n10, top_k10): user_row rating_matrix.loc[user_id] rated_items user_row[user_row 0].index.tolist() if not rated_items: return [] item_sim precompute_item_similarity(rating_matrix, rated_items) scores {} for item in rated_items: similar_items item_sim.get(item, []) for sim_item, sim_value in similar_items: if sim_item in rated_items: continue scores[sim_item] scores.get(sim_item, 0) sim_value * user_row[item] for sim_item in scores: scores[sim_item] / len(rated_items) ranked sorted(scores.items(), keylambda x: x[1], reverseTrue) return [movie_id for movie_id, _ in ranked[:top_n]]这里有个容易踩的坑similar_items是整个矩阵的相似度结果检索时一定要限制只查询与已评分物品相似的 Top K 个否则内存占用和计算时间都会爆炸。3.4 算法效果优化与冷启动处理算法跑通之后我发现推荐效果有明显的“目录化”倾向——什么都推荐高分的商业大片缺乏个性化。后来做了三个调整第一对用户未评分的电影做均值平滑。用户对一部电影的实际喜好 相似用户评分的加权平均但如果相似用户数量太少预测分会有较大偏差。我采用了基础分数加相似度加权的融合方式相当于做了一次贝叶斯平滑让预测值不会太极端。第二在相似度计算中设置“惩罚项”。如果两个用户只有一部共同评分电影算出来的相似度往往虚高。我给相似度乘以一个系数min(common_count, 20) / 20共同评分数量越少相似度折扣越大效果明显改善。第三冷启动问题的处理。新用户没有任何评分记录协同过滤直接歇菜。我在系统里做了一个回退策略对于无法生成个性化推荐的用户直接推荐全局评分最高的电影同时在前端提示“为你精选热门高分电影”等用户给出 5 条以上评分后再切回协同过滤推荐。def recommend_for_user(user_id, rating_matrix, top_n10): user_row rating_matrix.loc[user_id] if (user_row 0).sum() 5: return get_hot_movies(top_n) return itemcf_recommend(rating_matrix, user_id, top_n)这个“评分条数阈值”的设定是可调的我在前端也做了对应提示引导用户先给几部电影打分提高推荐效果的同时也丰富了交互体验。4. Django 后端 API 开发4.1 数据模型设计与数据库初始化Django 后端我建了三个 appusers负责用户管理movies负责电影数据ratings负责评分记录和推荐接口。这样分模块的好处是职责清晰Django 的 app 边界本身就是一种业务划分。数据模型要用心设计直接关系到后续算法调用取数的方便程度。我的模型设计大致这样from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): avatar models.URLField(blankTrue, nullTrue) created_at models.DateTimeField(auto_now_addTrue) class Movie(models.Model): title models.CharField(max_length255) genres models.CharField(max_length255, blankTrue) release_year models.IntegerField(nullTrue, blankTrue) rating_avg models.FloatField(default0.0) rating_count models.IntegerField(default0) cover_url models.URLField(blankTrue, nullTrue) class Meta: indexes [ models.Index(fields[rating_avg]), models.Index(fields[rating_count]), ] class Rating(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE, related_nameratings) movie models.ForeignKey(Movie, on_deletemodels.CASCADE, related_nameratings) score models.FloatField() created_at models.DateTimeField(auto_now_addTrue) class Meta: unique_together (user, movie)这里的关键点第一个是在Rating表加unique_together约束防止同一个用户对同一部电影重复评分前端的“提交评分”按钮再怎么狂点后端数据都不会乱。第二个是在Movie表建了rating_avg和rating_count这两个冗余字段全局热门推荐直接按它们排序即可不需要临时聚合计算。用空间换时间是个人项目里非常实用的策略。建好模型后执行python manage.py makemigrations和python manage.py migrate生成数据库表。MovieLens 数据导入时我写了一个脚本放在management/commands目录下通过python manage.py import_movielens就能一键导入 CSV 数据非常方便。4.2 DRF 视图与序列化器设计DRF 的设计思路是把数据模型变成接口核心有两层Serializer序列化器负责数据格式转换和校验ViewSet视图集负责处理 HTTP 请求。我的接口设计如下功能方法URL说明用户注册POST/api/auth/register/注册并返回 Token用户登录POST/api/auth/login/登录后返回 Token电影列表GET/api/movies/分页返回电影信息电影详情GET/api/movies/{id}/返回单部电影提交评分POST/api/ratings/保存或更新电影评分获取推荐GET/api/recommendations/返回个性化推荐列表序列化器方面MovieSerializer直接基于Movie模型生成只暴露前端需要的字段。RatingSerializer则要做一层校验确保评分范围在 0.5 到 5.0 之间并且不能重复提交from rest_framework import serializers from .models import Rating class RatingSerializer(serializers.ModelSerializer): class Meta: model Rating fields [id, movie, score, created_at] def validate_score(self, value): if value 0.5 or value 5.0: raise serializers.ValidationError(评分范围必须在0.5到5.0之间) return value def validate(self, attrs): user self.context[request].user movie attrs[movie] if Rating.objects.filter(useruser, moviemovie).exists(): raise serializers.ValidationError(你已经给这部电影评过分了) return attrsViews 方面我用了ModelViewSetpermission_classes做权限控制。未登录用户只能浏览电影列表提交评分和获取个性化推荐必须带上 Token。Django 自带的TokenAuthentication在这里完全够用不需要上 JWT。from rest_framework import viewsets, permissions from .models import Movie, Rating from .serializers import MovieSerializer, RatingSerializer class MovieViewSet(viewsets.ReadOnlyModelViewSet): queryset Movie.objects.all().order_by(-rating_count) serializer_class MovieSerializer permission_classes [permissions.AllowAny] class RatingViewSet(viewsets.ModelViewSet): queryset Rating.objects.all() serializer_class RatingSerializer permission_classes [permissions.IsAuthenticated] def perform_create(self, serializer): serializer.save(userself.request.user)4.3 推荐接口的后端调度逻辑推荐接口我没直接放到 ViewSet 里而是单独写了一个RecommendationService类把算法模块和 Web 层解耦。这个服务从数据库读取所有评分数据构建评分矩阵然后调用协同过滤算法最后把推荐的电影 ID 列表返回给视图层。在视图层我再根据电影 ID 列表查询电影详情组装成前端需要的 JSON 结构from rest_framework.views import APIView from rest_framework.permissions import IsAuthenticated from rest_framework.response import Response from .services import RecommendationService from .models import Movie from .serializers import MovieSerializer class RecommendationView(APIView): permission_classes [IsAuthenticated] def get(self, request): user_id request.user.id movie_ids RecommendationService.get_recommendations(user_id, top_n12) movies Movie.objects.filter(id__inmovie_ids) # 保持推荐顺序 order {mid: idx for idx, mid in enumerate(movie_ids)} movies sorted(movies, keylambda m: order.get(m.id, 999)) return Response(MovieSerializer(movies, manyTrue).data)这个设计里有个容易被忽视的细节直接从数据库filter(id__inmovie_ids)拿到的数据顺序不保证和movie_ids一致。如果只按这个列表渲染推荐顺序就乱套了。所以我用了一个字典做排序映射确保前端拿到的顺序就是算法算出来的推荐顺序。这种小细节面试时如果能主动提出来很加分。算法层的执行频率我也做了控制用户评分发生变化后推荐结果才需要重新计算。所以我服务里加了缓存用字典存用户 ID 对应的推荐结果并记录生成时间。这样同一用户短时间内反复请求推荐接口不会每次都重算一遍矩阵接口响应速度能提升好几倍。5. Vue 3 前端实现与联调5.1 页面结构与组件拆分前端我把页面拆成了四个核心视图首页电影瀑布流、推荐页个性化推荐、电影详情页含评分功能、个人中心我的评分记录。组件复用方面电影卡片组件、评分组件、分页组件都抽成了独立组件避免到处复制粘贴代码。路由设计用了 Vue Router我的路由配置示例import { createRouter, createWebHistory } from vue-router import HomeView from ../views/HomeView.vue import RecommendView from ../views/RecommendView.vue import MovieDetailView from ../views/MovieDetailView.vue import LoginView from ../views/LoginView.vue const router createRouter({ history: createWebHistory(), routes: [ { path: /, name: home, component: HomeView }, { path: /recommend, name: recommend, component: RecommendView, meta: { requiresAuth: true } }, { path: /movie/:id, name: movie-detail, component: MovieDetailView }, { path: /login, name: login, component: LoginView } ] }) router.beforeEach((to) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { return { name: login } } return true })meta.requiresAuth 全局前置守卫配合是前端拦截未登录用户最直接的方式比在每个组件里单独判断要干净得多。5.2 推荐列表与评分交互实现推荐页的核心逻辑是进入页面时带 Token 请求/api/recommendations/返回的电影数据渲染成卡片网格每张卡片上显示电影海报、标题、类型和预测评分。点击“评分”按钮后会弹出评分组件用户选择分数后提交评分。Axios 封装时我用请求拦截器统一添加 Authorization 头import axios from axios const api axios.create({ baseURL: http://localhost:8000/api, timeout: 10000 }) api.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Token ${token} } return config })评分提交后要做一个即时反馈更新前端展示的评分、把已推荐列表里的这部电影标记为“已看过”、提示用户可以刷新推荐。这是因为用户刚评分完后端缓存还没有失效如果前端不做状态更新用户会以为评分没有生效。5.3 前后端联调的端口与跨域配置前后端分离开发时最典型的问题就是跨域。前端跑在 5173 端口Django 跑在 8000 端口浏览器会拦截不同端口间的请求。解决方式有两种一种是在 Django 里配django-cors-headers另一种是在前端配置 Vite 代理。我实际开发时做的是双保险。生产展示阶段用 Django 配置 CORS开发阶段用 Vite 代理两个方案不冲突但理解它们的区别很重要。django-cors-headers的配置核心是在settings.py里添加INSTALLED_APPS [ # ... corsheaders, ] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, # ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, ] CORS_ALLOW_CREDENTIALS True而 Vite 代理的配置则是在vite.config.ts里server: { proxy: { /api: { target: http://localhost:8000, changeOrigin: true } } }大多数教程只讲其中一种但实际项目里两种都要会。CORS 是浏览器层面的拦截机制代理是开发服务器层面的转发策略应用的场景完全不同。以后部署上线时你可能还要加一层 Nginx 反向代理原理也是一脉相承的。6. 常见问题与排查实录6.1 MovieLens 数据集导入常见坑MovieLens 数据集导入 Django 时最常见的坑是 CSV 表头和数据库字段对不上。数据集的userId、movieId、rating、timestamp是驼峰命名而 Django 模型用蛇形命名movie_id、rating_avg导入时一定要做映射。另外 MovieLens 的movies.csv里电影标题带着年份括号比如 “Toy Story (1995)”。我要用正则表达式把年份单独提取出来存到release_year字段否则前端展示时标题太乱而按年份筛选功能也做不了。import re def extract_year(title): match re.search(r\((\d{4})\), title) if match: return int(match.group(1)) return None def clean_title(title): return re.sub(r\s*\(\d{4}\)\s*$, , title)数据导入时还要注意get_or_create的使用。因为 MovieLens 原始 CSV 里部分电影会在评分文件中重复出现但电影的movieId是唯一的。用get_or_create可以保证一个电影 ID 只创建一条记录。6.2 推荐接口响应慢与算法性能优化第一次跑通整个系统后我打开推荐页等了三秒钟才看到结果问题出在渲染前的推荐计算上。排查后发现每次请求推荐接口都要全量构建一次评分矩阵数据量才几百个用户、几千部电影矩阵计算不该这么慢。后来我把计算链路优化成了四步第一步评分数据加缓存五分钟过期。第二步用户评分少于 5 条的走热门推荐逻辑不触发协同过滤计算。第三步只对目标用户已评分的电影计算物品相似度不计算所有物品对。第四步相似度矩阵结果存入内存缓存用户评分不变时直接复用。优化后冷用户请求推荐接口耗时降到 50ms 左右热用户有评分的首次请求大约 200ms后续命中缓存后 10ms 级别。这个优化过程也是项目里值得写进简历的亮点。6.3 前端播放 m3u8 视频流的问题选答电影推荐系统做到后面通常还会接电影预告片或正片播放的功能。我发现不少初学者在用 Vue 播放 m3u8 格式视频时会碰到在 Chrome 里直接无法播放的问题。原因是 Chrome 原生不支持 HLS 协议必须借助hls.js库。用法很简单在组件初始化时创建一个 Hls 实例绑定 video 元素加载 m3u8 地址即可import Hls from hls.js const videoRef ref(null) onMounted(() { if (Hls.isSupported()) { const hls new Hls() hls.loadSource(/media/stream/test.m3u8) hls.attachMedia(videoRef.value) } })后端提供 m3u8 文件时要注意几个细节文件路径权限要放开Content-Type要设置成application/vnd.apple.mpegurl以及 ts 分片的路径必须是相对路径或可访问的绝对路径否则播放器会一直转圈加载。6.4 调试技巧与生产部署建议整个项目开发过程中我最推荐的一个调试习惯是把算法模块单独跑起来脱离 Django 和 Vue直接用命令行传参调接口。这样做的好处是能让你专注算法本身的输出是否正确不用被 Web 层干扰。协同过滤这种算法十次调试里有八次是矩阵维度不对、索引错位之类的问题命令行工具 打印中间结果可以快速定位。部署方面如果你要把项目给朋友看推荐用 Docker 把 Django 后端和 Vue 前端打两个镜像用 docker-compose 编排起来。数据库也建议切到 MySQL。这里有个很容易踩的坑Django 的DEBUG模式在生产环境必须设置为 False并且要配好静态文件服务不然 CSS 和 JS 全部加载不出来。我第一次部署时就是忘了关 DEBUG接口数据暴露了一堆敏感信息差点出糗。前后端分离部署时Vue 打包后的静态文件如果交给 Nginx 托管记得把try_files $uri $uri/ /index.html;配置上这样 Vue Router 的 history 模式刷新页面时才不会 404。这个坑我踩了至少三次现在还记忆犹新。写在最后的一点个人经验这个项目我从零开始做到功能完整前后花了大约三周时间。最大的体会是不要一上来就摊开一堆技术名词先确保用户能完成一条最简单的闭环——注册 → 浏览电影 → 给电影评分 → 收到个性化推荐结果。闭环跑通后面的优化才有意义。算法效果不理想可以先从数据质量找原因而不是急着换模型前端慢可以先看看是不是接口没有缓存评分提交不成功先检查 Token 和跨域配置。项目里每个模块都是可以独立验证的找到问题源头比盲目堆功能重要得多。如果你正准备做类似的项目我建议把注意力多放在“如何基于当前评分数据生成合理推荐”这个核心问题上。推荐系统当成一个普通 Web 项目做只做接口和页面最终呈现出来的东西会很单薄但当你真正把算法跑通、让推荐结果随着用户评分变化而发生肉眼可见的调整时这个项目就真正有了灵魂。后续你还可以继续扩展基于内容的推荐、热门榜单、相似电影推荐等功能一步步升级每一次升级都能让你学到新技术。 
长河君 · 2026/10/9 6:33:27 · 阅读 1.2k Python+Vue电影推荐系统：协同过滤算法与Django后端实战
我前前后后做过好几个推荐类的练手项目最后发现最能串起完整技术栈的还是“Python Vue 的电影推荐系统”。这个项目有一个非常典型的特点它不只是一个 CRUD 管理系统而是真正把“算法”和“业务”揉在了一起前端要展示推荐结果后端要算相似度、做预测评分整套流程走下来你对 Django/Flask、Vue 以及协同过滤算法的理解会一下子串成一条线。不管你是准备做毕业设计还是想给自己简历上加一个“推荐系统”相关的项目经历这套基于协同过滤的电影推荐系统都足够有分量。它既能体现后端接口设计能力又能展示前端交互水平更关键的是——它有一个可以讲清楚原理的算法内核。这篇文章我就结合自己实操过的完整流程从技术选型、算法实现、前后端联调到踩坑实录一次性讲透。1. 项目整体设计为什么选“协同过滤”做电影推荐1.1 推荐系统选型思路做电影推荐其实不是只有协同过滤一条路可走。最开始我也考虑过基于内容的推荐也就是给电影打标签、建特征向量然后算用户偏好和历史观看记录之间的相似度。但这类方法有个天然的短板新用户进来之后没有任何行为数据特征向量根本建不起来推荐效果基本靠猜。而协同过滤不一样它的核心逻辑是“物以类聚人以群分”只要你有一张用户对电影的评分表就能通过用户之间的行为相似性做推荐不需要任何电影的内容特征。选协同过滤还有一个非常现实的原因——数据集好找。MovieLens 数据集直接提供了用户 ID、电影 ID、评分、时间戳这几列关键数据拿过来就能用省去了爬数据、清洗内容特征的大量时间。对于个人项目来说数据是否容易获取直接决定项目能不能在有限时间内落地。我当时也对比过几种方案列个表大家就清楚了推荐方式核心依据优点缺点适合场景基于热度全局评分/播放量实现简单推荐结果千篇一律冷启动阶段基于内容电影标签/简介可解释性强特征工程工作量大内容库质量高时协同过滤用户行为矩阵不需要内容特征冷启动和新物品问题有历史行为数据的场景混合推荐多种策略叠加效果均衡复杂度高生产级系统考虑到项目周期和个人技术展示的需要协同过滤是性价比最高的选择。你既能讲清楚算法数学原理又能用 Django 把它做成一个接口服务配合 Vue 做交互展示整个项目的技术深度一下就上来了。1.2 数据链路与项目架构这个项目的整体架构我在动手前就定好了。前端用 Vue 3 Element Plus 做界面后端用 Django Django REST FrameworkDRF提供 API数据库先用 SQLite 开发调试后面再切 MySQL 也行。算法部分单独拆成一个 Python 模块不挂在 Django 的 Model 层里这样职责清晰也方便单独测试。整体数据流向是这样的Vue 页面发起请求 → DRF 的 ViewSet 接收 → 调用协同过滤算法模块获取推荐结果 → 从数据库查询电影详情 → 序列化返回 JSON → Vue 渲染展示。用户对电影的评分数据则反向流入Vue 评分组件 → POST 到 DRF 接口 → 写入数据库 → 下次计算推荐时最新评分会被纳入相似度计算。这套架构的好处是每个环节都能独立验证。算法模块可以脱离 Web 框架单独跑数据Django 接口可以用 Postman 测前端也可以先用 mock 数据开发最后再联调。项目出问题的时候排查链路非常清晰不会互相甩锅。2. 技术栈选型Django 还是 FlaskVue 还是别的2.1 Django 与 Flask 的选择对比我在这个项目里选的是 Django但不是因为它比 Flask 好而是看项目需求。Flask 非常轻量适合做小型 API 服务你要是只写一个推荐接口、不涉及后台管理、用户体系、ORM 这些东西Flask 确实更省事。但电影推荐系统跑起来之后你会慢慢发现用户注册登录、电影数据管理、评分记录查询这些需求都是“标配”如果用 Flask这些全都得自己搭或者找第三方扩展拼装时间成本比较高。Django 的优势在于“开箱即用”。admin 后台可以让你直接管理电影数据和用户评分记录ORM 让数据库操作变得非常清晰DRF 更是把序列化、认证、分页这些高频需求一次性解决掉了。我在开发中最直观的感受是Django 的 admin 后台帮我省了至少 5 天的管理界面开发时间。当然如果你非要纠结 Flask 和 FastAPI 的话我也稍微说两句。FastAPI 的异步性能确实强接口文档还能自动生成 Swagger UI做纯 API 项目很爽。但加上 Django 的生态配套FastAPI 目前还是不如 Django 全家桶方便尤其是你要用 admin 后台管理电影数据的时候。我个人的建议是如果重点是算法和前端展示选 Django 最稳如果你想把整个后端做成微服务架构Flask 或 FastAPI 可能更合适。2.2 Vue 前端框架与开发环境搭配前端选 Vue 3 是综合考虑了上手难度和生态成熟度的结果。Vue 的模板语法非常直观组件化思路清晰对于写 Python 后端的开发者来说切换成本很低。Element Plus 组件库直接提供了表格、卡片、评分、分页这些现成组件电影列表页和推荐页基本就是“组装组件”的过程。开发环境方面我强烈建议用 PyCharm Professional 而不是 Community 版本。Pro 版本自带 Vue 插件和数据库工具可以在一个 IDE 里同时编辑 Python 后端和 Vue 前端数据库连接、SQL 查询也都能直接在 IDE 里完成省去来回切换工具的麻烦。如果你用的是社区版前端代码建议用 VS Code 打开也能凑合但调试体验会差一些。前端项目初始化我有两点经验第一使用npm create vuelatest创建项目骨架时把 Vue Router 和 Pinia 都勾上后面做路由跳转和用户状态管理会方便很多第二安装依赖的时候尽量用npm install而不是cnpm虽然 cnpm 快但偶尔会出现路径解析问题尤其在 Element Plus 这种大型依赖上。2.3 开发环境搭建与依赖管理具体的环境搭建流程我帮大家梳理成了一份速查清单Python 版本建议 3.8 以上推荐 3.10 或 3.11太老的版本对新版 Django 支持不好。使用python -m venv venv创建虚拟环境Windows 下激活命令是venv\Scripts\activatemacOS/Linux 是source venv/bin/activate。安装 Django 时注意版本建议直接pip install django获取最新稳定版我当时用的是 Django 4.2 LTS。安装 Django REST Framework命令是pip install djangorestframework同时安装django-cors-headers解决前端跨域问题。算法部分需要numpy和pandas处理 MovieLens 数据集时会用到。前端 Vue 3 项目单独建一个目录用 npm 管理依赖。requirements.txt 里的核心依赖我列一下Django4.2.* djangorestframework3.14.* django-cors-headers4.* numpy1.24 pandas2.0有一点提醒大家不要图省事把数据库选成 MySQL 到生产再换。开发阶段我直接用 SQLite零配置跑起来方便等数据量大了再迁移到 MySQLDjango 的 ORM 层基本不用改代码切换成本很低。3. 协同过滤算法核心原理与实现3.1 基于用户还是基于物品场景决定选择协同过滤有两个分支一个叫 UserCF基于用户一个叫 ItemCF基于物品。我当时把两个都实现了也做了效果对比发现它们在电影推荐场景里各有各的味道。UserCF 的思想是“找和你口味相似的人看他们在看什么”。先算用户之间的相似度然后根据相似用户的评分记录预测你对某部电影的评分。这种算法在用户数量不太多、用户行为比较丰富的时候效果不错也很容易解释——“和你兴趣相同的人还喜欢《肖申克的救赎》”。ItemCF 的思想是“算物品之间的相似度推荐你喜欢的物品的相似品”。比如你给《盗梦空间》打了高分系统找到和《盗梦空间》最相似的《星际穿越》推荐给你。这类算法的优势是推荐结果更稳定能基于用户历史偏好做精细推荐也是电商平台常用的思路。两者对比来看维度UserCFItemCF适用用户规模用户少、物品多用户多、物品少实时性用户行为变化影响大物品关系相对稳定推荐解释“好友在看”“因为你喜欢某部电影”冷启动适应新物品友好新用户友好在电影推荐项目里我实际采用的是 ItemCF 为主、UserCF 辅助的混合策略。前期数据量小用户少UserCF 效果比较直观后期用户数量上来之后ItemCF 的稳定性优势会体现出来。做项目的话我建议至少把一个算法实现透彻另一个作对比展示面试的时候还能多聊一层算法选型的思考。3.2 相似度计算余弦相似度与皮尔逊相关系数相似度计算是协同过滤的核心。我用的两个最经典的指标余弦相似度和皮尔逊相关系数。余弦相似度把用户对物品的评分看成多维空间里的向量计算两个向量夹角的余弦值。公式是similarity(A, B) Σ(Ai * Bi) / (√Σ(Ai²) * √Σ(Bi²))如果只是“共同评分过某部电影”就算相似并不区分评分高低。比如 A 和 B 都给了《泰坦尼克号》3 分余弦相似度会比较高但两人一个对爱情片普遍给 1 分、一个普遍给 5 分实际口味完全不同。这个时候用皮尔逊相关系数更准。皮尔逊相关系数是在余弦相似度的基础上做了“中心化”先减去每个用户自己的平均评分再算相似度公式similarity(A, B) Σ((Ai - Ā) * (Bi - B̄)) / (√Σ(Ai - Ā)² * √Σ(Bi - B̄)²)这样算出来的相似度消除了个人评分习惯造成的偏差更真实地反映口味相似度。我实际实现时核心逻辑都用 NumPy 向量化处理了千万不能一个个循环去算数据量一大就慢到怀疑人生。下面是基本的相似度函数实现import numpy as np def cosine_similarity(user_matrix, user_a, user_b): common np.logical_and(user_matrix[user_a] 0, user_matrix[user_b] 0) if not np.any(common): return 0.0 vec_a user_matrix[user_a][common] vec_b user_matrix[user_b][common] return float(np.dot(vec_a, vec_b) / (np.linalg.norm(vec_a) * np.linalg.norm(vec_b) 1e-9)) def pearson_similarity(user_matrix, user_a, user_b): common np.logical_and(user_matrix[user_a] 0, user_matrix[user_b] 0) if not np.any(common): return 0.0 vec_a user_matrix[user_a][common].astype(float) vec_b user_matrix[user_b][common].astype(float) mean_a np.mean(vec_a) mean_b np.mean(vec_b) numerator np.dot(vec_a - mean_a, vec_b - mean_b) denominator np.linalg.norm(vec_a - mean_a) * np.linalg.norm(vec_b - mean_b) if denominator 0: return 0.0 return float(numerator / denominator)关键优化点是用np.logical_and拿到共同评分的索引然后直接切片运算把原本 Python 层的循环转移到了 NumPy 底层速度提升非常可观。3.3 构建评分矩阵与推荐生成流程相似度函数写完之后还需要把原始评分数据处理成算法能用的矩阵。我是这样做的从数据库里查出所有评分记录用 pandas 构建一个透视表行是用户 ID列是电影 ID值就是评分缺失的地方填 0。import pandas as pd # ratings_df columns: user_id, movie_id, rating rating_matrix ratings_df.pivot_table( indexuser_id, columnsmovie_id, valuesrating ).fillna(0)这里的 rating_matrix 存储的是所有用户的历史评价。构建 ItemCF 的物品相似度矩阵时需要对每一对物品计算相似度。理论上这是 O(N²) 的复杂度所以我只对“共同被评分过”的物品对计算相似度避免全量计算。同时只保留相似度 Top K 的邻居。推荐生成的关键步骤是这样找到用户已经评过高分的电影集合作为候选的来源依据。对于每个候选电影计算它和用户已评分电影之间的相似度加权评分。预测评分的公式是pred_score(u, i) Σ(sim(i, j) * rating(u, j)) / Σ(|sim(i, j)|)对预测评分排序剔除用户已经看过的电影返回 Top N。权重和归一化不能省不然推荐结果会被“评分高的电影”带偏失去个性化。我当时第一次做的时候省了分母归一化结果推荐列表基本被热门高分电影霸屏完全看不出协同过滤的效果。具体推荐代码可参考这个def itemcf_recommend(rating_matrix, user_id, top_n10, top_k10): user_row rating_matrix.loc[user_id] rated_items user_row[user_row 0].index.tolist() if not rated_items: return [] item_sim precompute_item_similarity(rating_matrix, rated_items) scores {} for item in rated_items: similar_items item_sim.get(item, []) for sim_item, sim_value in similar_items: if sim_item in rated_items: continue scores[sim_item] scores.get(sim_item, 0) sim_value * user_row[item] for sim_item in scores: scores[sim_item] / len(rated_items) ranked sorted(scores.items(), keylambda x: x[1], reverseTrue) return [movie_id for movie_id, _ in ranked[:top_n]]这里有个容易踩的坑similar_items是整个矩阵的相似度结果检索时一定要限制只查询与已评分物品相似的 Top K 个否则内存占用和计算时间都会爆炸。3.4 算法效果优化与冷启动处理算法跑通之后我发现推荐效果有明显的“目录化”倾向——什么都推荐高分的商业大片缺乏个性化。后来做了三个调整第一对用户未评分的电影做均值平滑。用户对一部电影的实际喜好 相似用户评分的加权平均但如果相似用户数量太少预测分会有较大偏差。我采用了基础分数加相似度加权的融合方式相当于做了一次贝叶斯平滑让预测值不会太极端。第二在相似度计算中设置“惩罚项”。如果两个用户只有一部共同评分电影算出来的相似度往往虚高。我给相似度乘以一个系数min(common_count, 20) / 20共同评分数量越少相似度折扣越大效果明显改善。第三冷启动问题的处理。新用户没有任何评分记录协同过滤直接歇菜。我在系统里做了一个回退策略对于无法生成个性化推荐的用户直接推荐全局评分最高的电影同时在前端提示“为你精选热门高分电影”等用户给出 5 条以上评分后再切回协同过滤推荐。def recommend_for_user(user_id, rating_matrix, top_n10): user_row rating_matrix.loc[user_id] if (user_row 0).sum() 5: return get_hot_movies(top_n) return itemcf_recommend(rating_matrix, user_id, top_n)这个“评分条数阈值”的设定是可调的我在前端也做了对应提示引导用户先给几部电影打分提高推荐效果的同时也丰富了交互体验。4. Django 后端 API 开发4.1 数据模型设计与数据库初始化Django 后端我建了三个 appusers负责用户管理movies负责电影数据ratings负责评分记录和推荐接口。这样分模块的好处是职责清晰Django 的 app 边界本身就是一种业务划分。数据模型要用心设计直接关系到后续算法调用取数的方便程度。我的模型设计大致这样from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): avatar models.URLField(blankTrue, nullTrue) created_at models.DateTimeField(auto_now_addTrue) class Movie(models.Model): title models.CharField(max_length255) genres models.CharField(max_length255, blankTrue) release_year models.IntegerField(nullTrue, blankTrue) rating_avg models.FloatField(default0.0) rating_count models.IntegerField(default0) cover_url models.URLField(blankTrue, nullTrue) class Meta: indexes [ models.Index(fields[rating_avg]), models.Index(fields[rating_count]), ] class Rating(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE, related_nameratings) movie models.ForeignKey(Movie, on_deletemodels.CASCADE, related_nameratings) score models.FloatField() created_at models.DateTimeField(auto_now_addTrue) class Meta: unique_together (user, movie)这里的关键点第一个是在Rating表加unique_together约束防止同一个用户对同一部电影重复评分前端的“提交评分”按钮再怎么狂点后端数据都不会乱。第二个是在Movie表建了rating_avg和rating_count这两个冗余字段全局热门推荐直接按它们排序即可不需要临时聚合计算。用空间换时间是个人项目里非常实用的策略。建好模型后执行python manage.py makemigrations和python manage.py migrate生成数据库表。MovieLens 数据导入时我写了一个脚本放在management/commands目录下通过python manage.py import_movielens就能一键导入 CSV 数据非常方便。4.2 DRF 视图与序列化器设计DRF 的设计思路是把数据模型变成接口核心有两层Serializer序列化器负责数据格式转换和校验ViewSet视图集负责处理 HTTP 请求。我的接口设计如下功能方法URL说明用户注册POST/api/auth/register/注册并返回 Token用户登录POST/api/auth/login/登录后返回 Token电影列表GET/api/movies/分页返回电影信息电影详情GET/api/movies/{id}/返回单部电影提交评分POST/api/ratings/保存或更新电影评分获取推荐GET/api/recommendations/返回个性化推荐列表序列化器方面MovieSerializer直接基于Movie模型生成只暴露前端需要的字段。RatingSerializer则要做一层校验确保评分范围在 0.5 到 5.0 之间并且不能重复提交from rest_framework import serializers from .models import Rating class RatingSerializer(serializers.ModelSerializer): class Meta: model Rating fields [id, movie, score, created_at] def validate_score(self, value): if value 0.5 or value 5.0: raise serializers.ValidationError(评分范围必须在0.5到5.0之间) return value def validate(self, attrs): user self.context[request].user movie attrs[movie] if Rating.objects.filter(useruser, moviemovie).exists(): raise serializers.ValidationError(你已经给这部电影评过分了) return attrsViews 方面我用了ModelViewSetpermission_classes做权限控制。未登录用户只能浏览电影列表提交评分和获取个性化推荐必须带上 Token。Django 自带的TokenAuthentication在这里完全够用不需要上 JWT。from rest_framework import viewsets, permissions from .models import Movie, Rating from .serializers import MovieSerializer, RatingSerializer class MovieViewSet(viewsets.ReadOnlyModelViewSet): queryset Movie.objects.all().order_by(-rating_count) serializer_class MovieSerializer permission_classes [permissions.AllowAny] class RatingViewSet(viewsets.ModelViewSet): queryset Rating.objects.all() serializer_class RatingSerializer permission_classes [permissions.IsAuthenticated] def perform_create(self, serializer): serializer.save(userself.request.user)4.3 推荐接口的后端调度逻辑推荐接口我没直接放到 ViewSet 里而是单独写了一个RecommendationService类把算法模块和 Web 层解耦。这个服务从数据库读取所有评分数据构建评分矩阵然后调用协同过滤算法最后把推荐的电影 ID 列表返回给视图层。在视图层我再根据电影 ID 列表查询电影详情组装成前端需要的 JSON 结构from rest_framework.views import APIView from rest_framework.permissions import IsAuthenticated from rest_framework.response import Response from .services import RecommendationService from .models import Movie from .serializers import MovieSerializer class RecommendationView(APIView): permission_classes [IsAuthenticated] def get(self, request): user_id request.user.id movie_ids RecommendationService.get_recommendations(user_id, top_n12) movies Movie.objects.filter(id__inmovie_ids) # 保持推荐顺序 order {mid: idx for idx, mid in enumerate(movie_ids)} movies sorted(movies, keylambda m: order.get(m.id, 999)) return Response(MovieSerializer(movies, manyTrue).data)这个设计里有个容易被忽视的细节直接从数据库filter(id__inmovie_ids)拿到的数据顺序不保证和movie_ids一致。如果只按这个列表渲染推荐顺序就乱套了。所以我用了一个字典做排序映射确保前端拿到的顺序就是算法算出来的推荐顺序。这种小细节面试时如果能主动提出来很加分。算法层的执行频率我也做了控制用户评分发生变化后推荐结果才需要重新计算。所以我服务里加了缓存用字典存用户 ID 对应的推荐结果并记录生成时间。这样同一用户短时间内反复请求推荐接口不会每次都重算一遍矩阵接口响应速度能提升好几倍。5. Vue 3 前端实现与联调5.1 页面结构与组件拆分前端我把页面拆成了四个核心视图首页电影瀑布流、推荐页个性化推荐、电影详情页含评分功能、个人中心我的评分记录。组件复用方面电影卡片组件、评分组件、分页组件都抽成了独立组件避免到处复制粘贴代码。路由设计用了 Vue Router我的路由配置示例import { createRouter, createWebHistory } from vue-router import HomeView from ../views/HomeView.vue import RecommendView from ../views/RecommendView.vue import MovieDetailView from ../views/MovieDetailView.vue import LoginView from ../views/LoginView.vue const router createRouter({ history: createWebHistory(), routes: [ { path: /, name: home, component: HomeView }, { path: /recommend, name: recommend, component: RecommendView, meta: { requiresAuth: true } }, { path: /movie/:id, name: movie-detail, component: MovieDetailView }, { path: /login, name: login, component: LoginView } ] }) router.beforeEach((to) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { return { name: login } } return true })meta.requiresAuth 全局前置守卫配合是前端拦截未登录用户最直接的方式比在每个组件里单独判断要干净得多。5.2 推荐列表与评分交互实现推荐页的核心逻辑是进入页面时带 Token 请求/api/recommendations/返回的电影数据渲染成卡片网格每张卡片上显示电影海报、标题、类型和预测评分。点击“评分”按钮后会弹出评分组件用户选择分数后提交评分。Axios 封装时我用请求拦截器统一添加 Authorization 头import axios from axios const api axios.create({ baseURL: http://localhost:8000/api, timeout: 10000 }) api.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Token ${token} } return config })评分提交后要做一个即时反馈更新前端展示的评分、把已推荐列表里的这部电影标记为“已看过”、提示用户可以刷新推荐。这是因为用户刚评分完后端缓存还没有失效如果前端不做状态更新用户会以为评分没有生效。5.3 前后端联调的端口与跨域配置前后端分离开发时最典型的问题就是跨域。前端跑在 5173 端口Django 跑在 8000 端口浏览器会拦截不同端口间的请求。解决方式有两种一种是在 Django 里配django-cors-headers另一种是在前端配置 Vite 代理。我实际开发时做的是双保险。生产展示阶段用 Django 配置 CORS开发阶段用 Vite 代理两个方案不冲突但理解它们的区别很重要。django-cors-headers的配置核心是在settings.py里添加INSTALLED_APPS [ # ... corsheaders, ] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, # ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, ] CORS_ALLOW_CREDENTIALS True而 Vite 代理的配置则是在vite.config.ts里server: { proxy: { /api: { target: http://localhost:8000, changeOrigin: true } } }大多数教程只讲其中一种但实际项目里两种都要会。CORS 是浏览器层面的拦截机制代理是开发服务器层面的转发策略应用的场景完全不同。以后部署上线时你可能还要加一层 Nginx 反向代理原理也是一脉相承的。6. 常见问题与排查实录6.1 MovieLens 数据集导入常见坑MovieLens 数据集导入 Django 时最常见的坑是 CSV 表头和数据库字段对不上。数据集的userId、movieId、rating、timestamp是驼峰命名而 Django 模型用蛇形命名movie_id、rating_avg导入时一定要做映射。另外 MovieLens 的movies.csv里电影标题带着年份括号比如 “Toy Story (1995)”。我要用正则表达式把年份单独提取出来存到release_year字段否则前端展示时标题太乱而按年份筛选功能也做不了。import re def extract_year(title): match re.search(r\((\d{4})\), title) if match: return int(match.group(1)) return None def clean_title(title): return re.sub(r\s*\(\d{4}\)\s*$, , title)数据导入时还要注意get_or_create的使用。因为 MovieLens 原始 CSV 里部分电影会在评分文件中重复出现但电影的movieId是唯一的。用get_or_create可以保证一个电影 ID 只创建一条记录。6.2 推荐接口响应慢与算法性能优化第一次跑通整个系统后我打开推荐页等了三秒钟才看到结果问题出在渲染前的推荐计算上。排查后发现每次请求推荐接口都要全量构建一次评分矩阵数据量才几百个用户、几千部电影矩阵计算不该这么慢。后来我把计算链路优化成了四步第一步评分数据加缓存五分钟过期。第二步用户评分少于 5 条的走热门推荐逻辑不触发协同过滤计算。第三步只对目标用户已评分的电影计算物品相似度不计算所有物品对。第四步相似度矩阵结果存入内存缓存用户评分不变时直接复用。优化后冷用户请求推荐接口耗时降到 50ms 左右热用户有评分的首次请求大约 200ms后续命中缓存后 10ms 级别。这个优化过程也是项目里值得写进简历的亮点。6.3 前端播放 m3u8 视频流的问题选答电影推荐系统做到后面通常还会接电影预告片或正片播放的功能。我发现不少初学者在用 Vue 播放 m3u8 格式视频时会碰到在 Chrome 里直接无法播放的问题。原因是 Chrome 原生不支持 HLS 协议必须借助hls.js库。用法很简单在组件初始化时创建一个 Hls 实例绑定 video 元素加载 m3u8 地址即可import Hls from hls.js const videoRef ref(null) onMounted(() { if (Hls.isSupported()) { const hls new Hls() hls.loadSource(/media/stream/test.m3u8) hls.attachMedia(videoRef.value) } })后端提供 m3u8 文件时要注意几个细节文件路径权限要放开Content-Type要设置成application/vnd.apple.mpegurl以及 ts 分片的路径必须是相对路径或可访问的绝对路径否则播放器会一直转圈加载。6.4 调试技巧与生产部署建议整个项目开发过程中我最推荐的一个调试习惯是把算法模块单独跑起来脱离 Django 和 Vue直接用命令行传参调接口。这样做的好处是能让你专注算法本身的输出是否正确不用被 Web 层干扰。协同过滤这种算法十次调试里有八次是矩阵维度不对、索引错位之类的问题命令行工具 打印中间结果可以快速定位。部署方面如果你要把项目给朋友看推荐用 Docker 把 Django 后端和 Vue 前端打两个镜像用 docker-compose 编排起来。数据库也建议切到 MySQL。这里有个很容易踩的坑Django 的DEBUG模式在生产环境必须设置为 False并且要配好静态文件服务不然 CSS 和 JS 全部加载不出来。我第一次部署时就是忘了关 DEBUG接口数据暴露了一堆敏感信息差点出糗。前后端分离部署时Vue 打包后的静态文件如果交给 Nginx 托管记得把try_files $uri $uri/ /index.html;配置上这样 Vue Router 的 history 模式刷新页面时才不会 404。这个坑我踩了至少三次现在还记忆犹新。写在最后的一点个人经验这个项目我从零开始做到功能完整前后花了大约三周时间。最大的体会是不要一上来就摊开一堆技术名词先确保用户能完成一条最简单的闭环——注册 → 浏览电影 → 给电影评分 → 收到个性化推荐结果。闭环跑通后面的优化才有意义。算法效果不理想可以先从数据质量找原因而不是急着换模型前端慢可以先看看是不是接口没有缓存评分提交不成功先检查 Token 和跨域配置。项目里每个模块都是可以独立验证的找到问题源头比盲目堆功能重要得多。如果你正准备做类似的项目我建议把注意力多放在“如何基于当前评分数据生成合理推荐”这个核心问题上。推荐系统当成一个普通 Web 项目做只做接口和页面最终呈现出来的东西会很单薄但当你真正把算法跑通、让推荐结果随着用户评分变化而发生肉眼可见的调整时这个项目就真正有了灵魂。后续你还可以继续扩展基于内容的推荐、热门榜单、相似电影推荐等功能一步步升级每一次升级都能让你学到新技术。