SpringBoot餐厅推荐系统实战：协同过滤与用户画像融合设计

毕设做到餐厅推荐系统这个选题，说实话在同届里不算新鲜，但真正能把“推荐”两个字落地、而不是做一个普通点餐CRUD的人确实不多。这个题目看起来像是SpringBoot全家桶的标准练手项目，实际上把用户画像、协同过滤、冷启动、实时反馈这些推荐系统核心问题全串起来了。这篇博客我就以“基于SpringBoot的个性化餐饮推荐服务平台”为例，把整个项目的技术拆解、设计思路和实操过程完整走一遍，目标读者是正在做类似选题的毕业生，以及想快速在自己的Web工程里接入推荐逻辑的后端开发者。

1. 内容整体设计与思路拆解

1.1 餐厅推荐系统的本质：不是一个点餐系统，而是一个决策引擎

很多同学拿到这个题目后第一反应是：做菜单管理、购物车、下单、订单管理，再加个用户登录注册，完事了。如果只是这样，这个项目跟“XX管理系统”没有任何区别，答辩时老师一问“推荐体现在哪里”，就会陷入被动。

我的理解是：这个项目的灵魂不在“点餐”而在“推荐”。“在线点餐”是业务载体，提供的是用户行为数据的采集场景；“智能推荐”才是核心价值，解决的是用户“不知道吃啥”的决策成本问题。用户打开一个小程序或者网页，不是为了浏览全部200道菜，而是希望在3秒内看到今天最想吃的3到5道菜。所以整个系统的数据模型、接口设计、页面逻辑，都应该围绕“采集行为-构建画像-生成推荐-反馈闭环”这条链路展开，而不是围绕传统的增删改查。

1.2 为什么选SpringBoot：核心是快速聚合生态，而不是框架本身

作为毕设技术栈，SpringBoot几乎是当前的最优解。原因很简单：社区资料多、面试常问、上手阻力小。从技术实现角度，它能以极低的配置成本整合数据持久层、缓存、定时任务和WebSocket推送，这套组合对于推荐系统这种“定时计算+实时反馈”混合型业务来说非常合适。

另外一个实际考虑是：推荐算法本身并不依赖Java生态，Python里用Surprise库写协同过滤代码量更少。但毕设要求是一个Web工程，需要完整的用户管理、菜品管理、订单流程、推荐结果展示，这些功能用SpringBoot做远比用Flask或者FastAPI更成熟顺手。算法部分用Java手写协同过滤反而更有教学价值——你能真正理解相似度计算的每一步，而不是调一个黑盒库。

1.3 推荐策略选型：先定规则，再谈算法

我用过很多推荐方案，从最简单的“按销量排序”到基于协同过滤的个性化推荐，它们的适用场景完全不同。餐饮推荐和电商推荐有个重要区别：餐饮是高频、短决策、强时段属性的场景，用户今天想吃辣的可能明天就想喝粥，历史行为权重不能太高。

所以我的方案是混合推荐策略——不是单一算法打天下，而是多个策略按场景融合：

• 协同过滤（基于用户的UserCF）：找口味相似的用户，推荐他们点过的菜，负责“猜你喜欢”。
• 内容推荐（基于菜品特征）：根据用户高频点击的菜品类别、口味标签，推荐同类但没点过的菜，负责“相似探索”。
• 热度兜底：新用户没有行为数据时，按销量、评分、时段热度推荐，负责“冷启动”。

这套组合逻辑放在一处定时任务里每天离线计算，用户点开推荐页时直接读取计算结果。虽然数据量不大达不到大数据实时推荐的效果，但完整覆盖了推荐系统的经典模块，论文和答辩素材都足够。

1.4 数据流设计：行为埋点是推荐的原料，不能省

推荐系统界有句老话叫“垃圾进，垃圾出”。很多毕设项目省掉了行为采集这一步，只依赖用户下单记录。但下单数据太稀疏——一个用户一周可能只下3次单，每次就点两三道菜，一两周下来行为数据量根本不够算相似度。

我在设计时增加了独立的行为记录功能：用户浏览菜品详情、搜索关键词、点击推荐位、收藏菜品、加入购物车，这些动作都会写入一张行为日志表。注意这里不是简单的log记录，而是带业务语义的结构化数据：行为类型、目标菜品、行为发生时的上下文（是来自推荐位还是搜索）、停留时长等。单次浏览行为虽然只是轻量级信号，但积少成多之后，它能让系统在用户只下过一次单的情况下就快速建立初步画像。

2. 核心细节解析与实操要点

2.1 数据库设计：画像数据建议用“宽表+JSON字段”方案

传统教学里数据库设计讲究范式化，但推荐系统里的用户画像如果完全做范式化设计，查询时会异常痛苦。比如用户画像可能包含：口味偏好（辣度、甜度）、菜品类别偏好（川菜、粤菜）、价格带偏好、平均下单时段、最近30天活跃度。如果每一项都分一张表，联合查询会写出极长的SQL，而且每次推荐结果展示时都要实时关联计算。

我在项目里采用了“核心表范式化 + 画像表JSON扩展”的方式。用户表、菜品表、订单表、行为表全部规范化设计，这些表承载核心业务，数据准确性和完整性第一位。额外创建一张user_profile表，字段设计为：用户ID、偏好向量JSON、最近行为摘要JSON、推荐结果快照JSON。这样推荐计算完成后，展示接口只需要一次查询把JSON取出来，避免推荐结果多次查库的麻烦。

菜品表的设计也需要额外用心，推荐算法需要特征字段支撑内容匹配。我设计的菜品表字段包括：菜品名称、类别ID、价格、辣度等级（0到3）、口味标签（多个用逗号分隔）、销量、评分、上下架状态。口味标签这个字段是内容推荐的核心依据——比如“微辣、下饭、荤菜、蒜香”一组标签，能跟用户画像中的偏好标签做交集计算。

2.2 用户行为权重：不是所有行为都等价

行为日志表收集到的原始行为五花八门，不能一股脑丢进算法里做等权计算。我在代码里维护了一个行为权重配置，不同行为对画像的影响力度不同，这样能更真实地反映用户当下的偏好强度。

我实测下来比较合理的权重设置是：

这个权重修正体现在两个层面：实时更新用户画像的“近30天偏好计数”时按照权重累加；离线计算推荐结果时，生成伪评分矩阵也按权重加权。实际效果是：只浏览不点菜的“白嫖党”用户不会因为大量浏览记录而收到和自己真实口味偏离的推荐。

2.3 冷启动处理：新用户和新菜品都要有救

冷启动是推荐系统里最基