每年毕业设计选题，这类“系统设计与实现”的题目永远是最稳的选择，但也是最容易做砸的。如果你拿到的是“基于Spring Boot + Vue + MySQL的美食信息推荐系统”，先别急着庆幸题目简单——这个题目真正的难点不在于前后端CRUD，而在于“推荐”两个字怎么落地。把推荐做成摆设的毕设一抓一大把，但把推荐真正讲清楚、做出来，你的答辩质量完全是另一个档次。
这篇博文我会直接从我的实际经验出发，把整套系统从需求分析、数据库设计、推荐算法选型、后端接口设计、前端页面组织到部署避坑全部讲透。内容面向正在做毕业设计或课程设计的同学，也适合想入门前后端分离项目、顺便了解推荐系统落地思路的开发者。你会发现，这个题目比想象中有料，但也比想象中需要你多动一点脑筋。
1. 这个项目到底在解决什么问题：先想清楚再动手写代码
拿到题目先别急着建工程。很多同学上来就写用户表、菜品表、增删改查，做到最后发现这只不过是一个“带数据库的网页”，推荐功能完全不知道从哪里塞进去。问题的根源在于没有做好需求分析。
美食推荐系统表面上是“给用户推荐好吃的”，但把它拆开，它解决的是三个具体问题：信息过载、决策成本、系统冷启动。用户在几百道菜品面前无从下手，平台需要根据用户的历史行为猜测他可能喜欢什么，而新用户首次登录时没有任何数据，系统又该怎么办。这三个问题分别对应推荐模块的三个子功能：猜你喜欢、相似菜品推荐、热门榜单。
拿我见过的一个模拟项目X举例，它的做法是：登录后首页展示“热门推荐”和“猜你喜欢”两块。热门推荐解决新用户的冷启动，猜你喜欢解决老用户的个性化，菜品详情页下方再挂一个“喜欢这道菜的人也喜欢”模块。这个设计非常聪明，因为它把三种推荐策略分别放在了不同的页面场景里，答辩时每条推荐逻辑都能讲清楚缘由。
需求阶段还必须明确系统边界。一个合格的美食推荐系统至少要有：用户注册登录、美食分类浏览、美食详情展示、评分与收藏行为记录、搜索筛选、推荐结果展示。后台管理属于加分项，有精力就做，没精力可以先放一放。核心精力必须放在用户行为数据的采集和推荐接口的打通上，因为推荐算法吃的就是行为数据，没有数据流，算法再漂亮也是空转。
我强烈建议你在动手前画一份简单的功能清单，把每个功能对应的页面、后端接口、数据库表写清楚。一份清晰的清单大概长这样：
| 功能模块 | 页面 | 后端接口 | 涉及数据表 |
|---|---|---|---|
| 用户注册登录 | 登录页/注册页 | /api/auth/register， /api/auth/login | user |
| 美食浏览分页 | 首页/分类页 | /api/food/list | food， category |
| 美食详情 | 详情页 | /api/food/detail/{id} | food |
| 评分收藏行为 | 详情页内操作 | /api/interaction/record | user_food_interaction |
| 热门推荐 | 首页热门区块 | /api/recommend/hot | food， interaction统计 |
| 个性化推荐 | 首页猜你喜欢 | /api/recommend/personal | 基于交互数据计算 |
| 相似菜品推荐 | 详情页下方 | /api/recommend/similar/{foodId} | food_tag， 相似度计算 |
| 搜索筛选 | 列表页搜索框 | /api/food/search | food， category |
这张表在写代码阶段会反复用到，它也决定了数据库建模的边界。建议各位花一晚上把这张表打磨完整，后面所有的开发都会变得非常顺。
2. 技术选型的理由：为什么是Spring Boot、Vue和MySQL
技术选型在你答辩时几乎必被问到，所以不但要选，还要能说出为什么选。Spring Boot + Vue + MySQL这套组合能成为毕设主流，不是因为它潮流，而是因为它每一层都刚好落在“够用、好学、好讲”的交叉点上。
后端选Spring Boot，核心理由是生态成熟、配置简单、社区资料极多。你遇到九成的问题，搜索引擎都能找到现成答案，这对独立做项目的人来说太重要了。它内置的Spring MVC负责接口层，Spring Security或者JWT方案负责认证，MyBatis-Plus负责数据库操作，整个分层结构清晰，写起来也顺手。如果用了SSH那套老框架，光是XML配置就能磨掉你一周的耐心，而Spring Boot起步就要快得多。
前端选Vue，理由同样现实。Vue的学习曲线比React平缓，模板语法直观，配合Element UI组件库可以在很短时间内搭出像样的管理界面和用户界面。它的响应式数据绑定，在美食列表、评分交互、推荐结果刷新这些场景下用起来非常顺手——用户给菜品打了分，前端拿到返回值后自动更新视图，逻辑直白。
MySQL在这里承担的是所有关系数据的存储。用户表、菜品表、分类表、行为记录表天然是关系型结构，用MySQL非常顺手。很多人纠结要不要上Redis做缓存、要不要用MongoDB存行为日志，我的建议是统统不要。毕设场景下数据量根本到不了需要NoSQL的水平，把这些技术写进系统里属于“过度设计”，答辩老师一问“你的数据规模有多大，为什么需要Redis”，很容易答不上来。
关于版本选择，我推荐Java 8/11、Spring Boot 2.7.x、Vue 2 + Element UI，或者Vue 3 + Element Plus也可以，但Vue 2的资料更多，遇到坑更好查。MySQL用5.7或8.0都行，8.0记得注意驱动配置的差异。这套组合不求新，求稳，因为你的目标是顺利把项目做完通过答辩，而不是追最新版本。
3. 数据库设计：推荐系统最不能省功夫的一环
数据库设计是推荐系统项目的地基，也是很多同学最先偷懒的地方。我见过不少项目把用户行为和美食数据混在一张表里，或者干脆不建行为表，导致后续写推荐算法时无从下手。这里我把核心表结构完整列出来，你可以直接照着建。
3.1 用户表与美食表：基础数据的字段规划
用户表（user）是系统身份信息的载体，字段不需要多，但必须够用。
CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(255) NOT NULL COMMENT '加密后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;密码字段务必保存加密后的字符串，用BCrypt加密，这是安全底线，即使只是毕设也要养成好习惯。美食表（food）则是系统的核心内容，字段设计要支撑起推荐算法的相似度计算，因此需要预留标签字段。
CREATE TABLE `food` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL COMMENT '菜品名称', `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID，关联category表', `image_url` varchar(500) DEFAULT NULL, `price` decimal(10,2) DEFAULT NULL, `description` text COMMENT '菜品描述', `tags` varchar(255) DEFAULT NULL COMMENT '逗号分隔的标签，如川菜,麻辣,鸡肉', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category` (`category_id`), KEY `idx_tags` (`tags`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有个细节非常关键：tags字段。它的存在决定了相似菜品推荐能做内容相似度计算。比如一道“辣子鸡丁”的标签是“川菜,麻辣,鸡肉”，另一道“宫保鸡丁”是“川菜,微辣,鸡肉”，它们就能通过标签重叠度被判定为相似菜品。这是实现相似菜品推荐最省钱的一种方式，不用动用复杂的文本向量化。
分类表（category）就很简单了，id、name、排序号三个字段足够，用于首页分类导航和列表筛选。
3.2 行为记录表：推荐算法的数据素材
如果说美食表是系统的血肉，行为记录表就是推荐算法的灵魂。所有推荐结果都来自用户行为数据的计算，这张表的设计会直接影响算法能做什么、不能做什么。
CREATE TABLE `user_food_interaction` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '用户ID', `food_id` bigint(20) NOT NULL COMMENT '美食ID', `behavior_type` tinyint(4) NOT NULL COMMENT '行为类型：1浏览 2评分 3收藏', `score` tinyint(4) DEFAULT NULL COMMENT '评分值，1-5，behavior_type=2时有效', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user` (`user_id`), KEY `idx_food` (`food_id`), KEY `idx_user_food_type` (`user_id`,`food_id`,`behavior_type`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这张表设计的妙处在于，它把浏览、评分、收藏三种行为统一放进一张表里，用behavior_type区分，采集数据时只需要一个接口。推荐算法可以从这张表里提取三重信息：用户喜欢什么（高评分和收藏）、用户看过什么（浏览记录）、热门菜品是什么（全局浏览与收藏的统计）。
我在做模拟项目X时吃过一个亏：最初设计时把评分和收藏分成了两张表，代码写起来麻烦不说，推荐算法还要跨表JOIN，运行效率很低。后来合并成一张表，逻辑立刻清爽了很多。
3.3 关于索引与性能的取舍
很多毕设项目在数据量只有几百条时根本感知不到索引的价值，所以有同学会忽略索引设计。但答辩老师问“这张表为什么要加联合索引”时，你答不上来就很尴尬。理论上说，联合索引 idx_user_food_type 是为了支撑“查询某个用户对某道菜的所有行为”这种高频操作，它是点击行为去重采集的前提。凡是WHERE子句里经常出现的组合字段，就应该考虑联合索引，这个习惯会跟着你进入实际工作，早点养成没坏处。
如果还想做更细的推荐优化，可以加一张美食标签表或者相似度缓存表，但毕设阶段不建议加，保持数据模型精简，把逻辑讲清楚比堆表更重要。
4. 推荐算法怎么落地：从协同过滤到真实代码
推荐算法是整个项目里最有区分度的部分，也是答辩老师最感兴趣的部分。如果只是“菜品列表按销量排序”冒充推荐，一眼就被看穿了。这里我会带你逐步实现两种最基本的推荐策略：基于内容相似度的相似菜品推荐，以及基于用户的协同过滤的“猜你喜欢”。
4.1 相似菜品推荐：用标签重叠度算内容相似度
相似菜品推荐的原理是基于内容的推荐。在美食场景里，我们可以用菜品的标签集合来定义相似度。
假设两道菜的标签集合分别为A和B，相似度用Jaccard系数计算，公式就是交集大小除以并集大小：
similarity(A, B) = |A ∩ B| / |A ∪ B|用Java实现这个逻辑非常简单，我给出一个可直接使用的参考代码：
public double calculateSimilarity(Set<String> tagsA, Set<String> tagsB) { Set<String> union = new HashSet<>(tagsA); union.addAll(tagsB); if (union.isEmpty()) { return 0.0; } Set<String> intersection = new HashSet<>(tagsA); intersection.retainAll(tagsB); return (double) intersection.size() / union.size(); }实际推荐过程中，遍历目标美食所属分类下的所有菜品，计算它们与目标美食的标签相似度，取TopN返回。这个逻辑写起来简单，但效果出乎意料的好。爱吃辣的用户看到“辣子鸡丁”的详情页时，在同一分类下系统推荐“麻婆豆腐”“水煮牛肉”，点击率很高。
这个小模块的工程实现注意一点：如果菜品数量多，遍历计算会慢。毕设场景数据量小无所谓，但如果数据量上去了，可以把计算结果缓存起来，或者只对同一分类的菜品做计算，因为跨分类的菜品相关性本来就低。
4.2 猜你喜欢：基于用户的协同过滤
协同过滤听起来高大上，实际上原理非常朴素：如果用户A喜欢的东西，用户B也喜欢，那么A喜欢而B没看过的东西，就有较大概率被B喜欢。
基于用户的协同过滤（UserCF）实现步骤分三步。第一步，构建“用户-菜品-评分”矩阵。评分数据可以融合行为数据定义：浏览记1分，收藏记3分，评分直接使用分数。第二步，计算用户之间的相似度，常用的有余弦相似度和皮尔逊相关系数。第三步，为目标用户找到最相似的K个用户，把这K个用户喜欢但目标用户没交互过的菜品，按感兴趣程度排序推荐。
我在项目中选用的是余弦相似度，公式和代码推导如下。两个用户u1和u2的评分向量分别为R1和R2，余弦相似度等于两个向量的点积除以模长的乘积：
public double cosineSimilarity(Map<Long, Double> userRatings1, Map<Long, Double> userRatings2) { Set<Long> commonItems = new HashSet<>(userRatings1.keySet()); commonItems.retainAll(userRatings2.keySet()); if (commonItems.isEmpty()) { return 0.0; } double dotProduct = 0.0; for (Long itemId : commonItems) { dotProduct += userRatings1.get(itemId) * userRatings2.get(itemId); } double norm1 = 0.0; for (double rating : userRatings1.values()) { norm1 += rating * rating; } double norm2 = 0.0; for (double rating : userRatings2.values()) { norm2 += rating * rating; } if (norm1 == 0.0 || norm2 == 0.0) { return 0.0; } return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2)); }这里要特别提醒一下：协同过滤的工程难点不在相似度公式，而在数据结构的组装。你需要先把行为记录表的数据按用户ID聚合，生成“用户 -> Map<美食ID, 评分>”的映射，然后再两两计算用户相似度。两步操作在数据量几百条时毫秒级就能完成，完全不需要引入额外框架，但代码写清楚并不容易，建议单独写一个RecommendService类，把这个逻辑封装好。
相似用户找到之后，预测目标用户对未交互菜品的评分，采用加权平均的方式：把相似用户的评分按相似度加权求和，再除以总相似度。代码片段如下：
public Map<Long, Double> predictScores(Long targetUserId, int topN) { Map<Long, Double> scores = new HashMap<>(); Map<Long, Map<Long, Double>> userRatings = buildUserRatingMatrix(); List<UserSimilarity> similarUsers = findTopSimilarUsers(targetUserId, userRatings); Map<Long, Double> targetRatings = userRatings.getOrDefault(targetUserId, new HashMap<>()); for (UserSimilarity similarUser : similarUsers) { Map<Long, Double> otherRatings = userRatings.getOrDefault(similarUser.userId, new HashMap<>()); for (Map.Entry<Long, Double> entry : otherRatings.entrySet()) { if (!targetRatings.containsKey(entry.getKey())) { scores.merge(entry.getKey(), similarUser.similarity * entry.getValue(), Double::sum); } } } return scores.entrySet().stream() .sorted(Map.Entry.<Long, Double>comparingByValue().reversed()) .limit(topN) .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue, (e1, e2) -> e1, LinkedHashMap::new)); }写到这里你会发现，推荐算法的核心不是数学，而是工程组织能力。如何从数据库捞出行为数据、如何组装成内存里的结构、如何优雅地处理用户没有行为的边界情况，这些才是真正考察功力的地方。
4.3 冷启动问题的处理方式
每个新用户注册进来时没有任何行为数据，协同过滤对他完全失效，这就是冷启动问题。我的处理策略是分层推荐：新用户和低活跃用户直接返回热门榜单，热门度定义为一个综合指标：
hotScore = 收藏数 * 3 + 评分人数 * 2 + 平均评分 * 10这个公式里，平均评分的权重最高，因为它的信号质量好。浏览和收藏数量则反映了人气。你可以在美食实体上增加一个hot_score字段，定时计算或者每次查询时实时计算都行。热门榜还有一个额外的好处——它是全站的流量入口，每个页面都能用，懒得写个性化算法时它可以兜底。
推荐模块做完后，一定要自测几个典型用户画像：新用户看热门榜、老用户看个性化推荐、低频用户看混合推荐，确保每一种情况都有结果返回，不让前端面对空白列表。
5. 后端核心接口设计：让前端有数据可用
后端开发的第一步是明确接口清单。前端页面需要什么数据，后端就提供什么接口，两者对应关系要清晰。这一节把最关键的几个接口的实现讲清楚。
5.1 用户注册登录与JWT认证
注册接口逻辑简单：接收用户名和密码，加密后写入user表，返回成功提示。登录接口验证密码后，生成JWT令牌返回前端，前端后续请求在请求头带上这个令牌，后端通过拦截器统一验签。
JWT配置建议放在application.yml里，设置一个足够长的随机字符串做密钥：
jwt: secret: xxxxx-your-secret-key-change-in-production expire: 86400登录接口的Controller代码可以这样写：
@PostMapping("/login") public Result login(@RequestBody LoginRequest request) { User user = userService.verifyPassword(request.getUsername(), request.getPassword()); if (user == null) { return Result.error("用户名或密码错误"); } String token = jwtUtil.generateToken(user.getId(), user.getUsername()); return Result.success(new LoginResponse(token, user)); }拦截器里统一检查Authorization请求头，取出令牌并解析，解析失败直接抛401异常，返回给前端处理。这里有一个常见坑：生成Token时一定要把用户ID放进去，因为后续所有推荐接口都需要当前用户的ID来判断行为数据，光放用户名不够用，用户名是可变的，用户ID才是稳定标识。
5.2 美食列表与详情接口
美食列表接口需要支持分页和分类筛选。用MyBatis-Plus的IPage可以很轻松实现，Service层返回给Controller时记得把IPage转换成简化后的VO对象，不要把数据库实体直接暴露给前端。字段裁剪这个习惯很多新手没有，但实际项目里一定要做，避免把description这种大文本在列表接口里全量回传。
详情接口要注意的是返回内容要包含该菜品的标签集合和相似菜品推荐。推荐逻辑可以和详情主逻辑分开写，详情接口只返回菜品基本信息、评分汇总、操作状态（当前用户是否收藏过），相似菜品放在推荐模块的独立接口里，前端另行调用。这样接口职责单一，出问题时也好排查。
5.3 交互行为采集接口与推荐接口
行为采集接口负责把用户的操作写入user_food_interaction表，这是推荐算法数据的唯一入口。接口设计成POST /api/interaction/record，接收参数：foodId、behaviorType、score。
这里有个值得注意的细节：同一用户对同一道菜重复操作，要做合并或更新逻辑。比如用户今天收藏了一道菜，明天又取消收藏，行为表里不能同时存在两条冲突记录。最简单的方案是在行为记录表上增加联合唯一约束，重复写入时用ON DUPLICATE KEY UPDATE更新。
这三个后端接口和推荐接口，是整个项目后端部分的全部核心。把它们的Controller、Service、Mapper三层结构写清楚，项目的后端骨架就立住了。
6. 前端页面与核心交互：让推荐结果看得见、点得动
Vue前端的架子搭建不难，难的是把推荐系统的“互动感”做出来。美食推荐系统是面向普通用户的C端应用，前端体验直接影响答辩时演示效果，值得认真对待。
6.1 页面结构与路由规划
我建议最少包含7个页面：登录页、注册页、首页、美食列表页、美食详情页、个人中心页、搜索结果页。Vue Router配置如下：
const routes = [ { path: '/', component: HomeView }, { path: '/login', component: LoginView }, { path: '/register', component: RegisterView }, { path: '/food/list', component: FoodListView }, { path: '/food/detail/:id', component: FoodDetailView }, { path: '/profile', component: ProfileView }, { path: '/search', component: SearchView } ];首页可以大致分成三个区域：顶部导航栏、热门推荐区、猜你喜欢区。热门推荐区用横向卡片滚动展示，猜你喜欢区用网格布局。这样的视觉层级会让答辩老师一眼看出系统的推荐能力。
6.2 Axios封装与请求拦截
Axios封装属于前端工程的必备工序。我们统一在axios的request拦截器里把JWT令牌加到请求头，在response拦截器里处理401跳转登录页和统一异常提示。代码参考：
service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = 'Bearer ' + token; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { ElementUI.Message.error(res.message || '系统错误'); return Promise.reject(new Error(res.message)); } return res; }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); router.push('/login'); } return Promise.reject(error); } );这段代码一定要写好，因为项目里所有推荐接口都要知道当前用户是谁，而用户身份的传递全靠这个拦截器。
6.3 推荐区域的展示逻辑与交互反馈
推荐的展示不是无脑调接口渲染。我的建议是每个推荐区域单独封装成子组件：热门推荐组件HotRecommend.vue、相似菜品组件SimilarFoods.vue、个性化推荐组件PersonalRecommend.vue。组件内部独立调用对应接口，用v-loading展示加载态，接口报错时展示兜底文案，告诉用户“推荐暂时走神了，请刷新试试”。
交互反馈是前端体验的关键。用户在美食详情页点击收藏按钮后，前端要立即更新收藏状态，同时可以触发一次推荐数据的局部刷新，让用户感受到“我的行为影响了推荐结果”。这种即时反馈对答辩演示很有说服力，因为它是推荐系统具备实时性的直接证据。
还有一个必做的细节：用户给一道菜打5分后，猜你喜欢区域应该立刻出现同类的菜品。这就要求推荐接口不能缓存得太死，行为发生后下一次请求就要能看到变化。后端可以用简单的时间戳缓存策略，行为数据变化后清一次推荐缓存，毕设阶段不要引太重的缓存框架。
7. 项目部署与实测：从本地开发到可演示的完整流程
项目开发完成后，还有一关必须过：把系统部署起来，让答辩老师可以在浏览器里直接访问。我见过太多项目在开发环境跑得欢，一到演示就翻车，问题大多出在部署环节。
7.1 后端打包与部署
后端用Maven打包成jar文件，命令行执行：
mvn clean package -DskipTests打包后生成target目录下的jar包，放到服务器或演示机上运行：
java -jar food-recommend-system.jar --spring.profiles.active=prod如果你的服务器上没有Java环境，记得先安装JDK。生产环境的配置里要把数据库地址、用户名、密码通过环境变量或启动参数传入，不要硬编码在配置文件里，这是工程素养的体现。MySQL需要先执行初始化SQL脚本，把表和初始菜品数据导进去，这样系统一启动就有内容可展示。
7.2 前端构建与Nginx反向代理
前端部署相对简单，在项目根目录执行：
npm run builddist目录就是打包后的静态文件。把它放到Nginx的html目录下，然后配置Nginx把API请求反向代理到后端服务。配置片段如下：
server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; } }关键在于 try_files $uri $uri/ /index.html; 这一行。Vue Router使用history模式时，直接访问某个路由地址会404，必须用它把所有未知路径都指向index.html，由前端路由接管页面切换。这个坑几乎每个用history模式的开发者都会踩一次。
7.3 上线前的功能自测清单与常见问题
演示前一定要完整自测一遍，我列一个我常用的检查清单供你参考。第一项是注册登录流程，注意密码加密、令牌产生和拦截器放行是否正常。第二项是美食列表分页和分类筛选是否准确。第三项是行为采集后，推荐结果是否出现明显变化，比如给某道川菜打了5分，猜你喜欢区域是否出现新的川菜。第四项是移动端或窗口缩放后页面布局是否正常。第五项是异常场景：后端挂掉时前端是否给出友好提示，而不是直接白屏。
部署阶段的高频错误，我也总结一下：数据库连接失败是最常见的，多半是IP地址、端口、密码不匹配；跨域问题如果正确配置了Nginx基本不会出现，但如果前端直接请求后端端口就会遇到；JWT密钥配置错误会导致所有接口401；前端路由404基本是Nginx缺少try_files配置导致的。
论文和答辩PPT里，这些部署细节、自测结果和问题解决过程都是很好的素材。真实项目中踩过的坑，老师看重的恰恰是这部分——它不是教科书上的知识点，而是你亲自动手换来的经验。
做完这个系统，我最大的感受是：推荐系统真正难的不是协同过滤算法本身，而是行为数据的采集、清洗和工程落地。很多初学者盯着算法公式研究好几天，却忽略了最基础的一步——先把用户行为数据点采集完整。没有数据，再精妙的算法也只是空中楼阁。这个项目做完后，你会发现Spring Boot、Vue、MySQL都只是工具，你真正学到的是从需求出发、以数据闭环为目标打通整套系统的工程思维。这种思维方式，才是毕业设计能带给你的最大财富。
