做毕业设计选题的时候很多人一眼看到“中华美食菜谱系统”第一反应就是“这不就是个增删改查吗”。说实话这个题目确实不像人工智能、大数据那么唬人但真正把一个菜谱分享交流平台做到能演示、能答辩、能讲明白设计思路还是有不少门道的。这个题目正好落在 Java SpringBoot 这套国内最主流的技术栈上前端再配一个 Vue 的 Web 页面做出来就是一个标准的前后端分离项目既有业务完整度又有展示效果非常适合计算机专业的本科毕业设计。这篇内容我按实际做完一整套项目的流程来拆从需求分析到数据库设计从后端接口到前端页面再到部署上线和答辩常见追问。准备选这个题、正在写这个题或者想拿这个项目去面试的同学都可以直接照着做我会把每一步怎么想、为什么这么选、踩过哪些坑都讲清楚。1. 项目定位与需求拆解1.1 系统角色与核心功能做毕设的第一步不是写代码而是把系统到底给谁用、要解决什么问题想明白。美食菜谱系统从名字就能看出来核心业务是“菜谱”但加上“分享交流平台”这几个字之后它的定位就不再是单机版的菜谱查询工具而是一个带用户体系、内容发布、互动反馈的社区型 Web 应用。我把角色拆成两个维度普通用户和管理员。普通用户能做的事情是注册登录、浏览菜谱、按分类或关键词搜索菜谱、查看菜谱详情、发布自己的菜谱、对自己喜欢的菜谱进行点赞、收藏和评论。这基本上覆盖了内容社区最常见的几个动作看内容、生产内容、互动内容。管理员做的事情则是用户管理、菜谱审核、分类管理、数据概览。菜谱审核这一块容易被忽略但实际做的时候很有必要。因为用户发布的内容质量参差不齐如果没有审核机制系统里很容易出现垃圾数据答辩时如果被问到“你怎么保证内容质量”审核状态设计就是一个很好的加分回答点。功能优先级上我建议先保证主链路完整登录注册 → 浏览菜谱 → 查看详情 → 发布菜谱 → 评论收藏。这五个功能串起来就是一个完整的用户旅程也是最核心的演示流程。分类管理、数据统计这些可以先做基础版放到后面再完善。1.2 功能模块边界与优先级划分我见过不少同学一上来就想把系统做得很庞大什么智能推荐、消息推送、好友关注全都要结果做到一半发现时间不够核心功能都没做完。我的建议是分清主次牢牢抓住毕业设计“功能完整、逻辑清晰、能演示、能答辩”这个核心目标。主模块我划分成四块用户模块注册、登录、个人信息维护、密码加密存储。菜谱模块菜谱发布、菜谱编辑、菜谱删除软删除或真删看情况、菜谱列表分页查询、菜谱详情查看、分类筛选、关键词搜索、浏览量统计。互动模块点赞、收藏、评论、我的收藏列表、我的发布列表。管理模块后台登录、用户列表与状态管理、菜谱审核与下架、分类维护。每个模块再拆出 RESTful 接口前端对应一个页面或一组组件。这样模块边界清楚开发的时候可以一个模块一个模块地做调试和答辩演示都方便。2. 技术选型与项目架构设计2.1 为什么选 SpringBoot Vue 这套组合选题的时候技术栈不是随便定的既然题目里明确写了 Java SpringBoot那后端就锁定 Java 生态。SpringBoot 是目前 Java Web 开发事实上的标准它解决了传统 SSM 框架大量 XML 配置的问题内置 Tomcat打一个 jar 包就能跑特别适合毕业设计这种需要快速交付、方便演示的场景。前端我推荐 Vue而且建议用 Vue 2 Element UI 或者 Vue 3 Element Plus。原因很简单Vue 在国内高校的普及度极高资料多Element 组件库直接提供表格、表单、分页、弹窗这些现成组件写出来的页面不会太丑还能省大量时间。如果你完全不会前端也不要怕Vue 的基础用法加 Element 组件大概一周就能上手做页面。数据库选 MySQL 8.0这个没什么争议免费、稳定、资料多。ORM 层我用 MyBatis-Plus原因是它比原生 MyBatis 省去大量写 SQL 的工作单表 CRUD 直接继承 BaseMapper 就有现成方法分页查询也有内置插件非常适合快速开发。这里我补充一个取舍逻辑为什么不直接用 MyBatis 原生因为菜谱系统大部分操作是单表操作MyBatis-Plus 可以极大提升效率。为什么不引入 Redis因为毕设项目规模不大Redis 缓存属于锦上添花如果你学有余力可以加但不要一开始就背上这个复杂度。老老实实先把业务功能做完整比堆砌技术栈更重要。2.2 前后端分离架构与目录规划整体架构采用前后端分离模式SpringBoot 只负责提供 RESTful API返回 JSON 数据Vue 工程独立开发通过 axios 调用后端接口。前端开发时用 devServer 代理解决跨域上线时把前端打包后的 dist 目录交给 Nginx 托管或者直接把 dist 文件复制到后端 resources/static 目录里SpringBoot 也能直接托管。我实际推荐的做法是本地开发用 Vue devServer 代理服务器部署用 Nginx。如果你不想折腾 Nginx就把 Vue 打包后的文件复制到 SpringBoot 的 static 目录下这样后端一个 jar 包就能同时提供 API 和页面访问演示的时候只需要启动一个 Java 进程特别省事。后端目录我按这个结构来组织com.example.recipe ├── config // 配置类跨域、拦截器、上传路径映射 ├── controller // 接口层 ├── entity // 实体类 ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── service // 业务逻辑层 │ └── impl ├── common // 公共类统一返回结果、异常处理、工具类 └── utils // JWT、文件上传等工具这个结构是标准的 Controller-Service-Mapper 三层架构Controller 不写业务逻辑只做参数接收和结果返回业务逻辑全部放到 Service 层。答辩时如果老师问“你这个项目怎么分层的”按这个结构就能讲清楚。2.3 统一返回结果与异常处理设计这块看似不起眼但实际开发中非常关键。前端调接口的时候最理想的情况是每个接口返回格式都一样这样 axios 封装一次所有页面都能统一处理。我定义了一个 Result 类结构是 code、message、data 三个字段。code 为 200 表示成功其他数字表示各种错误状态。类似的还有全局异常处理。我会用一个 RestControllerAdvice 注解的类来捕获所有未处理的异常兜底返回错误信息避免出现五万字堆栈直接抛给前端的尴尬情况。比如上传文件过大、请求参数格式错误、业务校验不通过这些都是可以预判的异常在全局异常处理器里做统一转换比每个接口单独 try-catch 要干净得多。3. 数据库设计与表结构规划3.1 设计思路围绕菜谱这条业务主线数据库是毕业设计最容易出彩也最容易翻车的地方。设计得好老师会觉得你思路清晰设计得烂哪怕代码写得再花哨一问你表结构就露馅了。菜谱系统的核心实体很明确用户、分类、菜谱、评论、收藏。互动数据围绕菜谱展开用户和菜谱之间是发布关系用户和菜谱还有收藏关系菜谱和评论是一对多关系。我要强调一个细节食材和制作步骤怎么存很多同学会把食材、步骤单独建表这样做确实符合第三范式但实际开发中反而麻烦——因为菜谱的食材和步骤通常是整体保存、整体修改很少有单独操作某个食材或某个步骤的需求。我的做法是在菜谱表里直接用 JSON 字符串存储食材列表和步骤列表前端提交 JSON 数组后端原样存储查询的时候直接返回。这样既减少了表数量又简化了开发。答辩时可以解释为“JSON 字段在此场景下比关联表更灵活且避免了过度范式化带来的查询复杂性”。3.2 核心表结构详解我设计五张核心表用户表、分类表、菜谱表、评论表、收藏表。用户表比较简单核心字段是用户名、密码、昵称、头像、角色、状态、创建时间。需要注意三点密码不能明文存储用 BCrypt 加密用户名要加唯一索引角色字段用字符串标识 USER 和 ADMIN方便扩展。分类表用于菜谱的分类管理比如川菜、粤菜、鲁菜、家常菜、烘焙、汤羹等。字段有分类名称、排序号、创建时间。这里可以预留一个 parent_id 字段做父子级分类不过如果时间紧张一级分类也完全够用。菜谱表是整个系统的核心我详细列出字段CREATE TABLE recipe ( id BIGINT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(100) NOT NULL COMMENT 菜谱标题, cover_image VARCHAR(255) COMMENT 封面图地址, summary VARCHAR(500) COMMENT 简介, category_id BIGINT NOT NULL COMMENT 分类ID, difficulty TINYINT DEFAULT 1 COMMENT 难度1简单 2中等 3困难, cook_time VARCHAR(20) COMMENT 烹饪时长, ingredients TEXT COMMENT 食材清单JSON数组, steps TEXT COMMENT 步骤列表JSON数组, user_id BIGINT NOT NULL COMMENT 发布用户ID, view_count INT DEFAULT 0 COMMENT 浏览量, like_count INT DEFAULT 0 COMMENT 点赞量, status TINYINT DEFAULT 1 COMMENT 状态0草稿 1审核通过 2已下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_category (category_id), KEY idx_user (user_id), KEY idx_status (status), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜谱表;这个表设计里有几个业务上的考虑view_count 和 like_count 是冗余计数字段每次浏览和点赞直接对这两个字段做加减避免实时 count 聚合带来的性能开销status 字段支撑菜谱审核流程管理员可以把用户发布的菜谱设置为下架create_time 加索引是为了支撑“最新菜谱”这类排序场景。评论表和收藏表也列一下CREATE TABLE comment ( id BIGINT AUTO_INCREMENT PRIMARY KEY, recipe_id BIGINT NOT NULL, user_id BIGINT NOT NULL, content VARCHAR(500) NOT NULL, parent_id BIGINT DEFAULT NULL COMMENT 回复的评论IDNULL表示顶级评论, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_recipe (recipe_id), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT评论表; CREATE TABLE favorite ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, recipe_id BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_recipe (user_id, recipe_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT收藏表;favorite 表的联合唯一索引很重要它能保证同一个用户只能收藏同一道菜一次前端点击收藏时先查记录存在就提示“已收藏”不存在就插入这个逻辑配合唯一索引就能彻底避免重复数据。3.3 索引设计与字段规范建议索引不是越多越好建多了影响写入性能建少了查询慢。这个系统我建议重点覆盖三类查询场景按分类查菜谱category_id、按作者查菜谱user_id、按状态查菜谱status。分页排序通常会按 create_time 或 view_count 来排所以这两个字段也建议建索引。字符集必须用 utf8mb4不要用 utf8。因为 utf8mb4 才支持完整的 Unicode 字符包括 emoji 和生僻字。字段类型上文本内容用 VARCHAR 或 TEXT 就够不要一看到内容就用 BLOB。时间字段统一用 DATETIME不要用 TIMESTAMP 存未来时间会有限制。另外所有表都要加 create_time有更新需求就加 update_time 并配置自动更新。这个习惯在答辩时提到会显得你有工程意识。4. 后端核心功能实现4.1 登录认证JWT 无状态方案登录认证我强烈建议用 JWT而不是传统的 Session。原因有两个前后端分离架构下Session 需要处理跨域 Cookie 问题而 JWT 是在请求头里带一个 token天然适合分离架构JWT 是无状态的后端不用存会话记录方便横向扩展这个点答辩时可以直接说。具体流程用户提交用户名密码后端校验通过后生成一个包含用户 ID、用户名、角色、过期时间的 token 返回给前端。前端把 token 存到 localStorage 里之后每次请求在 axios 拦截器中自动加上 Authorization 请求头。后端用一个拦截器统一解析 token解析成功就把用户信息放到 ThreadLocal 里后面的业务代码直接取用户 ID不需要每次手动传递。JWT 生成和解析的核心代码我贴一下public class JwtUtils { private static final String SECRET your-secret-key-please-change-in-production; private static final long EXPIRE_TIME 7 * 24 * 60 * 60 * 1000; public static String generateToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }这里有一点必须注意jjwt 的版本会影响 API 写法。如果你用的是 0.9.x 版本就是我上面这种写法如果用了 0.11.x 或更高版本API 会变成 Jwts.builder().signWith(SecretKey) 的形式。我第一次写的时候就是照着一个老教程敲代码结果依赖是 jjwt 0.11编译直接报错。建议用 0.9.1最省心。拦截器里排除登录、注册、图片访问、首页菜谱列表这类不需要登录就能访问的路径。这样一来菜谱浏览不需要登录也能看但发布菜谱、点赞、评论、收藏必须登录。这个设计符合内容社区的基本逻辑也便于答辩讲述权限设计的思路。4.2 菜谱发布与图片上传菜谱发布是核心业务接口前端表单会提交标题、封面图、分类、难度、时长、简介、食材数组、步骤数组这些数据。后端接收对象后把当前登录用户 ID 塞进菜谱实体状态默认设置为审核通过或者为了展示审核流可以设为待审核由管理员后台通过这个看你需要演示哪种效果。图片上传我用的是本地磁盘存储方案。配置一个上传路径比如 D:/upload/recipe/再通过一个 WebMvcConfigurer 把 /upload/** 路径映射到这个磁盘目录这样前端通过 URL 就能直接访问图片。Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadPath /); }上传接口接收 MultipartFile做一些基本校验后用 UUID 拼接原始文件名生成新文件名保存到磁盘返回访问 URL。文件类型我必须校验不要只依赖前端限制因为绕过前端太容易了。我一般会检查扩展名白名单同时限制文件大小比如图片最大 5MB。SpringBoot 默认单文件上传大小限制是 1MB很多人上传大图会报错。需要在 application.yml 里配置spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB这个坑我踩过当时前端一直报错后端控制台也没异常查了半天才发现是默认上传大小限制。4.3 菜谱分页搜索与详情菜谱列表页需要支持分页、关键词搜索、分类筛选可能还要按热门或最新排序。这个接口是查询最复杂的我用 MyBatis-Plus 的 LambdaQueryWrapper 来动态拼接条件配合分页插件实现。public PageRecipe getRecipePage(String keyword, Long categoryId, int pageNum, int pageSize) { LambdaQueryWrapperRecipe wrapper new LambdaQueryWrapper(); wrapper.eq(Recipe::getStatus, 1) .like(StringUtils.hasText(keyword), Recipe::getTitle, keyword) .eq(categoryId ! null, Recipe::getCategoryId, categoryId) .orderByDesc(Recipe::getCreateTime); return recipeMapper.selectPage(new Page(pageNum, pageSize), wrapper); }MyBatis-Plus 的 like 和 eq 方法第一个参数是 boolean 条件条件为 true 才拼接 SQL。这样同一个方法就能满足多个查询场景代码很简洁也不需要手写 XML。分页插件需要在配置类里注册 PaginationInnerInterceptor否则 selectPage 不会生效这个容易漏。菜谱详情接口比较简单传菜谱 ID 返回完整信息包括作者信息、食材、步骤、分类名。不过有两个细节要处理浏览量不能每次都在详情页里 1 就完了我会把它做成一个独立的接口或者详情接口里同时做 update view_count view_count 1用 SQL 自增而不是先查后改避免并发问题浏览量增加不应该让用户感觉页面卡顿所以异步或者直接在一条 SQL 里完成都可以。菜谱详情返回的时候我建议同时返回当前菜谱对应的评论列表和当前用户是否已收藏的状态这样前端详情页一次性把数据拿全减少请求次数。4.4 评论、点赞、收藏互动这三个互动功能逻辑上有共同点但在表结构上我做了区分评论是独立表收藏是独立表点赞则是菜谱表里的 like_count 字段搭配一张点赞记录表。为什么要加点赞记录表如果只维护 like_count 而没有记录表用户无法判断自己是否点过赞也无法取消点赞还会存在重复点赞刷数的问题。有一张点赞记录表接口逻辑就是先查记录是否存在不存在就插入记录并且 like_count 1存在就删除记录并且 like_count - 1。这就是点赞和取消点赞的完整闭环。评论的接口设计成支持回复parent_id 为空的评论是顶层评论回复时 parent_id 填被回复评论的 ID。前端展示的时候可以先展示顶层评论回复信息在评论下方缩进展示。后端返回评论列表时把评论对应的用户名和头像一起查出来评论实体会有一个 userName 字段从用户表关联而来接口层把用户基本信息拼装好再返回。收藏功能跟点赞很接近收藏记录存在 favorite 表里我的收藏页面直接按 user_id 查收藏表再关联菜谱信息返回列表。因为有联合唯一索引收藏操作不需要担心重复插入插入前检查一下即可。5. 前端页面实现与前后端联调5.1 Vue 工程搭建与请求封装前端工程我推荐用 Vue CLI 创建不要手动配 webpack。创建完项目之后先装好 Element UI 和 axios然后把项目里用到的通用能力一次性配置好后面写页面会非常顺手。首要配置是跨域代理。vue.config.js 里这样写module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:8081, changeOrigin: true } } } }这样开发环境前端请求 /api/xxx 就会自动代理到后端的 8081 端口不需要后端额外配置 CORS。但如果后端已经部署到服务器前端要走真实域名访问那就需要后端配 CORS 或者 Nginx 反向代理这个看部署方式。axios 封装我建议新建一个 request.js统一处理 baseURL、超时时间、token 注入和响应拦截。token 从 localStorage 取出来放在请求头里响应里如果 code 是 401就跳转到登录页。这样所有接口自动带登录信息页面代码里不用每个请求都手动传 token。路由设计上我规划了这些页面首页、菜谱详情页、登录页、注册页、发布菜谱页、个人中心首页、我的发布、我的收藏、管理后台。路由需要加导航守卫判断用户是否登录未登录访问需要登录的页面就重定向到登录页。5.2 首页与菜谱详情页实现首页是展示系统的门面我用三个区域来组织顶部导航栏、中间内容区、底部版权。顶部导航栏包含系统名称、分类下拉、搜索框、登录/用户下拉。中间内容区先展示一个轮播图或者热门菜谱推荐区再往下是菜谱分类标签页和分页菜谱卡片网格。菜谱卡片我用 el-card 组件每个卡片展示封面图、标题、简介、作者昵称、浏览量、点赞数。通过分页组件切换页面点击卡片进入详情页。整个首页只对接两个接口分页查询菜谱列表、查询分类列表逻辑不复杂但对整体观感影响很大封面图一定要选清晰好看的演示的时候加分很多。详情页是内容展示的核心我按从上到下的顺序来设计标题和基本信息区作者、分类、时长、难度、浏览量、大图展示区、食材清单区、步骤区带步骤序号、点赞收藏评论区。步骤区我用竖线的步骤条展示每一步显示序号和描述如果步骤内容里有图片就并用图文混排。评论区在页面下方用户登录后可以发评论不需要登录只能浏览评论。详情页的数据聚合比较丰富我建议进入页面之后并行请求详情和评论列表两个接口用 Promise.all 或者直接两个异步方法避免顺序等待。5.3 发布页与个人中心发布菜谱页面是一个长表单字段跟后端菜谱表的字段一一对应。食材和步骤这两个字段比较特殊我在前端用一个动态数组来管理用户点一下“添加食材”就多一行输入框点删除就移除一行最后提交时把数组转成 JSON 字符串放到请求体里。这个过程体验流畅也很容易讲清楚。封面图上传我用的 Element UI 的 el-upload 组件action 指向后台上传接口同时带上 token。上传成功后会返回图片 URL这个 URL 直接存到表单的 coverImage 字段里。注意 el-upload 在上传时会自动发请求如果后端需要登录得记得手动在组件里配置请求头否则会 401。个人中心首页展示当前用户的头像、昵称、注册时间以及我的菜谱数、收藏数、获赞数这些统计。我的发布页面可以查看和管理自己发布的菜谱支持编辑和删除。我的收藏页面展示收藏的菜谱卡片列表点击可以直接跳转到详情页。5.4 管理后台管理后台的入口我放在导航栏的用户下拉菜单里只有 role 为 ADMIN 的用户才能看到。后台的布局用侧边菜单加内容区的方式包含用户管理、菜谱管理、分类管理三个页面。用户管理页面用 el-table 展示用户列表包含用户名、昵称、角色、状态、注册时间。管理员可以启用或禁用用户禁用的用户无法登录系统。菜谱管理页面展示所有用户发布的菜谱状态列用一个 el-tag 显示审核状态管理员可以点击审核通过或下架按钮。分类管理页面就是一个简单的增删改查改完分类立即生效。管理后台不需要做得很重能把核心管理动作跑通就行。结构上复用用户端的技术方案只是页面布局不同工作量可控。6. 部署上线、常见问题与答辩要点6.1 本地启动与打包部署本地开发环境需要 JDK 8 或 11、Maven 3.6、MySQL 8.0、Node.js 14。先把 MySQL 建好库执行建表 SQL然后把后端 application.yml 里的数据库用户名密码改成自己的启动 SpringBoot 后访问接口测试。前端在项目目录下 npm install 装依赖npm run serve 启动开发服务器浏览器打开 localhost:8080 就能看到页面。部署到服务器时我推荐最省事的方式后端打 jar 包前端打 dist 包把 dist 里的文件复制到后端的 resources/static/ 目录下然后重新打一次 jar 包。这样一台服务器只需要装 JDK 和 MySQL用 java -jar 命令启动后浏览器直接访问服务器 IP 加端口就能看到系统。这种方法适合毕设演示也避免了你还要去配置 Nginx。当然如果你愿意写一份 Nginx 配置把静态资源和 API 请求分开代理那更接近真实企业部署方式面试时可以拿出来讲。后端打包用 mvn clean package如果打包时测试报错就加 -DskipTests。前端打包用 npm run build默认输出到 dist 目录。有一点要提醒打包之后如果你发现图片上传后再访问 URL 是 404检查一下是不是后端没有把静态资源映射目录包含进 jar默认 resources/static 下的文件会被打进去但磁盘上传目录不会需要单独配置映射。6.2 高频问题排查速查表我把实际开发中容易遇到的问题整理成一张速查表按概率排序问题现象原因解决办法前端所有接口 404代理路径或后端上下文路径不匹配检查 vue.config.js proxy 和后端 context-path跨域报错前端直接访问后端地址走 devServer 代理或后端加 CORS图片上传报错SpringBoot 默认上传大小 1MB配置 max-file-size 和 max-request-size图片访问 404静态资源映射未配置addResourceHandlers 映射 /upload/**中文乱码数据库连接串没指定编码url 参数加 characterEncodingutf8分页不生效没注册分页插件添加 PaginationInnerInterceptorSpringBoot 启动失败端口被占8080/8081 被占用改端口或杀掉占用进程token 解析一直失败jjwt 版本与代码不匹配统一用 jjwt 0.9.1前端页面空白路由模式或打包路径问题用 hash 模式publicPath 设为 ./这里多提一句 SpringBoot 版本的问题。现在很多同学直接选 3.x 的最新版结果发现代码里 import javax.servlet 全部报错因为 3.x 换成了 jakarta.servlet。毕设项目我建议直接用 2.7.x稳定、资料多、跟大部分教程一致等完全吃透这套之后再去追新版也不迟。6.3 答辩与面试追问怎么答最后聊一聊怎么把毕设讲出深度。老师问的问题其实很集中基本围绕几个点第一问为什么用 SpringBoot回答要点是快速搭建、内置服务器、生态成熟、便于前后端分离。第二问登录认证怎么做的回答 JWT 无状态认证的流程解释为什么不选 Session顺便说 token 过期机制。第三问密码怎么存储的回答 BCrypt 加密不存明文每次登录校验用加密算法比对。第四问菜谱搜索和分页怎么实现的回答 MyBatis-Plus 动态条件拼接加分页插件说明字段索引设计。第五问如果用户量大了怎么优化可以从 Redis 缓存热点菜谱、图片走 CDN、数据库读写分离这几个方向回答不用真的实现能讲出思路就行。第六问你这个项目和普通的增删改查有什么区别这个要提前准备——答社区化互动的完整流程比如内容审核状态、点赞去重、用户权限区分这些都是在普通 CRUD 之上多出来的业务思考。如果面试的话这个项目的亮点我会重点讲三件事情一是把业务闭环做完整了从内容生产到审核再到互动二是在表结构上考虑了冗余设计和联合唯一索引这种实际工程问题三是完整走了一遍前后端分离项目的开发部署流程。这三条讲清楚胜过在简历里堆十个名词。我自己做完这个项目的体会是毕业设计其实不需要多高深的技术但一定要有一条完整的业务主线每一步设计都能说出理由。菜谱系统把用户、内容、互动、管理四个维度串在了一起规模适中深度足够是一个非常聪明的选题。你按我上面讲的这套思路去做顺手把每一步为什么这么选记录下来答辩的时候你就有的讲了。