SpringBoot+Vue3美食网站系统：前后端分离实战项目解析

1. 项目定位与核心价值

1.1 这套美食网站究竟长什么样

搞Java后端这些年，带过不少新人，也看过很多课程项目。一个特别普遍的现象是：很多东西单独拎出来都会，SpringBoot能跑，Vue3能配，MyBatis会写，但把三个凑成一个完整的前后端分离网站系统，就卡壳了——不是不知道接口怎么定，就是被跨域折腾半天，要么建表建得随心所欲，联调时改来改去。

这篇要聊的是一套实际能跑的BS架构（浏览器/服务器架构）美食网站系统。后端用Java + SpringBoot，数据访问层用MyBatis，数据库是MySQL，前端用Vue3 + Vite + Element Plus，前后端之间通过RESTful接口通信，身份认证走JWT。整个项目覆盖了一个完整互联网站从零到上线所需要的大部分环节：数据库建模、服务端接口设计、用户注册登录、前台内容展示、后台数据管理。

它做的具体事情很直白：用户打开浏览器，可以看到首页推荐的各种菜品，按分类筛选食物，点进详情页看用料和制作步骤，登录后可以收藏喜欢的美食、发表评论；管理员则从另一个入口登录后台，维护菜品信息、管理分类和用户。看起来是个小型网站，但它五脏俱全，前端有路由和状态管理，后端有分层架构和安全控制，属于典型的“教学用得上、面试讲得出、二次开发跑得动”的完整源码项目。

1.2 主角是美食，但骨架是全栈分离

选美食这个垂直领域是有讲究的。纯CRUD的“学生管理系统”“图书管理系统”已经烂大街了，面试官一眼就能看出来是照着模板抄的。美食网站不一样，它的业务逻辑虽然不复杂，但功能面足够宽：菜品分类有层级关系，搜索有条件拼接，收藏有用户关联，评论有时间排序，后台有图片上传。这些恰好是前后端分离项目里最常见的通用场景。

更关键的是，美食主题让整个开发过程不那么枯燥。你在设计数据库的时候，脑子里想的是“麻辣香锅到底放哪个分类”，而不是对着“用户表加个字段叫remark”发呆。项目如果连开发者自己都觉得无聊，那写到一半放弃的概率就会直线上升。选一个自己真正愿意研究的东西作为载体，听起来像玄学，但确实是能跑完项目和烂尾项目之间最现实的区分点之一。

这套系统适合三类人：正在准备毕业设计的在校生，想从纯前端或者老PHP/C#技术栈转Java全栈的工程师，以及学完基础语法但不知道如何串起来做个完整东西的初学者。如果你已经在公司写过一两年业务代码，那这套系统的技术深度可能满足不了你，但它作为梳理前后端分离通用套路的参考价值，依然值得翻一翻。

2. 技术选型背后的关键决策

2.1 SpringBoot版本选择，一个容易翻车的地方

做Java后端，SpringBoot版本这事我吃过亏。热词里有一条“springboot版本太高”，简直说到心坎里了。SpringBoot 3.0之后，Java版本要求直接跳到JDK 17，很多人的电脑上还装着JDK 8，Maven也配的旧版本，结果项目一导入，全是红叉，不是“不支持发行版本5”就是“程序包org.springframework.boot不存在”，最后折腾半天，把版本降回2.7.18就一切正常。

这套美食网站源码用的是SpringBoot 2.7.x，搭配JDK 8/11都没问题，属于目前生态最成熟的组合。说实话，如果不是有硬性的新特性需求，新手项目选2.7.x是性价比最高的决定，教程最多、兼容性最好、网上踩坑记录也最全。你拿3.x去做毕业设计，不仅导师未必懂，自己排查问题的难度也会翻倍。

版本对应关系：

你拿到源码第一步，先检查自己的JDK版本。命令行输入java -version，是1.8版本就放心跑2.7.x；如果已经装了17，那也建议为了这个项目临时装一个8的JDK，切换环境，而不是反过来去升级项目依赖。我见过太多人把时间浪费在“升级依赖—报错—查半天—再升级”的循环里，最后项目没跑起来，心态先崩了。

2.2 MyBatis还是MyBatis-Plus，为什么不用JPA

ORM框架选型，是Java项目里最容易被低估的决策。JPA/Hibernate这类全自动框架，写起来舒服，实体类一映射，表自动建了，增删改查都有默认实现，但它们有个致命问题：复杂查询时SQL不好控，而且一旦使用不当，N+1查询能把数据库拖垮。如果你问团队里干了七八年的老Java，大多数人对JPA的态度都是“能用但不敢乱用”。

MyBatis和MyBatis-Plus则相反，SQL是明文写在Mapper XML里的，你完全知道每一条查询在干什么。面试的时候，MyBatis也是问得最细的一个话题，缓存机制、动态SQL、参数映射，随便一问就能看出候选人到底是背了笔记还是真的写过大半年项目。

这套系统选择的是纯MyBatis。为什么不用MyBatis-Plus？核心原因是教学场景下，我希望把SQL的控制权攥在手里，毕竟动态SQL和结果映射才是MyBatis的精髓所在。Plus虽然把单表CRUD封装到了极致，甚至能根据Java实体类生成创建表的SQL语句，但这种便利性容易让新手跳过SQL这一步，后面一旦遇到复杂多表查询，照样露馅。用MyBatis，你会发现自己在写SQL的过程中，真的在读数据，真的在理解表结构，这是被框架包裹住的时候体会不到的。

2.3 Vue3 + Vite + Element Plus组合的正确性

前端部分选Vue3，其实不需要太多纠结。Vue2已经停止维护，新项目再不用Vue3就是给自己挖坑。真正需要想清楚的是构建工具：Vite还是Webpack。Vite的开发服务器启动速度是真的快，因为它按需编译，不像Webpack那样一启动就要把整个项目都打包一遍。对这个美食网站来说，页面不算多，Webpack那几分钟的启动时间可能感觉不明显，但开发体验上的流畅感是实实在在的。

Element Plus是Vue3对应的UI组件库，后台管理系统那种表格加表单的界面，用组件库能省掉80%的样式时间。有一点需要提醒，Element Plus的组件建议按需引入，不要一股脑全量注册，否则最终打包体积会大上很多，首屏加载速度也会受影响。很多人在项目里用全量引入，图省事，结果打包出来一个2MB的js文件，就是没考虑这一点。

Vue3的核心概念里，ref和reactive是绕不开的。很多新手踩过一个坑：用reactive定义了一个对象，然后在某个方法里直接整个把它替换掉，结果发现页面不更新。这是因为reactive返回的是代理对象，你把它赋值成一个新的普通对象，代理关系就断了。后来我才彻底想明白，简单场景用ref就不会有这个问题，但凡是对象嵌套比较深、需要整体替换的场景，要么用ref包一层，要么用reactive时永远通过.field = xxx的方式改属性，而不能整体赋值。这套系统里我用ref比较多，就是为了少踩这个坑。

2.4 MySQL单库在这个体量下够用了

后端存储这块，很多人一上来就考虑Redis缓存、Elasticsearch搜索，但对一个菜品几百上千条、用户量几千级的网站来说，这是典型的过度设计。MySQL单库单表，在这个数据量级下性能绰绰有余，查询加合适的索引，毫秒级返回毫无压力。

这套美食网站系统的数据库设计就是个典型的MySQL实践样本：用户表、菜品分类表、菜品表、收藏表、评论表，五张核心表外加一些辅助字段。线上部署到一台2核4G的云服务器上，跑个几百人同时访问没有任何问题。真要等哪天用户量变成几万人，再来考虑读写分离、缓存分层这些事也不迟。架构这东西，永远是为当前规模和可预见的增长服务的。

3. 核心功能拆解与数据库设计

3.1 三个角色三种权限，菜单跟着身份走

美食网站系统的用户角色很清晰：游客、注册用户、管理员。游客只能在首页和菜品列表页逛一逛，看看详情，一旦点击“收藏”或“发表评论”，前端就会弹出登录框；注册用户登录后，除了浏览，还能收藏菜品、评论、维护个人中心信息；管理员登录后台，位于另一个完全独立的界面。

前后端分离项目里，权限控制通常在两处做。前端通过路由守卫控制页面跳转，比如未登录的用户访问“收藏列表”页面，会强制重定向到登录页；后端则通过拦截器校验JWT，客户端发的请求如果没有带上有效的Token，直接返回401。这种双重防线是必要且合理的——前端的限制只服务于体验，后端的校验才是真正的安全防线。

3.2 五张核心数据表，建表SQL直接抄

数据库设计是整个系统的地基。地基打歪了，后面写多少代码都别扭。这套系统里我给出的建表思路非常简单直白，但细节上都有讲究。

-- 用户表 CREATE TABLE `sys_user` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID', `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT '密码(MD5加密)', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `avatar` varchar(255) DEFAULT NULL COMMENT '头像路径', `role` tinyint NOT NULL DEFAULT '1' COMMENT '角色:0-管理员 1-普通用户', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态:1-正常 0-禁用', `create_time` datetime NOT NULL COMMENT '注册时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; -- 菜品分类表 CREATE TABLE `food_category` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID', `name` varchar(50) NOT NULL COMMENT '分类名称', `sort` int NOT NULL DEFAULT '0' COMMENT '排序值(越小越靠前)', `create_time` datetime NOT NULL COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='菜品分类表'; -- 菜品表 CREATE TABLE `food_info` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID', `category_id` bigint NOT NULL COMMENT '所属分类ID', `name` varchar(100) NOT NULL COMMENT '菜品名称', `price` decimal(10,2) NOT NULL COMMENT '价格', `image` varchar(255) DEFAULT NULL COMMENT '菜品图片路径', `description` text COMMENT '菜品描述', `steps` text COMMENT '制作步骤', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态:1-上架 0-下架', `view_count` int NOT NULL DEFAULT '0' COMMENT '浏览量', `create_time` datetime NOT NULL COMMENT '创建时间', PRIMARY KEY (`id`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='菜品表'; -- 收藏表 CREATE TABLE `favorite` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL COMMENT '用户ID', `food_id` bigint NOT NULL COMMENT '菜品ID', `create_time` datetime NOT NULL COMMENT '收藏时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_user_food` (`user_id`,`food_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='收藏表'; -- 评论表 CREATE TABLE `comment` ( `id` bigint NOT NULL AUTO_INCREMENT, `food_id` bigint NOT NULL COMMENT '菜品ID', `user_id` bigint NOT NULL COMMENT '评论用户ID', `content` varchar(500) NOT NULL COMMENT '评论内容', `create_time` datetime NOT NULL COMMENT '评论时间', PRIMARY KEY (`id`), KEY `idx_food` (`food_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这套表结构在数据库设计上属于最基础的三范式模型，每个表之间通过ID逻辑关联。在收藏表上我特意加了一个联合唯一索引(user_id, food_id)，这是为了防止同一个用户重复收藏同一道菜——如果你不建这个唯一索引，代码里又忘了查重，数据库层面就会漏进脏数据，这个细节很容易被忽略。

3.3 建表和类型选择里那些不起眼的规范

价格字段用decimal(10,2)，不用float或double。浮点数在MySQL里存价格会出问题，比如0.1 + 0.2可能得到0.30000000000000004，虽然平时看着没事，订单金额一累计就会出现分毫误差。虽然这个美食网站不做支付，价格只是展示用，但这是一个应该养成的习惯——涉及钱，一律定点数。

菜品图片存的是路径，不是二进制。图片文件落在服务器的上传目录里，数据库的image字段只存一个相对路径。这样数据库表不会变得臃肿，查询速度快，以后把图片迁移到OSS对象存储也容易。

制作步骤用text类型。为什么不拆成单独的表？因为美食网站的做法展示通常是整块的文本，拆了反而增加关联查询的复杂度。只有当你需要“步骤支持单独评论、单步骤点赞”这类场景时，才有拆表的必要。做系统设计时，一定要先问自己“这个字段未来会被单独查询吗”，答案是否定的情况下，尽量不要过度设计。

所有表都加了create_time，这是一个小习惯，但极其重要。你永远不知道什么时候就需要查一条数据的创建时间去做统计或者排查问题。有些员工建表图省事不加，等运营想要“这个月新增了多少菜品”的时候，就傻眼了。

4. 关键实现环节与技术细节

4.1 后端分层架构与统一返回格式

后端代码我按Controller-Service-Mapper三层来组织，这是绝大多数Java后端项目的标准姿势。Controller只负责接收参数和返回结果，不写业务逻辑；Service层承载业务规则，处理事务；Mapper层只做数据库读写。这样分层的意义在于，出问题时能快速定位——前端传参不对，先看Controller；业务逻辑算错了，看Service；SQL写错了，看Mapper。

接口返回值必须统一封装，不要不同接口各返回各的格式。这套系统里我定义了一个通用的Result对象，结构是{ code, message, data }，code为200表示成功，401表示未登录，500表示服务端异常。所有接口返回的都是这个结构，前端只用解析一种格式就行，处理错误时也只用看code。

后端还有两个容易被忽略但非常影响开发体验的环节：全局异常处理和分页。全局异常处理用Spring的@RestControllerAdvice，把业务异常统一转换成Result返回，这个很省事，不然每个Controller里都要加try-catch，代码写得想吐。分页方面，列表页和后台表格都需要分页，参数是pageNum和pageSize，返回结构里包含total总数，这样前端就知道共有多少页了。

4.2 MyBatis里值得写下来的几个关键点

MyBatis是这套系统的数据访问核心。映射配置里有两个重点：第一，全局开启驼峰命名映射，数据库字段create_time能自动映射到实体类的createTime，省掉一堆resultMap手写配置；第二，复杂的多表查询、动态SQL才需要resultMap和XML里的拼接，比如菜品列表的搜索功能，要按分类筛选，又要按名称模糊匹配，用动态SQL写就是典型的<where>标签加<if>判断。

#{}和${}的区别，这是MyBatis面试必考题，也是实际开发里最容易出事的地方。我在写动态SQL时，凡是值都走#{}预编译，绝不直接拼字符串。${}只有在动态排序列名或者表名时才用，而且必须保证传参可控。你在这个系统的源码里，只要看到排序字段那种位置，都是经过前端选项白名单校验的，不会直接把用户输入拼进去。

MyBatis的缓存机制也值得多说一句。一级缓存默认开启，范围是SqlSession；二级缓存需要手动开启，范围是Mapper级别。这个美食网站的数据变化不算频繁，我开了二级缓存，因为菜品的浏览量大、写入少，缓存命中后性能提升立竿见影。但直接后果是，后台更新菜品信息时，必须显式刷新缓存，不然前台看到的还是旧数据。要不要开二级缓存，取决于你的业务到底是读多写少还是写多读少，读多写少才值得开。

4.3 前端Vue3的工程化实践与状态管理

Vue3项目使用Vite创建，命令是npm create vite@latest，选择Vue模板，然后npm install安装依赖。目录结构上，src/api统一放请求函数，src/router放路由配置，src/store放全局状态，src/views放页面组件。这是目前Vue3后台管理类项目最主流的结构，按这个组织，找文件和加功能都方便。

状态管理用的是Pinia。Vuex在Vue3时代已经算历史遗留了，Pinia更轻量，写法也更简单。这个系统里，用户登录信息、Token、昵称头像这些全局数据都放在Pinia里。登录成功后，后端返回Token，前端存到localStorage，同时把用户信息写进Pinia。请求拦截器里每次带Token，响应拦截器里如果发现返回的code是401，就清空本地存储并跳转登录页。

路由守卫是权限控制的前端半边天。router.beforeEach里检查目标路由元信息（meta），如果meta里标了requiresAuth: true，再看Pinia里有没有用户信息。没有就跳登录页，这是所有后台管理系统都会用到的通用逻辑。

Element Plus按需引入的操作是，下载unplugin-auto-import和unplugin-vue-components这两个插件，在vite.config.js里配置一下，然后组件就能自动按需加载了。如果没有这一步，全量引入Element Plus时，打包体积会明显增加不说，页面加载速度也会被拖累。

4.4 前后端如何优雅地联调

前后端分离项目最烦的过程就是联调。后端在localhost:8080跑着，前端在localhost:5173跑着，端口都不一样，直接发请求就会被浏览器跨域拦截。

开发环境解决跨域，最优雅的办法不是让后端写个CORS配置类，而是在Vite的代理配置里做转发。vite.config.js里配置server.proxy，把/api开头的请求转发到http://localhost:8080，这样浏览器的请求就都在同一个域名下了，也不会触发跨域策略。这套系统后端接口的统一前缀是/api，一部分原因就是为了配合这个代理规则，前端请求写/api/food/list，后端收到的也是这个路径，映射关系清晰直观。

不过生产环境部署时，代理就不归前端管了。线上是把前后端打出来的静态文件部署到Nginx，由Nginx把/api开头的请求反向代理到后端的服务端口。开发环境用Vite代理、生产环境用Nginx，这两者之间的差别很多新手分不清，但只要你完整部署过一次，就永远不会忘记。

联调时还有一个常见的摩擦点——时间格式。Java后端返回的时间默认是一串数字（时间戳）或者带毫秒的格式，前端展示得格式化。为了避免各自处理造成不一致，我在后端统一配置了spring.jackson.date-format，把LocalDateTime序列化成了yyyy-MM-dd HH:mm:ss的格式，前端拿到的就是人类可读的字符串，直接展示。这类约定如果能提前定好，联调能少吵好几回架。

5. 部署运行与常见问题排查

5.1 从源码到跑起来，一步一步来

你拿到源码想跑起来，并不复杂，按下面这个顺序走，每一步都能验证成功后再进行下一步。

第一步，准备好运行环境。JDK 8、Maven 3.6+、Node.js 16以上、MySQL 5.7或8.0，这四个缺一不可。MySQL的安装这里多说一句，Windows上安装5.7.44或者8.0时，注意选择UTF-8字符集，初始化数据库时把用户名密码记好，最省心的方案是下载解压版配置my.ini，不推荐用安装包默认配置，因为自定义目录和数据文件位置会牵扯很多后续权限问题。

第二步，初始化数据库。打开Navicat或者命令行，新建一个名为food_website的数据库，字符集选utf8mb4，然后把源码里提供的SQL文件导入。SQL文件里包含建表和基础示例数据，导入后验证一下，看看有没有报错，如果提示SQL语法问题，大概率是MySQL版本太旧，建议升级到5.7以上。

第三步，配置后端。用IDEA打开后端项目，等Maven把依赖下载完，修改src/main/resources/application.yml里的数据库账号密码，保证和本机MySQL一致。然后启动主类，看到“Started Application in X seconds”的日志就说明启动成功了。此时浏览器访问http://localhost:8080/api/food/list?pageNum=1&pageSize=10，应该能返回JSON格式的菜品列表数据。

第四步，启动前端。命令行进入前端目录，npm install安装依赖，然后npm run dev启动开发服务器。浏览器访问http://localhost:5173，能看到首页渲染出菜品数据和图片，说明前后端已经联通。

第五步，验证登录和后台。先在前台注册一个普通用户，然后登录，尝试收藏一道菜和发一条评论。再用管理员账号登录后台，看能不能在后台修改菜品数据。这一套流程走通，项目就算完全跑起来了。

5.2 我实际踩过的坑，整理成速查手册

开发这类前后端分离系统时，我遇到的坑大概可以整理成下表。这些内容在官方文档里很难找全，但都是真实开发中会反复遇到的问题：

有一个值得单独说的问题，就是数据库密码包含特殊字符，比如@、#时，连接URL会解析错误。这种情况要么改一个纯数字字母的密码，要么在yml里对特殊字符转义，我第一次遇到时排查了很久，最后发现是密码里的#被当作注释符处理了。这个细节没经历过的人不太会第一个想到。

5.3 如果你想让这个项目再往前走一步

这套系统已经把基础功能跑通了，但它绝对不是一个封顶的项目，反倒是扩展空间大得很。最顺理成章的扩展方向是给搜索加全文检索，现在菜品列表的搜索是SQL里的LIKE模糊查询，数据量几千条倒是没什么问题，但如果菜品过万，搜索体验就会明显下降。可以给菜名和描述字段建立全文索引，或者上Elasticsearch，但除非你真的有几千条以上的数据，否则不建议提前上。

第二个值得扩展的点是图片上传。目前图片上传后是存在本地磁盘的，单机部署没有问题，但如果以后部署到云服务器，磁盘空间、备份和分布式场景下都会受限，一个合理的升级方向是把图片存储迁移到OSS或者云存储服务，数据库里仍然只存url路径，改动量主要在文件上传的工具类上，对整体架构影响很小。

第三个方向是加入Redis。当前收藏数量和浏览量的统计是直接在MySQL里做UPDATE操作的，如果并发写量上来，行锁竞争是个隐患。用Redis做一个计数缓存，先写Redis，再定时同步回MySQL，这是很经典的方案。不过对于当前项目规模，先维持现有实现就好，等你真正理解了缓存和数据库的一致性怎么做，再来动这块也不晚。

第四，如果要做成多商户或者内容社区的形态——类似美食分享社区，用户可以发自己的独家菜谱，这就涉及到创作者体系、内容审核、关注关系这些更复杂的业务模型。底子里还是这几张表往上加，但整个项目的价值感会上升一个档次。可以说，当前这个美食网站，是一个收得住的骨架，也是一个随时能往外扩的起点。