图书推荐系统毕设全攻略：Python+Spark+Django+协同过滤完整闭环

每年到毕设选题季，“图书推荐系统”基本是热门候选里的前排选手。题目看起来平平无奇，但把技术栈换成 Python + Spark + Django + 协同过滤推荐算法之后，整个项目的层次一下就不同了——这不再是“增删改查 + 算法糊弄”的 CRUD 毕业设计，而是一套有数据采集、离线计算、实时服务、可视化展示的完整闭环。

我见过太多人选了这个题目，最后却只交出一个 Django 博客 + 一个 SK-learn 电影评分预测 Demo，答辩被老师当场问住：Spark 在哪？协同过滤的公式是什么？可视化数据从哪来？所以这篇我打算从一个能拿良好甚至优秀等级的项目视角，把它完整拆一遍。不管你是正在选题的应届生，还是想拿推荐系统练手攒项目经验的开发者，照着这条路线推进，绝大多数暗坑都能提前避开。

1. 选这个题目之前，先想清楚它是“几个模块的拼盘”

很多同学拿到题目后的第一反应是“我要开始写代码了”，但我的建议正好相反——先花两天时间做产品拆解。图书推荐与协同过滤平台表面上是一个 Web 系统，实际上藏着五个相互独立又需要串联的子模块，如果上来就写，后面必然返工。

1.1 从标题关键词反向推导功能模块

把题目里的关键词逐个拿出来对照，你会发现每个词都对应一块逃不掉的工作量：

别急着追求大而全。我建议系统边界收拢成五个页面：登录注册、书架浏览/搜索、图书详情+评分、个人推荐中心、数据分析看板。其中“相似图书”和“猜你喜欢”必须在详情页和个人中心之间互相呼应，这样答辩时能讲清楚推荐结果从哪里来、往哪里去。

1.2 数据模型设计是决定算法能不能落地的地基

如果你把 Rating 表设计成“用户对图书的评论内容 + 分数”混在一起，后面 Spark 写 SQL 统计时会觉得很别扭。推荐领域最经典的四张核心表基本是固定的：

• User：用户信息，可以在 Django 自带的 AbstractUser 上扩展。
• Book：图书元信息，包括 ISBN、书名、作者、出版社、分类、出版日期、价格。
• Rating：用户-图书评分，这是整个推荐算法的核心输入。
• RecommendResult：离线推荐结果表，用户每次刷新页面时直接读这张表，而不是现场调 Spark。

Django 里的最小模型可以直接参考下面这版：

python复制from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    nickname = models.CharField(max_length=32, blank=True)

class Category(models.Model):
    name = models.CharField(max_length=64, unique=True)

class Book(models.Model):
    isbn = models.CharField(max_length=20, unique=True)
    title = models.CharField(max_length=255, db_index=True)
    author = models.CharField(max_length=128)
    publisher = models.CharField(max_length=128, blank=True)
    pub_date = models.DateField(null=True, blank=True)
    price = models.DecimalField(max_digits=6, decimal_places=2, default=0)
    category = models.ForeignKey(Category, on_delete=models.SET_NULL, null=True)
    desc = models.TextField(blank=True)

class Rating(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='ratings')
    book = models.ForeignKey(Book, on_delete=models.CASCADE, related_name='ratings')
    score = models.PositiveSmallIntegerField()  # 1-5 分
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        unique_together = ('user', 'book')

class RecommendResult(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE, db_index=True)
    book = models.ForeignKey(Book, on_delete=models.CASCADE)
    rank = models.PositiveIntegerField()
    algorithm = models.CharField(max_length=16)  # itemcf / als / hot
    created_at = models.DateTimeField(auto_now=True)

    class Meta:
        ordering = ['user', 'rank']

额外强调一点：尽量保留 RecommendResult.algorithm 字段。答辩时老师问“哪些结果是 ItemCF 算出来的，哪些是热门榜兜底的”，你可以直接跑一条 SQL 统计出来，这种细节比嘴上解释“我用了协同过滤”有说服力得多。

1.3 书籍数据从哪里来：公开数据集的“围城”

做图书推荐最常见的做法是拿公开数据集，但这里有个深坑：非常经典的 MovieLens 电影评分数据集虽然字段干净、评分量大，可你做的题目是“图书推荐”，如果演示页面里全是电影海报，会非常违和。

我建议两条路：

一是找 Book-Crossing 这类图书评分公开数据，但它的数据噪声很大，ISBN 编码混乱，清洗成本不低。二是自己造一份仿真数据，比如写脚本生成 8000 本书和 6-10 万条评分，让评分分布符合“长尾效应”——头部几百本书拿走了大部分评分，尾部大量书籍只有零星几条。这样反而更接近真实场景，协同过滤算法也能看出明显效果。

如果你手头有爬虫经验，爬一些开源的书籍信息来做封面展示没问题，但注意不要抓取具有版权争议的内容页，保留少量字段用于展示即可。坦白说，毕设核心是算法和工程链路，数据规模在 10 万级就足够跑通 Spark 了，不需要真的堆到上亿条。

2. 协同过滤为主、大模型为辅：算法层怎么设计才不会被问倒

推荐算法是整个项目最容易被追问的部分。常见的低级错误是：只会调用 model.fit()，连协同过滤的两大分支都说不清楚。这一节我把选型逻辑和核心公式一次讲明白。

2.1 UserCF 和 ItemCF 到底选哪个

协同过滤分两类：

基于用户的协同过滤（UserCF）先找与当前用户兴趣相似的其他用户，再把这些相似用户喜欢的物品推荐给他。它在用户量小、物品变化快的场景下更合适，比如新闻资讯。

基于物品的协同过滤（ItemCF）先计算物品与物品之间的相似度，然后把“和你历史上喜欢过的物品相似”的其他物品推荐给你。电商、视频网站、图书平台几乎都用它，理由是能给出可解释的推荐语——“因为你读过《百年孤独》，给你推荐《霍乱时期的爱情》”。

图书平台天然适合 ItemCF。书目相对稳定，用户兴趣会随阅读阶段变化，按“物品相似”去推荐，比按“用户相似”去推荐解释性更强。即使你没有完整实现两者，也应该在文档里做一张对比表，说明为什么选 ItemCF，这是答辩时的加分动作。

2.2 图书场景下 ItemCF 的两步计算逻辑

第一个公式是用户行为打分矩阵的正则化。假设用户 u 对物品 i 的评分为 r_ui，我们能得到“用户-物品”矩阵。在纯隐式反馈场景下 r_ui 可以只用 0/1 表示是否点击或购买；在有评分的情况下直接用分数即可。

第二个公式是物品间相似度，常用余弦相似度：

sim(i, j) = (Σ_u r_ui * r_uj) / (sqrt(Σ_u r_ui²) * sqrt(Σ_u r_uj²))

分母是各自评分向量的模长乘积，分子是两个物品共同被同一批用户评分时的加权和。为什么用余弦而非简单的“共同评分次数”？因为评分次数只会体现出热度，无法体现评分模式的一致性；比如两本书都频繁被评，但喜欢书 A 的人给低分、喜欢书 B 的人给高分，它们的真实相似度就很低。

开算之前还要对原始评分做一次“用户均值中心化”，把每个用户的评分减去他自己的平均分。原因很现实：有些人习惯打 4-5 分，有些人习惯打 2-3 分，如果不做去偏，余弦相似度会被评分尺度的偏好污染。这一步用 PySpark 做非常简单：

python复制from pyspark.sql import functions as F

ratings = spark.read.csv("ratings.csv", header=True, inferSchema=True)
avg = ratings.groupBy("user_id").agg(F.avg("score").alias("avg_score"))
centered = ratings.join(avg, "user_id") \
    .withColumn("norm_score", F.col("score") - F.col("avg_score"))

接下来做物品相似度矩阵的朴素实现思路是：先按用户分组，收集每个人评分过的图书集合，然后把集合内两两图书组成“共现对”。真正工程上可以这样写：

python复制from pyspark.sql.functions import collect_set, explode, size

item_users = ratings.groupBy("book_id").agg(collect_set("user_id").alias("users"))
# 统计每个物品的总评分人数，作为分母的一部分
item_cnt = ratings.groupBy("book_id").agg(F.countDistinct("user_id").alias("cnt"))

# 简化版：先把单本图书的共现对推导出来
user_books = ratings.groupBy("user_id").agg(collect_set("book_id").alias("book_ids"))
pairs = user_books.select(
    explode("book_ids").alias("book_i"),
    "book_ids"
).selectExpr("book_i", "explode(book_ids) as book_j") \
 .filter("book_i != book_j") \
 .groupBy("book_i", "book_j") \
 .agg(F.countDistinct("user_id").alias("co_cnt"))

现实里不会对所有物品两两算一遍，因为复杂度是 O(N²)。你应该对每个物品先取评分人数 top 200 的候选集合，只在这个范围内计算相似度，效率会高非常多。这个“先粗筛再精算”的思路，答到会非常加分。

2.3 ALS 是效果兜底线，不是备选方案

理论上 ItemCF 是主导算法，但数据稀疏到一定程度后，基于物品的共现计数经常找不到相似书籍，这时候必须有一个保底：基于 Spark MLlib 的 ALS（交替最小二乘）矩阵分解。

ALS 的思想是把巨大的“用户-物品”评分矩阵拆成两个低维矩阵：用户特征矩阵和物品特征矩阵，两个矩阵相乘后尽可能还原原始评分。由于两个矩阵维度远低于原始矩阵，它能在稀疏数据上泛化出潜在的关联。Spark 里调用很简洁：

python复制from pyspark.ml.recommendation import ALS
from pyspark.ml.evaluation import RegressionEvaluator

(train, test) = ratings.randomSplit([0.8, 0.2], seed=42)

als = ALS(
    userCol="user_id",
    itemCol="book_id",
    ratingCol="score",
    rank=20,
    maxIter=10,
    regParam=0.1,
    coldStartStrategy="drop"
)

model = als.fit(train)
predictions = model.transform(test)
evaluator = RegressionEvaluator(metricName="rmse", labelCol="score", predictionCol="prediction")
rmse = evaluator.evaluate(predictions)
print(f"RMSE = {rmse}")

user_recs = model.recommendForAllUsers(10)
item_recs = model.recommendForAllItems(10)

rank 是隐语义特征的维度，太小欠拟合，太大容易过拟合且计算慢；regParam 是正则化系数，防止极小众用户和冷门书被拟合到噪声中。这两个参数可以通过简单网格搜索调优，答辩时可以输出一张不同参数下的 RMSE 对比表。

在实际结果里，我会让系统同时保存 itemcf 和 als 两套推荐结果。页面优先展示 ItemCF 结果，当它不足时用 ALS 结果补齐，最后一层才是热门榜。这样任何一个算法失效都不会导致页面空白，同时也展示了“多种召回策略融合”的工程意识。

2.4 冷启动与稀疏矩阵：没有评分记录的人怎么办

毕设演示最怕注册一个新账号，然后推荐页空无一物。冷启动问题必须单独设计。

处理办法按用户状态拆成三档：老用户直接读 ItemCF + ALS 结果；只有零星评分的新用户可以用“热门类别加权”——从他有打分的书的分类里拉出该分类下评分最高的书；完全没有任何行为的新用户，只能给平台热门榜。别觉得这样不“智能”，业界几乎所有推荐系统入口都有热门榜单兜底。

热门榜本身也可以做加权排序，不要只按平均分倒序。因为一本 5 星书只要有 2 个人评分就可能冲到榜首，冷启动期的正确排序规则是贝叶斯平均：

score = (avg_score * num_ratings + C * m) / (num_ratings + C)

其中 m 是全局平均分，C 是惩罚系数，可以通过试验调整，让样本量少的书向均值收缩。

2.5 大模型要加的话，这样加才不会被问倒

题目里出现了“大模型”三个字，很多同学的第一反应是让大模型直接做召回，也就是输入用户历史记录，输出推荐书单。这个路线在毕设里风险很高，因为大模型幻觉、实时性、算力成本都很难解释清楚。

更稳妥的定位是“推荐理由生成器”：让协同过滤先把候选书单算出来，然后大模型为每本书生成一两句推荐理由，比如“这本书延续了《三体》对宏大宇宙的思考，阅读门槛不高，但完成度很高”。前端展示时，用户看到的不再是干巴巴的“猜你喜欢”，而是一段有说服力的解释，产品的可用性和演示效果都会有明显提升。

如果邀请答辩现场联网调用云端模型 API，万一断网或账号额度用完就直接翻车。我的建议是把生成结果预先缓存到数据库里，Spark 每次产出新推荐列表后，只对新增书目生成理由；演示时优先展示缓存，这样既能体现大模型的存在，又不依赖现场网络环境。

3. Spark 环境搭建与数据离线计算：那些实测能避免的坑

Spark 环境配置是劝退最多人的第一步。如果在这里卡住两三天，后面进度就会全面崩盘。这一节我把最容易踩的三个坑单独拎出来说。

3.1 版本搭配比“最新版”更重要

不少同学一上来就装最新版 Spark 和最新版 JDK，结果一跑就报错。Spark 对 JDK 版本的兼容很敏感，过高的 JDK 版本会导致内部模块无法加载。我反复验证下来比较稳的一套组合是：

Spark 的下载包分为 Hadoop 版本，如果你的项目只在本地跑、不部署集群，选 pre-built for Hadoop 版本就可以，否则还要单独配置 Hadoop 客户端。Windows 上跑 Spark 需要把 SPARK_HOME 和 HADOOP_HOME 都配到系统环境变量里，并在 hadoop/bin 下放置对应版本的 winutils.exe，否则会直接报“Failed to locate the winutils binary”。

3.2 本地运行 PySpark 时的高频报错

即使版本没配错，还有几个经典问题：

Failed to locate the winutils binary in the Hadoop binary path。这是 Windows 下最经典的报错。下载对应 Hadoop 版本的 winutils.exe，放到 hadoop/bin 目录，然后配置 HADOOP_HOME 指向该目录即可。

Python 环境找不到。PySpark 启动时会默认寻找 python 命令，如果你用的是虚拟环境或 Anaconda，就需要设置环境变量：

bash复制# Windows 命令行临时设置
set PYSPARK_PYTHON=D:\conda\envs\recsys\python.exe
set PYSPARK_DRIVER_PYTHON=D:\conda\envs\recsys\python.exe

Py4JJavaError: An error occurred while calling o123.save。这种 Java 层报错背后往往才是真正原因，比如 MySQL JDBC 驱动没放进 Spark 的 jars 目录。把 mysql-connector-java 的 jar 包放到 $SPARK_HOME/jars 下，重新启动就能解决。

3.3 不是一定要搭集群

看到 Spark 就觉得自己要搭 Hadoop 集群、配 HDFS，这种想法会把自己吓退。毕业设计的数据量也就几十万条，单机 Spark 的 local 模式完全能跑出效果。启动代码里用 .master("local[*]") 就是本地多线程运行，所有分布式能力都在，只是没有跨机器调度而已。

为什么还要用 Spark，不直接用 Pandas？因为评分矩阵的笛卡尔积运算在 Pandas 里容易内存溢出，Spark 的 DataFrame 和惰性计算能自动优化执行计划，而且你在毕设文档中写“基于 Spark 的分布式计算”整体技术立意也更高。你只需要在文档中坦诚地说明：本地开发使用 local 模式，生产环境可扩展为 Standalone/YARN 集群。做到这个程度，答辩老师基本不会再揪着环境问题不放。

3.4 离线计算任务到底应该算几轮

推荐结果前一天晚上的数据和今天凌晨的数据可能差别很大，所以不能只跑一次。建议用 APScheduler 设定每天凌晨 2 点触发一次离线任务：

拉取用户行为日志 → 清洗数据 → 计算热门榜 → 跑 ItemCF → 跑 ALS → 写回 MySQL → 更新大模型推荐理由缓存

Django 里启动定时任务可以直接借助 APScheduler：

python复制from apscheduler.schedulers.background import BackgroundScheduler
from django_apscheduler.jobstores import DjangoJobStore

def start_scheduler():
    scheduler = BackgroundScheduler()
    scheduler.add_jobstore(DjangoJobStore(), "default")
    scheduler.add_job(
        run_recommend_pipeline,
        trigger="cron",
        hour=2,
        minute=0,
        id="recommend_daily",
        replace_existing=True,
    )
    scheduler.start()

每天同一时间跑的好处是：Spark 只启动一次，多张结果表保持原子更新，不会出现页面上一部分推荐是新的、一部分是旧的。

4. Django 如何把 Spark 算好的结果稳定推送给前端

环境通了以后，真正的系统主体工作才开始。Django 负责用户交互，Spark 负责离线算数。数据链路要打通，关键在设计好“结果落地”和“缓存策略”两层。

4.1 Spark 结果写回 MySQL 的两种方式

Spark 算完推荐后，第一步是把结果持久化到业务数据库里。最直接的方式是 JDBC 写回：

python复制recommend_df.write.mode("overwrite") \
    .format("jdbc") \
    .option("url", "jdbc:mysql://localhost:3306/recsys?useUnicode=true&characterEncoding=utf8") \
    .option("dbtable", "recommend_result") \
    .option("user", "root") \
    .option("password", "yourpassword") \
    .option("driver", "com.mysql.cj.jdbc.Driver") \
    .save()

注意 mode("overwrite") 会先删表再写入，如果有外键关联会报错或影响线上查询。所以实际生产逻辑里，我建议先用一个 recommend_result_tmp 临时表写数据，写完以后用一个原子 SQL 切表：

sql复制RENAME TABLE recommend_result TO recommend_result_bak,
             recommend_result_tmp TO recommend_result;

这样页面在切换过程中不会读取到半截数据。

另一种方式是 Spark 先把结果输出为 Parquet 或者 CSV 文件，再由 Django 管理命令导入。这种方式更适合调试，因为你能用文本工具直接检查输出是否符合预期。开发期建议用文件方式，真正确认推荐链路没问题了，再切换成 JDBC 直写。

4.2 页面接口不应该每次请求都去查全表

如果每次用户刷新推荐页都执行 filter(user_id=...).order_by("rank")，在数据量不大时没问题，但 Demo 演示时一旦并发变高或者被别人访问，MySQL 的查询压力会直接反映到页面响应时间上。这里应该加一层 Redis 缓存。

Django 里可以这样设置缓存键：

python复制from django.core.cache import cache

def get_user_recs(user_id):
    cache_key = f"rec_user_{user_id}"
    recs = cache.get(cache_key)
    if recs is None:
        recs = RecommendResult.objects.filter(user_id=user_id).select_related("book")
        cache.set(cache_key, recs, timeout=30 * 60)
    return recs

缓存 30 分钟是一个比较合适的折中：用户再次刷新不需要反复查库，但每天凌晨 Spark 更新结果后，缓存最多延迟半小时也会失效。如果你希望更精细，可以每天任务跑完后主动删除所有 rec_user_* 前缀的键。

4.3 给前端返回什么结构

不要直接把 ORM 对象序列化给前端，建议通过 Django REST Framework 返回一个统一的推荐卡片结构：

• book_id：图书 ID
• title：书名
• author：作者
• category：分类
• score：预测得分或排序依据
• reason：大模型生成的推荐理由
• algorithm：产生该推荐的算法标签

下面是一个可以直接用的序列化思路：

python复制def recommend_api(request):
    user_id = request.user.id
    recs = get_user_recs(user_id)[:10]
    data = [{
        "book_id": r.book_id,
        "title": r.book.title,
        "author": r.book.author,
        "category": r.book.category.name if r.book.category else "",
        "score": round(r.rank_score, 4) if hasattr(r, "rank_score") else r.rank,
        "reason": r.reason_text,
        "algorithm": r.algorithm,
    } for r in recs]
    return JsonResponse({"code": 0, "data": data})

前端拿到这份 JSON 后直接渲染卡片列表即可。实际开发时，如果想省掉手写 JsonResponse 的繁琐，可以用 Django REST Framework 的 ModelSerializer，但要注意不要直接序列化整个 Book 对象，把不需要的字段暴露给前端反而会对性能造成损耗。

4.4 前端交互里的“用户行为回传”是完整闭环的关键

很多做推荐系统的毕设遗漏了关键一环：用户在前端给书打了分，但这个行为没有回流到 Spark 的输入数据集里。第二天 Spark 重新训练时，评分数据还是老的，推荐结果自然毫无变化。

解决方案很简单：用户每次评分或点击图书详情，前端都向后端发一条行为日志，后端写一张 user_behavior_log 表。离线任务开始前，把这张表里的增量数据合并到评分主表。这样你就能在答辩现场做真实演示：“给某本推理小说打 5 分，第二天重新触发训练，猜你喜欢里出现了更多推理书”。这个闭环逻辑是推荐系统项目最容易出彩的地方。

5. 可视化与数据分析：如何让页面自己会说话

可视化模块看似是锦上添花，实际上承担着证明数据链路真实性的任务。这里不需要做一个炫酷到失真的 3D 大屏，更需要的是让图表和数据来源可解释。

5.1 可视化应该展示哪几个维度

具体看板我建议安排四块内容：

图书评分分布。展示“评分-人数”的柱状图，它会很自然地呈现出一个偏态分布：4 分和 5 分集中，1-2 分低谷。这能直接说明原始数据的质量和用户打分倾向。

热门图书 TOP10。按贝叶斯平均排序，用横向条形图展示，同时标注每本书的评论数，让人一眼看出“热度”受数量和评分双重影响。

分类占比。用环形图或饼图展示各图书分类的占比，展示时顺便说明图书数据的采集范围覆盖是否均匀。

用户行为漏斗。从“注册用户-有过评分行为的用户-触发推荐点击的用户”三个指标拆解，这一块可以直接证明你的系统真的被使用了，而不只是后台造了一堆数据。

5.2 图表用 ECharts 而不是手写 Highcharts

Apache ECharts 是开源项目，在毕设场景里不存在商业授权问题，交互和图表类型也足够全。如果你不想在项目里引入完整的 Node 构建链路，直接在 Django 模板里用 CDN 引入即可：

html复制<script src="https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js"></script>

页面加载时通过 Fetch 请求 Django 写好的聚合接口：

javascript复制async function loadRatingDistribution() {
  const res = await fetch("/api/stats/rating-distribution/");
  const data = await res.json();
  const chart = echarts.init(document.getElementById("ratingChart"));
  chart.setOption({
    xAxis: { type: "category", data: data.scores },
    yAxis: { type: "value" },
    series: [{ type: "bar", data: data.counts }]
  });
}

这类接口的聚合逻辑非常简单：对 Rating 表 score 字段做 group by 计数，返回 JSON 即可。数据规模小的时候完全可以直接在 Django ORM 层算，不需要再去调用 Spark。

5.3 后端聚合接口示例

Django 视图可以做得很薄，业务都集中在 ORM 聚合上：

python复制from django.db.models import Count
from django.http import JsonResponse
from .models import Book, Rating, User

def rating_distribution(request):
    rows = (Rating.objects.values("score")
            .annotate(cnt=Count("id"))
            .order_by("score"))
    return JsonResponse({
        "scores": [r["score"] for r in rows],
        "counts": [r["cnt"] for r in rows],
    })

想看更复杂的趋势图，比如某个月份用户评分数量的变化趋势，直接把 Rating.created_at 按天做 truncate 后 Count 即可。别忘了给 created_at 加上索引，否则数据到几十万条以后这类聚合查询会变慢。数据和图表的对应关系要写清楚，答辩时如果被问“这个柱状图是从哪张表的哪个字段来的”，你要能立刻指出来。

6. 系统验收与答辩前最后冲刺：指标、实验与自查

写完功能和页面只能算完成 60%。剩下 40% 的工作，是把这个系统包装成“有实验、有指标、有结论”的完整项目。

6.1 推荐效果应该拿什么指标说话

口头说“推荐挺准”没有用，要拿数据证明。常见离线评估指标：

RMSE 用于评分预测，衡量预测分数与实际分数的偏差：

RMSE = sqrt( (1/N) * Σ (r_ui - r_hat_ui)² )

对推荐列表类任务，可以算 Precision@K 和 Recall@K。简单说就是在测试集中保留用户真实看过的书目，看你推荐列表的前 K 本书里命中了多少。我建议把 ALS 模型在随机切分出的训练集/测试集上跑一遍，输出 RMSE 和 Precision@5，做一个简单实验表格：

不需要跑复杂的交叉验证，一次 randomSplit 就足够支撑毕业设计的实验论证了。关键是表格里要有一个“热门榜基线”，有了基线，才能证明你的协同过滤算法比普通做法有效。

6.2 演示环境必须提前准备的三个细节

第一，不要在答辩现场跑 Spark 离线训练。现场网络、内存、临时目录各种不稳定因素叠加，训练可能要几分钟，老师等不起。你应该提前跑完任务，把结果写入 MySQL，并 dump 一份 SQL 快照。答辩时只要启动 Django 就能演示。

第二，准备一个新注册的测试账号提前造行为：给 5-10 本书打分、收藏几本，让推荐页有内容。不要临时注册一个空白账号，看到“暂无推荐”会影响第一印象。如果确实要用空白账号演示冷启动，也应该提前想好台词：“这是冷启动场景，平台会先推荐热门榜，等用户产生行为后再逐步个性化”。

第三，PowerPoint 里放一张最终的架构图，手绘或 draw.io 画都行，但层次必须清晰：用户行为采集 → MySQL → Spark 离线计算 → 结果写回 MySQL/Redis → Django API → 前端可视化。这张图能让答辩老师 30 秒内理解你的全部工作。

6.3 给自己留一版“20 分钟全流程演示脚本”

演示不能随性发挥，我通常会让同学准备一个固定脚本：

1. 输入普通用户账号登录，展示首页可视化看板，点开评分分布图，简单解读数据形态。
2. 打开个人推荐页，展示 ItemCF 推荐结果，点开某一本推荐图书，展示右下角“因为你看过 XX，所以推荐这本书”的解释。
3. 打开图书详情页，展示相似书籍模块。
4. 现场给一本冷门书打 5 分，展示推荐页的立即变化或说明触发离线任务后次日更新。
5. 展示数据库表中沉淀出的推荐结果，用一条 SQL 查询证明数据已经真实落库。
6. 如果能现场跑一条小规模 Spark 任务，最好现场展示；不能的话展示提前录制好的终端执行视频或日志切片。

这个顺序基本覆盖了从数据采集、离线计算、在线服务到效果展示的完整链路，老师看完就能确认：你不是只做了一个网页，而是完整落地了一个推荐系统工程。

最后分享一个很实际的建议：做完上述所有事后，留一个最朴素的热门榜页面别删。不是所有功能都要让算法接管，热门榜既是冷启动兜底，也是你验证协同过滤效果最好的基线参照。哪怕答辩现场所有模型接口都出错，热门榜页面依然能救场。系统在关键时刻不崩，比什么都重要。