午间十二点的某高校食堂，三层十个窗口，排队的人从取餐口一直蜿蜒到门口。你以为学生纠结的是排哪条队最快，其实大部分人纠结的是另一件事：今天到底吃什么。口味不同、预算有限、又怕踩雷，一顿饭的决策成本比想象中高得多。我自己就是从这个场景出发，决定动手做一套“高校学生饮食推荐系统”。项目整体采用前后端分离架构，后端用 Java + SpringBoot 2.7 + MyBatis，前端用 Vue + Element UI，数据库用 MySQL 5.7，最终交付了一套完整可运行的源码。核心不是做一个简单的菜品展示页面，而是真正把“学生偏好、历史评分、菜品营养标签”三个维度串起来，形成一套轻量级的推荐引擎。整篇文章我会把需求拆解、数据库设计、推荐算法实现、前后端联调、部署踩坑全部讲透，代码片段都可以直接抄走改改用，适合正在做相关毕设、课设，或者想入门前后端分离项目的人。1. 为什么校园食堂需要一套“饮食推荐”而不是简单点餐1.1 从窗口排队说起：学生真正的痛点很多人一听“推荐系统”，第一反应是电商、短视频，觉得一个食堂项目做推荐有点小题大做。但如果你真的在学校食堂待过一段时间，你会发现这个场景有它非常独特的痛点。校园食堂的菜品数量通常在几十到上百种之间，但学生的决策路径极其有限：今天想吃什么、哪个窗口不用排太久、哪个菜不会踩雷、哪道菜价位合适。这些信息分散在多个窗口，没有人帮你整合。再加上大一新生对食堂完全不熟，往往是“跟着人多的队伍盲选”。而食堂管理员同样头疼：菜品卖得不好，不知道是口味问题还是展示问题；想推新品，又不知道目标人群是谁。所以这个系统的第一定位不是“炫技”，而是把食堂里零散的菜品信息、学生口味偏好、历史消费反馈集中到一个平台上，用一套规则算法给出推荐结果。系统的价值在于让新生快速找到合口味的菜，让老生减少踩雷概率，让管理员拿到真实的菜品反馈数据。1.2 系统目标与角色权限划分项目里我划分了三种角色：学生用户、食堂管理员、系统管理员。学生用户是推荐功能的核心服务对象，能完成登录、维护饮食偏好、浏览菜品、查看推荐、对吃过的菜品评分留言。食堂管理员负责菜品的新增、上下架、修改价格和标签、查看评分统计。系统管理员负责用户管理、角色分配和数据初始化。功能模块我用一张表梳理一下，方便对照：功能模块服务角色核心功能点用户登录与注册全部学号/工号登录，JWT鉴权偏好设置学生选择口味标签、忌口标签菜品浏览学生分类搜索、标签筛选、分页智能推荐学生标签匹配+评分反馈混合推荐评分与评论学生给吃过的菜品打分、写短评菜品管理管理员菜品CRUD、上下架、标签维护数据统计管理员菜品平均分、热门Top10其中推荐模块是核心，其他模块更多是支撑推荐所需要的数据闭环。这个思路很重要，我建议你写设计文档时也采取“先定算法，再定数据，最后定界面”的顺序，而不是反过来。2. 技术选型的取舍逻辑与项目骨架搭建2.1 为什么是 SpringBoot + Vue + MySQL + MyBatis这套技术栈在高校项目中几乎成了“标准答案”，但标准答案不意味着没有道理。我实际用下来，每个组件都有它不可替代的位置。SpringBoot 胜在开发效率。内嵌 Tomcat，不用单独配置服务器；Spring 全家桶的自动装配让我省去了大量 XML 配置时间。对于中小型管理系统，SpringBoot 的生态已经完全够用，而且资料多，遇到问题几乎都能搜到解决方案。Vue 的核心优势是组件化开发和数据驱动视图。推荐卡片、评分弹窗、标签选择器这些 UI 都可以拆成独立组件，维护起来非常舒服。加上 Element UI 现成的组件库，管理后台的表格、表单、对话框基本不需要手写样式。MySQL 没什么好说的，学校项目数据量基本在十万级以下，MySQL 无论是成本、稳定性还是易用性都是最优解。MyBatis 的选择需要多说两句。很多人纠结用 MyBatis 还是 MyBatis-Plus，又或者 JPA。我最后选定的是MyBatis 原生 + 少量 XML 手写 SQL的方案。原因是推荐算法里有一条核心 SQL 需要做“多表关联 + 动态条件拼接”，手写 SQL 可控性最高，看得见执行计划，调优也方便。MyBatis-Plus 确实能减少单表 CRUD 代码，但多表复杂查询反而容易写出性能不稳定的代码。如果你们团队里有新手，我也建议从原生 MyBatis 开始，逐步理解后上 MyBatis-Plus 并不冲突。2.2 后端工程与前端工程的目录组织项目采用前后端完全分离的目录结构，根目录下分 backend 和 frontend 两个子工程。后端按分层架构组织：src/main/java/com/campus/diet/ ├── config # 跨域配置、MyBatis配置、WebMvc配置 ├── controller # REST接口层 ├── service # 业务逻辑层，推荐引擎核心类在此 ├── mapper # MyBatis Mapper接口 ├── entity # 数据库实体类 ├── common # 统一返回结果、异常处理、JWT工具类 └── CampusDietApplication.java如果项目到了一定规模，我会建议把 service 拆成接口与实现，但当前阶段直接写实现类反而更清爽，不要过度设计。前端采用标准 Vue 脚手架结构：src/ ├── api # axios请求封装 ├── assets # 静态资源 ├── components # 通用组件（推荐卡片、评分弹窗等） ├── router # 路由配置 ├── store # Vuex状态管理（用户信息、偏好信息） ├── views # 页面视图前端的关键是把 axios 实例统一封装好，加上请求拦截器，带上 JWT token，响应拦截器统一处理 401 和业务错误码。这些代码我放在后文联调部分详细说。2.3 环境与版本适配建议这里我踩过一个大坑，必须单独提醒。SpringBoot 2.7 对 JDK 8 和 11 都兼容，但如果装了新版 JDK 17 以上，某些旧版本依赖的反射机制会报错。建议直接用 JDK 1.8 搭配 SpringBoot 2.7.18，MySQL 用 5.7 或 8.0，Node 环境用 14 或 16 的 LTS 版本，前端包管理器用 npm。这套组合我调试下来是最稳的，不需要在配置上浪费太多时间。3. 数据库设计：用户、菜品、标签与评分如何支撑推荐权重3.1 表结构与字段设计（含DDL）数据库设计是整个系统的地基。我在设计时只坚持一个原则：推荐所需的每一种信号，都必须有对应的表承接。信号无外乎三种——用户是谁（画像）、菜品是什么（标签）、用户对菜品的反馈（评分）。核心表一共五张：用户表 user、菜品表 dish、标签表 tag、菜品标签关联表 dish_tag、用户菜品评分表 rating，另加一张用户偏好表 user_preference 作为推荐权重的持久化容器。DDL 如下，我删减了部分注释，保留关键字段：CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `student_no` varchar(20) DEFAULT NULL COMMENT '学号/工号', `password` varchar(100) NOT NULL COMMENT '加密后的密码', `username` varchar(50) NOT NULL, `role` tinyint(4) NOT NULL DEFAULT 1 COMMENT '1学生 2食堂管理员 3系统管理员', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `dish` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, `description` varchar(500) DEFAULT NULL, `price` decimal(10,2) NOT NULL, `image_url` varchar(255) DEFAULT NULL, `category` varchar(50) DEFAULT NULL COMMENT '窗口/分类', `status` tinyint(4) DEFAULT 1 COMMENT '1上架 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `tag` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `tag_name` varchar(30) NOT NULL, `tag_type` varchar(20) DEFAULT NULL COMMENT '口味/类型/营养', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `dish_tag` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `dish_id` bigint(20) NOT NULL, `tag_id` bigint(20) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_dish_tag` (`dish_id`,`tag_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `rating` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `dish_id` bigint(20) NOT NULL, `score` int(11) DEFAULT 5 COMMENT '评分1-5', `comment` varchar(500) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_dish` (`user_id`,`dish_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `user_preference` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `tag_id` bigint(20) NOT NULL, `weight` decimal(5,4) NOT NULL DEFAULT 0.5000 COMMENT '偏好权重0-1', `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_tag` (`user_id`,`tag_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;rating 表是推荐最重要的反馈数据源。这里要特别强调，我放弃了把多种行为（浏览、点击、收藏）拆成多张表的做法，而是只用评分表承载显式反馈。理由很简单：校园场景下单次会话短，隐式行为噪声大，而且评分字段本身足够直观。后期想扩展点击行为，在这个表上增加 action_type 字段即可，没必要一开始就建三张表。3.2 权重模型：从标签偏好到评分历史数据库只是存储，真正的权重模型需要考虑两个维度：用户偏好权重和菜品综合得分。用户偏好权重存在 user_preference 表里，初始值由用户在注册页或偏好设置页选择的口味标签决定。比如用户勾选了“重辣”“不吃香菜”，前者 weight 置为 0.9，后者置为 0.1 甚至负权重。这里我没有用单纯的 0/1 布尔值，因为推荐系统需要知道“讨厌的标签”和“喜欢的标签”对评分的影响程度。菜品综合得分在推荐接口里实时计算，由三个部分构成：标签匹配分：用户对该菜品所有标签的偏好权重求和群体好评分：该菜品在 rating 表中的平均分，标准化到 0-1热度矫正分：该菜品近期的评分数占总评分数比例，作为冷启动补偿这样设计的好处是算法逻辑透明，出了问题可以逐条排查；坏处是如果并发高，实时计算会吃掉一些性能。后面我会讲如何用索引和 SQL 优化来弥补。4. 推荐引擎实现：基于“标签匹配+评分反馈”的混合算法4.1 算法思路与计算流程很多同学一听推荐算法就想到协同过滤、矩阵分解、深度学习，实际上校园食堂这个场景根本不需要上这么重的方案。原因很简单：食堂菜品的用户行为矩阵非常稀疏，一个学生一天最多记录 2 条评分，协同过滤做出来效果反而不稳定。我采用的方案是“标签匹配 + 群体评分反馈”的混合式推荐，核心是基于内容的思路加上少量群体智慧。整体计算流程如下：用户请求推荐，获取当前用户 id；查出用户的 user_preference 偏好映射表，拿到每个标签的权重；查出所有上架菜品，遍历每个菜品，取出它的标签集合；根据用户偏好权重计算标签匹配分；查该菜品在 rating 表的平均分和评分总数；计算最终得分：finalScore = 标签匹配分 * 0.6 + 标准评分 * 0.3 + 热度分 * 0.1；按 finalScore 降序排列，取前 10 条返回。权重比例 0.6/0.3/0.1 不是拍脑袋来的，是我用初期模拟数据反复测出来的。标签匹配分权重太高，会导致系统只推用户固有口味的菜，失去多样性；评分权重太高，则对新人友好但对老用户不够个性化。0.6 的比例在冷启动和个性化之间基本能平衡。4.2 核心Java代码实现推荐引擎的入口是一个 Service 方法，我把核心代码简化后放在下面：@Override public List<RecommendResult> recommend(Long userId, int limit) { // 1. 查询用户所有偏好标签 List<UserPreference> prefs = userPreferenceMapper.selectByUserId(userId); Map<Long, Double> prefMap = new HashMap<>(); for (UserPreference pref : prefs) { prefMap.put(pref.getTagId(), pref.getWeight().doubleValue()); } // 2. 查询所有上架菜品 List<Dish> dishes = dishMapper.selectAvailable(); // 3. 遍历菜品计算得分 List<RecommendResult> results = new ArrayList<>(); for (Dish dish : dishes) { List<DishTag> dishTags = dishTagMapper.selectByDishId(dish.getId()); // 标签匹配分 double tagScore = 0.0; int matchedTagCount = 0; for (DishTag dt : dishTags) { Double weight = prefMap.get(dt.getTagId()); if (weight != null) { tagScore += weight; matchedTagCount++; } } if (matchedTagCount == 0) { tagScore = 0.1; // 没有任何标签匹配时给低分而非零分 } // 群体评分分 RatingStat stat = ratingMapper.selectAvgByDishId(dish.getId()); double avgScore = stat == null ? 3.0 : stat.getAvgScore().doubleValue(); double ratingScore = avgScore / 5.0; // 热度分：评分人数占总人数比例 long totalRatings = stat == null ? 0 : stat.getTotalCount(); double hotScore = Math.min(1.0, totalRatings / 50.0); double finalScore = tagScore * 0.6 + ratingScore * 0.3 + hotScore * 0.1; results.add(buildRecommendResult(dish, finalScore, matchedTagCount)); } // 4. 排序取TopN results.sort((a, b) -> Double.compare(b.getScore(), a.getScore())); return results.stream().limit(limit).collect(Collectors.toList()); }这段代码里有一个小细节容易被忽略：tagScore计算时，如果用户对某个标签有偏好的同时又有忌口标签，权重会互相抵消。所以 user_preference 表的 weight 我允许存小于 0.5 的值（实际上可以设为 0.1 或 0.05），这样“蒜蓉”和“少辣”这类冲突标签才能正确对冲。对应的 MyBatis XML 里，selectAvgByDishId 的 SQL 是这样写的：<select id="selectAvgByDishId" resultType="com.campus.diet.entity.RatingStat"> SELECT AVG(score) AS avgScore, COUNT(*) AS totalCount FROM rating WHERE dish_id = #{dishId} </select>单条执行没问题，但如果在 recommend 里对 50 道菜都执行一次，会产生 50 次数据库往返。优化方案是在遍历前一次性查出所有菜品的评分统计，用 Map 缓存。4.3 冷启动与热门兜底策略冷启动是所有推荐系统都逃不开的问题。新用户没有评分记录，偏好只有注册时勾选的那几个标签；新菜品没有任何评分，会被热度分和评分分压得很低。我的处理策略是三层兜底：新用户只按初始标签匹配分排序；如果用户连初始标签都没有，系统直接返回“热门菜品榜”，即按评分数总量排序；新菜品在固定时间内赋予一个初始评分权重（模拟评分为 4.2 分），保证它有机会出现在推荐列表里。这个策略虽然简单，但实测下来用户体验不错，没有出现“推荐完全不认识”的突兀感。如果你要扩展，可以把“热门菜品榜”做成一个独立的接口，前端在推荐卡片流下方加一个“大家都爱吃”的横向滚动栏，两个数据源互不干扰。5. 后端接口与Vue前端联调的完整链路5.1 核心接口列表与权限设计后端接口我遵循 RESTful 风格，统一返回结构是Result<T>，里面包含 code、message、data 三个字段，配合全局异常处理器，前端不用每个接口单独写 try-catch。接口方法权限说明/api/auth/loginPOST公开登录获取JWT/api/auth/registerPOST公开学生注册/api/recommendGET学生获取推荐菜列表/api/dishesGET全部分页查询菜品/api/dishes/{id}GET全部菜品详情/api/ratingPOST学生提交评分评论/api/preferencesPUT学生更新饮食偏好/api/admin/dishPOST/PUT/DELETE管理员菜品管理接口/api/admin/stats/topGET管理员热门菜品统计权限方面我用 JWT + 拦截器实现，登录成功返回 token，前端把 token 存在 localStorage，每次请求在 axios 拦截器里加 Authorization。没登录访问受保护接口返回 401，前端路由守卫统一跳转登录页。5.2 Vue组件与前端请求封装的落地细节前端 axios 封装是项目体验的关键。我直接贴出核心的 request.js，这套写法可以复用到任何项目里：import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }, error => Promise.reject(error)) service.interceptors.response.use(response => { const res = response.data if (res.code !== 200) { // 业务错误统一提示 Message.error(res.message) if (res.code === 401) { router.push('/login') } return Promise.reject(new Error(res.message)) } return res.data }, error => { Message.error('网络异常') return Promise.reject(error) }) export default service需要注意两点。第一，baseURL 用了/api，但开发环境后端跑在 8080，前端跑在 8081，所以需要在 vue.config.js 里配置 devServer 代理把/api转发给 8080，同时解决跨域问题。第二，响应拦截器里我先判断业务 code 再返回 res.data，这样组件里调用时拿到的直接是后端业务数据，不需要再解一层壳。5.3 推荐结果的展示与交互推荐页的 UI 我用了卡片流布局，每张卡片展示菜品名称、图片、价格、综合得分，以及一条推荐理由。这个推荐理由是前端根据后端返回的 matchedTags 拼接的，比如“匹配你喜欢的辣味、荤菜标签”。卡片组件中比较重要的是评分弹窗。学生在卡片上点击“吃过了”，弹窗里展示五个星星，提交后调用 POST /api/rating，刷新推荐流。这里有个交互细节，推荐列表在用户评分后应该局部更新而非整体刷新。我在前端把推荐结果维护在 Vuex 的 recommendList 中，评分成功后直接替换对应卡片的状态，避免抖动。管理员的菜品管理页就相对常规，Table + Dialog 表单 + 标签多选，Element UI 的 el-tag 组件配合可输入下拉框，基本能满足需求。6. 上线部署与实操中踩过的坑6.1 项目打包与一键部署本地跑通很容易，真正上手部署时才发现几个问题。后端打包用 Maven 执行mvn clean package -DskipTests，生成 jar 包后放到服务器，执行nohup java -jar campus-diet.jar > log.file 2>&1 &即可。前端执行npm run build生成 dist 目录。部署方式上，我强烈建议前端 dist 文件不要单独配 Nginx 虚拟主机，直接把 dist 目录拷贝到后端项目的src/main/resources/static/下，让 SpringBoot 自己托管静态页面。这样整个项目只有一个 jar 包，部署成本最低，还能复用同一个端口，避免跨域问题。当然，如果并发量上来要走 CDN 或静态资源分离，再拆 Nginx 也不迟。数据库初始化时要注意，mysqldump 导出的 sql 文件直接执行经常出现编码问题。我统一用SET NAMES utf8mb4开头，并在连接字符串里加上characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai，三处对齐才彻底解决中文乱码。6.2 常见故障排查手册这里整理几张我在开发中真实踩过的坑，希望能给你省点时间。推荐接口响应慢：第一版 recommend 方法在循环里执行 50 次 rating 统计查询，平均耗时 800ms 以上。优化方式上面说过了，一次性查出所有菜品统计用 Map 缓存，接口降到了 80ms 以内。如果你的菜品量上千，建议再在 dish 表的 category、status 上建复合索引。图片上传路径问题：菜品图片我存的是相对路径，例如/uploads/dish/xxx.jpg。开发环境直接放在磁盘目录，生产环境通过配置项注入。如果出现图片加载不出来，先看后端日志里有没有“Path not found”，多半是没有设置静态资源映射。一个简单的做法是在 WebMvcConfigurer 里添加registry.addResourceHandler("/uploads/**").addResourceLocations("file:" + uploadPath)。JWT过期后前端白屏：token 过期是异步发生的，用户正在一个页面停留很久，点击操作突然返回 401，此时如果直接跳转登录页会丢失当前页面状态。我优化成了弹窗提示“登录已过期，请重新登录”，用户确认后再跳转，体验好很多。MySQL时区问题：所有时间字段都定义成 datetime，后端实体用 LocalDateTime，加上 serverTimezone=Asia/Shanghai 基本没问题。但要注意 SpringBoot 的 Jackson 序列化 LocalDateTime 默认格式是数组，需要配置spring.jackson.date-format或者加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。前端打包后路由刷新404：这是 Vue Router 的 history 模式问题。如果你用了 history 模式，Nginx 或 SpringBoot 对未知路径会直接 404。我生产环境为了省事直接改用 hash 模式，刷新就不会出问题；如果一定要 history 模式，需要后端把所有非接口路径都转发到 index.html。6.3 后续可以继续扩展的几个思路整个系统跑通之后，我还在琢磨几个扩展方向，一并分享给你。一是把推荐接口做成异步任务。每天凌晨根据前一天的评分数据离线计算一份“个人推荐表”，存到一张 recommend_result 表里，用户白天请求直接查表。这样权重比例再复杂也不影响接口性能，只是牺牲了一点实时性。二是接入真实的食堂消费数据，用支付记录代替手动评分，作为隐式反馈信号。三是用 Redis 缓存热门榜、标签匹配分，缓存穿透用空值缓存兜底。这些扩展都可以在现有架构上平滑实现，不会推翻重来。如果你正准备拿这个项目做毕设或课设，我的建议是先把第 3 章的数据库表和核心推荐 SQL 吃透，再按照第 4 章的代码一步步跑通。有很多人一上来就想加协同过滤，结果数据量不够效果差，最后还把项目搞复杂了。基于标签的推荐在这个体量下已经是性价比最高的方案，等数据攒够了再迭代也不迟。做项目最重要的是每一步都能解释清楚“为什么这么做”，这份逻辑比代码本身更有价值。
午间十二点的某高校食堂，三层十个窗口，排队的人从取餐口一直蜿蜒到门口。你以为学生纠结的是排哪条队最快，其实大部分人纠结的是另一件事：今天到底吃什么。口味不同、预算有限、又怕踩雷，一顿饭的决策成本比想象中高得多。我自己就是从这个场景出发，决定动手做一套“高校学生饮食推荐系统”。项目整体采用前后端分离架构，后端用 Java + SpringBoot 2.7 + MyBatis，前端用 Vue + Element UI，数据库用 MySQL 5.7，最终交付了一套完整可运行的源码。核心不是做一个简单的菜品展示页面，而是真正把“学生偏好、历史评分、菜品营养标签”三个维度串起来，形成一套轻量级的推荐引擎。整篇文章我会把需求拆解、数据库设计、推荐算法实现、前后端联调、部署踩坑全部讲透，代码片段都可以直接抄走改改用，适合正在做相关毕设、课设，或者想入门前后端分离项目的人。1. 为什么校园食堂需要一套“饮食推荐”而不是简单点餐1.1 从窗口排队说起：学生真正的痛点很多人一听“推荐系统”，第一反应是电商、短视频，觉得一个食堂项目做推荐有点小题大做。但如果你真的在学校食堂待过一段时间，你会发现这个场景有它非常独特的痛点。校园食堂的菜品数量通常在几十到上百种之间，但学生的决策路径极其有限：今天想吃什么、哪个窗口不用排太久、哪个菜不会踩雷、哪道菜价位合适。这些信息分散在多个窗口，没有人帮你整合。再加上大一新生对食堂完全不熟，往往是“跟着人多的队伍盲选”。而食堂管理员同样头疼：菜品卖得不好，不知道是口味问题还是展示问题；想推新品，又不知道目标人群是谁。所以这个系统的第一定位不是“炫技”，而是把食堂里零散的菜品信息、学生口味偏好、历史消费反馈集中到一个平台上，用一套规则算法给出推荐结果。系统的价值在于让新生快速找到合口味的菜，让老生减少踩雷概率，让管理员拿到真实的菜品反馈数据。1.2 系统目标与角色权限划分项目里我划分了三种角色：学生用户、食堂管理员、系统管理员。学生用户是推荐功能的核心服务对象，能完成登录、维护饮食偏好、浏览菜品、查看推荐、对吃过的菜品评分留言。食堂管理员负责菜品的新增、上下架、修改价格和标签、查看评分统计。系统管理员负责用户管理、角色分配和数据初始化。功能模块我用一张表梳理一下，方便对照：功能模块服务角色核心功能点用户登录与注册全部学号/工号登录，JWT鉴权偏好设置学生选择口味标签、忌口标签菜品浏览学生分类搜索、标签筛选、分页智能推荐学生标签匹配+评分反馈混合推荐评分与评论学生给吃过的菜品打分、写短评菜品管理管理员菜品CRUD、上下架、标签维护数据统计管理员菜品平均分、热门Top10其中推荐模块是核心，其他模块更多是支撑推荐所需要的数据闭环。这个思路很重要，我建议你写设计文档时也采取“先定算法，再定数据，最后定界面”的顺序，而不是反过来。2. 技术选型的取舍逻辑与项目骨架搭建2.1 为什么是 SpringBoot + Vue + MySQL + MyBatis这套技术栈在高校项目中几乎成了“标准答案”，但标准答案不意味着没有道理。我实际用下来，每个组件都有它不可替代的位置。SpringBoot 胜在开发效率。内嵌 Tomcat，不用单独配置服务器；Spring 全家桶的自动装配让我省去了大量 XML 配置时间。对于中小型管理系统，SpringBoot 的生态已经完全够用，而且资料多，遇到问题几乎都能搜到解决方案。Vue 的核心优势是组件化开发和数据驱动视图。推荐卡片、评分弹窗、标签选择器这些 UI 都可以拆成独立组件，维护起来非常舒服。加上 Element UI 现成的组件库，管理后台的表格、表单、对话框基本不需要手写样式。MySQL 没什么好说的，学校项目数据量基本在十万级以下，MySQL 无论是成本、稳定性还是易用性都是最优解。MyBatis 的选择需要多说两句。很多人纠结用 MyBatis 还是 MyBatis-Plus，又或者 JPA。我最后选定的是MyBatis 原生 + 少量 XML 手写 SQL的方案。原因是推荐算法里有一条核心 SQL 需要做“多表关联 + 动态条件拼接”，手写 SQL 可控性最高，看得见执行计划，调优也方便。MyBatis-Plus 确实能减少单表 CRUD 代码，但多表复杂查询反而容易写出性能不稳定的代码。如果你们团队里有新手，我也建议从原生 MyBatis 开始，逐步理解后上 MyBatis-Plus 并不冲突。2.2 后端工程与前端工程的目录组织项目采用前后端完全分离的目录结构，根目录下分 backend 和 frontend 两个子工程。后端按分层架构组织：src/main/java/com/campus/diet/ ├── config # 跨域配置、MyBatis配置、WebMvc配置 ├── controller # REST接口层 ├── service # 业务逻辑层，推荐引擎核心类在此 ├── mapper # MyBatis Mapper接口 ├── entity # 数据库实体类 ├── common # 统一返回结果、异常处理、JWT工具类 └── CampusDietApplication.java如果项目到了一定规模，我会建议把 service 拆成接口与实现，但当前阶段直接写实现类反而更清爽，不要过度设计。前端采用标准 Vue 脚手架结构：src/ ├── api # axios请求封装 ├── assets # 静态资源 ├── components # 通用组件（推荐卡片、评分弹窗等） ├── router # 路由配置 ├── store # Vuex状态管理（用户信息、偏好信息） ├── views # 页面视图前端的关键是把 axios 实例统一封装好，加上请求拦截器，带上 JWT token，响应拦截器统一处理 401 和业务错误码。这些代码我放在后文联调部分详细说。2.3 环境与版本适配建议这里我踩过一个大坑，必须单独提醒。SpringBoot 2.7 对 JDK 8 和 11 都兼容，但如果装了新版 JDK 17 以上，某些旧版本依赖的反射机制会报错。建议直接用 JDK 1.8 搭配 SpringBoot 2.7.18，MySQL 用 5.7 或 8.0，Node 环境用 14 或 16 的 LTS 版本，前端包管理器用 npm。这套组合我调试下来是最稳的，不需要在配置上浪费太多时间。3. 数据库设计：用户、菜品、标签与评分如何支撑推荐权重3.1 表结构与字段设计（含DDL）数据库设计是整个系统的地基。我在设计时只坚持一个原则：推荐所需的每一种信号，都必须有对应的表承接。信号无外乎三种——用户是谁（画像）、菜品是什么（标签）、用户对菜品的反馈（评分）。核心表一共五张：用户表 user、菜品表 dish、标签表 tag、菜品标签关联表 dish_tag、用户菜品评分表 rating，另加一张用户偏好表 user_preference 作为推荐权重的持久化容器。DDL 如下，我删减了部分注释，保留关键字段：CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `student_no` varchar(20) DEFAULT NULL COMMENT '学号/工号', `password` varchar(100) NOT NULL COMMENT '加密后的密码', `username` varchar(50) NOT NULL, `role` tinyint(4) NOT NULL DEFAULT 1 COMMENT '1学生 2食堂管理员 3系统管理员', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `dish` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, `description` varchar(500) DEFAULT NULL, `price` decimal(10,2) NOT NULL, `image_url` varchar(255) DEFAULT NULL, `category` varchar(50) DEFAULT NULL COMMENT '窗口/分类', `status` tinyint(4) DEFAULT 1 COMMENT '1上架 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `tag` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `tag_name` varchar(30) NOT NULL, `tag_type` varchar(20) DEFAULT NULL COMMENT '口味/类型/营养', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `dish_tag` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `dish_id` bigint(20) NOT NULL, `tag_id` bigint(20) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_dish_tag` (`dish_id`,`tag_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `rating` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `dish_id` bigint(20) NOT NULL, `score` int(11) DEFAULT 5 COMMENT '评分1-5', `comment` varchar(500) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_dish` (`user_id`,`dish_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `user_preference` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `tag_id` bigint(20) NOT NULL, `weight` decimal(5,4) NOT NULL DEFAULT 0.5000 COMMENT '偏好权重0-1', `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_tag` (`user_id`,`tag_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;rating 表是推荐最重要的反馈数据源。这里要特别强调，我放弃了把多种行为（浏览、点击、收藏）拆成多张表的做法，而是只用评分表承载显式反馈。理由很简单：校园场景下单次会话短，隐式行为噪声大，而且评分字段本身足够直观。后期想扩展点击行为，在这个表上增加 action_type 字段即可，没必要一开始就建三张表。3.2 权重模型：从标签偏好到评分历史数据库只是存储，真正的权重模型需要考虑两个维度：用户偏好权重和菜品综合得分。用户偏好权重存在 user_preference 表里，初始值由用户在注册页或偏好设置页选择的口味标签决定。比如用户勾选了“重辣”“不吃香菜”，前者 weight 置为 0.9，后者置为 0.1 甚至负权重。这里我没有用单纯的 0/1 布尔值，因为推荐系统需要知道“讨厌的标签”和“喜欢的标签”对评分的影响程度。菜品综合得分在推荐接口里实时计算，由三个部分构成：标签匹配分：用户对该菜品所有标签的偏好权重求和群体好评分：该菜品在 rating 表中的平均分，标准化到 0-1热度矫正分：该菜品近期的评分数占总评分数比例，作为冷启动补偿这样设计的好处是算法逻辑透明，出了问题可以逐条排查；坏处是如果并发高，实时计算会吃掉一些性能。后面我会讲如何用索引和 SQL 优化来弥补。4. 推荐引擎实现：基于“标签匹配+评分反馈”的混合算法4.1 算法思路与计算流程很多同学一听推荐算法就想到协同过滤、矩阵分解、深度学习，实际上校园食堂这个场景根本不需要上这么重的方案。原因很简单：食堂菜品的用户行为矩阵非常稀疏，一个学生一天最多记录 2 条评分，协同过滤做出来效果反而不稳定。我采用的方案是“标签匹配 + 群体评分反馈”的混合式推荐，核心是基于内容的思路加上少量群体智慧。整体计算流程如下：用户请求推荐，获取当前用户 id；查出用户的 user_preference 偏好映射表，拿到每个标签的权重；查出所有上架菜品，遍历每个菜品，取出它的标签集合；根据用户偏好权重计算标签匹配分；查该菜品在 rating 表的平均分和评分总数；计算最终得分：finalScore = 标签匹配分 * 0.6 + 标准评分 * 0.3 + 热度分 * 0.1；按 finalScore 降序排列，取前 10 条返回。权重比例 0.6/0.3/0.1 不是拍脑袋来的，是我用初期模拟数据反复测出来的。标签匹配分权重太高，会导致系统只推用户固有口味的菜，失去多样性；评分权重太高，则对新人友好但对老用户不够个性化。0.6 的比例在冷启动和个性化之间基本能平衡。4.2 核心Java代码实现推荐引擎的入口是一个 Service 方法，我把核心代码简化后放在下面：@Override public List<RecommendResult> recommend(Long userId, int limit) { // 1. 查询用户所有偏好标签 List<UserPreference> prefs = userPreferenceMapper.selectByUserId(userId); Map<Long, Double> prefMap = new HashMap<>(); for (UserPreference pref : prefs) { prefMap.put(pref.getTagId(), pref.getWeight().doubleValue()); } // 2. 查询所有上架菜品 List<Dish> dishes = dishMapper.selectAvailable(); // 3. 遍历菜品计算得分 List<RecommendResult> results = new ArrayList<>(); for (Dish dish : dishes) { List<DishTag> dishTags = dishTagMapper.selectByDishId(dish.getId()); // 标签匹配分 double tagScore = 0.0; int matchedTagCount = 0; for (DishTag dt : dishTags) { Double weight = prefMap.get(dt.getTagId()); if (weight != null) { tagScore += weight; matchedTagCount++; } } if (matchedTagCount == 0) { tagScore = 0.1; // 没有任何标签匹配时给低分而非零分 } // 群体评分分 RatingStat stat = ratingMapper.selectAvgByDishId(dish.getId()); double avgScore = stat == null ? 3.0 : stat.getAvgScore().doubleValue(); double ratingScore = avgScore / 5.0; // 热度分：评分人数占总人数比例 long totalRatings = stat == null ? 0 : stat.getTotalCount(); double hotScore = Math.min(1.0, totalRatings / 50.0); double finalScore = tagScore * 0.6 + ratingScore * 0.3 + hotScore * 0.1; results.add(buildRecommendResult(dish, finalScore, matchedTagCount)); } // 4. 排序取TopN results.sort((a, b) -> Double.compare(b.getScore(), a.getScore())); return results.stream().limit(limit).collect(Collectors.toList()); }这段代码里有一个小细节容易被忽略：tagScore计算时，如果用户对某个标签有偏好的同时又有忌口标签，权重会互相抵消。所以 user_preference 表的 weight 我允许存小于 0.5 的值（实际上可以设为 0.1 或 0.05），这样“蒜蓉”和“少辣”这类冲突标签才能正确对冲。对应的 MyBatis XML 里，selectAvgByDishId 的 SQL 是这样写的：<select id="selectAvgByDishId" resultType="com.campus.diet.entity.RatingStat"> SELECT AVG(score) AS avgScore, COUNT(*) AS totalCount FROM rating WHERE dish_id = #{dishId} </select>单条执行没问题，但如果在 recommend 里对 50 道菜都执行一次，会产生 50 次数据库往返。优化方案是在遍历前一次性查出所有菜品的评分统计，用 Map 缓存。4.3 冷启动与热门兜底策略冷启动是所有推荐系统都逃不开的问题。新用户没有评分记录，偏好只有注册时勾选的那几个标签；新菜品没有任何评分，会被热度分和评分分压得很低。我的处理策略是三层兜底：新用户只按初始标签匹配分排序；如果用户连初始标签都没有，系统直接返回“热门菜品榜”，即按评分数总量排序；新菜品在固定时间内赋予一个初始评分权重（模拟评分为 4.2 分），保证它有机会出现在推荐列表里。这个策略虽然简单，但实测下来用户体验不错，没有出现“推荐完全不认识”的突兀感。如果你要扩展，可以把“热门菜品榜”做成一个独立的接口，前端在推荐卡片流下方加一个“大家都爱吃”的横向滚动栏，两个数据源互不干扰。5. 后端接口与Vue前端联调的完整链路5.1 核心接口列表与权限设计后端接口我遵循 RESTful 风格，统一返回结构是Result<T>，里面包含 code、message、data 三个字段，配合全局异常处理器，前端不用每个接口单独写 try-catch。接口方法权限说明/api/auth/loginPOST公开登录获取JWT/api/auth/registerPOST公开学生注册/api/recommendGET学生获取推荐菜列表/api/dishesGET全部分页查询菜品/api/dishes/{id}GET全部菜品详情/api/ratingPOST学生提交评分评论/api/preferencesPUT学生更新饮食偏好/api/admin/dishPOST/PUT/DELETE管理员菜品管理接口/api/admin/stats/topGET管理员热门菜品统计权限方面我用 JWT + 拦截器实现，登录成功返回 token，前端把 token 存在 localStorage，每次请求在 axios 拦截器里加 Authorization。没登录访问受保护接口返回 401，前端路由守卫统一跳转登录页。5.2 Vue组件与前端请求封装的落地细节前端 axios 封装是项目体验的关键。我直接贴出核心的 request.js，这套写法可以复用到任何项目里：import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }, error => Promise.reject(error)) service.interceptors.response.use(response => { const res = response.data if (res.code !== 200) { // 业务错误统一提示 Message.error(res.message) if (res.code === 401) { router.push('/login') } return Promise.reject(new Error(res.message)) } return res.data }, error => { Message.error('网络异常') return Promise.reject(error) }) export default service需要注意两点。第一，baseURL 用了/api，但开发环境后端跑在 8080，前端跑在 8081，所以需要在 vue.config.js 里配置 devServer 代理把/api转发给 8080，同时解决跨域问题。第二，响应拦截器里我先判断业务 code 再返回 res.data，这样组件里调用时拿到的直接是后端业务数据，不需要再解一层壳。5.3 推荐结果的展示与交互推荐页的 UI 我用了卡片流布局，每张卡片展示菜品名称、图片、价格、综合得分，以及一条推荐理由。这个推荐理由是前端根据后端返回的 matchedTags 拼接的，比如“匹配你喜欢的辣味、荤菜标签”。卡片组件中比较重要的是评分弹窗。学生在卡片上点击“吃过了”，弹窗里展示五个星星，提交后调用 POST /api/rating，刷新推荐流。这里有个交互细节，推荐列表在用户评分后应该局部更新而非整体刷新。我在前端把推荐结果维护在 Vuex 的 recommendList 中，评分成功后直接替换对应卡片的状态，避免抖动。管理员的菜品管理页就相对常规，Table + Dialog 表单 + 标签多选，Element UI 的 el-tag 组件配合可输入下拉框，基本能满足需求。6. 上线部署与实操中踩过的坑6.1 项目打包与一键部署本地跑通很容易，真正上手部署时才发现几个问题。后端打包用 Maven 执行mvn clean package -DskipTests，生成 jar 包后放到服务器，执行nohup java -jar campus-diet.jar > log.file 2>&1 &即可。前端执行npm run build生成 dist 目录。部署方式上，我强烈建议前端 dist 文件不要单独配 Nginx 虚拟主机，直接把 dist 目录拷贝到后端项目的src/main/resources/static/下，让 SpringBoot 自己托管静态页面。这样整个项目只有一个 jar 包，部署成本最低，还能复用同一个端口，避免跨域问题。当然，如果并发量上来要走 CDN 或静态资源分离，再拆 Nginx 也不迟。数据库初始化时要注意，mysqldump 导出的 sql 文件直接执行经常出现编码问题。我统一用SET NAMES utf8mb4开头，并在连接字符串里加上characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai，三处对齐才彻底解决中文乱码。6.2 常见故障排查手册这里整理几张我在开发中真实踩过的坑，希望能给你省点时间。推荐接口响应慢：第一版 recommend 方法在循环里执行 50 次 rating 统计查询，平均耗时 800ms 以上。优化方式上面说过了，一次性查出所有菜品统计用 Map 缓存，接口降到了 80ms 以内。如果你的菜品量上千，建议再在 dish 表的 category、status 上建复合索引。图片上传路径问题：菜品图片我存的是相对路径，例如/uploads/dish/xxx.jpg。开发环境直接放在磁盘目录，生产环境通过配置项注入。如果出现图片加载不出来，先看后端日志里有没有“Path not found”，多半是没有设置静态资源映射。一个简单的做法是在 WebMvcConfigurer 里添加registry.addResourceHandler("/uploads/**").addResourceLocations("file:" + uploadPath)。JWT过期后前端白屏：token 过期是异步发生的，用户正在一个页面停留很久，点击操作突然返回 401，此时如果直接跳转登录页会丢失当前页面状态。我优化成了弹窗提示“登录已过期，请重新登录”，用户确认后再跳转，体验好很多。MySQL时区问题：所有时间字段都定义成 datetime，后端实体用 LocalDateTime，加上 serverTimezone=Asia/Shanghai 基本没问题。但要注意 SpringBoot 的 Jackson 序列化 LocalDateTime 默认格式是数组，需要配置spring.jackson.date-format或者加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。前端打包后路由刷新404：这是 Vue Router 的 history 模式问题。如果你用了 history 模式，Nginx 或 SpringBoot 对未知路径会直接 404。我生产环境为了省事直接改用 hash 模式，刷新就不会出问题；如果一定要 history 模式，需要后端把所有非接口路径都转发到 index.html。6.3 后续可以继续扩展的几个思路整个系统跑通之后，我还在琢磨几个扩展方向，一并分享给你。一是把推荐接口做成异步任务。每天凌晨根据前一天的评分数据离线计算一份“个人推荐表”，存到一张 recommend_result 表里，用户白天请求直接查表。这样权重比例再复杂也不影响接口性能，只是牺牲了一点实时性。二是接入真实的食堂消费数据，用支付记录代替手动评分，作为隐式反馈信号。三是用 Redis 缓存热门榜、标签匹配分，缓存穿透用空值缓存兜底。这些扩展都可以在现有架构上平滑实现，不会推翻重来。如果你正准备拿这个项目做毕设或课设，我的建议是先把第 3 章的数据库表和核心推荐 SQL 吃透，再按照第 4 章的代码一步步跑通。有很多人一上来就想加协同过滤，结果数据量不够效果差，最后还把项目搞复杂了。基于标签的推荐在这个体量下已经是性价比最高的方案，等数据攒够了再迭代也不迟。做项目最重要的是每一步都能解释清楚“为什么这么做”，这份逻辑比代码本身更有价值。