SpringBoot+Vue前后端分离美食网站毕设：从数据库设计到部署实战

1. 项目定位与需求拆解

先说结论：这是一套标准到可以直接拿去部署演示的Java Web毕业设计项目，技术栈固定在SpringBoot + Vue，前后端分离，B/S架构（即Browser/Server，浏览器访问服务器，用户不需要安装任何客户端，打开浏览器输地址就能用）。

每年毕业季我都能在选题库里刷到大量美食类网站，为什么？因为这个选题太适合做毕设了。它不像纯商城系统那样要扯一堆支付、库存、物流的复杂逻辑，也不像纯博客那样功能单薄容易答不上来。一个美食网站天然覆盖了用户登录注册、菜品展示、分类筛选、关键词搜索、评论、收藏、订单、后台管理这套完整的CRUD闭环，既有前端表现力（页面可以做得很好看），又有后端复杂度（权限、分页、联表查询、文件上传），答辩的时候每块功能都能对应到一个技术点，评委问什么你都有东西讲。

整套项目交付物包含三样：完整源码（前端+后端）、SQL脚本、接口文档。拿到之后解压、建库、改配置、跑起来，整个流程我下面都会拆开讲。

适合参考的人有两类：一类是准备做类似主题毕设的学生，另一类是想快速上手SpringBoot+Vue前后端分离项目的开发者。前者可以把它当成一个标准答案，理解每张表、每个接口为什么这么设计；后者可以跳过业务本身，直接关注工程结构、代码分层、接口规范这些能迁移到其他项目里的东西。

2. 技术选型：为什么是 SpringBoot + Vue，B/S 架构香在哪

2.1 后端技术栈的价值逻辑

SpringBoot 现在已经是Java Web开发的绝对主流，它比传统SSM（Spring + SpringMVC + MyBatis）强在三个地方：零XML配置、内嵌Tomcat容器、起步依赖开箱即用。你在SSM时代要写一大堆XML配置文件来声明扫描包、配视图解析器、配数据源，SpringBoot里一个启动类全搞定。对毕设而言还有一个隐藏优势：SpringBoot项目结构非常统一，Controller-Service-Mapper三层分包清晰，答辩时画架构图、讲请求链路都非常顺畅。

项目里集成的核心组件包括：MyBatis或MyBatis-Plus做数据访问层、MySQL存业务数据、JWT做登录状态管理、Lombok减少样板代码。如果你拿到的是MyBatis-Plus版本（新版毕设项目里很多都换成了这个），那查询条件构造器写分页和条件查询会省很大力气，底层原理则是把SQL片段封装成了Java方法调用，最终还是在执行SQL，所以不懂MP的也能看懂。

2.2 前端技术栈与BS架构的真实优势

前端用Vue全家桶：Vue 2.x/3.x + Vue Router + Vuex/Pinia + Axios + Element UI/Element Plus。Vue的核心思路是数据驱动视图，你只需要维护一个data对象，页面自动跟着变，不用像JQuery时代那样手动操作DOM。配合Element UI的组件库，表格、表单、弹窗、分页都是现成的，开发速度非常快。

有人可能疑惑：为什么不直接做成前后端不分离，用JSP/Thymeleaf模板渲染？这里要说一下B/S架构为什么适合这类项目。前后端分离之后，前端代码打包成静态文件扔在任何Web服务里就能跑，后端只提供纯JSON接口，前后端可以并行开发，前端调用的是一个HTTP接口而不是页面跳转。这样出来的项目在真实企业里更接近主流开发模式，在毕业设计打分里也更占优势。加上现在前后端分离意味着如果以后想换个客户端（比如做成小程序），后端接口完全可以复用。

2.3 为什么说这是一套经典的Java Web毕设配方

列一张表就能看清这套技术组合为什么被反复使用：

这套组合覆盖面够广，几乎每个技术选型都能对应到一个软考、面试或者答辩高频问题，证明题目选得好，技术栈选得稳。

3. 数据库设计与 SQL 脚本：先画关系，再建表

3.1 表结构设计思路

拿到项目源码后，第一个打开的还是SQL脚本。推荐先看表结构，不要急着跑代码，通过几张核心表就能大致猜出整个系统有什么功能。一套成熟美食网站的建表脚本通常包含这些表：

• t_user 用户表：存储登录账号、密码（加密后的密文）、用户名、昵称、手机号、头像、创建时间
• t_category 菜品分类表：分类名称、排序字段、图标
• t_dish 菜品表：菜品名称、所属分类ID、封面图、描述、价格、月销量、状态
• t_comment 评论表：关联用户ID和菜品ID、评分、评论内容、回复内容、时间
• t_favorite 收藏表：关联用户ID和菜品ID，记录收藏时间
• t_order 订单表：关联用户ID、订单编号、下单时间、总金额、订单状态

有的项目会扩展t_cart购物车表、t_address收货地址表，但核心最少就是这六张。重点观察它们之间的关系：一个用户能收藏多个菜品，一个菜品能被多个用户收藏，所以收藏表是典型的关联表；一个菜品属于一个分类，一个分类下面有多个菜品，则是一对多关系。辨析清楚关系之后，再去看外键字段的设计，就会觉得顺理成章。

习惯上，主键一般用自增ID，Java代码里对应Long或Integer类型，不要用UUID做业务主键（虽然不会冲突，但索引性能差、打印日志也不直观）。

3.2 SQL 脚本里的几个关键细节

打开SQL脚本你会看到很多细节，这里挑几个直接影响项目能否跑起来的地方展开说。

首先是字符集。建库语句一般会写成CREATE DATABASEfood_dbDEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci。为什么一定要用utf8mb4？因为MySQL原生的utf8最多只能存3字节的字符，存不了Emoji表情和一些特殊符号。用户评论里插一个emoji，如果字符集不对，整条SQL直接报错，这是一个非常隐蔽的坑。

然后是存储引擎。表默认是InnoDB，教程里不会单独强调，但答辩时真的有人被问到“为什么选InnoDB”而答不上来。关键回答点：支持事务（ACID）、支持行级锁（并发写性能好）、支持外键（虽然实际项目很少用物理外键）、崩溃恢复能力强。

再一个细节是时间字段。常见的写法是datetime DEFAULT NULL或者timestamp DEFAULT CURRENT_TIMESTAMP。在Java实体类里对应Date或LocalDateTime，JSON序列化后给前端展示的是字符串，注意一下时区设置即可。

还有一个聪明的设计点：逻辑删除字段。很多表里会看到deleted字段（0未删除，1已删除），删除操作其实执行的是UPDATE而不是DELETE，这样做的好处是历史数据不丢，后面想恢复和统计都有余地。看到这个字段的时候不要觉得多余，可以在答辩时主动说“这里我做了逻辑删除，防止误操作导致关联数据丢失”，属于加分项。

3.3 导入SQL脚本的正确姿势

拿到脚本，新手最容易在导入阶段翻车。推荐两个办法：

第一种是在Navicat/DataGrip这种图形工具里，新建连接、新建数据库（注意字符集选utf8mb4），然后右键运行SQL文件，选到你的food.sql脚本即可，跑完后刷新表列表能看到所有表。

第二种是命令行导入，在MySQL安装目录的bin下面打开终端（或者在系统环境变量里已配置mysql命令的情况下）：

mysql -u root -p < food.sql

记得先确认SQL文件里有没有CREATE DATABASE语句。如果脚本里有建库语句，执行后会自动建库；如果没有，就得先手动CREATE DATABASE food_db，再USE food_db，最后SOURCE food.sql。很多人导入报错“No database selected”，原因就是库没先建好或者SOURCE前忘了USE。

4. 后端接口设计：从用户登录到菜品下单的完整链路

4.1 统一返回结果与状态码规范

前后端分离的项目，接口返回格式一定要统一，否则前端处理起来会写一堆重复代码。这套源码里通常定义了一个Result类（也有叫R、ResponseData的），结构大致为：

{ "code": 200, "message": "操作成功", "data": { } }

code是业务状态码，200代表成功，401代表未登录，403代表无权限，500代表服务器异常。data放实际数据，可以是对象、列表，分页接口则通常封装成一个包含total、records、pageNum、pageSize等字段的分页对象。

这里要提醒一个实战中容易忽略的点：HTTP状态码和业务状态码要区分开。不要想当然地让所有接口都返回HTTP 200，然后在body里用业务code标识错误。RESTful风格提倡按语义返回HTTP状态码（比如未登录401、参数校验失败400），前端Axios拦截器里再对HTTP状态码做第一次拦截，对业务code做第二次判断。这样错误处理链路更清晰，答辩讲起来也更专业。

4.2 登录鉴权：从JWT生成到拦截器校验

用户登录这块，源码里几乎都是JWT方案。简要拆解一下流程：

用户提交username和password，后端根据用户名查库，比对密码。密码不是明文存的，而是MD5加密或BCrypt加密后的密文。比对通过后，服务端用登录用户信息生成一个带过期时间的Token字符串返回给前端。前端把Token存到localStorage里，之后每次请求都在请求头里带上Authorization: token。后端有个拦截器（Interceptor）或过滤器，在请求进入Controller之前取出Token进行校验，校验通过放行，不通过直接返回401。

为什么不用Session？因为Session是靠Cookie维护的，Cookie由浏览器自动携带，天然适合同一个浏览器的多页面请求。但传统Session模式在后端多实例部署（比如同时跑两个SpringBoot实例做负载均衡）时会失效，要么引入Session共享（比如存Redis），要么前端多次手动传SessionID，都很麻烦。JWT本身是无状态的在服务端不存任何登录数据，只要客户端拿着Token并且Token没过期就能访问，天然适合前后端分离和分布式部署。

实操中一般会让JWT过滤器继承OncePerRequestFilter，重写doFilterInternal方法，对白名单路径（登录接口、注册接口、获取验证码接口）直接放行，其他路径统一去请求头里取Token。

这里有两个容易踩的坑：一是Token里不要塞太多用户信息，只放用户ID和用户名就够了，像密码这类敏感信息严禁放进去，因为Token的payload部分按Base64编码后是能明文解出来的；二是生成的Token最好设置过期时间，常见的是2小时或7天，格式可以直接在生成时指定。

4.3 核心接口清单与分页方案

展开一份典型接口文档，大致长这样：

分页是每个项目都绕不开的操作。手写SQL实现LIMIT offset, pageSize当然没问题，但推荐优先用MyBatis-Plus的分页插件，配置一个MybatisPlusInterceptor添加PaginationInnerInterceptor，然后在Service层用LambdaQueryWrapper配合分页参数查询。传参时注意pageNum从1开始，pageSize是每页条数，返回的total是总记录数，前端分页组件的页码和总条数直接绑定这两个字段即可。

菜品分页接口的查询条件设计也有讲究。前端把搜索关键词、分类ID、当前页、每页条数一起传过来，后端代码里用条件构造器动态拼接SQL，关键词不为空才加like条件，分类ID不为空才加eq条件，这就是MyBatis动态SQL最典型的应用场景。而不是给前端开放好几个参数写死分支。

4.4 文件上传与图片访问

美食网站必然涉及图片，菜品封面、用户头像都要走文件上传。常见做法是前端用Element UI的Upload组件把文件POST到后端upload接口，后端用MultipartFile接收，把文件写到本地磁盘的指定目录，比如项目根目录下的upload文件下，然后把相对路径或完整URL返回给前端，前端Data里存这个路径，整个菜品记录创建即完成。

这个环节有两个非常容易踩的坑需要重点说：

第一个是静态资源映射。如果配置不生效，上传成功后返回的路径在浏览器里没法打开图片，页面上一片空白。SpringBoot默认只映射classpath:/static目录，你如果传到项目根目录的upload下，需要使用WebMvcConfigurer的addResourceHandlers方法手动加一个映射，把/upload/**映射到file:D:/xxx/upload/。很多同学图片上传了却显示不了，排查方向就是这里。

第二个是文件和数据库分离的路径问题。数据库里存的是相对路径/upload/xxx.jpg，展示图片时前端拼上后端地址http://localhost:8080，这样换服务器迁移数据时只要相对路径不变，图片就能跟着走。相反如果你在数据库里直接存了带本机IP的完整地址，换个环境整批图片全部失效。

5. 前端 Vue 实现：页面到状态管理的落地细节

5.1 工程结构与核心依赖

拿到前端源码，先看package.json里有哪些依赖，一般都能看到axios、vue-router、vuex/pinia、element-ui/element-plus这几个核心库。src目录下面按功能拆分成views（页面）、components（组件）、router（路由）、store（状态）、utils（工具）、api（接口请求模块）这几个文件夹。

前端工程化的核心逻辑就是把页面拆小。一个美食网站前端页面看似多，但很多部分是重复的：首页的菜品卡片、菜品分类的tabs、分页条、导航栏。这些都应该抽成组件，比如DishCard组件接收一个dish对象作为prop，渲染菜品图片、名称、价格、月销量；DishList组件循环渲染DishCard数组，并在数据为空时展示空状态文案。

在api目录里，一般按业务模块拆文件，比如dish.js里导出函数getDishPage(params)，内部实际是调用axios.get('/api/dish/page', { params })。页面组件里导入对应函数后调用即可，不要在页面里到处写死请求路径。这样做的好处是后端接口只要改一处文件里的路径，全站生效，维护方便得多。

5.2 Axios 封装与请求拦截

Axios需要在前端做一次统一封装，并在里面处理Token的携带与错误状态。典型的封装逻辑是：

axios实例的baseURL从环境变量读取（不同环境切换后端地址），同时设置请求超时时间。请求拦截器里判断localStorage里有没有Token，有就加到请求头。响应拦截器里根据HTTP状态码做统一处理，例如401时提示“登录已过期”，并自动清除本地Token跳转到登录页。

这里有个细节非常实用：登录状态管理不要做成存进Vuex/Pinia就完事。因为Vuex刷新页面后状态会丢，必须配合persist插件或者手动从localStorage读取初始化数据。页面初始化时在App.vue的created里从localStorage取一次Token和用户信息，塞进Store，刷新就不会出现登录状态丢失的情况。

5.3 路由设计与权限控制

前端路由设计一般是这套结构：

• 首页 /
• 菜品列表 /dishList，带查询参数
• 菜品详情 /dish/{id}
• 登录页 /login
• 注册页 /register
• 个人中心 /user（收藏、订单、个人信息）
• 管理后台 /admin（用户管理、菜品管理、分类管理、评论管理、订单管理）

路由权限用导航守卫实现。在router.beforeEach里判断目标路由的meta字段，如果该路由requiresAuth为true，则检查Store里有没有Token，没有就redirect到/login并携带redirect参数，登录后回跳原页面。管理后台还需要校验角色，只有管理员角色的用户才能进入。

动态路由可以做但没必要在毕设里强行上。如果管理端页面很多，已经够展示路由守卫和权限控制这两个技术点了，再往上加动态路由反而增加复杂度，答辩容易卡壳。

5.4 管理端表格的增删改查

管理后台是前端工程量最大的部分，也是技术含量最容易被低估的地方。菜品管理页面的核心是一个可编辑表格，列包括菜品图、名称、分类、价格、状态，行尾有编辑和删除按钮。

编辑弹窗里用到el-dialog嵌套el-form，表单校验用rules，提交时校验通过再调接口。删除操作不能只调接口就完事，一般先弹出确认框，确认后再发请求，成功之后重新拉一次当前页数据，保证表格和数据源同步。这个流程是report里最常被问到的“前端如何与后端保持数据一致”的答案。

另外一个加分点是状态列用el-switch或el-tag展示，状态切换调用更新接口实现上下架，比单纯显示文本更亮眼，也体现组件交互设计能力。

6. 本地运行与项目部署：把整套源码跑起来的完整步骤

6.1 环境准备清单

想把这套项目在本地完整跑起来，环境版本是有讲究的。经验值如下：

• JDK：1.8或11，毕设项目用1.8最常见
• Maven：3.6+
• MySQL：5.7或8.0，8.0要注意驱动包版本
• Node.js：14+（Vue2项目Node版本不宜太高，如果装的是Vue3+Vite则建议16+）
• 前端包管理器：npm或yarn

如果电脑上多个Java版本，记得确认IDE里项目SDK能选对版本，以及Maven配置的settings.xml使用了国内镜像，否则首次拉依赖会卡到怀疑人生。

6.2 后端启动步骤

第一步，用IDEA打开后端源码目录，等待Maven自动下载依赖，确认pom.xml里的依赖没有红色报错。JDK版本如果不对，在Project Structure里调整。

第二步，在MySQL里执行SQL脚本，确认数据库和表都创好，再插入几条初始数据。初始数据里一般会有一个管理员账号，比如admin / 123456，这点查看readme或者t_user表中的密文就能确认。

第三步，打开application.yml或application.properties，修改数据源配置：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/food_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver

serverTimezone如果不想写死，也可以配成CTT或者GMT%2B8，但最直观的还是Asia/Shanghai。不配时区，在MySQL 8下连接会直接报错，提示server time zone的异常，这个是高版本MySQL的常见坑。

第四步，直接运行启动类，看到类似Tomcat started on port(s): 8080的日志就说明后端起来了。可以先用浏览器访问一下登录接口，或者用接口文档里的测试工具试着登录拿Token。

6.3 前端启动步骤

前端在另一个终端窗口里操作：

npm install npm run serve

默认会跑在8081或3000端口，如果和后端8080不冲突就不用改。Vue2项目npm run serve是开发模式启动，改了前端代码会自动热更新，配合后端联调非常方便。如果遇到Vue CLI老版本的安全提示，或者依赖版本冲突，可以删掉node_modules和package-lock.json后重新install，这是前端装依赖遇到奇奇怪怪报错的通用解法。

开发模式下前端请求后端接口能畅通，是因为项目里做了开发代理配置。在vue.config.js里：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

全部请求都代理到后端的8080端口，同时不会出现跨域问题。这一点强烈建议在答辩PPT里面体现，它体现了对前后端联调的理解，而不只是会套脚手架。

6.4 生产环境打包部署

开发完要部署或演示，打包命令分别是：

mvn clean package -DskipTests npm run build

后端打出一个jar包，直接java -jar xxx.jar运行；前端build后生成dist目录，里面是纯静态文件，放到nginx或者任意Web服务器里即可。有经验的会把dist放到nginx，nginx里配置反向代理/api到后端8080端口，这样可以实现前后端同端口访问，省去跨域配置。这个部署方式在企业里也是最主流的，说出来很加分。

如果只是毕设演示不要求上服务器，那在前端页面用开发模式跑起来，后端jar包正常启动就已经够了，演示环境和开发环境并没有本质区别。

7. 常见问题排查与避坑清单

7.1 问题速查表

7.2 一个隐藏很深的坑：数据库驱动与方言

当代码里用到了MyBatis-Plus的分页插件，必须确保配置的DbType和实际数据库一致，例如MySQL就配DbType.MYSQL。因为分页插件在拦截SQL时，会根据数据库类型生成不同的分页方言SQL。数据库类型配错了，内存中没有相应的分页方言常量，常见报错是“Unsupported DbType”，页面分页直接失效。这个坑特别隐蔽，因为项目能正常启动、前几页数据也能显示，但依赖于count和limit的拼接逻辑就是不对。

7.3 自查经验：拿到项目先干什么

说实话，拿一份源码到自己手里，直接打开就开始跑代码、点页面，是典型的新手操作，遇到问题会非常被动。我的习惯是先花10分钟做三件事：看README了解启动步骤，看SQL脚本了解系统模块，看application.yml确认端口和数据库配置。这三件事做完，你还没有运行任何代码，但脑子里已经能大体画出这个系统长什么样了，后面出问题也知道该往哪个模块去排查。

再补一个实用小技巧：登录接口调试时，可以先用接口文档里的测试请求直接调后端，确认后端没问题后再点前端页面。这样一旦报错，能立刻定位是后端问题还是前端联调问题，省掉大量排查时间。前后端分离项目里80%的联调问题都是路径写错、字段名不一致、请求头没带Token这三类，保持怀疑的顺序基本都能查到。

7.4 春节前大家常问的“能不能跑”类问题

每年都会有人私信类似“我导入SQL后什么都不显示”“8080端口被占用”这类问题。端口被占用的解法很简单：Windows下netstat -ano | findstr 8080查到占用进程PID，然后taskkill /PID 进程号 /F，或者在application.yml里换一个不冲突的端口，两个办法都行，推荐改配置，避免误杀系统进程。

还有一个常见情况是前端页面打开了但数据库没有初始数据，比如登录页面进去了，但没有任何菜品展示。这是SQL脚本没导入成功，或者导入成功但表里真的有数据空跑。检查数据库里t_dish表有没有数据，就一目了然。

8. 如果重新做一遍，我会在哪些地方继续扩展

如果这套项目是你自己的毕设，答辩拿到基础分后，可以低成本地在以下几个方向做优化，每一个都可以作为答辩亮点：

第一，加一个Redis缓存。菜品分类和菜品列表属于热点数据，访问量大、变化不频繁，完全可以在Service层先查Redis，查不到再查DB并回填缓存，同时给菜品新增、修改时加上缓存清理逻辑。这样一个点，既展示了非关系型数据库的知识，也展示了对系统性能的思考。

第二，登录改为Spring Security或Sa-Token的集成方案。Spring Boot的权限设计在真实企业中更通用，Sa-Token相比JWT手写拦截器则更简洁、支持踢人下线等功能。如果你把认证授权做成通用组件而不仅仅是登录那一段逻辑，答辩目光会明显不一样。

第三，加入文件上传服务化。现在项目里的图片是本地上传，换成OSS对象存储或者MinIO自建对象存储，把上传能力和业务解耦，顺带还能讲一讲CDN加速图片访问，这个话题很能体现工程化意识。

第四，接口文档从手写改成Swagger注解自动生成。接口文档是这套交付物的一部分，但手写文档维护成本太高、容易和代码不一致。给Controller类和方法加上@Api和@ApiOperation注解后，启动项目访问/swagger-ui.html就能自动看到在线文档。这个改动技术含量不高，但答辩时直接打开在线接口文档演示，观感极佳。

这些扩展都不改变原有架构，属于在原项目上的医生升级。如果有余力，建议至少挑一条做进去。做成的收益不是功能多了，而是每一块改动都能讲出动机和效果，比堆十个CRUD功能都强。