“毕业设计选啥题”这个问题每年都能把一批人逼到墙角。选纯理论吧答辩时没什么能演示的选纯前端页面吧又体现不出“大数据”的味儿。我这两年帮人参谋过的毕设项目不下几十个今天想认真聊一个我非常看好的方向基于Django K-means算法的校园美食推荐系统。这题目乍一看是“网站开发”实际上是一个标准的大数据推荐系统闭环既有 Django 后端实战又有 MySQL 数据存储还包含 K-means 算法的落地应用非常适合用来撑起一份有技术深度、有演示效果、又有完整业务故事的毕业设计。这选题不是拍脑袋想出来的我建议你先理解它的核心逻辑再决定要不要照着做推荐系统本身是当前互联网最经典的大数据应用场景而“校园美食”这个切口极其巧妙数据量级适中、数据获取方便、业务规则清晰比起做电商推荐、电影推荐它更适合学生阶段去完整地跑通从数据处理到算法建模再到 Web 展示的全流程。本文我会把这个项目的选题逻辑、技术选型、数据库设计、K-means 聚类做推荐的原理、完整实现步骤和踩坑记录全部摊开讲同时附上源码和调试思路的参考目标是让不同基础的人都能看明白、能复现、能答辩。1. 这个毕设选题的“坑位”分析为什么校园美食场景最适合练手先别急着聊技术细节我见过太多人选了一堆“高大上”的题目最后连数据都搞不定光环境配置就折腾两周。校园美食推荐系统这题的优势恰恰在于它的场景足够具体、数据足够干净、业务足够合逻辑。1.1 大数据毕设选题的三个硬性标准一个合格的大数据毕设选题至少要同时满足三个条件有真实可获取的数据、有可解释的算法、有可运行的系统。三者缺一个答辩时都会很难受——数据不行你的算法就是空转算法不行你的系统就是个普通的 CRUD 增删改查系统不行你的论文就落不了地。校园美食这个场景完美命中这三条。数据方面美食类别中餐、西餐、快餐、甜品、饮品、口味标签辣、甜、清淡、重口、价格区间0-10元、10-20元、20元以上、学生评分这些都是现成的结构化字段完全符合大数据里的“小数据全流程”训练要求算法方面K-means 聚类可以根据学生的口味偏好和行为特征把用户分群同一个簇的用户共享推荐结果这个逻辑清晰易懂系统方面Django 负责整个 Web 框架和后台管理MySQL 负责数据的持久化存储整个架构就是一个微型的大数据推荐系统。1.2 选“校园美食”而不选“电商/电影”的真实原因电商推荐看起来更“工业级”但你上哪儿弄几万条真实交易数据自己爬反爬机制先把你劝退。电影推荐是推荐系统领域最经典的公开数据集 MovieLens但这题早被人做烂了每年答辩都能撞车好几个。相比之下校园美食推荐自带社交属性和地域属性你甚至可以在自己学校做一个真实的小规模问卷收集数据也可以自己构造合理的模拟数据——这在大数据实践里叫作“数据构造”本身就是一个论文中可以写的亮点说明你理解数据字段背后的业务含义而不是只会套模板。另外一个很实在的点是校园美食的业务边界非常清晰。用户就是学生商品就是食堂/周边商户的美食推荐逻辑就是“根据你过去的选择和相似口味群体的选择猜你接下来可能喜欢什么”。这种“用户物品交互”的三元组结构是推荐系统的基础形态同构于电商、内容分发、社交推荐等一切主流场景。你做完这个项目写简历时完全可以说“掌握推荐系统的基本建模流程”——这不是吹牛这是实话。1.3 毕设答辩时你能拿出什么“硬货”我帮你复盘一下答辩现场能展示的东西你就明白为什么这题好过了第一完整的 Django 项目结构包括用户注册登录、美食浏览、评分、推荐结果展示等模块每个都能现场跑起来演示第二一个 K-means 聚类的建模过程你能在 Jupyter Notebook 或后台代码里展示聚类中心、簇分布可视化图甚至现场调整 K 值看推荐效果变化第三一份带 ER 图的 MySQL 数据库设计文档能完整说清楚用户表、美食表、评分表、聚类结果表之间的关系第四一套成体系的推荐结果生成逻辑冷启动时怎么推、有数据后怎么推、用户行为更新后怎么重算。这些硬货拿出来老师很难问倒你。2. 技术选型解析Django、K-means、MySQL 为什么各司其职确定好场景之后第二个关键决策就是技术栈。市面上能选的东西很多Flask 可以、Spring Boot 可以、Spark MLlib 也不是不行但 Django K-means MySQL 这个组合在“毕设”这个特定场景下是实战性、学习曲线和答辩表现三者平衡得最好的方案。下面我把每个角色的定位讲透。2.1 Django 作为推荐系统“外壳”的四个优势Django 是一个重量级的 Python Web 框架我经常跟人说它像是一座精装修的房子——该有的房间都有了你只需要往里面放家具。它在毕设中的优势主要体现在四个方面。其一自带 Admin 后台。这一点在开发调试阶段简直救命。你可以直接通过 Django Admin 管理美食数据、查看用户列表、调整评分记录不需要额外写一堆管理页面节约下来的时间可以全部投入到推荐算法的调优上。答辩的时候现场往后台加一条新菜品数据前端立刻有变化这个演示效果比干讲 PPT 强太多。其二ORM 对象关系映射层。Django 内置的 ORM 让你操作 MySQL 数据库像操作 Python 对象一样自然物理删除对象就是一行obj.delete()查询就是Food.objects.filter(category川菜)根本不需要手写 SQL。对于基础一般的同学来说这意味着你不需要精通复杂的 SQL 语法依然能完成所有数据库操作。当然如果对 MySQL 有一定基础你也可以通过connection.cursor()执行原生 SQL这样论文里还能写“本系统同时支持 ORM 与原生 SQL 操作”显得技术深度更高一层。其三MTV 架构解耦清晰。Model 定义表结构Template 渲染前端页面View 处理业务逻辑三层各管各的。这跟推荐系统的“数据层-算法层-展示层”天然对应论文里的架构图直接照这个画就行逻辑上严丝合缝。你甚至可以这样写Django 的 MTV 模式为推荐系统的模块化开发提供了清晰的工程基础这在系统设计层面是有理论依据的。其四中间件与信号机制。Django 的 middleware 可以在请求进入视图函数之前做一个通用的拦截处理比如全局登录校验signal 可以在某个事件发生时异步触发一个操作比如“用户新增一条评分记录后自动更新聚类模型”。这两个高级特性如果能在答辩时提一嘴立刻能跟那些只会写基本增删改查的同学拉开差距。2.2 K-means 算法在这套系统里的真实角色是什么很多同学一提 K-means 就觉得是“机器学习”心里发怵。其实 K-means 是最简单易懂的无监督聚类算法它的核心思想一句话就能讲完把 n 个样本点划分到 K 个簇中使得每个样本到其所属簇中心的距离平方和最小。展开说就是你先定好要把用户分成几类算法随机初始化 K 个中心点然后反复迭代“分配样本-更新中心”这两个步骤直到中心点不再变化或达到最大迭代次数。在这个美食推荐系统里K-means 的目标不是直接预测“用户会打几分”而是把“口味相似的人”找出来。假设我们把全校学生分成 5 个簇簇 0 可能偏向重口味簇 1 可能偏向清淡养生簇 2 可能是甜品爱好者簇 3 是追求性价比的干饭人簇 4 是愿意为环境买单的体验派。那么当一个新用户来了我们只需要判断他更接近哪个簇的特征就可以直接把那个簇里的热门美食推荐给他。这就是 K-means 推荐的核心逻辑基于用户的协同过滤思想用“聚类”代替“逐用户相似度计算”用“簇的集体偏好”代替“单个用户的偏好画像”。为什么选 K-means 而不是 KNNKNN 是分类算法需要已知标签才能训练而校园美食场景下你很难拿到“这个用户属于哪一类”的预设标签K-means 不需要标签它自己就能发现群体结构这更符合真实场景中“数据无标注”的现实。为什么选 K-means 而不是 DBSCAN 密度聚类因为用户口味偏好数据通常是连续型数值特征分布近似球状簇K-means 在这种数据上效果好、效率高、好解释。当然K值的选择是一个需要重点交代的问题我建议论文里同时使用“肘部法则”和“轮廓系数”两个指标来确定最佳K值这部分内容在第四章我会详细展开。2.3 MySQL 为什么够用什么时候才需要上升到 Spark/Hadoop“大数据”这三个字在毕设里经常被误解——是不是非得用 Hadoop、Spark 才叫大数据不是的。大数据技术栈的核心是处理“单机处理不了”或“单机处理不划算”的问题。校园美食数据量级也就是几千用户、几百条美食记录、几万条评分这个规模在 MySQL 单表千万级都没问题根本不需要分布式计算。但你怎么在论文里体现“大数据思维”呢有两个方向可以写。方向一把 MySQL 作为整个系统架构中的数据存储层说明数据如何清洗、转换、加载这个过程对应大数据里的 ETL 概念方向二明确说明本项目采用“轻量级大数据架构”适合中小规模数据集如果未来数据量增长到千万级以上可以平滑迁移到 Spark 集群。这两段话写在论文里非常加分——它表明你清楚技术边界而不是盲目堆砌技术。MySQL 本身在安装、配置、SQL 语法、存储过程、性能优化方面也有大量可以写的点。比如我在实操中常用的几个操作ALTER TABLE user ADD COLUMN age INT DEFAULT 0;设置默认值UPDATE rating SET score 5 WHERE id 3;修改评分DELETE FROM rating WHERE user_id 2;删除用户行为记录以及通过index索引优化热门查询字段。如果论文里能加一个“MySQL 查询优化”小章节比如对比加索引前后的查询耗时这又是一个答辩亮点。3. 系统全貌与数据库设计把推荐需求翻译成数据表结构技术选型定了之后下一步就是把业务需求翻译成系统设计。我建议你按照“功能模块图 → 数据库 ER 图 → 接口设计 → 页面设计”这个顺序来每一步都落在文档里这样写论文时就不用来回补材料。下面把你必须设计的核心模块和数据表结构完整过一遍。3.1 系统功能模块拆解前端展示、用户中心、后台管理、算法服务校园美食推荐系统按功能划分核心要落地五个模块。用户模块负责注册、登录、个人信息维护密码加密存储Django 自带的User模型可以直接继承扩展美食管理模块负责菜品的增删改查包括名称、类别、价格、口味标签、图片、描述等字段这部分用 Django Admin 就能快速搭建评分与行为收集模块是推荐系统的数据来源用户对吃过的美食进行 1-5 星评分系统记录用户对美食的浏览行为评分数据写入数据库并作为聚类算法的输入推荐模块是系统的核心亮点它读取用户特征数据运行 K-means 聚类模型生成“为你推荐”列表数据可视化模块用图表展示菜品的评分分布、热门排行、用户聚类结果可以让前端ECharts或后端的Matplotlib来实现。这五个模块不是平行堆砌的。评分与行为收集是上游它为推荐模块和数据可视化模块提供数据输入推荐模块是核心它调用聚类结果生成个性化推荐后台管理是支撑它保障整个系统数据可维护。论文中的架构图可以画成“数据采集层 → 数据存储层 → 算法分析层 → 应用展示层”这个分层既对应了大数据架构又跟 Django 的 MTV 结构一一对应。3.2 数据库表设计详解用户表、美食表、评分表、聚类结果表数据库设计是面试和答辩的重点你不要只丢出几张建表语句而要讲清楚“为什么这么设计”。我这里直接给出核心表和关键的字段设计思路。用户表user主键id用户名username唯一索引密码passwordDjango 自带加密学号student_no可选口味偏好taste_pref用于冷启动推荐可多选辣、甜、清淡等创建时间created_at。这个表在 Django 中通常直接继承AbstractUser扩展。美食表food主键id菜名name分类category川菜、粤菜、快餐、甜品等价格price口味标签taste一个菜品可以有多个标签评分均值avg_rating冗余字段避免每次查询都实时计算销量或热度hot用于生成热门榜图片路径image描述desc。这里设计一个细节——avg_rating为什么要冗余因为推荐列表里要频繁展示评分如果每次都要AVG()聚合评分表查询会随着数据量线性变慢冗余之后只需要在用户评分时更新这个字段就行这也是实际项目中常用的“以空间换时间”的优化手段。评分表rating主键id用户外键user_id美食外键food_id评分score1-5 的整数评语comment可选时间created_at联合唯一约束(user_id, food_id)防止同一用户对同一菜品重复评分。这张表是推荐系统的“行为日志”K-means 的输入数据主要来自这张表。聚类结果表user_cluster主键id用户外键user_id所属簇cluster_id距簇中心的距离distance可选聚类时间戳clustered_at。这张表用来保存离线计算得到的用户分组结果。为什么要把聚类结果存数据库而不是每次实时计算因为推荐请求要求毫秒级响应而 K-means 聚类计算是秒级甚至分钟级。我们把聚类过程设计成“近线计算”定期批量更新聚类结果Web 请求只做查询——这就是真实推荐系统里“离线计算 在线服务”的标准分工这个理念一定要在论文里写出来。3.3 Django 模型层实现要点外键关联、查询优化和管理员配置Django 模型层用代码定义上面这些表结构几行代码就能完成。外键关联是重点中的重点比如Rating表里user和food字段都设成外键这样表之间就形成了引用完整性约束删除一个美食时会级联处理相关评分。菜单表通过category字段分组查询就可以得到“每个分类的美食数量”“每个分类的平均评分”这类统计分析数据。查询优化上有一个经常被忽略的坑Django ORM 默认是懒加载的如果你写ratings Rating.objects.all()然后循环里去访问rating.user.username会产生 N1 次查询数据量一大页面会卡到怀疑人生。正确做法是用select_related(user, food)做联表查询预加载。这类细节写进论文的“系统优化”章节比空谈“性能优化”有力得多。管理员配置方面Django Admin 注册表模型设置list_display展示关键列search_fields设置搜索字段list_filter设置分类筛选这样你在后台就能很舒服地管理所有数据。答辩时可以现场操作一遍在后台修改一条美食的价格前端页面刷新立刻变化——这个闭环演示虽然简单但能把前后端打通的概念直观传达给评委。4. 推荐系统核心算法K-means 聚类的原理、K值调优与业务落地现在进入整个系统最核心的部分K-means 算法怎么跟校园美食推荐结合起来。这块也是论文里“算法设计”章节的绝对主力我尽量把原理讲到能直接抄进论文的程度同时把实操中需要注意的参数细节都标出来。4.1 从“物以类聚”到“人以群分”把用户口味特征变成数值向量推荐的第一步是刻画用户。K-means 要求的输入是一组数值特征向量所以我们需要把每个用户的“口味画像”转换成一串数字。这里我给出一种经典且好实现的构造方式。假设美食系统有 10 个菜品类别川菜、湘菜、粤菜、江浙菜、西餐、日料、快餐、甜品、饮品、烧烤。每个用户对每一类都有一个平均评分如果该用户没有吃过某一类的任何菜品则该类的特征值置为中性分 3.0 或 0取决于你选择的数据标准化方式。这样每个用户就变成了一个 10 维向量例如用户 A 的特征向量是[4.5, 4.8, 2.0, 2.5, 3.0, 3.2, 3.8, 4.0, 3.5, 4.2]这个向量表示他偏重川湘菜不偏好粤菜和江浙菜。所有用户的行向量拼在一起就形成了一个 用户数 行 × 10 列的特征矩阵。特征构造完之后必须做标准化处理。为什么要标准化因为如果不做标准化价格区间0-50元会完全主导口味评分区间1-5分聚类结果就变成了“按价格分人”而不是“按口味分人”。这里推荐使用StandardScaler标准分数标准化把每个维度的均值变为 0、标准差变为 1。这一步代码很少但对聚类效果的影响至关重要我会在后面的实操步骤中给出具体代码。4.2 肘部法则 SS E与轮廓系数怎么向答辩老师解释你选择的K值K-means 里最头疼的参数就是 K要分成几个簇。直接用n_clusters5拍脑袋定答辩老师一问理由就露馅。比较科学的方法是结合两个评估指标来定 K。第一个是肘部法则基于簇内误差平方和 SSE。SSE 定义的是每个样本点到其所属簇中心的距离平方之和K 越大、每个簇内越紧凑、SSE 越小。但 K 超过某个阈值之后SSE 下降速度会明显放缓形成“肘部”。曲线从 2 到 10 跑一遍找到那个“手肘”位置对应的 K 值就是最合适的分群数。第二个是轮廓系数它同时衡量簇内凝聚度和簇间分离度取值在 -1 到 1 之间越接近 1 说明聚类效果越好。实际使用中我会综合两个指标优先看轮廓系数的峰值再看肘部曲线是否有明显拐点两个指标都指向的 K 值就是最佳选择。在我的测试数据上K5 时轮廓系数最高结合肘部图拐点也在 5 附近于是确定分为 5 个用户口味群。4.3 K-means 聚类在推荐链路中的完整代码落地下面我给出 K-means 模块在 Django 项目里的核心实现代码。这段代码你可以放在一个独立的recommend.py文件里由 Django 的视图函数调用。import numpy as np import pandas as pd from sklearn.cluster import KMeans from sklearn.preprocessing import StandardScaler from .models import User, Rating, Food, UserCluster def build_user_feature_matrix(): 构造用户-菜品类别评分特征矩阵 users User.objects.all() categories Food.objects.values_list(category, flatTrue).distinct() cat_list list(categories) matrix [] user_ids [] for user in users: feature [] for cat in cat_list: # 该用户在该类别下所有评分的均值 avg_score Rating.objects.filter( useruser, food__categorycat ).aggregate(avgmodels.Avg(score))[avg] feature.append(avg_score if avg_score is not None else 3.0) # 再附加上用户平均消费价格 avg_price Rating.objects.filter(useruser).aggregate( avgmodels.Avg(food__price) )[avg] feature.append(avg_price if avg_price is not None else 15.0) matrix.append(feature) user_ids.append(user.id) return np.array(matrix), user_ids, cat_list def run_kmeans_clustering(k5): 运行K-means聚类将用户分组结果写入数据库 X, user_ids, _ build_user_feature_matrix() # 标准化 scaler StandardScaler() X_scaled scaler.fit_transform(X) # K-means聚类 kmeans KMeans(n_clustersk, initk-means, n_init10, random_state42) labels kmeans.fit_predict(X_scaled) # 清洗旧聚类结果并写入新结果 UserCluster.objects.all().delete() for idx, user_id in enumerate(user_ids): UserCluster.objects.create( user_iduser_id, cluster_idint(labels[idx]), distancefloat(np.linalg.norm(X_scaled[idx] - kmeans.cluster_centers_[labels[idx]])) ) # 将聚类中心也存为参数可扩展ClusterCenter表 return labels, kmeans.cluster_centers_ def recommend_for_user(user_id, top_n10): 为指定用户生成推荐菜品列表 try: cluster UserCluster.objects.get(user_iduser_id) except UserCluster.DoesNotExist: # 冷启动返回全局热门菜品 return Food.objects.order_by(-hot)[:top_n] # 找到同一簇的用户 same_cluster_user_ids UserCluster.objects.filter( cluster_idcluster.cluster_id ).values_list(user_id, flatTrue) # 排除当前用户已评分的菜品 rated_food_ids Rating.objects.filter(user_iduser_id).values_list(food_id, flatTrue) # 在同簇用户的高分菜品中选推荐项 candidates Rating.objects.filter( user_id__insame_cluster_user_ids, score__gte4, ).exclude(food_id__inrated_food_ids) # 聚合统计同簇用户给这道菜的平均分和评分数量 from django.db.models import Count, Avg ranked candidates.values(food_id).annotate( avg_scoreAvg(score), rating_countCount(id) ).order_by(-avg_score, -rating_count)[:top_n] food_ids [item[food_id] for item in ranked] return Food.objects.filter(id__infood_ids)这里有几个参数值得展开讲一下。initk-means是一种更聪明的初始中心点选择策略它让初始的中心点尽量分散避免随机初始化导致的糟糕局部最优n_init10表示算法会跑 10 次随机初始化选 SSE 最小的一次作为最终结果random_state42固定随机种子确保每次运行结果可复现——这一点在毕设答辩中特别重要老师会当场让你再跑一次如果两次结果不一样场面会很尴尬。4.4 冷启动问题新用户没有行为数据时推荐什么推荐系统领域有个经典难题叫冷启动——新用户注册进来系统中没有任何他的评分记录build_user_feature_matrix里他每个维度的平均分都是默认值聚类时他会被塞到某个簇里但我们依据不足。这个问题的解决方案有两个层次我建议你至少实现其中一层。第一层基于用户注册时主动选择的偏好标签做初识推荐。在用户注册页设计一组“口味偏好”复选框偏爱辣、偏爱甜、偏爱清淡、偏爱重口、偏爱快餐等用户勾选后系统根据偏好标签匹配菜品分类直接生成第一批推荐列表。这叫作“基于内容的推荐”或“显示偏好建模”代码实现起来很简单Food.objects.filter(taste__contains辣)。第二层基于统计热度的冷启动兜底。用户没有勾选偏好或者刚注册还没产生行为时直接推荐整个平台的热门菜品——按评分人数和平均分综合排序。这一层适合做默认页的“大家都在吃”板块即使没有个性化数据页面也不至于空着。两个层次一起用冷启动就不再是答辩漏洞反而成了你展示思考深度的亮点。4.5 聚类重算的策略多久更新一次推荐结果用户的评分行为是不断产生的聚类结果如果一直不更新推荐就会逐渐失真。但每次评分都重跑一次聚类计算成本又太高虽然数据量小无所谓但思路不对。我建议采用两种更新策略。增量策略当单个用户的评分行为达到一定阈值比如每新增 10 条评分触发对该用户的单独重算——把他的特征向量重新计算再分配到最近的簇中心。这能用 Django 的信号机制post_save来做代码量很小批度策略每天晚上凌晨 2 点用定时任务crontab或 Django-crontab 批量重跑一次完整的聚类流程更新整个user_cluster表。论文里把这两种策略写清楚推荐系统的“近线计算”概念也自然带出来了这条技术链路就是完整的企业级推荐系统简化版。5. Django MySQL 环境搭建与项目初始化完整实操讲了这么多理论下面的重点是真正把系统跑起来。很多同学总是卡在环境搭建这一步vscode 里写img标签加载 static 文件显示不出来、MySQL 连接报error 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock、python 版本不对导致 Django 启动失败……这些都是我见过无数次的经典问题。我在这里手把手把完整流程走一遍宿舍一台 Windows 电脑就够了。5.1 本地开发环境准备Python 虚拟环境、Django 安装、MySQL 安装先说 Python 环境。强烈建议使用虚拟环境不要直接把 Django 装到全局 Python 里——毕设做到一半依赖崩了、版本冲突心态会直接爆炸。创建虚拟环境的步骤很简单py -m venv venvWindows 激活命令是 Windows 下venv\Scripts\activateMac/Linux 下是source venv/bin/activate。激活后安装依赖包pip install django4.2 pip install mysqlclient pip install scikit-learn pip install pandas numpy pip install matplotlib pip install django-crontab这里稍微解释下版本选择。Django 4.2 是长期支持版本稳定且文档丰富mysqlclient 是 Python 连接 MySQL 的老牌驱动Windows 如果装不上会要求编译环境可以用 pymysql 替代在__init__.py里加两行import pymysql; pymysql.install_as_MySQLdb()这是最常见的兼容手段。MySQL 的安装配置是坑最多的一个环节。强烈建议下载 MySQL Community Server 8.x安装时选择“Use Legacy Authentication”或安装完成后执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;否则新版 MySQL 的默认认证插件会让老版本 MySQLdb 连不上。安装完成后打开 MySQL 命令行检查服务状态-- 检查服务是否正常 SELECT VERSION(); -- 创建项目数据库指定 utf8mb4 编码防止中文乱码 CREATE DATABASE campus_food DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;5.2 从零创建一个 Django 项目项目骨架、App 划分与配置环境准备好之后开始创建项目和 App。项目名我建议叫CampusFoodRecommend核心 App 叫user用户模块、food美食模块、recommend推荐模块、rating评分模块。先用命令创建一个干净的项目骨架django-admin startproject CampusFoodRecommend cd CampusFoodRecommend python manage.py startapp user python manage.py startapp food python manage.py startapp rating python manage.py startapp recommendApp 划分好后最关键的开发临时任务是配置settings.py。要做的事包括把新 App 注册到INSTALLED_APPS配置 MySQL 数据库连接把DATABASES的默认配置改成ENGINE: django.db.backends.mysql、NAME: campus_food、USER: root、PASSWORD: 你的密码、HOST: 127.0.0.1、PORT: 3306设置语言和时区改成LANGUAGE_CODE zh-hans、TIME_ZONE Asia/Shanghai配置静态文件STATIC_URL /static/并新建static目录。这些配置好比房子的水电管线不接好后面全没法用。配置完成后执行两行核心命令python manage.py makemigrations和python manage.py migrate。前者生成数据库迁移文件后者把 Django 内置的数据表用户表、session 表等和你的模型真正同步到 MySQL。然后创建超级管理员python manage.py createsuperuser填用户名、密码就可以跑python manage.py runserver启动开发服务器了。5.3 从数据构造到前端可视化一条完整的推荐闭环实现路径有了骨架和数据库接下来要填充内容。我建议的落地顺序是先造数据再跑通推荐页面最后做可视化。造数据的标准动作是写一个mock_data.py脚本。手动造 20 条美食数据、模拟 200 个用户的评分数据这里的关键是评分数据要带一定的“口味倾向性”不要纯随机。比如模拟用户 A 对川菜都打 4 分以上对粤菜都打 2 分这样的数据聚类效果才会明显。造好之后运行脚本python manage.py shell mock_data.py数据就进 MySQL 了后台管理里面能看到。跑通推荐页面的标准动作是写一个检验闭环用户登录 → 对 5 个菜品评分 → 调用run_kmeans_clustering(5)重新聚类 → 回到首页看到“为你推荐”列表和之前不一样了。这个闭环一打通整个项目最核心的技术逻辑就真的落地了。数据可视化部分可以在“美食排行榜”页面用ECharts或者后端matplotlib生成并展示菜品评分分布图、用户聚类散点图。聚类散点图是答辩展示的“王牌图”把 200 个用户映射到二维平面可以用 PCA 主成分分析降维不同簇用不同颜色标出来一眼就能看出 K-means 确实把用户分群了视觉冲击力极强。5.4 模板与静态文件为什么 vscode 里写 img 标签总是显示不了图片前端页面上有个超高频问题Django 的模板里写了img src/static/images/pizza.jpg图片死活显示不出来控制台一直报 404。这里我直接给你最完整的排查清单。第一步确认 settings 里STATIC_URL是否为/static/并确认是否设置了STATICFILES_DIRS [BASE_DIR / static]第二步确认项目根目录下确实有static/images/这个物理目录并且文件名、扩展名完全一致Linux 系统尤其要注意大小写第三步确认你的页面文件是放在 templates 目录下并通过 Django 视图返回的而不是直接用浏览器打开本地 HTML 文件第四步模板中要用{% load static %}然后写img src{% static images/pizza.jpg %} 。Debug 模式下 Django 开发服务器会默认自动伺服静态文件但模板标签必须写对。这四步走完图片问题百分之百解决别再傻傻刷新缓存了。6. 毕设调试、论文写作与答辩演示的实战经验系统能跑通只是第一步毕业设计的最终目标是交出一份完整、可读、有深度的报告并在答辩现场说服评委。这一章我围绕调试、文档和答辩给大家梳理一套实战打法。6.1 数据分析视角的 K-means 可视化毕业设计里怎么展示聚类效果聚类效果不能光靠嘴说“分了 5 个类”你要用数据可视化证据来支持。核心的展示图有两个。第一个是 K 值选择曲线图。横轴是候选 K 值2 到 10纵轴是 SSE肘部法则曲线呈现一个“滑梯”形状。你把这个图画出来标出拐点 K5这就是你选 5 个簇的科学依据。第二个是聚类结果分布图。用 PCA 把高维的用户特征向量压缩到二维平面散点图按簇着色展示聚类在二维空间的可分性。另外可以加一个簇特征雷达图用每个簇在 10 个菜品类别上的平均评分画雷达图能直观看出“簇 1 偏辣、簇 2 偏甜”的差异这是论文里非常亮眼的一张图。这三个图加在一起的视觉说服力远强于十页文字描述。6.2 调试阶段的踩坑记录与问题速查表我在协助调试这个项目的过程中把高频问题整理成了一张速查表分享给各位照着排查能节省大量瞎折腾的时间。现象根本原因解决方案MySQL 连接报错Cant connect through socket /tmp/mysql.sockMySQL 服务未启动或者 socket 路径不一致Windows 下到服务管理器启动 MySQL 服务Mac 下用brew services start mysql检查my.cnf的 socket 路径Django 启动报ModuleNotFoundError: No module named MySQLdb未安装 mysqlclient 或者没有安装 pymysqlpip install mysqlclient或用 pymysql 替代并执行install_as_MySQLdb()页面中文乱码数据库字符集不是 utf8mb4建库时指定CHARACTER SET utf8mb4已经建好的库用ALTER DATABASE ... CHARACTER SET utf8mb4修复评分榜单数据不变聚类结果没有重新计算调用recommend.run_kmeans_clustering()重跑聚类或调整定时任务频率前端页面报 404 找不到静态文件STATICFILES_DIRS未配置或者模板标签写错确认配置和{% static %}写法见上一节的四步排查法聚类结果每次跑不一样没有固定随机种子在 KMeans 中设random_state42并在论文中说明实验可复现性管理后台无法登录没有执行migrate或者没创建超级用户执行python manage.py migrate、python manage.py createsuperuser环境和全局依赖冲突未使用虚拟环境创建并激活 venv所有依赖装在虚拟环境中6.3 论文结构模板怎么把项目包装成一份优秀的毕业设计毕设论文的本质是讲清楚“你遇到了什么问题、你用什么方法解决、你如何验证你解决了”。我给大家一个可以直接套用的章节大纲。第一章绪论写研究背景推荐系统的价值、国内外研究现状、研究内容与论文结构第二章相关技术介绍写 Python、Django、MySQL、K-means 算法、推荐系统基础理论第三章系统需求分析与概要设计写功能需求、非功能需求、系统架构图、数据库 ER 图第四章系统详细设计与实现写各个功能模块的代码结构与核心实现第五章系统测试与结果分析写功能测试用例、K 值选择实验、推荐效果评估——要有图第六章总结与展望写工作成果、不足之处、后续扩展方向。这里给一个额外的加分技巧在每一章末尾加一个“本章小结”。不是复制粘贴前面内容的摘要而是用一两句总结这一章“解决了什么问题、为什么这么解决”。老师翻论文速度快看到每章的清晰收束第一印象会非常好。6.4 答辩演示的黄金八分钟脚本答辩通常只有五到十分钟你要把这当成一场产品发布会而不是技术的流水账。我的建议是提前准备一份八分钟演示脚本按如下节奏走第一分钟用两句话介绍项目是什么——一个基于 Django 和 K-means 的校园美食推荐系统解决学生找饭难的问题第二到三分钟打开系统管理后台展示美食数据、评分数据、聚类结果说明数据是怎么收集和存储的第四到五分钟展示 K 值选择曲线图和用户聚类散点图讲解 K-means 的原理和调参过程这是全场的技术高潮第六分钟现场演示完整的推荐闭环用一个测试账号评分几道菜刷新推荐页展示“推荐结果随之变化”第七到八分钟展示系统架构图和数据库 ER 图总结项目的扩展性——未来数据量大了可以把算法迁移到 Spark 集群。在答辩问答环节有两个问题一定提前准备老师问“K-means 的缺点是什么”怎么办答它对初始中心点敏感、需要预先指定 K 值、对噪声和离群点敏感、不适合发现非凸形状的簇然后补一句“根据本项目数据特征这些缺点影响有限且通过 k-means 和轮廓系数评估进行了有效控制”老师问“你这算是大数据吗”答当前数据规模属于中小规模但整个数据处理流程与大数据推荐系统一致未来可通过消息队列接收实时行为数据、用 Spark 进行分布式聚类平滑升级到大数据架构。7. 从毕设到工程能力这个项目还能延伸出什么最后我想跳出“完成毕设”这个短期目标聊聊这个项目对个人能力成长的长远价值。一个毕设如果只是用来交差那确实浪费了它应有的价值。校园美食推荐系统这个选题往深了挖能挖出很多大厂实际业务里的核心场景。从工程角度说你打通了 Django MTV 架构、MySQL 数据建模、ORM 查询优化、第三方库集成sklearn、pandas、matplotlib、前后端协作这几条主线这在后端开发岗位的实习面试里是实打实能聊的项目经验。从算法角度说你完整吃了一轮“特征构造 → 标准化 → 模型训练 → 参数调优 → 效果评估 → 在线服务”的机器学习项目闭环虽然 K-means 本身不难但这个流程是所有算法岗面试必问的底层能力。从数据思维角度说你理解了“离线计算与在线服务分离”“冷启动处理”“近线更新”“行为日志驱动推荐”这些真实推荐系统里的经典概念。面试官听到你能说出这几个词且能结合自己做过的项目展开就已经超过大多数简历上只写着“熟悉推荐算法”的候选人了。如果你学有余力这个项目还有几个低成本高收益的扩展方向。一个是增加基于物品的协同过滤算出美食之间的相似度矩阵做“看了这道菜的人也看了那些菜”K-means 做粗粒度推荐协同过滤做细粒度补充另一个是引入时间因素把评分数据加上时间衰减权重最近的评分权重更大推荐结果更能反映用户当前的口味变化再一个是尝试爬取真实的外卖平台评论数据或学校论坛的美食话题做情感分析把“好评度”作为推荐排序的一个特征维度。这些扩展方向每做出来一个论文技术含量就上一个台阶。在实操中我有一点点心得做这个项目最重要的是别一开始就追求“完美推荐效果”。推荐效果不是毕设的核心评价维度——老师更在意的是你“为什么这么做”和“怎么验证这么做是有效的”。所以哪怕你的聚类结果在可视化图上分布不是那么完美只要你能解释清楚原因并且给出优化方向这反而比“完美运行但讲不出道理”更加分。我见过太多学生把精力耗在“让准确率更高一点”上结果忽略了最基本的系统完整性和文档规范——那是丢了西瓜捡芝麻。最后补充一个非常现实的经验无论你的选题是什么、技术栈是什么请在答辩前至少完整跑通三遍从启动服务器到演示推荐的全流程并且把运行环境和启动步骤写进 README 文档。我校验过太多次“演示前五分钟环境崩了”的惨案——数据库服务没启动、端口被占用、虚拟环境没激活、依赖少安装了一个包这些低级问题很可能直接毁掉半年的努力。把这个项目的源码下载下来之后第一件事也不是急着看代码而是老老实实根据 README 把环境装好、把系统跑起来再去研究每一行代码背后的设计逻辑。这样才能保证最终答辩的时候你能从容地把每一个按钮都点给老师看。