基于Django与协同过滤的电影推荐系统设计：从爬虫到可视化全攻略

毕业设计做电影推荐系统，这个题我太熟了。每年到了这个季节，总有一批计算机专业的学生在“选题焦虑”和“技术选型焦虑”之间反复横跳。Django、协同过滤算法、爬虫、可视化、大数据，这几个词拼在一起，看起来像是一堆技术名词的堆砌，但真正上手做过的人都知道，这套组合其实是大数据方向毕设里相当经典、也相当稳妥的一条技术路线。

先说结论：这个题目的核心价值在于“完整链路”。从数据采集到数据存储，从算法引擎到Web应用，从后端接口到前端可视化，一条线全部打通。相比那些只做一个算法demo或者只写一个管理系统界面的毕设，这种全栈式项目在答辩时的说服力完全不是一个量级。我自己带过不少学生做类似方向的项目，这篇就把整个系统的设计思路、算法落地、爬虫实现、可视化方案，以及那些文档里不会写的坑，一次性拆解清楚。

1. 系统架构与方案选型：为什么偏偏是这套组合

1.1 选型逻辑：Django扛后端，协同过滤做大脑

很多人在选后端框架时会纠结是Flask还是Django。我的建议很直接：做毕设、做完整系统，Django的性价比碾压Flask。

不是说Flask不好，而是Flask太“自由”。自由意味着你需要自己去组织项目结构、自己设计ORM映射、自己处理Admin后台、自己去拼装Session、Cache、Auth这一堆组件。Django则是“全都要”的典型代表——自带Admin后台、自带ORM、自带用户认证体系、自带模板引擎和静态文件处理机制。对毕设来说，这意味着你从零到跑通一个带登录注册、带后台管理的完整Web应用，省掉的时间足够你再折腾两轮协同过滤算法。

再说协同过滤。这是推荐系统里最经典、也是面试和答辩时最好解释的算法。它不需要复杂的特征工程，不需要深度学习那种“黑箱”式的模型结构，核心思想就一句话：物以类聚，人以群分。UserCF（基于用户的协同过滤）找跟你口味相似的人，把那些人喜欢的电影推荐给你；ItemCF（基于物品的协同过滤）找你喜欢过的电影的“孪生兄弟”，把相似电影推给你。这种算法逻辑清晰、代码实现可控、效果可见，非常适合作为毕设的核心算法支撑。

1.2 数据链路设计：爬虫喂数据，Redis做缓存，MySQL做持久化

一个推荐系统没有数据就是空中楼阁。公开数据集（比如MovieLens）确实是备选方案，但它有两个问题：一是数据太“干净”，清洗部分没有工作量；二是数据跟自己系统的契合度需要额外适配，答辩时讲“数据的获取与处理”环节会显得单薄。

所以这个项目里引入了爬虫来构建数据集——这既是技术需要，也是毕业设计的“内容填充”需要。通过爬虫抓取电影的基础信息、评分数据、类型标签、封面图，构建出包含用户-电影-评分三元组的核心数据集。这里的技术栈用requests + BeautifulSoup或者Scrapy都可以，具体我在后面的部分展开。

存储层面用MySQL做持久化存储，保留完整的用户表、电影表、评分表。Redis在这个项目里的角色容易被人忽视，但实际上很关键——它承担两个职责：一是缓存热门电影榜单、推荐结果等高频读取的数据，减轻MySQL压力；二是存储用户Session或者Token，提升Web应用的响应体验。这一层不复杂，但写进论文里就是“使用Redis构建缓存层提升系统并发响应能力”，这个表述在答辩时很加分。

1.3 可视化到底解决什么问题

可视化不是锦上添花，它是整个项目的“门面”。想想答辩时的场景：评委打开你的系统，第一眼看到的是什么？不是你后端写得有多优雅，不是算法调参调得多精准，而是页面上的图表和数据面板。

ECharts是这个项目里可视化部分的主力。用Django的API把数据喂给前端，前端通过ECharts渲染出电影类型分布饼图、评分区间直方图、热门电影排行榜、用户行为趋势折线图等等。这些图表的意义不仅仅是好看，它们承载的是“数据分析”这个模块的完整性——从数据采集到数据存储，从数据分析到数据展示，这是一个完整的大数据项目叙事逻辑。

2. 数据采集与存储实现：爬虫不是莽着抓就完事

2.1 冷启动问题与数据集构建策略

整个系统的数据流是这样的：启动爬虫脚本，抓取一批电影基础信息（名称、类型、导演、演员、上映时间、封面链接、简介），同时抓取用户在平台上的评分行为数据。这些原始数据经过清洗后写入MySQL，形成推荐算法所需的数据基础。

这里有个毕设常见的问题：真实平台（比如豆瓣、IMDb）的评分数据量是百万级的，你不可能全量抓取，也没有必要。我的做法是设置一个可控的目标：抓取几百部核心电影和对应的几千条评分记录，保证每个用户至少有20个以上的评分行为，每个电影至少有5个以上用户评过分。这个数量级对协同过滤算法来说已经能产生可用的推荐结果，同时数据处理流程完整，论文里有数据可写，答辩时有数据可讲。

2.2 SQLAlchemy与Django ORM的数据模型设计

这里有个细节值得注意：热搜词里出现了“SQLAlchemy储存爬虫数据”，而Django默认用的是自己的ORM。为什么会出现SQLAlchemy？因为爬虫脚本很多时候是独立于Django项目运行的，你完全可以在爬虫模块中用SQLAlchemy建立独立的数据库连接和ORM模型，将清洗后的数据写入MySQL，Django应用再通过自己的ORM去读取同一份数据。

这样设计的好处是解耦——爬虫是爬虫，Web应用是Web应用，两者通过数据库交互，不互相干扰。如果强行把爬虫逻辑塞进Django的app里，你会发现管理和调试都非常别扭。

核心数据表结构设计如下：

• 用户表：user_id、username、password_hash、注册时间
• 电影表：movie_id、title、genres、rating_average、cover_url、release_date、intro
• 评分表：record_id、user_id、movie_id、score、timestamp
• 行为日志表：log_id、user_id、movie_id、action_type（浏览/收藏/评分）、timestamp

评分表是整个协同过滤算法的核心数据源。它的数量级决定了算法的推荐质量。在爬虫设计时，需要有意构造“用户-电影评分矩阵”——具体做法是模拟多个用户角色，采集他们各自对不同类型电影的评分偏好，形成有一定区分度的评分矩阵。

2.3 爬虫的坑与反爬应对思路

Python爬虫这块，我的建议是requests + BeautifulSoup 就能覆盖绝大多数场景。Scrapy功能强但学习成本高，对毕设来说会分散你对核心算法和系统架构的精力。

实际踩过的坑有两个：

第一个是编码问题。很多网站的页面编码是GBK或者GB2312，直接用requests返回的text属性会乱码。正确做法是用response.encoding显式指定解码方式，或者用response.content.decode('gbk', errors='ignore')这种容错解码方式。

第二个是请求频率控制。爬虫跑太快容易被封IP。一套简单可靠的“绅士爬虫”配置包含三要素：随机User-Agent池、随机延时（比如1到3秒之间随机sleep）、单次请求失败后的重试机制。写代码时给每个请求加一个time.sleep(random.uniform(1, 3))，看似简单，但能省掉你一半的封IP麻烦。

因为是毕设/项目实战，不建议也不必要去做高强度的逆向破解。抓取那些对爬虫态度相对温和、数据结构规整的公开数据源，足以满足项目需求。

2.4 数据清洗：脏数据是一切推荐效果的隐形杀手

爬虫抓下来的数据直接喂给算法，结果一定是灾难。我做这个项目时在数据清洗环节遇到过三个典型问题：

1. 电影名重复。同一部电影在不同来源里出现多个标题表述（比如英文名和译名），需要做去重合并。
2. 字段不完整。部分电影没有导演信息或者上映时间缺失，处理策略是：核心字段（电影名、类型、评分）缺失的记录直接丢弃，次要字段（简介、封面）缺失的保留但填充默认值。
3. 评分尺度不一致。如果数据来源于多个平台，各平台的评分机制不一样，需要统一归一化到同一尺度。比如A平台是5分制，B平台是10分制，直接混用会严重干扰协同过滤算法的相似度计算。

注意：数据清洗的质量直接决定了协同过滤的推荐效果。算法再牛，喂给它一锅脏数据，出来的结果也一定是垃圾。答辩时讲清楚“数据采集→清洗→归一化→入库”这条链路，本身就是重要的工作量展示。

3. 协同过滤推荐算法：从公式到代码完整落地

3.1 UserCF和ItemCF：到底怎么选

协同过滤分为两大类：UserCF和ItemCF。用户规模小用UserCF，物品规模小用ItemCF——这是理论上的选择依据。放在电影推荐的具体场景里，我更推荐以ItemCF为主算法，UserCF作为辅助对照。

原因是电影这个场景有其特殊性：用户的兴趣相对稳定，电影的数量和用户数量相比是“小头”。ItemCF可以根据用户历史喜欢的电影，实时找出相似的电影推荐出去，计算量可控，推荐结果也更容易解释——“因为你喜欢《盗梦空间》，所以推荐《星际穿越》”。这种推荐理由在演示时直观感极强。

但UserCF也有它的价值。当用户没有足够的历史评分时，ItemCF无从下手，这时候可以通过UserCF找到“跟自己口味最像的人”，参考他们的观影列表来推荐。两个算法在系统中可以并存，用加权或者分策略的方式来输出最终结果。

3.2 相似度计算：余弦相似度的工程实现

协同过滤的核心是相似度计算。最常用的是余弦相似度。原理用生活化的方式说就是：把每个用户的评分看作一个向量，向量的维度是所有电影，用户对每部电影的评分就是该维度上的数值。两个向量的夹角越小，说明两个用户的口味越接近。

公式长这样：

similarity = cos(θ) = (A·B) / (|A| * |B|)

具体到Python实现，用numpy可以非常简洁地写出这个逻辑。

import numpy as np def cosine_similarity(vec_a, vec_b): """计算两个向量的余弦相似度 vec_a, vec_b: 维度一致的评分向量，0表示该用户未对电影评分 """ # 找出两个用户都评过分的电影索引（非零交集） common_indices = np.nonzero((vec_a > 0) & (vec_b > 0))[0] if len(common_indices) == 0: # 没有共同评分记录，相似度直接按0处理 return 0.0 vec_a_common = vec_a[common_indices] vec_b_common = vec_b[common_indices] # 余弦相似度计算 numerator = np.dot(vec_a_common, vec_b_common) denominator = np.linalg.norm(vec_a_common) * np.linalg.norm(vec_b_common) if denominator == 0: return 0.0 return numerator / denominator

这里有两个工程细节要注意：

细节一：冷启动处理。两个用户没有共同评分的电影时，向量点积为0，相似度也为0。在实际系统中，这意味着他们“没有可比性”，不参与彼此的推荐计算。这是合理的，因为完全没有任何共同口味基础的用户，强拉关系反而会产生劣质推荐。

细节二：评分向量稀疏性问题。实际评分矩阵极其稀疏，大部分用户只对一小部分电影打过分。直接对整个矩阵做numpy运算会浪费大量内存和计算资源。实际做法是维护一个“用户-评分记录索引字典”，只对有一定重叠度的用户对或物品对计算相似度。

3.3 ItemCF推荐全流程：一个可直接落地的完整逻辑

ItemCF的推荐流程分四步走：

第一步：构建“电影-评价用户”倒排索引。遍历所有评分记录，为每个电影维护一个列表，记录哪些用户给它评过分以及评分是多少。

第二步：计算电影间相似度矩阵。对任意两个电影，找出共同评价过它们的用户集合，计算两条评分向量的余弦相似度。这一步是计算量最大的环节，优化策略是只计算那些有共同评价用户且共同用户数超过阈值的电影对。

第三步：生成用户推荐列表。根据用户的历史评分记录，对每个用户评过分的电影，找出与之最相似的N部电影，按相似度加权汇总，剔除用户已经看过的电影。

第四步：TopK推荐输出。对加权汇总后的候选电影按分数排序，取前K个结果展示给用户。

核心代码如下：

def item_based_recommend(user_id, user_ratings, item_sim_matrix, top_n=10): """ user_ratings: 当前用户的评分字典 {movie_id: score} item_sim_matrix: 电影相似度矩阵 {movie_a: {movie_b: similarity}} """ # 给每部候选电影累计加权分 scores = {} # 遍历用户评过分的电影 for rated_movie, rating in user_ratings.items(): # 找出与当前电影相似的其他电影 similar_movies = item_sim_matrix.get(rated_movie, {}) for movie_b, sim in similar_movies.items(): # 跳过用户已经评过分的电影 if movie_b in user_ratings: continue # 加权累加 scores[movie_b] = scores.get(movie_b, 0) + sim * rating # 按加权分数排序取TopN sorted_movies = sorted(scores.items(), key=lambda x: x[1], reverse=True) return [movie_id for movie_id, _ in sorted_movies[:top_n]]

3.4 算法改进：从“能跑”到“跑得好”

如果只用基础协同过滤，推荐效果往往有“热门化倾向”——大部分用户推荐出来的都是同一批热门电影，个性化程度不足。我在项目里做了三个改进：

改进一：评分归一化。用户评分习惯不同，有人习惯打高分，有人习惯打低分。直接将原始分用于相似度计算，会让“严苛用户”的评分向量在数值上整体偏低，影响相似度判断。处理方式是对每个用户的评分做均值中心化——每个评分减去该用户所有评分的均值，得到“相对喜好度”。

改进二：热门物品降权。一个人喜欢《肖申克的救赎》不代表他有什么独特品味，因为几乎人人喜欢。真正能体现用户个性的是那些“小众但打了高分”的电影。实现方式是在加权评分时除以log(1 + 该物品的流行度)，对热门物品的贡献做惩罚。

改进三：相似度阈值过滤。相似度低于0.3的电影对直接忽略，既降低了计算量，又避免了噪声数据对推荐结果的干扰。

这三个改进在答辩时非常好讲——它们体现的是你对算法原理的理解深度，而不是简单地调包调用。

4. Django后端架构：API设计与功能模块拆解

4.1 项目结构规划：从一开始就别乱

Django项目最怕目录结构乱七八糟。我的推荐布局是把系统拆成几个清晰的应用（app），每个app只负责一条业务线。

movie_recommend/ ├── manage.py ├── config/ # 项目配置：settings、urls ├── apps/ │ ├── users/ # 用户模块：注册、登录、个人信息 │ ├── movies/ # 电影模块：电影列表、详情、搜索 │ ├── ratings/ # 评分模块：评分提交、记录查询 │ ├── recommendations/ # 推荐模块：核心算法调用与结果输出 │ └── statistics/ # 统计可视化模块：图表数据API ├── utils/ # 通用工具：缓存封装、相似度计算、爬虫脚本 └── scripts/ # 独立爬虫脚本、数据初始化脚本

这种结构的好处是：每个模块都可以独立测试，功能边界清晰，论文里画系统架构图的时候也能一步到位。

4.2 核心API接口设计

这个系统需要提供以下几类核心接口：

• POST /api/register：用户注册，写入用户表，密码用Django内置的make_password加密
• POST /api/login：用户登录，返回Token，后续请求在Header中携带
• GET /api/movies：电影列表，支持分页、按类型筛选、按关键字搜索
• GET /api/movies/：电影详情，返回完整信息并附带推荐该电影的理由
• POST /api/ratings：用户提交评分或修改评分
• GET /api/recommendations：获取针对当前用户的TopN推荐结果
• GET /api/statistics/overview：返回可视化大屏所需的聚合统计数据

这里有个实际项目经验要分享：把推荐结果缓存到Redis。因为协同过滤的计算虽然不算慢，但也不是毫秒级响应——尤其是数据集变大之后，每次请求都现算推荐结果会明显拖慢响应速度。我的做法是：用户第一次请求推荐时计算并写入Redis，设置10分钟的过期时间，过期后重新计算。这样既保证数据新鲜度，也保证接口响应速度。

4.3 Django执行查询与对象操作：几个高频场景的代码示范

很多人搜“django执行查询-删除对象”，那我就把这两个高频操作的规范写法放这里。

查询操作，使用Django ORM的链式过滤：

# 查询评分大于4分且类型包含"科幻"的电影 movies = Movie.objects.filter( rating_average__gte=4.0, genres__contains="科幻" ).order_by("-rating_average")[:20] # 查询指定用户评过分的所有电影（多表关联） user_rated_movies = Movie.objects.filter( rating__user_id=user_id ).distinct()

删除操作，要注意批量删除和单条删除的取舍：

# 删除单条评分记录 rating = Rating.objects.get(record_id=record_id) rating.delete() # 批量删除（注意：不会自动触发每个对象的delete方法） old_records = Rating.objects.filter(timestamp__lt=cutoff_date) deleted_count, _ = old_records.delete()

批量删除时尤其要注意，Django的QuerySet.delete()方法是直接SQL级别的批量删除，不会调用模型自定义的delete()方法。如果模型里重写了delete()做了一些额外逻辑（比如删除后更新缓存），批量删除会跳过这些逻辑。这种隐藏的坑平时遇不到，遇到了就是bug排查半小时起。

5. 数据可视化与前端交互：大屏展示才是答辩的门面

5.1 ECharts接入Django的完整链路

可视化大屏的数据流前端和后端通过JSON交互。Django的视图函数从数据库聚合数据，转换为JSON，通过JsonResponse返回给前端，前端拿到数据后交给ECharts实例渲染。后端只需要提供数据，图表渲染逻辑全在前端。

下面是Django侧返回可视化数据的标准写法：

from django.http import JsonResponse from django.db.models import Count, Avg from apps.movies.models import Movie, Rating def statistics_overview(request): # 1. 电影类型分布 type_distribution = Movie.objects.values("genres").annotate( count=Count("movie_id") ) # 2. 评分区间分布 rating_distribution = Rating.objects.values("score").annotate( count=Count("record_id") ) # 3. 热门电影Top10 top_movies = Movie.objects.order_by("-rating_average")[:10].values( "title", "rating_average" ) data = { "type_distribution": list(type_distribution), "rating_distribution": list(rating_distribution), "top_movies": list(top_movies), } return JsonResponse(data)

前端的可视化实现，用一个基本的饼图展示电影类型分布作为示例：

// 页面引入 echarts.min.js 后 const chartDom = document.getElementById('typeChart'); const myChart = echarts.init(chartDom); fetch('/api/statistics/overview') .then(response => response.json()) .then(data => { myChart.setOption({ title: { text: '电影类型分布', left: 'center' }, tooltip: {}, series: [{ type: 'pie', radius: '55%', data: data.type_distribution.map(item => ({ name: item.genres, value: item.count })) }] }); });

5.2 可视化大屏的布局设计逻辑

可视化大屏不是把几个图表堆在页面上就完事了，它需要有一个叙事逻辑。我的设计思路是三个区域：

左侧区域：展示数据整体情况，包括电影总数、用户总数、评分总数、平均评分等KPI卡片，搭配评分区间分布图。这个区域回答的问题是“系统里有什么”以及“数据质量如何”。

中间区域：展示推荐引擎的核心输出，包括热门电影Top10榜单、推荐结果瀑布流展示。这个区域回答的问题是“推荐系统怎么工作”。

右侧区域：展示用户行为分析，包括用户活跃时段分布、评分趋势、类型兴趣雷达图。这个区域回答的问题是“用户喜欢什么”。

大屏布局通常用Grid布局或者Flex布局配合百分比宽度实现，加上深色背景、光效边框，做出数据大屏的“科技感”。这里不推荐用现成的大屏模板直接套，因为那些模板的布局跟你的数据往往不匹配。自己画一个简单的布局，每个区域放一个图表容器，效果反而更贴自己的需求。

5.3 WebSocket实时推送：当后台有新数据时前端自动更新

热搜词里有“django websocket实现后台有数据前端推送”，这个功能放在可视化大屏上非常出彩——爬虫定时抓取新电影数据写库后，后台通过WebSocket推送一个通知，前端图表自动更新。答辩现场演示的效果比任何口头描述都有说服力。

实现方案有两种：

方案一：Django Channels。这是Django官方的异步扩展，支持WebSocket协议。配置比较复杂，需要安装channels、channels-redis，改造ASGI入口。

方案二：SSE（Server-Sent Events）。基于HTTP的单向推送，服务端到客户端的实时推送，实现比WebSocket简单得多，浏览器原生支持EventSource接口，对“后台有数据前端推送”这个场景完全够用。

如果只是做毕设，我更推荐SSE——少引入一个组件，少踩一半的坑。用Django的StreamingHttpResponse来持续推送事件：

import json import time from django.http import StreamingHttpResponse def stream_new_movies(request): def event_stream(): last_count = Movie.objects.count() while True: time.sleep(5) current_count = Movie.objects.count() if current_count != last_count: yield f"data: {json.dumps({'new_count': current_count - last_count})}\n\n" last_count = current_count return StreamingHttpResponse(event_stream(), content_type='text/event-stream')

前端用EventSource监听：

const source = new EventSource('/api/stream/movies'); source.onmessage = function(event) { const data = JSON.parse(event.data); showNotification(`新增${data.new_count}部电影，正在刷新...`); refreshCharts(); // 重新拉取统计数据并刷新图表 };

5.4 前端遇到Django静态文件的坑：img标签显示不了

这是热搜词里出现的高频问题：“vscode写img标签在django的static文件中显示不了”。原因很简单，Django在生产模式下不会自动提供静态文件服务，而且模板里的静态文件引用必须通过专门的模板标签来处理。

正确写法是：

{% load static %} <img src="{% static 'images/poster.jpg' %}" alt="电影海报">

而不是直接写相对路径：

<!-- 错误写法 --> <img src="/static/images/poster.jpg">

虽然这个写法在debug=True时偶尔能生效，但一旦关闭debug模式就会失效。原因在于Django的静态文件处理机制：模板中的{% static %}标签会根据STATIC_URL配置动态生成URL，并且能正确处理带版本号的静态文件。直接写死路径则完全没有这些机制的支持。

另外还要确认settings.py里做了这些配置：

STATIC_URL = '/static/' STATICFILES_DIRS = [BASE_DIR / 'static']

以及urls.py里在debug模式下挂载静态文件访问：

from django.conf import settings from django.conf.urls.static import static urlpatterns = [...] if settings.DEBUG: urlpatterns += static(settings.STATIC_URL, document_root=settings.STATICFILES_DIRS[0])

6. 部署、排错与毕业答辩全流程避坑指南

6.1 本地开发环境怎么配才不出幺蛾子

这个项目的本地环境配置，按下面这个顺序来基本不会出错：

第一步：Python版本。建议用Python 3.8到3.10之间，不要追最新的3.12/3.13。很多第三方库的兼容性还没跟上最新版本，装包时报错会非常打击士气。

第二步：依赖安装。在项目根目录建一个requirements.txt，一次性列全所有依赖：

Django>=4.0,<5.0 djangorestframework>=3.14 pandas>=1.5 numpy>=1.24 requests>=2.28 beautifulsoup4>=4.11 redis>=4.5 sqlalchemy>=2.0 PyMySQL>=1.0

用pip install -r requirements.txt一条命令装完。千万别一个包一个包手动装，遗漏的依赖会让你排查到怀疑人生。

第三步：数据库准备。MySQL建库时统一用utf8mb4字符集，避免中文乱码。然后在settings.py里配置数据库连接信息：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'movie_recommend', 'USER': 'root', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } }

第四步：Redis安装与启动。Windows用户直接用官网的Redis for Windows，Linux用户用apt或yum安装。启动后确认6379端口是通的。

第五步：迁移与初始化。先跑python manage.py makemigrations，再跑python manage.py migrate。然后把爬虫抓取的CSV数据通过初始化脚本批量写入数据库。

6.2 高频报错与排查方案速查表

这些是我在实际部署过程中踩过的、也是学生问得最多的报错，整理成一张表给各位存好：

6.3 部署上线：从本地到服务器的关键三步

如果答辩前要求在线演示系统，部署到Linux服务器是躲不掉的一步。不求生产级高可用，但至少要做到“外网能访问”的级别。

第一步：安装基础环境。服务器上装好Python 3.8+、MySQL、Redis、Nginx。用virtualenv或venv创建虚拟环境，把代码传上去，pip install依赖，迁移数据库，python manage.py runserver 0.0.0.0:8000先验证本地能跑通。

第二步：用Gunicorn跑动态接口。

gunicorn config.wsgi:application -b 0.0.0.0:8000 --workers 3

注意用Django的WSGI应用入口，workers数量按服务器核数配置。

第三步：Nginx反向代理。把80端口转发到8000端口，同时托管静态文件：

server { listen 80; server_name your_server_ip; location /static/ { alias /path/to/project/static/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里有个很大的坑提醒一下：Django的debug模式在部署时必须关闭，否则静态文件服务变慢、报错信息泄露，安全性也有隐患。但关闭debug后静态文件全要靠Nginx托管——如果你之前没有用{% static %}规范引用，部署时就会突然发现页面全都变成“素颜”了。

6.4 答辩演示的三条“保命”建议

技术做完了，最后一步是答辩。从我带学生的经验看，算法本身做得再牛，演示环节翻车也是致命的。三件事务必提前准备好：

第一件：准备一份干净的演示数据包。答辩现场的服务器环境跟开发环境不一样，重新爬数据不现实。把采集好的CSV数据连同初始化脚本一起打包，上台前一条命令初始化完毕。

第二件：推荐结果的“证据链”要提前设计好。不要随便找个用户登录看推荐，你要知道自己要演示什么：比如用户A看过《盗梦空间》《星际穿越》，系统推荐了什么；为什么推荐这些？因为ItemCF计算发现它们的相似度最高。这条逻辑链在答辩提问环节是核心。

第三件：预演“缓存没命中”的场景。答辩时如果Redis突然没启动，你的接口会是怎样一个表现？是优雅降级重新计算，还是直接报错？我在项目中统一做了这样的处理：推荐接口读取Redis失败时，主动回退调用算法实时计算——这就是为什么核心推荐逻辑不能只放在Django视图里，要单独抽取成服务层。好的架构设计，在答辩现场救你命。

最后分享一点个人体会

做这类“Django+协同过滤+爬虫可视化”的完整链路项目，最大的价值不在于你用了多前沿的技术，而在于你打通了一条完整的数据管道——从爬虫端的数据采集，到数据库端的存储清洗，到算法端的推荐计算，到Web端的展示交互。这个“端到端”的能力，恰恰是很多只做算法调参或者只做页面开发的人所欠缺的。

如果你也在做这个方向，我最想叮嘱的一句话是：不要只盯着代码能不能跑通，多花点时间想清楚每一层之间如何衔接、每个数据流如何流转。答辩时老师问的往往不是你调用了哪个函数，而是你为什么要这样设计、遇到了什么困难、是怎么解决的。把这些想透了，这个项目你才真正算得上“做完”了。