基于SpringBoot+Vue+MyBatis的高校饮食推荐系统设计与实现

做校园信息化系统这块有年头了，我见过最多的一类项目就是“食堂点餐”和“菜品展示”，但说实话，纯展示的价值很有限。学生每天面对十几个窗口、几十个菜品，真正缺的不是信息，而是怎么在最短时间里找到“今天吃什么”的答案。这套企业级高校学生饮食推荐系统管理系统，就是围绕这个真实问题来做的：后端采用SpringBoot+Vue+MyBatis架构，数据落库在MySQL数据库，前端走Vue组件化路线，把“饮食推荐引擎”和“后台管理系统”两件事合并到一个完整项目里。源码是完整版，覆盖多角色登录、菜品管理、标签筛选、推荐分发、收藏评价等核心功能，跑起来就能改，非常适合做毕业设计、课程设计，也很适合刚接触前后端分离工程的开发者当作一份可参考的系统蓝本。

1. 项目背景与目标拆解

1.1 校园饮食场景的三个真实痛点

第一个痛点是无从选择。高校食堂档口多、菜品杂，同一个窗口今天和明天卖的菜还不一样，学生到了饭点经常在几个窗口之间来回徘徊，最后凭感觉随便点一个，体验并不好。

第二个痛点是信息不对称。菜品有没有辣、是不是荤菜、属于哪个菜系、热量高不高，这些信息学生往往要走到窗口前抬头看菜单才知道。如果这些信息提前结构化、标签化，学生就能在手机上先筛一遍，到了食堂直接取餐，效率会高很多。

第三个痛点其实在管理侧。食堂档口和后勤管理人员需要知道哪些菜品卖得好、哪些菜品长期滞销，需要一个统一的后台来维护菜品上下架、调整推荐位、查看基本统计。很多校园场景里的早期系统只做了点餐，却没有给管理端留入口，导致菜品数据常年不更新，推荐准确度自然越来越差。

这套系统的设计目标就是同时解决这三件事：给学生一个能筛选、能推荐、能收藏评价的前端，给管理员一个能维护菜品、配置标签、查看推荐效果的后台，再通过数据库表结构的合理设计把两边串起来。

1.2 系统定位：推荐引擎与管理后台的一体化

我把它定位成“一体化”的系统，而不是单独的“点餐小程序”或者“菜谱网站”。

面向学生的用户端，核心功能包括：浏览菜品列表、按标签筛选、查看“为你推荐”的结果、收藏喜欢的菜品、提交评价和口味偏好。这个端重点解决“推荐”问题，界面要轻量，操作要快。

面向管理员的后台端，核心功能包括：菜品的新增与编辑、菜品上下架、分类管理、标签维护、推荐位的开启与关闭、用户评价查看。这个端重点解决“管理”问题，界面可以重一些，但功能要全。

“企业级”这个说法在标题里不是噱头，它主要体现在三点：一是多角色权限体系，学生和管理员走完全不同的功能入口；二是标准的前后端分离结构，以后要拆成微服务、要加新的客户端，不用推倒重来；三是数据库设计预留了扩展空间，比如用户偏好表、推荐记录表，后续接更复杂的推荐算法时有数据可以支撑。

2. 技术架构与选型思路

2.1 为什么是SpringBoot+Vue+MyBatis这套组合

这是一套非常成熟的“标准款”组合，放在中小型管理系统里安全、可控、资料多。

先看后端。SpringBoot解决了传统SSH框架里大量XML配置的痛点，内嵌Tomcat容器，打包后一个jar就能跑起来。对于校园饮食推荐这个量级的系统，它的启动速度和开发效率都让人舒服。既然标题明确了“MyBatis架构”，那就离不开灵活写SQL的能力。饮食推荐系统里有大量多条件组合查询的场景，比如“不辣+荤菜+川菜”，原生MyBatis的动态SQL写起来很直观，优化空间也大。

前端选Vue，看中的是组件化开发和渐进式上手难度。页面级的复用、路由管理、状态管理都有成熟的生态，配合Element UI这类组件库，表格、表单、弹窗等后台管理界面能快速搭建。相比React，Vue的中文资料和踩坑记录更丰富，对初学者友好，对团队协作也友好。

MySQL数据库在这里不是“随便选的”，是因为这类系统的数据量级根本不需要上重型数据库，MySQL在读写性能、运维成本和工具链成熟度上都是最稳的选择。一台普通服务器就能扛住几千个学生的日常访问。

提示：如果完全从零开始又希望少写样板代码，可以考虑用MyBatis-Plus替换原生MyBatis，但核心架构不变。标题既然说的是MyBatis架构，本文示例按原生MyBatis来写，两种方式在表结构设计上完全通用。

2.2 前后端分离的架构分层

项目整体分为三层：前端Vue工程、后端SpringBoot工程、MySQL数据库。

后端内部按标准分层拆包，我习惯这样组织：

com.example.campusdiet ├── controller // 接收 HTTP 请求，参数校验 ├── service // 业务逻辑，推荐算法核心 ├── mapper // MyBatis 数据访问接口 ├── entity // 数据库实体类 ├── common // 统一返回体、异常处理、工具类 └── config // 拦截器、跨域配置等

前端按Vue标准结构组织：

src ├── api // 封装 axios 请求 ├── router // 路由配置 ├── views // 页面组件 ├── components // 公共组件 ├── store // 状态管理 └── utils // 工具函数

前后端通过RESTful API + JSON格式通信。后端不关心页面长什么样，只返回数据；前端不关心SQL怎么写，只根据接口文档渲染页面。这种分离带来的直接好处是，以后如果想做小程序端或者App端，后端接口可以复用，不需要重新开发。

2.3 推荐引擎的轻量级落地方案

在校园饮食场景里，我不建议一上来就堆复杂算法。用户量和菜品数量都是千级、万级规模，协同过滤这类算法不是不能用，而是工程成本高、收益不明显。这里采用了一套“标签匹配 + 热门兜底 + 随机补充”的轻量级推荐方案。

核心思路是：把菜品的特征抽象成标签，把学生的选择行为映射成对标签的偏好，然后通过标签重叠度给菜品打分，最后结合销量和评价做排序。

这样做的好处很明显：算法逻辑清晰，出问题容易排查；依赖的只有MySQL，不需要额外引入Redis、Elasticsearch等组件；后续想升级算法时，数据模型并不需要推翻重来。

3. 数据库设计：饮食推荐系统的地基

3.1 核心数据表拆解

数据库设计是整个系统里最不能图省事的部分，后期所有推荐逻辑、筛选逻辑、统计逻辑都建立在表结构之上。我按业务模块拆成以下核心表：

用户表(user)：字段包含用户ID、用户名、密码、昵称、角色标识、创建时间。角色标识用整型区分学生和管理员，建议不做太复杂的权限模型，够用就好。

菜品表(dish)：主键dish_id，菜名、价格、所属档口、分类ID、封面图URL、描述信息、销量、评分、上下架状态、逻辑删除标记。上下架状态和逻辑删除标记是管理系统里必须有的两个字段，前者控制前台是否展示，后者避免误删导致历史数据丢失。

分类表(category)：用于一级归类，比如“川菜”“粤菜”“面食”“快餐”等。

标签表(tag)：用于描述菜品特征，比如“微辣”“重辣”“素食”“高蛋白”“低卡”。标签体系和分类不是一回事，分类是固定维度，标签是灵活特征，同一个菜可以属于“川菜”分类，同时拥有“重辣”“荤菜”多个标签。

菜品-标签关联表(dish_tag)：多对多关系需要中间表来解耦，这也是推荐系统做匹配的关键表。

收藏表(favorite)：记录哪个学生收藏了哪个菜品，收藏时间是重要数据，后续可以用来训练个人偏好。

评价表(comment)：记录学生对菜品的评分和文字评价，评分会同步影响菜品的综合评分字段。

3.2 关键表关系与索引设计

菜品和标签的关系是典型的多对多，通过dish_tag中间表建立联系。学生和菜品的关系通过收藏表、评价表来体现。

索引设计方面有几个关键点。一是菜品表的下架状态、分类ID要建索引，因为前台列表页查询基本都带着这两个条件。二是dish_tag表的tag_id和dish_id都需要建索引，这两个字段是推荐逻辑里最频繁的查询条件。三是收藏表的user_id要建索引，用户查看自己收藏列表时走索引会快很多。

给菜品打标签的SQL关联查询大概是这样的：

SELECT d.dish_id, d.dish_name, d.price, t.tag_name FROM dish d LEFT JOIN dish_tag dt ON d.dish_id = dt.dish_id LEFT JOIN tag t ON dt.tag_id = t.tag_id WHERE d.status = 1 AND t.tag_name IN ('微辣', '荤菜') GROUP BY d.dish_id HAVING COUNT(DISTINCT t.tag_id) >= 2

这个查询的核心逻辑是：先把启用的菜品关联到对应标签，然后筛选出同时包含“微辣”和“荤菜”两个标签的菜品。HAVING子句在这里起到“必须全部匹配”的效果，这在多标签筛选场景里非常常用。

3.3 数据初始化与菜品标签体系

数据初始化是这类系统跑起来之后效果好不好看的决定性因素。很多项目做出来以后不好演示，就是因为库里只有三五条测试数据，学生端打开列表页面一片空白，推荐界面更是无从谈起。

初始化数据至少需要包含：20到30个菜品、5到8个分类、10个左右的标签、以及每道菜对应的标签关系。标签体系建议按五个维度来建：口味维度（不辣、微辣、重辣）、荤素维度（荤菜、素菜）、菜系维度（川菜、粤菜、东北菜）、营养维度（高蛋白、低卡、全素）、场景维度（快手餐、轻食、饱腹感强）。

初始化语句用INSERT批量插入，同时写入dish_tag关联关系。学生端第一次打开时，即使还没有任何用户行为数据，也能通过默认热门推荐把界面填充起来。

4. 后端核心模块实现要点

4.1 登录鉴权与角色权限

登录模块是用户端的入口，也是管理端的门槛。项目采用JWT做无状态鉴权，登录成功后后端返回token，前端把token存在本地，之后每次请求在请求头里带上。

后端的拦截器会统一解析token，拿到用户ID和角色信息，然后决定当前请求是否有权限访问。学生和管理员的接口需要有清晰的分界线，管理端接口统一加/admin前缀，拦截器里对这个前缀做角色校验。

密码不能明文存库，用BCrypt加密。这个细节很多初学项目会忽略，但正规管理系统里属于必备要求。BCrypt的特点是对同一个密码每次加密结果都不同，即使数据库泄露，原始密码也不容易被反推。

4.2 菜品管理与多条件检索

管理端的菜品管理接口包括：新增菜品、编辑菜品、上下架菜品、按条件分页查询菜品列表。

学生端最常用的多条件检索是“分类 + 标签 + 关键词”的组合。商品名称和分类是固定条件，标签数量是动态的，用户勾选了哪几个标签，SQL里就动态拼哪几个。MyBatis的动态SQL在此时就非常顺手：

<select id="searchDishes" resultType="com.example.campusdiet.entity.Dish"> SELECT d.* FROM dish d WHERE d.status = 1 <if test="categoryId != null"> AND d.category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND d.dish_name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="tagIds != null and tagIds.size() > 0"> AND d.dish_id IN ( SELECT dish_id FROM dish_tag WHERE tag_id IN <foreach collection="tagIds" item="tagId" open="(" separator="," close=")"> #{tagId} </foreach> GROUP BY dish_id HAVING COUNT(DISTINCT tag_id) = #{tagIds.size} ) </if> ORDER BY d.sales DESC </select>

这段SQL的逻辑是：关键词走模糊匹配，分类走精确匹配，标签走子查询并要求全部命中。销量排序保证没有特殊偏好时，学生看到的是大家都在吃的菜。实际使用中这个查询响应速度很快，索引覆盖到位的情况下毫秒级返回。

4.3 推荐逻辑的落地方案

推荐接口是这个项目最有看点的部分。我在实现时把它拆成了三步。

第一步，计算用户的标签偏好分。用户收藏过的菜品、评价过的菜品，每个都带着标签，累计计数后可以得到一个“用户标签权重列表”，权重越高代表越喜欢。

第二步，计算菜品的推荐得分。每道菜的标签和用户偏好标签做重叠匹配，重合的都是重点加分项。计算公式可以理解为：推荐分 = 菜品与用户偏好重合的标签数 × 标签权重 + 菜品本身的基础分（包含销量权重和评分权重）。实际代码里为了避免菜品过期下架导致推荐空列表，还要加一个兜底条件：如果推荐结果不足10条，就从销量最高的菜品里补足。

第三步，洗牌和返回。为了不让学生每次打开看到的顺序完全一样，在推荐结果确定后做一次轻度乱序，只改变展示顺序，不改变分组。

核心计算代码示意如下：

public List<DishVO> recommendForUser(Integer userId, int limit) { // 1. 获取用户的标签偏好 Map<Integer, Integer> tagPreference = favoriteService.countUserTagPreference(userId); // 2. 如果用户没有偏好数据，直接返回热门菜品 if (tagPreference.isEmpty()) { return dishMapper.selectHotDishes(limit); } // 3. 按标签匹配度给所有上架菜品打分 List<DishVO> dishes = dishMapper.selectAvailableDishes(); List<DishScore> scored = new ArrayList<>(); for (DishVO dish : dishes) { double score = calculateMatchScore(dish.getTagIds(), tagPreference); score += dish.getSales() * 0.01 + dish.getAvgScore() * 0.2; scored.add(new DishScore(dish, score)); } // 4. 排序 + 补足 + 轻度随机 scored.sort((a, b) -> Double.compare(b.getScore(), a.getScore())); List<DishVO> result = scored.stream().limit(limit) .map(DishScore::getDish).collect(Collectors.toList()); fillWithHotDishesIfNeeded(result, limit); Collections.shuffle(result); return result; }

有一个容易忽略的细节：一个学生如果只用过一两次收藏，偏好标签非常稀疏，直接走推荐会导致结果偏向单一类型。我的处理方式是设置一个“最少行为次数阈值”，比如收藏或评价记录少于3条时，优先走热门推荐，而不是强行推荐。

4.4 接口设计与统一返回体

前后端联调最怕接口返回格式不统一，前端每个请求都要单独判断成功失败，体验很糟糕。这个项目里我统一封装了一个Result类：

public class Result<T> { private Integer code; private String message; private T data; // 成功、失败等静态方法... }

code为200表示成功，其他为业务异常码。前端axios封装里统一拦截code，非200状态直接弹错误提示。接口地址按模块划分，便于维护。整体接口列表大致如下：

接口设计上有个原则：学生端所有接口都要求登录后才能访问，但推荐接口要看用户身份灵活处理，未登录时返回默认热门推荐，登录后返回个性化推荐。这样用户体验不会因为登录问题被打断。

5. 前端Vue页面与交互实现

5.1 页面框架与路由设计

前端页面分两条线，学生端和管理端。

学生端页面包括：登录注册页、首页推荐页、菜品列表页、菜品详情页、收藏页、个人中心。首页推荐页是流量核心，进入后默认展示推荐结果，顶部放分类筛选和标签筛选入口。

管理端页面包括：登录页、工作台、菜品列表管理页、菜品编辑页、分类管理页、标签管理页、评价管理页。

路由设计最关键的是权限控制。Vue Router的全局前置守卫会在每次路由跳转前检查token和用户角色，如果访问管理端页面但角色不是管理员，直接重定向到学生端首页。这里要注意一个问题：路由守卫里容易写出死循环，跳转逻辑必须设置好“当前已经要去的是哪个页面”这个条件，避免两个路由互相跳来跳去。

5.2 推荐结果展示与筛选交互

推荐页面的交互可以做得比较细腻。页面结构是顶部搜索栏、中间标签筛选区、下方菜品卡片流。

筛选交互上，标签采用“多选联动”的方式：选定“不辣”后，可选的其他标签里与“不辣”冲突的（比如“重辣”）自动置灰。这个体验在真实使用里非常加分，学生筛选时不会选出一组没有结果的组合。

接口请求封装时，axios拦截器统一附加token、统一处理错误码：

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) { Message.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error => { Message.error('网络异常，请稍后重试') return Promise.reject(error) } )

菜品卡片上展示菜品图、名称、价格、档口、标签、评分，右下角有两个快捷操作按钮：收藏和“看详情”。列表页做了下拉分页加载，滚动到底部自动加载下一页，这个交互比传统的点击翻页更适合手机端使用习惯。

5.3 后台管理界面的权限控制与CRUD

管理端界面的核心是表格页的增删改查。菜品管理页面使用Element UI的表格组件展示数据，顶部是搜索表单和新增按钮，行内放编辑、上下架操作按钮。

表单校验是管理端最容易暴露问题的地方。菜品名称必填、价格必须是大于0的数字、图片URL必须符合格式，这些校验规则用Element UI的表单校验规则就能实现。但要注意，价格输入框里用户可能输入"12.5元"这样的字符串，前端校验通过后后端还要再做一层兜底校验，尽量在请求DTO里用注解加校验。

管理端权限控制的难点在于菜单的按需渲染。普通学生访问管理端页面时，不仅路由要拦截，页面左侧菜单栏也不能显示管理入口。我的做法是根据登录接口返回的角色字段动态生成菜单数据，管理员多渲染一组“系统管理”菜单，学生只渲染个人功能菜单。

新增菜品表单里的图片处理也值得一提，项目里没有选择文件上传到对象存储，而是采用图片URL直填的方式。这样简化了部署成本，不需要额外搭建文件服务，但要做好图片地址的格式校验。

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

6.1 本地运行需要改哪些配置

拿到源码以后从零跑起来，最核心的操作就是三件事：建库、改连接、启动前后端。

先创建数据库并导入初始化脚本：

mysql -u root -p < campus_diet.sql

然后修改后端的application.yml配置文件，调整数据库连接信息：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/campus_diet?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.campusdiet.entity

前端进入项目目录安装依赖并启动开发服务：

npm install npm run dev

很多新人在这一步会踩坑。npm install报错通常有几种情况：Node版本太高或太低、网络源不稳定、依赖包版本冲突。我的建议是Node使用16到18这个区间，使用国内镜像源安装依赖。后端启动时要注意JDK版本，SpringBoot 2.x配JDK 8或11都很稳定，配JDK 17可能遇到兼容性问题。

6.2 常见报错与解决办法速查

整个联调阶段我遇到和帮别人排查过的问题不少，整理成一张速查表，遇到类似情况可以直接对照处理。

其中跨域问题在前后端分离场景下是必然遇到的。开发环境最简单的方式是在后端写一个全局CORS配置类，允许前端地址跨域访问。生产环境一般通过Nginx反向代理解决，让前端和后端使用同一个域名，通过不同路径区分。

6.3 一些实操心得

第一次把推荐分数算歪的时候，我排查了很久才发现问题不在算法，而在标签权重累计逻辑。用户如果对某道菜连续收藏多次，这个菜的标签权重会重复累加，看起来合理，实际上会让单道菜主导整个推荐列表。后来把收藏去重后再累计权重，结果就正常了。类似的隐藏问题在业务里多得是，最好的排查方式是打印出中间数据，把每一步计算过程放出来，别只看最终结果。

还有个细节是数据库字段名大小写。MySQL在Windows和Linux下对表名、字段名的大小写敏感度不一样，如果实体类字段和数据库字段映射不上，启动时可能不会报错，但查询结果全是null。解决方式是MyBatis配置下划线转驼峰映射，并在写SQL时为每个字段指定别名，实体类字段与表字段严格对应。

图像资源的处理，如果不想引入文件服务器，建议图片链接指向一个统一的静态资源目录，后台上传时保存到本地目录，通过虚拟路径映射对外访问。这样比直接填第三方图床链接更可控，至少不会因为外链失效导致菜品卡片大面积破图。

这套系统后续要扩展也不是难事。推荐算法可以从标签匹配升级到基于协同过滤的用户相似度推荐，只需要在偏好数据表里增加更多行为记录；高并发场景下可以引入Redis做热点菜品的缓存，把推荐结果缓存起来，数据库压力会明显下降；管理端需要看趋势报表的话，可以在评价表和收藏表上做简单的聚合统计，前端配几个图表组件就能展示。

如果是从毕业设计或者课程设计的角度来用这份源码，我的建议是先跑通主流程，理解清楚“后端返回什么数据、前端怎么渲染、数据库怎么存储”这三层关系，然后挑一个模块深挖改造。比如把推荐逻辑改成协同过滤，或者给管理端加一个销售统计图表，都是比较亮眼的优化方向。系统本身是一块很标准的样板田，往哪个方向深耕都有空间。