姬轩亦做毕业设计选题目这事，十个人里有八个都会卡在同一个坎上：既要显得有技术含量，又怕工作量太大做不完，还得保证答辩的时候有东西可以讲。如果你正在为这个纠结，我强烈建议你认真看看"Spring Boot + 智能推荐"这个组合。它几乎是为毕业设计量身定做的题目：推荐算法可以讲深，Spring Boot可以把工程能力体现出来，而且外卖这个场景数据天然丰富、演示效果直观。这篇分享就把我当时从选题、技术选型、核心代码实现到答辩准备的完整思路拆开揉碎讲清楚，都是可以直接复用的经验。
1. 选题逻辑：为什么这个题目是毕业设计的"最优解"之一
1.1 它同时踩中了"算法"和"工程"两个加分点
很多同学选课题时会陷入一个误区：要么选纯管理系统，比如"图书管理系统""超市进销存系统"，这类题目确实简单，但答辩老师一句"你这个系统哪里体现了计算机专业区别于培训班的水平"就能把你问住。要么反过来选纯算法研究，比如"基于深度学习的图像识别"，听起来高大上，但以本科阶段的精力，光是把模型跑通、调出满意的准确率就够喝一壶的，前端页面和系统功能往往草草了事，最后系统不像系统，算法也没有深度。
智能外卖推荐系统天然避开了这两极。从系统层面看，它是一个完整的前后端分离项目，用户端、商家端、管理端三端齐全，涉及订单、商品、用户、评价、浏览记录这些标准业务模块，该有的CRUD一步不少。从算法层面看，它又确实有真正的"智能"成分——不再是简单地把数据库里的数据查出来展示，而是要通过用户的历史行为数据去预测他可能喜欢什么菜品。技术栈可以同时覆盖Spring Boot、Redis、MySQL、推荐算法、消息队列，几乎每一门核心课程的知识点都能在项目里找到落点。
1.2 外卖场景的数据价值比你想的要大
你可能觉得推荐系统常见于电商、短视频，但外卖场景其实更适合做推荐，原因有三个。第一，用户决策成本低，打开外卖App到下单往往只有几分钟，用户更倾向于快速浏览推荐内容而不是仔细搜索比价，这让推荐结果对最终转化的影响非常明显。第二，行为数据密集，一个用户一天内可能产生多次浏览、点击、加购、下单、评价行为，数据量积累速度远超传统电商。第三，位置和时间维度是天然的上下文特征，同样的用户在午餐时间偏好盖饭面食，晚餐可能想吃清淡一点的，在办公室和在家点外卖的选择也完全不同。这些额外维度的引入，让你的推荐算法可以从"用户—物品"二维关系扩展到"用户—物品—场景"三维匹配，这在毕业论文里是非常好的创新点。
1.3 这个题目的难度边界很清晰
选题时最怕的就是"不知道做到什么程度算完"。智能外卖推荐系统的难度是阶梯式的：基础版是商品管理加订单管理加简单的按销量排序；进阶级是基于用户行为数据的协同过滤推荐，能根据相似用户或相似菜品产生个性化结果；高配版是在此基础上引入Redis缓存、消息队列异步处理、冷启动策略、排序模型融合。你可以根据自己的实际水平选择做到哪一档，每一档都是完整可交付的项目，不会出现做到一半发现做不下去了的情况。我当时给自己的目标是进阶级加部分高配版功能，既保证了工作量，又留出了算法调优的余量。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体架构设计：先把地基的每一层想清楚再动手
2.1 技术选型的原则：能毕业、能答辩、能落地
技术选型是这个项目里最容易被忽视但实际最重要的决策。选型的原则我总结成九个字：能毕业、能答辩、能落地。"能毕业"指技术不能太旧，最好用当前主流版本；"能答辩"指你要能清楚解释每一个技术选型的原因，不能只是"网上都说这个好"；"能落地"指你选的每一样东西都必须真的在项目里用起来，而不是装个依赖就完事。
我最终确定的技术栈如下：
| 层级 | 技术选型 | 在项目中的具体职责 |
|---|---|---|
| 后端框架 | Spring Boot 3.x | 提供RESTful API，管理业务逻辑和事务 |
| 持久层 | MyBatis Plus 3.5.x | 数据访问，避免手写大量重复SQL |
| 数据库 | MySQL 8.x | 存储用户、商家、菜品、订单等核心业务数据 |
| 缓存 | Redis 7.x | 缓存推荐结果、实时排行榜、用户会话 |
| 消息队列 | Redis Stream | 异步处理用户行为日志，削峰解耦 |
| 安全认证 | Spring Security + JWT | 登录认证与接口访问控制 |
| 推荐算法 | 协同过滤 + 内容召回 + 热度加权 | 生成个性化推荐列表 |
这里特别说一下为什么用Redis Stream而不是RocketMQ或RabbitMQ。对于毕业设计来说，额外部署一套RocketMQ服务器会增加环境配置的复杂度，而Redis你已经装了，Redis Stream从Redis 5.0开始就提供原生支持，它的消费者组机制完全够用，还能少维护一个中间件。答辩时老师如果问"为什么不用专门的消息队列"，你可以回答：项目规模和数据量用Redis Stream足够承担，同时减少了系统组件数量，降低了部署和运维成本，这也是架构设计的一种取舍。
2.2 数据库设计：七张核心表搭建完整业务闭环
表结构设计直接决定你后面写代码的速度。我设计的是七张核心表，它们之间可以通过外键关系覆盖整个外卖业务流程。
用户表是基础，除了用户名密码手机号这些常规字段外，要预留一个taste_tags字段，用来存用户偏好标签的JSON数组，比如"辣、重口、快餐"。这张表是推荐系统的数据源头之一。
商家表和菜品表是一对多关系。商家表要有cuisine_type（菜系类型）、delivery_time（平均配送时间）、delivery_fee、rating、monthly_sales这些推荐算法需要用到的基础属性。菜品表要有category（菜品分类）、spicy_level（辣度）、image_url、price、status（上下架状态）。
用户行为表是整个推荐系统的灵魂。我设计了两种：browse_record记录浏览次数和停留时长，behavior_log用统一的格式记录所有行为事件，字段包括user_id、item_id