happy最紧要我开始先说点实际的：这个"基于SpringBoot+Vue的菜谱交流平台"，乍一看就是一个标准的增删改查项目，很多同学第一反应也是"这不就是又一个管理系统吗"。但真把它做明白，你会发现它比普通的图书管理、商品管理系统多了一层难题——它不只是管数据，还要管"人和内容之间的互动"。用户发布菜谱、浏览别人的菜做参考、评论吐槽、收藏备用，这些行为交织在一起，才构成了"交流"两个字。
这篇博文我围绕这个毕设题目，从需求拆解、技术选型、数据库设计、前后端落地、部署排坑到答辩准备，完整过一遍。我自己复现过同类项目，也在好几个交流群里看过别人在这个项目上卡住的点，所以这篇文章不是照搬文档，而是把"为什么这样做"和"踩过的坑"一起讲清楚。如果你正好在准备计算机毕设，或者想快速跑通一个前后端分离的完整项目做参考，可以直接按这个思路走。
1. 菜谱交流平台的本质：先拆清"交流"再谈技术实现
1.1 核心角色与业务闭环
做毕设最容易犯的错，是拿到题目就建工程写代码。你别急，先把角色和业务流程捋清楚。菜谱交流平台至少有三种角色：游客、注册用户、管理员。游客能看菜谱、看评论，但不能发布和互动；注册用户除了浏览，还能发菜谱、编辑自己发布的菜谱、评论、收藏、点赞；管理员负责审核内容、管理用户、维护分类。
业务闭环是这样的：用户发布一道菜谱，包含标题、封面图、食材清单、步骤说明、难度和耗时信息；其他用户通过首页推荐或者搜索发现这道菜谱，点进去浏览，然后产生评论、收藏、点赞；平台根据互动数据反哺推荐逻辑，管理员从后台看到内容热度，定期处理不合规的内容。这个闭环走通了，项目基本就立住了。
1.2 功能清单拆到什么程度可以直接画原型
我习惯把功能清单拆成"用户端"和"管理端"两张表。用户端包括：
- 注册登录、个人信息维护
- 菜谱发布、编辑、删除（至少支持封面上传和步骤动态录入）
- 首页推荐、分类浏览、关键词搜索
- 菜谱详情、评论、点赞、收藏
- 个人主页查看我发布的菜谱和我收藏的菜谱
管理端包括：
- 登录鉴权（通常和用户端共享账号体系，角色区分）
- 用户管理：启用、禁用、重置密码
- 菜谱管理：审核、下架、删除、置顶
- 分类管理：新增、修改、删除分类
- 基础统计：用户数、菜谱数、评论数，能画几张简单的图表更好
拆到这个粒度，你画原型、建表、写接口就都有了依据。很多同学卡在"功能太多做不完"或者"功能太少不够评"之间，核心原因就是没在需求阶段做取舍。我建议保底功能是：菜谱的完整CRUD、图片上传、评论、收藏、搜索分页、后台管理。这几个功能串起来，工作量适中，展示效果好。
1.3 它和普通博客系统的本质差异
你可能会问：这不就是个博客系统换了个皮肤吗？其实差别在数据结构的复杂度上。博客的文章是纯文本+标题，而菜谱是结构化内容：食材名称、用量、单位、步骤顺序、图片、难度、烹饪时长、分量，这些字段如果只用一个大文本字段硬存，后续做筛选和展示会非常痛苦。还有图片的处理，博客可以只有一个封面图，菜谱详情往往还要多步骤配图，这对前端表单设计、后端文件上传逻辑、静态资源访问路径都提出了额外要求。
所以这个项目真正考验你的，不是写一个登录注册，而是面对一个多字段、多图片、多互动形式的内容型项目，如何把结构设计得干净、扩展性又不差。把这个想明白了，技术实现反而水到渠成。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么是SpringBoot+Vue：选型逻辑和备选方案对比
2.1 SpringBoot在后端真正解决了什么
毕设选SpringBoot，不是因为它是"默认答案"，而是它对单人开发的前后端分离项目确实友好。SpringBoot的自动配置把SpringMVC、Jackson、Tomcat内置这些琐事收敛了，你只需要引入依赖、写配置、然后专注于Controller、Service、Mapper三层。它不需要外部容器，java -jar一键启动，这对演示和部署都是实打实的方便。
配合MyBatis-Plus，开发效率能再提一档。菜谱列表分页、条件查询、逻辑删除这些高频需求，MyBatis-Plus的Page对象和LambdaQueryWrapper基本几十行就搞定，不用手写复杂的XML。你要是用原生的MyBatis，写分页和动态SQL会多花不少时间，毕设周期本来就不长，没必要在这儿硬扛。
2.2 Vue前端如何匹配这个项目节奏
前端用Vue3+Vite，组件化开发让"菜谱卡片、评论列表、发布表单"这些复用性强的模块拆得很干净。每个页面只需要组合若干组件，状态管理用Pinia就够了，不需要Redux那种重方案。
Vue对细节交互的支持也到位：发布菜谱时的动态表单，需要随时添加一行食材输入项，这种"数组驱动视图"的场景，Vue的响应式特性写起来非常顺手；搜索框的防抖、列表的加载状态、页面的路由切换，Vue生态里都有成熟的解决方案。
2.3 前后端通过什么契约协作
前后端分离的核心是接口契约。我在项目里习惯定义一个统一的返回结构Result<T>，包含code、msg、data三个字段。后端所有接口都返回这个结构，前端在Axios响应拦截器里统一判断code，不等于200就直接抛提示，等于200就把data返回给调用方。这样前端不需要在每个请求里重复处理错误分支。
举一个实际例子：GET /api/recipe/page?current=1&size=10&keyword=红烧，后端返回：
java复制// 统一返回结构
{
"code": 200,
"msg": "操作成功",
"data": {
"records": [...], // 菜谱列表
"total": 56, // 总记录数
"size": 10,
"current": 1
}
}
前端拿到data.records渲染卡片列表，用data.total算分页组件总页数。整个过程逻辑清晰，出了问题也好定位——是后端数据不对，还是前端渲染不对，边界一眼就看出来了。
2.4 备选方案对比：为什么我没选SSM+JSP或者纯Node
不是所有"看起来火"的方案都适合毕设。SSM+JSP的写法在课程设计里常见，但它前后端耦合重，页面模板写起来啰嗦，而且现在的技术趋势也偏向前后端分离，展示效果要打折扣。纯Node方案（比如Express+Nuxt）对前端友好的确没错，但如果你未来找工作或考研更偏Java方向，一个SpringBoot项目带来的收益明显更高。
还有一个容易被忽略的点：SpringBoot项目资料多、排坑容易。菜谱平台涉及文件上传、跨域、JWT登录、MyBatis分页，这些问题在SpringBoot生态里几乎都有成熟的解决方案，你遇到一个诡异问题，搜索引擎随便一搜就是类似案例。做毕设图和"稳"字，这一点很重要。
3. 数据库设计：几张核心表怎么撑起整个平台
3.1 核心表结构与字段规划
菜谱交流平台我建议至少设计五张核心表：用户表user、菜谱表recipe、分类表category、评论表comment、收藏/点赞表user_favorite。如果想把点赞单独做，也可以拆出user_like表，但大多数场景下收藏和点赞合并处理或用同一张行为表加类型字段，都是可以的。
用户表比较常规，关键字段有id、username、password（存BCrypt加密串）、nickname、avatar、role（user/admin）、status（启用/禁用）、create_time。
菜谱表是所有表里最核心的，我强调几个容易设计出问题的字段：
title：菜谱标题，搜索时高频命中，建普通索引即可cover：封面图URL，注意存相对路径，不要存完整http地址，方便部署环境切换category_id：关联分类表difficulty：难度，用tinyint存1/2/3，比字符串更省空间cook_time：烹饪时长，用int存分钟数ingredients：食材清单，用JSON字符串存储steps：步骤说明，用JSON字符串存储status：审核状态，0待审核、1通过、2下架，这是内容审核机制的关键view_count、favorite_count、comment_count：三个冗余计数，避免每次列表展示都去做统计查询
3.2 食材和步骤为什么要用JSON字符串
我先说结论：食材和步骤用JSON字符串存，对这个项目规模是合理的。如果你把食材拆成独立表，步骤再拆成独立表，那菜谱的增删改查要同时操作三张表，事务、排序、级联删除都变得复杂，而且前端表单的数据结构也要跟着拆，工作量直接翻倍。
JSON方案的优势是：一次查询拿到整道菜谱的完整数据，前端直接JSON.parse就能渲染。比如食材：
json复制[
{"name": "五花肉", "amount": "500", "unit": "克"},
{"name": "生抽", "amount": "2", "unit": "勺"}
]
步骤：
json复制[
{"step": 1, "text": "五花肉切块焯水", "image": "/upload/step1.jpg"},
{"step": 2, "text": "锅中放油加糖炒出糖色", "image": "/upload/step2.jpg"}
]
后端存的时候序列化字符串，读取的时候转回对象。MySQL的JSON字段类型支持得很好，MyBatis-Plus配合String互转也不麻烦。缺点是不能按食材内容做数据库层的SQL筛选，但菜谱平台搜索核心按标题、分类和描述，基本用不上食材筛选，没必要为了这个需求牺牲开发效率。
3.3 用户登录与访问控制的设计
前后端分离项目做登录，JWT是主流选择。用户登录成功后，后端生成Token返回前端，前端存在localStorage，每次请求在Axios请求拦截器里带上Authorization: Bearer <token>，后端用拦截器解析Token并放用户信息到ThreadLocal或请求上下文。
密码部分务必用BCryptPasswordEncoder，别用MD5。MD5加固定盐也容易撞库，BCrypt每次生成的哈希都不同，安全性显著更高。毕设答辩时老师说"为什么用BCrypt"，你可以直接回答：它是自适应哈希算法，自动加盐，能抵抗彩虹表攻击。
3.4 评论、收藏、点赞的数据关系
评论表相对简单，关键字段：id、recipe_id、user_id、parent_id（0表示一级评论）、content、create_time。做一级评论和回复两层就够了，不建议做无限层级，前端递归渲染加上后端递归查询会浪费不少时间。
收藏和点赞我建议用一张行为表：
json复制{
"id": 1,
"user_id": 102,
"recipe_id": 55,
"type": "favorite" // 或 "like"
}
用户点收藏或点赞时，先查询表中是否已有记录，有就删除（取消），没有就插入（添加），这就是经典的"开关"逻辑。同时更新菜谱表的favorite_count或like_count。这个方案表结构简单，还能保证用户行为幂等。
关于数据一致性，我提醒一句：更新计数时直接用SQL自增，比如UPDATE recipe SET favorite_count = favorite_count + 1 WHERE id = ?，不要先查出来再加再更新。并发场景下先后查再改会丢更新，直接自增语句可以避免这个问题。
4. 后端核心实现：Controller层到底该怎么写
4.1 包结构与分层规范
后端代码结构我推荐这样分：
code复制com.example.recipe
├── controller // 接口层
├── service // 业务逻辑层
│ └── impl
├── mapper // 数据访问层
├── entity // 实体类
├── dto // 接收前端参数的传输对象
├── vo // 返回前端的视图对象
├── config // 配置类
├── common // 统一返回、异常处理、常量等
├── utils // 工具类
└── interceptor // 登录拦截器
很多同学的代码喜欢把前端传来的参数直接塞进Entity，图省事。但到了菜谱发布这种场景，前端传的ingredients和steps是数组，而Entity里的字段是字符串，直接塞必然类型转换失败。所以针对发布、编辑这种复杂接口，单独建DTO是必要的，DTO里用List<IngredientDTO>接，由Service层负责序列化成字符串再落库。
4.2 菜谱搜索与分页查询的落地
菜谱列表是所有接口里最核心的一个。它的查询条件包括：关键词（标题模糊匹配）、分类ID、难度、排序方式（最新/最热）。MyBatis-Plus的写法如下：
java复制@Override
public IPage<RecipeVO> pageRecipes(RecipeQueryDTO query) {
Page<Recipe> page = new Page<>(query.getCurrent(), query.getSize());
LambdaQueryWrapper<Recipe> wrapper = new LambdaQueryWrapper<>();
// 关键词搜索，标题或描述
if (StringUtils.hasText(query.getKeyword())) {
wrapper.and(w -> w.like(Recipe::getTitle, query.getKeyword())
.or().like(Recipe::getDescription, query.getKeyword()));
}
// 分类筛选
if (query.getCategoryId() != null) {
wrapper.eq(Recipe::getCategoryId, query.getCategoryId());
}
// 只查审核通过的内容
wrapper.eq(Recipe::getStatus, 1);
// 排序：最新按创建时间倒序，最热按浏览量倒序
if ("hot".equals(query.getSort())) {
wrapper.orderByDesc(Recipe::getViewCount);
} else {
wrapper.orderByDesc(Recipe::getCreateTime);
}
IPage<Recipe> result = recipeMapper.selectPage(page, wrapper);
// 再转VO补充作者信息、封面完整路径等
return convertToVO(result);
}
一个关键细节：所有用户端查询必须做status = 1过滤，否则未审核的菜谱直接被普通用户看到了，管理审核功能形同虚设。这是你项目逻辑完整性的一个体现，答辩时讲到"内容安全"可以顺手提一句。
4.3 文件上传与静态资源映射
图片上传涉及两个问题：存哪、怎么访问。
本地存储方案最省事，适合毕设。配置一个上传目录，比如D:/upload/，然后通过SpringBoot的资源配置把它映射到/upload/**：
yaml复制spring:
servlet:
multipart:
max-file-size: 10MB
max-request-size: 20MB
# 自定义配置
upload:
path: D:/upload/
url-prefix: /upload/**
实现一个WebMvcConfigurer做静态资源映射：
java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
@Value("${upload.path}")
private String uploadPath;
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry.addResourceHandler("/upload/**")
.addResourceResolver(new PathResourceResolver())
.addResourceLocations("file:" + uploadPath);
}
}
上传接口用MultipartFile接收文件，生成UUID防止文件名冲突，保存后用/upload/xxx.jpg作为访问路径返回给前端。前端展示时图片URL拼上当前域名或IP即可。
这里有一个容易踩的坑：开发时前后端分离，前端地址是localhost:5173，后端的图片地址是localhost:8080/upload/xxx.jpg，浏览器访问前端页面时，图片请求会跨域报错。标准做法是：开发环境下，前端配置Vite的server.proxy，把/upload和/api都代理到localhost:8080。这样图片URL直接写相对路径，部署到服务器时也通用，不用改代码。
4.4 后端容易被忽视的三个小问题
第一是时间格式化。前后端分离项目里，Java默认的LocalDateTime序列化出来是带T的格式，前端显示很不友好。在配置里加个Jackson全局配置：
java复制spring:
jackson:
date-format: yyyy-MM-dd HH:mm:ss
time-zone: GMT+8
第二是空值处理。前端传parent_id不传、传null、传0是有区别的。评论接口要明确约定：parent_id传0表示顶级评论。后端判断用Integer而不是int，否则前端忘记传，NPE就来了。
第三是事务。删除菜谱时要同时删除评论、收藏记录，这必须在Service层加@Transactional。面试官或答辩老师如果问"为什么不直接在Controller里写删除逻辑"，你能答出"Controller只做参数接收，事务和业务规则放Service层"就过了。
5. 前端工程实践：页面组织和核心组件设计
5.1 项目初始化和目录结构
前端我用Vue3 + Vite + Element Plus组合。Vite的启动速度比Webpack快很多，迭代体验好。目录结构这样组织：
code复制src
├── api // 接口请求封装
│ ├── recipe.js
│ ├── user.js
│ └── comment.js
├── assets // 静态资源
├── components // 通用组件
│ ├── RecipeCard.vue
│ ├── CommentList.vue
│ ├── Pagination.vue
│ └── RecipeForm.vue
├── router // 路由配置
├── stores // Pinia状态
├── views // 页面
│ ├── home
│ ├── recipe
│ ├── user
│ └── admin
└── utils // 请求工具、工具函数
5.2 路由和Axios拦截器
路由分成两组：user路由和admin路由，用meta.requiresAuth标记是否需要登录。在全局前置守卫里判断：
javascript复制router.beforeEach((to, from, next) => {
const token = localStorage.getItem('token')
if (to.meta.requiresAuth && !token) {
next('/login')
} else {
next()
}
})
Axios拦截器处理令牌和错误消息：
javascript复制request.interceptors.request.use(config => {
const token = localStorage.getItem('token')
if (token) {
config.headers.Authorization = `Bearer ${token}`
}
return config
})
request.interceptors.response.use(
response => {
const res = response.data
if (res.code !== 200) {
ElMessage.error(res.msg)
return Promise.reject(new Error(res.msg))
}
return res.data
},
error => {
if (error.response?.status === 401) {
localStorage.removeItem('token')
router.push('/login')
}
ElMessage.error('请求失败，请稍后重试')
return Promise.reject(error)
}
)
5.3 核心组件：菜谱卡片与发布表单
菜谱卡片组件是整个平台曝光最密集的组件。它接收一个recipe对象，展示封面、标题、难度、时间、浏览数。设计要点是点击整卡跳详情页，而不是依赖某个按钮。鼠标悬浮时有个简单的缩放动画，交互感一下就出来了。
发布表单是这个项目前端最复杂的部分。动态食材行是这样实现的：
javascript复制const ingredients = ref([])
function addIngredient() {
ingredients.value.push({ name: '', amount: '', unit: '' })
}
function removeIngredient(index) {
ingredients.value.splice(index, 1)
}
模板里用v-for渲染每一行输入框，提交前校验每一项不能为空。步骤部分也类似，但每步可能要上传一张图片，所以步骤里包含text和image两个字段，图片上传组件用Element Plus的ElUpload分步上传，拿到URL后存入对应步骤对象。
一个我重点提醒的交互细节：发布表单是长表单，用户填到一半不小心离开页面或者刷新就全丢了。可以在onBeforeRouteLeave里做提示，或者在页面销毁前自动存草稿到localStorage。毕设评审现场展示时，现场断网、误操作的可能性都有，加一层草稿保护是加分项。
5.4 展示层如何接分页和搜索
搜索和分页在用户端是高频操作。我的做法是：搜索条件用reactive对象统一管理，包含keyword、categoryId、sort、current、size。任何条件变化都重置current为1并调用查询接口。分页组件用ElPagination，监听current-change和size-change事件，更新条件重新查询。
这里有个很实际的问题：搜索防抖。用户在搜索框输入关键词时，如果每个字都发一次请求，后端压力大，前端也会出现请求乱序导致展示错误。处理方式是输入框加debounce，一般在300ms左右。手写：
javascript复制let timer = null
function onKeywordInput(value) {
clearTimeout(timer)
timer = setTimeout(() => {
queryParams.keyword = value
queryParams.current = 1
fetchList()
}, 300)
}
5.5 管理员端页面注意事项
管理员端用独立路由和布局，侧边栏菜单包含用户管理、菜谱管理、分类管理、数据统计。菜谱管理表格里，审核通过的显示"下架"按钮，未审核的显示"通过/拒绝"，每个操作都弹确认框，防止误操作。
这个页面做起来不难，但容易显得粗糙。我的建议是：复用用户端的菜谱卡片组件来预览，管理员点击某条菜谱记录时，弹出一个抽屉，里面直接展示该菜谱的完整内容，而不是只看到一行数据。这样既体现了代码复用，也提升了演示时的观感。
6. 从源码到可运行：启动部署全流程排坑记录
6.1 环境准备与版本匹配
先把开发环境确认清楚，避免第一个坑就劝退：
- JDK 1.8或JDK 11（如果用的SpringBoot 2.x）
- Maven 3.6+
- Node.js 16+（Vue3 + Vite 4要求Node 16以上，Node 18更好）
- MySQL 5.7+或MySQL 8.0
版本最容易出问题的是SpringBoot和JDK的匹配。SpringBoot 3.x底层是Spring Framework 6，强制要求JDK 17。很多同学电脑装的是JDK 8，直接导入SpringBoot 3.x项目启动就报UnsupportedClassVersionError。我建议，毕设项目就选SpringBoot 2.7.x，兼容JDK 8，资料也多，够用。
6.2 数据库初始化与导入常见错误
源码里一般会带sql文件，你导入到MySQL时注意两点：一是先确认数据库字符集是utf8mb4，否则菜谱里的中文、表情符号可能乱码；二是确认端口、账号密码和application.yml里配置的一致。最常见的报错是：
code复制Access denied for user 'root'@'localhost'
这个不用慌，十有八九是密码不对或者没配远程访问权限。本地开发直接用root，密码改成配置里的即可。
另一个高频报错：
code复制Table 'recipe.xxx' doesn't exist
通常是手动建表脚本没跑全，或者脚本在导入时因为SQL方言问题中断了。建议用Navicat直接运行整个SQL文件，运行成功后检查核心表数量，别急着启动项目。
6.3 后端启动报错排查
后端启动报错集中在三类：
- 端口被占用：
Port 8080 was already in use，换个端口或者杀掉占用进程。Windows下用netstat -ano | findstr 8080找到PID，taskkill /PID <pid> /F。 - 数据库连接失败：报
Communications link failure或者Access denied，按6.2排查。 - Redis连接失败：如果项目配置里用了Redis存储Token或缓存，本地没有Redis服务就会启动失败。解决方案有两种，要么本地装一个Redis，要么把Redis依赖和用法彻底去掉，改内存存储。
对毕设来说，不是非要上Redis。菜谱平台的Token验证用JWT本身就可以做无状态校验，不依赖Redis，我也建议源码里去Redis化，能减少一整套环境依赖。
6.4 前端启动与联调
前端从仓库克隆下来后，第一步是npm install。这一步常见的报错是：
code复制npm ERR! ERESOLVE unable to resolve dependency tree
通常是依赖版本冲突。解决方法是先删掉package-lock.json，然后用npm install --legacy-peer-deps安装。如果你是Node 18+，部分旧依赖还会在安装时弹node-gyp相关错误，建议直接升级到项目要求的Node大版本。
装完依赖执行npm run dev，如果页面打不开，大概率是vite.config.js的端口或代理配置有问题。检查开发环境代理：
javascript复制server: {
port: 5173,
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
},
'/upload': {
target: 'http://localhost:8080',
changeOrigin: true
}
}
}
如果代理配置正确但接口还是404，看两种可能：一是后端接口路径是/api/recipe/page，但前端请求的是/recipe/page；二是Controller的@RequestMapping("/api/recipe")写错级别，前缀重复。打开浏览器Network面板看实际请求URL，逐个对照。
6.5 部署到服务器的最小演示方案
毕设答辩有时要求做远程演示，或者导师要求部署到服务器。最小可行方案是：
- 后端打成Jar包：
mvn clean package -DskipTests，生成target/xxx.jar。 - 服务器装JDK和MySQL，导入SQL文件。
- 把Jar包上传，改
application.yml里数据库地址为服务器地址，java -jar xxx.jar启动。 - 前端
npm run build生成dist目录。 - 用Nginx托管
dist，并反向代理/api和/upload到后端8080端口。
Nginx配置核心片段：
nginx复制server {
listen 80;
server_name your-domain-or-ip;
location / {
root /path/to/dist;
try_files $uri $uri/ /index.html;
}
location /api/ {
proxy_pass http://127.0.0.1:8080;
}
location /upload/ {
proxy_pass http://127.0.0.1:8080;
}
}
这样部署后，用户访问80端口就是前端页面，/api和图片请求自动转发到后端。注意proxy_pass后面的地址结尾是否带/会影响路径拼接，建议用http://127.0.0.1:8080，不带尾部斜杠。
7. 毕设答辩与项目演进：做完代码只是第一步
7.1 答辩时要讲清楚哪三个点
很多同学答辩时只会点一遍功能，"这是登录，这是注册，这是发布菜谱"——评委听得昏昏欲睡。真正有效的讲解方式，是围绕三个点展开：
第一是需求完整度。你说"我做的是菜谱交流平台"，重点突出交流，把用户发布菜谱、评论互动、收藏、审核这条业务闭环串起来讲。
第二是技术难点与解决方案。比如图片上传后的静态资源映射与跨域处理，JSON方式存储食材步骤的选择理由，JWT无状态登录的设计，MySQL分页查询优化。这些是你区别于"只会CRUD"的证明。
第三是数据设计合理性。拿出核心表结构图，讲清楚为什么设计行为表、为什么冗余计数字段、为什么用JSON存食材。评委听到你有意识地做设计权衡，分已经拿到大半了。
7.2 高频答辩问题与回答思路
我整理了评委大概率会问的几个问题：
- "为什么选SpringBoot？" 答：简化配置和内嵌服务器让部署便捷，配合MyBatis-Plus能高效实现业务，适合快速迭代。同时强调它生态成熟，资料丰富，遇到问题容易解决。
- "你的权限控制怎么做的？" 答：JWT无状态认证，登录发放Token，前端请求携带Token，后端拦截器统一校验。管理员和普通用户通过角色字段区分。
- "点赞和收藏的区别？" 答：收藏是保存到个人主页的菜谱集合，点赞是对菜谱热度的一种轻量反馈。技术实现上共用行为表，通过type字段区分。
- "如果并发访问量大，哪里会成为瓶颈？" 答：可以诚实说目前是单机部署，瓶颈可能在图片带宽和数据库查询。优化方向是给热点查询加Redis缓存，图片走CDN或OSS。这个回答既诚实又体现你有思考。
- "食材步骤为什么要JSON存储？" 答：为了兼顾开发效率和简单扩展性，此规模项目不需要对食材做数据库级筛选。如果未来需要按食材匹配菜谱，可以拆成关联表。
7.3 这个项目还能往哪些方向扩展
如果做完之后还有富余时间，我建议加这几个扩展点，非常出效果：
- 个人主页的"厨艺档案"：展示发布数、收藏数、被收藏数，按发布菜谱的品类自动生成"擅长菜系"标签。
- 菜谱的"一键复制/参考"：用户看到别人的菜谱，点"我也要做"，自动复制一份到自己草稿箱，在原菜谱步骤上修改。这个功能交流属性极强，答辩演示效果非常好。
- 首页推荐逻辑：不搞复杂算法，就按
view_count+favorite_count*2加权排序，再按发布时间做衰减。写一段简单的加权排序规则，讲出来比"按时间倒序"高级不少。 - 数据报表：管理端用ECharts展示近7天新增菜谱数、用户活跃数、菜谱分类分布。可视化永远是汇报场合最直观的东西。
从复现源码到真正跑通，我的经验是你至少会踩一到两次环境坑，这很正常。但只要你把数据表结构吃透，把用户端到管理端的请求链路走一遍，这个项目就不只是"能运行"，而是你想讲什么都能讲清楚。操作上如果卡在某个具体报错，优先看控制台第一行异常，再去对着配置文件排查，比自己瞎改高效得多。
就先说这么多，希望对正在做这个题目的你有帮助。拿到源码后别急着改功能，先按照数据库初始化、后端启动、前端启动这个顺序跑通一次，再把每个模块的业务逻辑读一遍，那时候你再看这篇博文里的细节，会更有共鸣。