基于Python的校园美食推荐系统：协同过滤与冷启动实战

你接手过一个美食推荐系统的毕设或者实际项目吗？如果没有，那正好，这篇内容能帮你少走不少弯路。如果是已经做完了，那你更该看看，很多坑我在正文里都帮你提前踩过了。

我要聊的就是基于 Python 的校园美食推荐系统。这个方向这几年在毕设、课设里出现频率很高，原因不复杂：场景具体、数据可得性好、算法落地路径清晰，而且可扩展的方向多，从协同过滤到深度学习都能做。但正因为太常见了，很多人反而做得千篇一律，答辩的时候被老师一问就露馅。所以这篇我不会只给你一个流水账式的功能清单，而是把“为什么这样做”和“数据从哪来”“算法怎么选”“系统怎么落地”这些真正有价值的东西全部拆开讲。

这篇内容适用的人群比较广：正在选毕设题目的在校生、准备参加比赛想找项目练手的开发者、或者单纯想给自己学校做一个美食推荐小站的技术爱好者，都能从里面找到可以立刻上手的东西。我默认你有 Python 基础知识，但即使你只学到列表和字典，下面的代码也能直接跑通，不用担心门槛问题。

先说一下整体技术画像，这个系统的核心链路是：数据采集与清洗 -> 特征工程与存储 -> 推荐算法计算 -> API 服务与前端展示。每一环我都会给到实际的代码、表结构和踩坑提示，尽量让你看完就能动手。

1. 系统整体设计与核心模块拆解

我见过很多失败的校园美食系统，最大的通病是贪多嚼不烂。上来就想要评论、点赞、收藏、私信、后台管理、大数据大屏、用户画像、实时推荐，恨不得把所有“流行功能”全堆上去。结果呢？数据库表建了二十多张，代码写了一万多行，最后跑起来卡到不行，推荐效果还奇差。

我自己做这类系统时，第一件事永远是做减法。一个以“推荐”为核心的校园美食系统，真正不可或缺的模块只有四个：

1. 数据层：菜品信息、用户信息、评分/行为记录。这是所有推荐算法的输入。
2. 算法层：核心的推荐引擎，负责根据用户历史行为生成候选集并排序。
3. 服务层：封装推荐结果、处理业务逻辑，对外提供 API。
4. 展示层：Web 或者小程序前端，让用户能浏览、评分、查看推荐结果。

没有用户注册行不行？行，短期用随机 ID 也可以跑通，但评分数据关联不到人，推荐就没意义了。没有评论功能行不行？当然行，评论是增强模块，对核心推荐链路影响不大。所以你设计系统架构的时候，先分清哪些是“骨架”，哪些是“装饰”，避免一开始就陷入细节。

我用到的技术栈很朴素，但对这个场景来说非常合适：

有人会说，用 Flask 是不是太 low 了？我不这么认为。Flask 够轻、够直接，逻辑都在 Python 这一层，对推荐系统这种算法密集型的项目非常合适。你如果愿意，换成 FastAPI 也行，但没必要为了“高级”去牺牲调试效率。核心代码仍然跑在 Python 算法层，Web 框架只是壳而已。

2. 数据从哪里来？校园美食场景的数据建设

推荐系统业内有一句老话：算法决定上限，数据决定下限。一个校园美食系统如果只有几十条菜品记录、十几个用户，再厉害的模型也推荐不出花来。所以数据建设必须是最先做、做扎实的一步。

2.1 数据采集的三种方式对比

数据来源这事，我听到过不少奇奇怪怪的想法。有人想直接爬美团和饿了么，有人想抓大众点评的评论。技术上行不行？行，但我不建议在毕设或实际校园项目里这么干。首先是合规问题，第三方平台的数据受保护，大量爬取会有法律风险；其次是数据时效性差，校内食堂和周边小店的菜品变化很快，爬来的数据可能开学和期末就是两个样。

我推荐用“手动整理 + 定向采集”组合方案。把你学校食堂的菜单拍下来，把周边店的外卖单收集一下，这些信息结构化之后，就是质量最高的菜品数据。你甚至可以拉上同学一起录入，一人负责几个窗口，一晚上就能得到几百条菜品记录。这种数据的好处是干净、准确、无版权隐患，而且你可以标注口味特征、价格区间、推荐指数这些非常贴合校园场景的属性。

爬虫这块，如果你确实想练手，可以爬校内论坛或者学生会公众号里的美食推荐文章。这类内容是校内学生自己写的，相对开放，数据量不大但内容质量很高。一定要控制频率，多页面解析而不是暴力请求，别给人家服务器添麻烦。

2.2 菜品数据模型设计

菜品数据是整个系统的地基，建议至少包含以下字段。我这里用实际用过的表结构举例，你有更好的想法可以在此基础上扩展：

CREATE TABLE dishes ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, category VARCHAR(50), price DECIMAL(10, 2), taste_tags VARCHAR(200), restaurant_id INT, canteen_location VARCHAR(100), avg_rating DECIMAL(3, 2) DEFAULT 0, rating_count INT DEFAULT 0, monthly_sales INT DEFAULT 0, is_available BOOLEAN DEFAULT TRUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

字段里面有几个值得你注意的地方。taste_tags是口味标签，比如“微辣”“重辣”“偏甜”“清淡”之类的，直接存成逗号分隔的字符串就行，没必要单独建表，处理成本低。restaurant_id关联店铺信息，monthly_sales是月销量，这个字段在冷启动阶段的作用非常大，后面讲推荐算法的时候你会看到它的价值。

用户行为数据我单独设计了一张表，记录评分和浏览行为：

CREATE TABLE user_preferences ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, dish_id INT NOT NULL, rating TINYINT, -- 1-5分 behavior_type VARCHAR(20), -- rating/browse/order created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

为什么要把浏览行为也保留？因为真实的推荐场景里，用户评分是稀疏的，大部分人用完系统根本不评。但浏览记录是稠密的，用户在菜列表页停留、点击了哪个菜品详情，这些都是很好的隐式反馈信号。你初版系统可以只用评分做推荐，但把行为字段留好，后面做混合推荐就有依据了。

2.3 数据量不够怎么办？冷启动阶段的临时方案

数据量不足是所有推荐系统冷启动阶段的通病，不止你一个人会遇到。我提供的临时方案有三个：

第一，规则冷启动。系统上线初期，没有用户行为数据，直接先按热度推荐——“月销量高 + 平均评分高”的菜排前面。这个逻辑很简单，但效果非常稳定，学生到了新食堂也会选择人多的窗口，这个推荐逻辑本质模拟的就是从众心理。

第二，同校学生的偏好修正。如果你采集数据的时候发现某个宿舍楼的学生普遍对辣味接受度高，那在推荐排序时，可以把辣味标签的权重适当调高。这个在代码里就是一个标签匹配度的加分项，实现成本很低。

第三，随机探索。给推荐列表里掺一定比例的“新菜”或“小众菜”，避免推荐结果永远被热门菜垄断。探索率设置在10%到20%之间比较合理，既不会让用户觉得推荐不靠谱，又能让新品有机会被看到。

3. 推荐算法选型：为什么基于用户的协同过滤最适合校园场景

推荐算法是系统的灵魂，也是答辩时老师最喜欢深挖的部分。这块写得好，整个项目直接上升一个档次；写得不好，前面做的所有工作都会被扣印象分。

3.1 三类算法的横向对比

现在主流的推荐算法可以分为三类，我用一个表格带你快速建立认知：

我最终选择 UserCF 作为核心算法，一个很重要的原因是校园场景的特殊性：学生的偏好聚集性很强。大一新生刚进校不知道吃什么，最自然的做法就是问学长学姐——兴趣相似的人推荐的东西往往就是最优答案。这种社交属性恰好是 UserCF 的强项。

当然，这个选择有个前提，就是用户行为数据要有一定积累。如果你的系统从零开始，用户数不超过 20 个，那 TeacherCF 算出来的邻居关系非常失真。我的方案是把 UserCF 当成“主算法”，但配上刚才说的热度冷启动规则，等行为数据积累到一定量级之后，算法推荐才真正接管排序。

3.2 相似度计算的两种主流方式：余弦相似度与皮尔逊相关系数

确定用 UserCF 之后，核心问题变成了怎么计算用户之间的相似度。我常用的是两种：余弦相似度和皮尔逊相关系数。

余弦相似度关注的是两个向量方向上的相似程度，公式是：

similarity = cos(A, B) = A · B / (|A| × |B|)

放在用户评分场景里，A 和 B 是两个用户对同一批菜品的评分向量。它的直观含义就是看两个学生的口味“方向”是否一致——你喜欢咸辣，他也喜欢咸辣，就算你们打分的绝对值不一样，方向一致也算相似。

但余弦相似度有一个小问题：它没处理用户评分尺度差异。有人习惯给高分，什么都打 4 分以上；有人严格，好吃的也只给 3 分。这时候直接比较数值会产生误判。解决办法就是皮尔逊相关系数，它先把每个用户的评分做去中心化（减去该用户所有评分的均值），再算相似度。这样消除的是“打分宽松还是严格”的个体习惯差异，只保留真实的兴趣模式。

我实际测试下来，在校园美食这种“人数中等、评分偏稀疏”的环境里，皮尔逊相关系数效果普遍更好一些。但如果你的数据很稠密，比如每个用户都有几十上百条评分，那余弦相似度也完全够用，且计算更快。刚开始可以用余弦相似度跑通全流程，后续再切换到皮尔逊做对比实验。

3.3 用户评分预测与 Top-N 推荐生成

算完用户相似度之后，推荐生成分两步走。第一步，找到和目标用户最相似的 K 个“邻居用户”；第二步，把这 K 个邻居喜欢过但目标用户还没吃过的菜品汇总，按预测评分排序，取前 N 个作为推荐结果。

预测评分的计算公式如下：

pred(user, dish) = avg(user) + Σ(sim(user, neighbor) × (neighbor_rating - avg(neighbor))) / Σ(sim)

这个公式的核心逻辑是：先把邻居用户的评分减去他自己的平均分，得到的差值表示“这个菜对他而言比平均偏好高了多少”，然后按相似度加权求和。用生活类比就是：你有个口味很像的朋友，他觉得某个菜比他平时吃到的平均水平高 2 分，那你大概率也会喜欢——前提是这个朋友和你的口味相似度权重够大。

4. 从算法到系统：核心编码实现与全流程串联

理论说再多，最后都得落地成代码。我把自己实现这个系统时写的核心代码提炼成几个片段，你可以直接拿去做骨架。代码以 Python 为主，配合 Flask 提供 API。

4.1 数据处理与加载阶段

无论用什么算法，第一步都是把 MySQL 里的数据读出来，转成算法能用的格式。我习惯用 Pandas 的 DataFrame 来做清洗和透视：

import pandas as pd import pymysql def load_data(): conn = pymysql.connect( host='localhost', user='root', password='your_password', database='campus_food', charset='utf8mb4' ) # 读取用户评分记录 ratings_df = pd.read_sql( "SELECT user_id, dish_id, rating FROM user_preferences WHERE rating IS NOT NULL", conn ) # 读取菜品信息 dishes_df = pd.read_sql( "SELECT id, name, category, taste_tags, monthly_sales FROM dishes", conn ) conn.close() return ratings_df, dishes_df

这一步看起来简单，但有一个坑必须提前说：字符编码。MySQL 连接必须加上charset='utf8mb4'，否则菜品名字段一旦包含 emoji 或者特殊符号，直接乱码。我见过不只一个人栽在这里，卡了一下午最后发现就是少了个参数。

接下来把评分表转换成一个用户-菜品评分矩阵。注意这里是一个稀疏矩阵，行是用户，列是菜品，值是对应的评分。实际操作中我用 Pandas 的 pivot 函数来做，效率最高：

def build_user_item_matrix(ratings_df): user_item_matrix = ratings_df.pivot_table( index='user_id', columns='dish_id', values='rating' ) # 查看一下矩阵形状 print(f"用户数: {user_item_matrix.shape[0]}, 菜品数: {user_item_matrix.shape[1]}") return user_item_matrix

pivot 之后没评过分的菜品位置会是 NaN，这就是矩阵稀疏的原因。你不用专门去填充它，计算相似度的时候，Pandas 的corr()方法会自动忽略 NaN。这一点很方便，但在接下来的相似度计算中你要格外注意对齐问题，不要带着 NaN 相加。

4.2 皮尔逊相似度计算与邻居选择

计算用户相似度可以用DataFrame.corr(method='pearson')，一行代码就能得到所有用户两两之间的相似度矩阵。但这个方法要求你的数据至少是干净的，评分不能全是同一个值，否则除数为零。当成型代码发布时，我会建议你用更可控的 NumPy 实现一段自己的函数，方便调试：

import numpy as np def compute_user_similarity(user_item_matrix): # 用户-菜品评分矩阵，行是用户，列是菜品 matrix = user_item_matrix.values n_users = matrix.shape[0] similarity = np.zeros((n_users, n_users)) for i in range(n_users): for j in range(i + 1, n_users): # 找到两个用户共同评过分的菜品 mask = ~np.isnan(matrix[i]) & ~np.isnan(matrix[j]) common = np.sum(mask) if common >= 2: # 至少要有2个共同评分菜品，否则相似度没意义 # 皮尔逊相关系数 r_i = matrix[i][mask] r_j = matrix[j][mask] # 去中心化 r_i_centered = r_i - np.mean(r_i) r_j_centered = r_j - np.mean(r_j) # 计算相关系数 denom = np.sqrt(np.sum(r_i_centered ** 2) * np.sum(r_j_centered ** 2)) if denom > 0: sim = np.sum(r_i_centered * r_j_centered) / denom else: sim = 0 else: sim = 0 similarity[i][j] = similarity[j][i] = sim return similarity

这段代码值得注意的点有二。其一，common >= 2这个阈值是我多次实验调出来的。如果两个用户只共同评过一道菜，计算出的相似度随机性太大，不能代表真实偏好。其二，皮尔逊公式要求分母不为零，如果某个用户对所有菜品的评分完全一致（全打 3 分），他的分值没有区分度，跟谁都算不出有效相似度，直接归零处理是对的。

邻居数量 K 的选择也有讲究。K 太小，推荐结果质量不稳定；K 太大，会把相似度很低的用户也拉进来，稀释推荐精度。校园场景我一般取 10 到 20 之间的值，你可以把 K 设成变量，后面做实验对比不同 K 值的效果。

4.3 推荐生成函数

有了相似度矩阵，就可以对指定用户生成 Top-N 推荐列表了。这里我把流程写完整：

def recommend_for_user(user_id, user_item_matrix, similarity, dishes_df, top_n=10): # 找到用户在所有用户列表中的位置 user_idx = list(user_item_matrix.index).index(user_id) # 取该用户的相似度向量 sims = similarity[user_idx] # 找到相似度最高的 K 个用户 k_neighbors = 15 neighbor_indices = np.argsort(sims)[::-1][:k_neighbors + 1] # 过滤掉自己 neighbor_indices = [idx for idx in neighbor_indices if idx != user_idx] # 当前用户已吃过的菜品 user_ratings = user_item_matrix.iloc[user_idx] rated_dishes = set(user_ratings.dropna().index) # 计算候选菜的预测评分 dish_scores = {} for dish_id in user_item_matrix.columns: if dish_id in rated_dishes: continue # 已经吃过的就不推荐了 total_sim = 0 weighted_score = 0 for n_idx in neighbor_indices: n_rating = user_item_matrix.iloc[n_idx][dish_id] if pd.notna(n_rating): n_user_avg = np.nanmean(user_item_matrix.iloc[n_idx]) weighted_score += sims[n_idx] * (n_rating - n_user_avg) total_sim += sims[n_idx] if total_sim > 0: user_avg = np.nanmean(user_ratings) pred = user_avg + weighted_score / total_sim dish_scores[dish_id] = pred # 排序取 Top-N sorted_dishes = sorted(dish_scores.items(), key=lambda x: x[1], reverse=True)[:top_n] recommend_ids = [d[0] for d in sorted_dishes] # 关联菜品信息 recommend_df = dishes_df[dishes_df['id'].isin(recommend_ids)].copy() # 保留推荐顺序 recommend_df['sort_order'] = recommend_df['id'].map( {d_id: idx for idx, (d_id, _) in enumerate(sorted_dishes)} ) recommend_df = recommend_df.sort_values('sort_order') return recommend_df[['id', 'name', 'category', 'taste_tags', 'price']]

写完这段代码以后，你可以先拿几组测试数据自检一遍。比如找两个口味非常相似的用户，看看系统给他的推荐结果里，被跳过的已评分菜品和最终推荐菜品是否符合预期。如果完全偏离，就检查一下是否数据稀疏导致邻居里全是相似度为 0 的“无效邻居”。

4.4 API 服务封装与前端对接

算法层写完之后，还差一层关键封装：把推荐结果通过接口暴露出来。我用 Flask 写一个最简单的接口示例如下：

from flask import Flask, jsonify, request app = Flask(__name__) @app.route('/api/recommend', methods=['GET']) def recommend(): user_id = int(request.args.get('user_id', 1)) try: ratings_df, dishes_df = load_data() user_item_matrix = build_user_item_matrix(ratings_df) similarity = compute_user_similarity(user_item_matrix) result = recommend_for_user( user_id, user_item_matrix, similarity, dishes_df ) # 把结果转成 JSON 返回 return jsonify({'code': 0, 'data': result.to_dict(orient='records')}) except Exception as e: return jsonify({'code': 1, 'msg': str(e)}), 500 if __name__ == '__main__': app.run(host='0.0.0.0', port=5000, debug=True)

前端你可以用 Vue + ECharts 做展示，也可以直接用 Flask 的模板引擎渲染页面。我不建议在这个阶段过度纠结前端技术栈，毕竟核心是推荐系统，不是可视化比赛。一个简单的菜品卡片列表、评分组件、推荐结果区，就能完整串联起整个系统。

注意：协同过滤的相似度计算是 O(n²) 复杂度，用户量到了几百上千之后，接口响应会明显变慢。解决办法是给推荐结果加 Redis 缓存，用户第一次请求时算好存进去，后续直接读缓存，过期时间可以设成 1 小时或者 1 天。

5. 混合推荐策略与排序优化

只用协同过滤就完事了吗？可以把话说得实在一点：够用，但不优秀。系统一旦运行起来，你会发现协同过滤有几个天生短板，要解决就得靠混合推荐策略。

5.1 处理“新用户”和“新菜品”的冷启动

新用户没有评分记录，协同过滤完全失效。新菜品没有用户吃过，永远不会出现在推荐结果里。这就叫冷启动问题。我在第 2 节提到了热度推荐解决冷启动，这里把逻辑讲透。

具体实现是把多种信号线性加权成一个“冷启动评分”：

def cold_start_score(dish): # 月销量：标准化到 0-1 sales_score = min(dish['monthly_sales'] / 1000, 1) # 平均评分：归一化 rating_score = (dish['avg_rating'] - 1) / 4 # 综合得分，销量权重略高，模拟从众心理 return 0.6 * sales_score + 0.4 * rating_score

这个公式不是固定的，你可以按需求调整。比如学校附近的奶茶店，上新速度很快，那你可能要调高“上新时间”这个因素的权重。核心思路只有一条：在没有个性化信号时，用大众口碑和从众数据顶上去。

5.2 用户标签画像与排序加权的实践

既然存在taste_tags这个字段，就别浪费。我额外做了一层轻量化的用户口味画像，做法是先从该用户历史高评分菜品里提取出现频率最高的前三个口味标签，再在推荐排序阶段给带有这些标签的菜品增加一个小幅度的分数加成。

这个方案比单独跑一个复杂的分类模型要实用得多，毕竟校园系统不需要工业级的精度，稳定、可解释、代码简单才是硬道理。而且答辩的时候，这层“标签加权”逻辑很容易跟老师讲明白，比玄学调参有说服力。

5.3 多样性与惊喜感的兜底策略

推荐系统还有一个隐蔽问题：越推荐越窄。如果用户只吃麻辣烫，系统就会一直推麻辣烫，但人的口味是会变的，尤其是学生，隔三差五就想去试试新窗口。纯协同过滤很容易陷入这种“信息茧房”。

我的兜底方案是：推荐列表的前 8 个结果按照评分排序输出，但第 9 和第 10 个位置固定插入两条“探索性推荐”——随机选取从未出现在该用户历史偏好里的菜品品类。这样既不影响主体的推荐质量，也能保证每个推荐周期的结果都有新鲜感，不会让人越看越腻。

6. 部署、测试与常见问题排查实录

代码写完了，算法跑通了，剩下的就是上线部署和调试。这一节内容虽然靠后，但我个人觉得它才是决定整个项目能不能拿到高评价的关键。一个逻辑完整但运行一天就崩的系统，和一个功能朴素但稳定运行的项目，工业界的评价完全不一样。

6.1 系统部署环境搭建

实际项目里我建议用 Linux 服务器部署，哪怕是本地虚拟机都行。用systemd直接托管 Flask 服务，进程崩溃后能自动拉起，比手敲python app.py可靠得多。

部署的关键步骤就三件事：装依赖、配数据库、起服务。

# 1. 安装 Python 依赖 pip install flask pandas numpy pymysql redis # 2. 初始化数据库 mysql -u root -p < schema.sql # 3. 使用 gunicorn 启动服务，四进程 gunicorn -w 4 -b 0.0.0.0:5000 app:app

这里插一句，gunicorn的-w 4是开启 4 个 worker 进程。不要贪多，worker 数一般设为 CPU 核数的 2 倍左右即可，开太多反而会因为上下文切换开销导致性能下降。

6.2 高并发场景下的缓存策略

校园美食推荐系统的特征之一是突发流量明显——中午 11 点半下课到 12 点半之间，访问量可能是其他时段的十几倍。如果不做缓存，一到饭点服务器就开始卡，下课后学生刷不出来，第一印象就崩了。

我的解决方案是 Redis 缓存三层：第一层缓存推荐列表，key 是user_id:recommend:date，过期时间设成 6 小时；第二层缓存菜品详情；第三层缓存相似度矩阵，离线计算后写进 Redis，在线服务只读。这样做完之后，高峰期接口的响应时间基本可以从 800ms 以上压到 50ms 左右。

6.3 常见报错与问题排查技巧

因为做这套系统的人很多，我在学习和带人的过程中收集了不少高频问题，这里整理成一张排查表，对照处理比重新看文档效率高得多：

下面我把两个出现频率最高的坑单独拎出来讲。

第一个是关于“为什么协同过滤跑出来结果全是热门菜”。这个问题根因基本是数据稀疏。你在算相似度时，如果大部分用户之间共同评分菜品数只有一两个，那么相似度矩阵里几乎全是噪声，排序结果就退化成了“大家都评分过的菜”。其中评分人数最多的菜自然排到了最前面，看起来就是热门菜推荐，其实算法已经失效了。解决办法不是调算法，而是回去补数据，至少保证大部分用户都有 10 条以上的评分记录。

第二个是关于“Excel 导出的数据读出来小数点精度高到离谱”。这个其实不是 bug。评分矩阵中的数值如果本身来自计算（比如预测评分），就会有浮点误差，而 MySQL 里的 price 或 rating 都是 DECIMAL 类型，本身精度可控。如果你发现自己导入的数据出现 3.0000000000000004 这种情况，大概率是代码里用 Python 做过除法运算然后写回了库。解决方式是写库之前先round(value, 2)，避免脏数据污染。

6.4 基于用户反馈的迭代优化

系统真正上线后你会发现，推荐按钮谁都会点，但点赞、评论的人很少。所以你要把“观看菜品详情页”这种隐式行为也记录下来，这在算法上叫隐式反馈。它的价值在于：不需要用户额外动手，你就能知道用户对哪些菜有真实的兴趣。

我建议在你的前端页面上加一个简单的埋点：

// 用户点击了某个菜品卡片 function onDishClick(dishId) { fetch('/api/behavior', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ user_id: currentUserId, dish_id: dishId, behavior_type: 'browse' }) }); }

后端收到这个请求后往user_preferences表里插一条behavior_type='browse'的记录。算法层在计算用户偏好时，可以把浏览行为折算成一个隐式评分（比如默认 3.5 分），但权重低于真实评分。这样就不怕用户不评分的场景，推荐系统照样有信号可以用。

7. 进阶方向与扩展思考

如果一个基础版的校园美食推荐系统你已经能完整写出来，并且成功跑通全流程，那我给你几个进阶方向，可以根据自己的时间和能力酌情扩展。

第一个方向是引入协同过滤的工业级优化。现在计算用户相似度是 O(n²) 的暴力算法，用户量到几千之后性能就不太行了。业界通用的做法是 MinHash / LSH 近似最近邻搜索，先用签名矩阵压缩用户向量，再用局部敏感哈希把候选邻居范围缩小，最后再精确计算相似度。这是阿里和腾讯在真实业务里用过的方案，能做到十亿级用户实时推荐。

第二个方向是使用深度学习模型替换协同过滤。比如 Neural Collaborative Filtering（NCF），用神经网络替代内积来建模用户和物品的交互；或者用双塔模型，把用户特征和菜品特征分别编码，再做向量召回。这些方法在数据量够大的情况下，效果会比协同过滤好一个身位，可解释性上会弱一些。

第三个方向是做实时特征计算。现在的推荐系统本质上是离线计算好列表以后直接展示，没有利用“刚刚发生的用户行为”。你可以引入 Flink 或者 Spark Streaming，把用户的新评分行为变成实时特征，触发一次轻量级的增量推荐，达到“用户刚给一道菜打了 5 分，刷新以后同类型推荐权重立刻上升”的效果。

这三个方向难度递增，但无论选哪个，都能让你的毕设或项目从“课程设计水平”直接跳到“工程实践水平”。尤其是第一个方向，论文都可以直接出一个小章节，答辩时有真实落地价值，比堆UI强太多了。

我在实际做这类系统的时候，最大的感触是：推荐系统这块真的不用追求“用了什么新潮模型”，关键是逻辑链路要通。你把数据建好、算法选对、接口写好、缓存加上，整个系统的完成度就已经超过八成的人了。剩下的都是锦上添花，但基础盘不牢，花再多也是空中楼阁。

最后分享一个小技巧，帮你在答辩或者项目汇报时从容一些。讲推荐系统时，不建议第一个就甩出公式和代码，建议先讲故事：“我研究了校园里学生寻找美食的行为习惯，发现大家最依赖的是身边同学的口碑，所以我选用了基于用户的协同过滤算法。”一句话讲清楚动机，再接着说实现难点，整个思路高下立判。这一个项目认真做完，你对 Python 数据处理、Flask 接口开发、简单算法实现、Linux 部署、MySQL 和 Redis 的掌握程度都会实质性地上一个新台阶。按照上面的步骤走，别贪多，你会发现这套系统并没有想象中那么难。