开题选“厨艺交流平台”这类社会型内容平台是计算机毕设里性价比很高的方向。它既不像纯管理系统那样功能单调也没有电商、短视频那么复杂刚好卡在“技术覆盖面足够、实现难度可控”的甜蜜点上。这篇帖子我会把整个项目从需求拆解、技术选型、数据库设计、核心代码实现到问题排查和答辩加分项完整梳理一遍全程用我实际做毕设带学生的经验来讲。先说结论这个题目适合用 Spring Boot Vue 前后端分离来落地核心是内容发布菜谱、互动评论/点赞/收藏、用户体系和搜索分类。技术栈不堆砌但足够撑起一场答辩。下面我按实际推进顺序把每个环节的关键决策和踩坑点都过一遍。1. 项目蓝图拆解这个毕设到底在做什么1.1 从题目里读出隐藏需求很多同学拿到题目第一反应是“做个菜谱管理增删改查”。这是这个题目最大的坑——如果真做成一个菜谱的CRUD后台答辩时会有明显的薄弱感。你仔细体会“厨艺交流平台”这几个字核心是“交流”而不是“菜谱”。这意味着系统必须有用户生成的菜谱内容、用户之间的互动评论、点赞、收藏、关注、内容的筛选与排序甚至要有社区运营的痕迹——热门推荐、最新发布、分类浏览。那这和普通“菜谱管理系统”的本质区别就出来了管理系统以管理员为中心而交流平台以普通用户为中心。用户需要能够注册登录、发布自己的菜谱、查看别人的菜谱、对菜谱发表看法。如果只做一个管理后台你等于把题目做窄了一半。我见过不少学生把“毕设”做成“课设”——功能太少答辩时老师轻描淡写一句“系统复杂度不够”就给你压到中等评分。1.2 角色与核心功能清单正常需求分析阶段应该画出角色和功能矩阵。厨艺交流平台一般是两个角色普通用户和管理员。普通用户是绝对的主角管理员只做内容的审核和用户管理不用把重心放在管理端。角色功能模块重点内容普通用户注册、登录、个人信息维护头像上传、昵称修改、查看自己发布的菜谱普通用户菜谱浏览与搜索按分类、关键字、热度排序浏览普通用户菜谱发布与编辑填写菜谱名称、封面图、食材清单、步骤、小贴士普通用户收藏与点赞收藏列表、点赞状态记录普通用户评论互动针对菜谱发表评论、回复评论管理员用户管理禁用违规账号、重置密码管理员内容审核下线违规菜谱、删除违规评论这个功能清单看起来常规但每一项落实到数据库和接口设计时都有值得展开的细节。例如“点赞”怎么幂等“收藏”的数据结构怎么去重“搜索”怎么做才能不至于慢到卡死后面我都会专门拆开讲。1.3 为什么这个题目适合做毕设选这个题有四个理由你在开题报告里可以直接用第一技术覆盖广但不杂。你做了这个项目基本就把 JavaWeb 的核心栈覆盖完了Spring Boot 的自动配置与依赖注入、MyBatis 的持久层操作、关系型数据库的表设计与事务、前端 Vue 的组件化与异步交互。二来它需要一个相对完整的数据库设计ER 图、范式分析都有内容可写。三来它的扩展性极强后续可以加 redis 缓存、Elasticsearch 搜索、推荐算法这直接决定你论文“研究点”的深度。第四演示效果直观。厨艺平台功能天然适合录屏演示和截图展示开题、中期、答辩的 PPT 素材都好准备。2. 技术选型与架构设计稳、省、说得清2.1 后端为什么选 Spring Boot 系列我见过有同学用 JSP Servlet JDBC 做也有用 Python Flask 做的。不是不能过但如果你学的是 Java老老实实 Spring Boot 是最稳的。Spring Boot 帮你把配置地狱解决了大半起步依赖让你不用自己手动引入一堆 jar。更关键的是答辩时老师默认你学过 Java Web用 Spring Boot 至少框架层面的问题你都能答上来。ORM 选 MyBatis-Plus 会事半功倍。它自带条件构造器、分页插件、逻辑删除菜谱的分页查询、用户名的模糊搜索这些项目里的高频操作你都能省下很多样板代码。有些同学会纠结“用 MyBatis 还是 MyBatis-Plus”我的态度很明确毕设项目用 Plus 完全没问题面试时补一句“我了解 Plus 底层是封装了 MyBatis 的也写过自定义 XML 映射”就补齐了。真正容易被追问的点在于“为什么不用 JPA”——这需要你有自己的答案比如“项目中有复杂的多表联查MyBatis 对 SQL 的可控性更强”这比单纯说“大家都用”要有底气得多。数据库方面MySQL 8.x 是标配。如果你服务器内存有限8.0 比 5.7 稍微吃资源但功能上 8.0 的窗口函数和 JSON 类型可以让你的项目在部分场景下写 SQL 更优雅。Redis 建议引入但不做深用就用它做热门菜谱缓存和验证码存储论文里能写“引入缓存层降低数据库压力”这已经是毕业设计里很好的性能亮点了。2.2 前端Vue3 是下限不是上限前几年我一般建议 Vue2 Element UI现在 Node 生态已经全面转 Vue3新的 Element Plus 也很稳定了。Vue3 的组合式 API 写起来逻辑更清晰答辩老师一眼就能看出你的前端不是套模板。如果你对前端比较怵可以退一步用 Vue2但别用纯 HTML jQuery——这个年代毕设还在用 jQuery 做交互技术对比这块会被问到卡壳。前端我会采用单一页面应用SPA方式用 vue-router 管理页面路由axios 做 HTTP 请求。UI 组件库选 Element Plus它内置的 table、form、upload、pagination 几乎覆盖平台全部需求你不需要花时间造轮子。状态管理只做轻量用途就选 Vuex 或 Pinia比如保存登录态和用户信息没必要上重型方案。2.3 数据库设计的核心思路数据库设计是这类毕设的灵魂。我把核心表拆出来讲用户表 t_user主键自增 id、用户名、加密密码、昵称、头像地址、个人简介、状态正常/禁用、创建时间。这里有一个坑密码千万不要明文存储用 BCrypt 加密入库答辩老师问安全设计时就答“密码采用 BCrypt 不可逆加密”。头像字段建议存 URL 而不是 Base64不然数据库直接膨胀到爆。菜谱表 t_recipe主键、发布者 id、标题、封面图片、分类 id、简介、食材清单JSON 或长文本、制作步骤JSON 或长文本、点赞数、收藏数、评论数、浏览量、状态、创建时间。注意“食材”和“步骤”这种列表结构存在关系型数据库里可以有两种建模方式一种是拆成子和表另一种是存 JSON。对于毕设我强烈建议存 JSON 或 TINYTEXT——你不需要用菜谱字段做复杂关系检索拆成子和表反而让查询复杂。自己明白“这是为了简化查询做反范式设计”就行被问到时能解释就是加分项。分类表 t_category常见的类别如川菜、粤菜、烘焙、小吃、家常菜。表虽小但你要做关联设计菜谱表里存分类 id而不是直接存分类名这样以后改名方便。评论表 t_comment菜谱 id、用户 id、内容、父评论 id支持楼中楼、创建时间。设计父评论 id 是为了支持回复和排序字段加一个 root_id 存根评论 id查详情页时先按根聚合再按时间排序不然“只看楼主”之类的功能没法做。互动记录表 t_favorite / t_like这两张表的结构类似用户 id、菜谱 id、状态、创建时间。一定要记得加唯一索引(user_id, recipe_id)否则点赞收藏的幂等全得靠代码判断并发高一点就会插入重复数据。浏览量表 t_view_log如果只做菜谱浏览量的累加直接 update 菜谱表的 view_count 字段就可以。但如果你想在论文里展示“用户行为分析”就建一张浏览日志表记录每次访问的用户和菜谱及时间这样后面做“推荐”和“热榜”都有数据源。2.4 分层架构与请求流程后端三层架构是这类项目的常规解法Controller 负责接收参数和返回统一响应体Service 层写业务逻辑Mapper 层负责 SQL 操作。你可能会问“要不要加 DTO/VO 分层”我的建议是加但别走火入魔。在 controller 和 service 之间我通常会明确区分请求对象DTO和响应对象VO。菜谱保存时前端传的 JSON 结构是“标题、食材数组、步骤数组”而数据库里存的是 JSON 字符串这个转换必须放在 service 层Controller 里不出现任何 JSON 解析逻辑。这样以后改存储方案时只动 service。统一响应体很简单一个类搞定Data public class ResultT { private Integer code; private String message; private T data; }所有接口返回 Result.success(data) 或 Result.error(msg)前端 axios 拦截器里统一处理 code。这套约定看着不起眼但实操中能让你省很多事——你不需要在 controller 里反复写 try-catch统一异常处理器接住业务异常往 Result 里塞就行。前端请求链路就是页面点击 → vue-router 切换组件 → 组件里调 API → axios 携带 token 请求后端 → 后端校验 token → 返回 JSON → 页面渲染。这一条线理清楚前后端联调时基本不会出大乱子。3. 核心功能设计与实现细节别死在细节上3.1 用户注册登录与权限控制用户模块的关键词是“token”和“安全”。登录成功之后后端生成一个 JWT token 返回给前端前端存在 localStorage 里然后每次请求在 axios 拦截器里把 token 放到请求头的 Authorization 字段。这里要写一段很小的代码// axios 请求拦截器 service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer token; } return config; });后端用一个拦截器校验请求头里的 token解析出来如果合法就放行。Spring Boot 中实现方式很简单写一个 HandlerInterceptor在 preHandle 方法里从请求头取 token调用 JWT 工具类解析解析失败就返回 401。然后在 WebConfig 里注册拦截器并记得排除登录、注册、获取分类列表这些公开接口。我见过很多学生第一次写时把静态图片路径也拦了结果前端图片全挂这个细节在配置拦截路径时一定要留意。密码加密这块我必须再强调一遍。用 Spring Security 的 BCryptPasswordEncoder 单独引入即可不用整套 Security 上马。你只要在注册时passwordEncoder.encode(password)入库登录时passwordEncoder.matches(rawPassword, encodedPassword)校验。答辩当面问“如何防止密码泄露”你就可以说“即使数据库泄漏密文也无法反解出明文”这一句就挡掉半个安全问题了。3.2 菜谱发布的完整链路发布菜谱是整个系统最核心的提交场景我们把它拆成三步第一步前端表单。用 Element Plus 的 el-form 写好标题、分类选择、封面上传、简介输入、食材表的动态增删行、步骤表的动态增删行。这里有一个体验细节食材和步骤都支持动态添加行每次 push 一个空对象即可这是很基础的双向绑定操作但页面复杂度一下就上来了。第二步图片文件上传。封面图不能跟着表单 JSON 一起往后端传通常做法是单独先调一次上传接口后端把它存到服务器的指定目录或者云 OSS然后返回一个地址前端把地址拼进表单项之后随表单一起提交。本地存储时需要配置静态资源映射否则上传成功但前端访问 404spring: web: resources: static-locations: classpath:/static/,file:/path/to/upload/第三步后端保存。前端提交的 body 里包含菜谱基本信息和两个数组食材、步骤后端用 DTO 接收Service 层将数组转成 JSON 字符串存进对应 TEXT 字段然后插入菜谱表。事务注解Transactional是必须要加的万一插入过程抛异常不至于留下半截脏数据。3.3 搜索和分类从 LIKE 到覆盖索引“搜索”这件事毕设里常见的做法是 SQL 的 LIKE。SELECT * FROM t_recipe WHERE title LIKE CONCAT(%, #{keyword}, %) OR ingredients LIKE CONCAT(%, #{keyword}, %)这样做简单直观但有两个问题一是%keyword%无法利用普通 B 树索引数据上了几千条还没事到几万条就明显变慢二是搜索食材字段会把 JSON 字符串整个扫一遍。毕设阶段最简单的方案是加个全文索引ALTER TABLE t_recipe ADD FULLTEXT INDEX ft_title (title, introduction)然后在 MySQL 中使用MATCH ... AGAINST查询。这个点解释权很强答辩时可以提“传统 Like 模糊查询无法利用索引全文索引可提升检索效率”已经比大多数人强不少了。分类查询则简单得多菜谱表已经有 category_id直接按该字段过滤配合分页查询即可。注意分类筛选和搜索是可以组合的你可以通过 MyBatis-Plus 的 LambdaQueryWrapper 动态拼接条件就不用手写动态 SQL 了。3.4 评论、点赞、收藏互动的幂等设计这三个功能是平台的“交流”属性所在也是最容易出 bug 的地方。点赞的设计要点用户点击点赞按钮时不能简单让前端把状态变了就当完成——一定要再请求一次后端接口。后端的逻辑是先查 t_like 表是否存在该用户和该菜谱的记录如果不存在就插入并给菜谱点赞数加一存在就删除并减一。这个“先查再写”在并发下可能出现重复插入或计数不准所以表的唯一索引就是兜底手段。数据库层面有唯一索引约束即使并发来了重复请求第二次插入会抛 DuplicateKeyException捕获后按“已点过赞”处理即可。评论的设计要点前端的评论区要展示“根评论 子回复”。我的建议是评论表用 root_id 记录根评论 id查询评论列表时先用“菜谱 id root_id is null”查出根评论再查出 root_id 等于这些根评论 id 的子评论在 Java 层做一次组装成树形结构。这样表结构很简单查询也不复杂。为了优化性能你可以加一个评论数量冗余字段在菜谱表上评论成功后 update 一下这样列表页展示评论数不用每次 count。收藏和点赞高度类似只是收藏不会“点一下取消”而是“只能收藏 / 取消收藏”判断逻辑换成“存在则删不存在则新增”。同样加唯一索引同样在菜谱表冗余字段 favorite_count。3.5 热门推荐榜单怎么排“首页热门菜谱”是这类平台的灵魂板块。最简单的方案按浏览量倒序取前十条。但纯看浏览量有问题——发布早的永远霸榜新内容没有出头机会。所以必须配一个热度公式。我给一个入门但合理的公式热度值 浏览量 * 0.3 点赞数 * 0.5 收藏数 * 0.8 评论数 * 0.7 发布时间加权发布时间加权可以这样写越新发布的菜谱获得一定的基础加分例如(1 - diffDays / 30)这样新内容有自然倾斜同时又不至于完全淹没老内容。直接用 SQL 计算这个热度值然后按热度排序分页。真要做推荐系统那可以扯到协同过滤和离线计算但毕设阶段先把这个公式跑通你能讲明白加权逻辑就已经超过 80% 的人了。4. 实操过程从建表到联调一步步跟你走一遍4.1 项目初始化和配置后端我用 IDEA 创建一个 Spring Boot 项目依赖选择 Web、MySQL、MyBatis-Plus、Lombok、Validation再加一个 JWT 工具库比如 jjwt和 Hutool 工具集。application.yml 里的关键配置长这样server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/cook_platform?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver data: redis: host: localhost port: 6379 servlet: multipart: max-file-size: 10MB max-request-size: 20MB web: resources: static-locations: file:/home/ubuntu/upload/ mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0我习惯把测试时 SQL 日志打开这样前端报错时你能在后端控制台看到实际执行的 SQL定位问题非常高效。文件上传大小限制也提前配好不然菜谱封面大一点直接报 500很浪费排查时间。前端用npm create vuelatest创建项目然后装 element-plus、axios、vue-router、pinia。vite.config.js 里配置开发代理server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } }这样前端开发环境请求 /api 开头的接口会自动转发到后端 8080同时绕开了跨域问题。部署时再让 Nginx 做同样转发。这里有个很基础的逻辑要跟新手讲清楚跨域问题的本质是不同端口前端 5173、后端 8080之间的请求被浏览器拦截了。开发环境用代理转发就绕过去了不是非得在后端配 CORS。4.2 建表实操记录这里直接给两张核心表的 DDL其他表结构类似我就不逐张贴了CREATE TABLE t_user ( id int NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL, password varchar(100) NOT NULL, nickname varchar(50) DEFAULT NULL, avatar varchar(255) DEFAULT NULL, bio varchar(255) DEFAULT NULL, status tinyint DEFAULT 1, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_recipe ( id int NOT NULL AUTO_INCREMENT, user_id int NOT NULL, category_id int NOT NULL, title varchar(100) NOT NULL, cover_image varchar(255) DEFAULT NULL, summary varchar(255) DEFAULT NULL, ingredients_json text, steps_json text, view_count int DEFAULT 0, like_count int DEFAULT 0, favorite_count int DEFAULT 0, comment_count int DEFAULT 0, status tinyint DEFAULT 1, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_category_id (category_id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;建表有几个细节值得注意一是所有文本字段统一用 utf8mb4 而不是 utf8否则用户昵称里放个 emoji 就报编码错二是冗余计数字段——like_count 等直接放 recipe 表里查列表页不需要 count 关联表省下一个 N1 问题。虽然冗余字段有数据一致性问题但毕设项目你只要保证“增删改时同步更新”即可论文里大胆写“用空间换查询性能”。4.3 核心后端接口代码示例登录接口的代码逻辑非常简单但写好它需要层次分明RestController RequestMapping(/api/auth) public class AuthController { Resource private AuthService authService; PostMapping(/login) public ResultLoginResponse login(RequestBody Valid LoginRequest request) { LoginResponse response authService.login(request.getUsername(), request.getPassword()); return Result.success(response); } }Service 层里public LoginResponse login(String username, String rawPassword) { User user userMapper.selectOne( new LambdaQueryWrapperUser().eq(User::getUsername, username)); if (user null || !passwordEncoder.matches(rawPassword, user.getPassword())) { throw new BusinessException(用户名或密码错误); } if (user.getStatus() 0) { throw new BusinessException(账号已被禁用); } String token jwtUtils.generateToken(user.getId(), user.getUsername()); return new LoginResponse(token, user); }菜谱发布接口我习惯放在 RecipeControllerPostMapping(/publish) public ResultLong publish(RequestBody Valid RecipePublishRequest request) { Long recipeId recipeService.publish(request, currentUserId()); return Result.success(recipeId); }Service 层把食材和步骤数组序列化成 JSONTransactional public Long publish(RecipePublishRequest request, Long userId) { Recipe recipe new Recipe(); BeanUtils.copyProperties(request, recipe); recipe.setUserId(userId); recipe.setIngredientsJson(JSONUtil.toJsonStr(request.getIngredients())); recipe.setStepsJson(JSONUtil.toJsonStr(request.getSteps())); recipeMapper.insert(recipe); return recipe.getId(); }这里的 currentUserId() 是你封装的一个从 Token 解析出的当前登录用户 id可以用 ThreadLocal 存起来。这套代码写完整个项目的主干已经通了。4.4 前端页面与后端联调前端联调阶段最有价值的一件事是先把 axios 封装好了再写页面。写一个 request.js封装 baseURL、请求拦截器带 token、响应拦截器统一判断 code。这样所有页面的代码都很干净。以首页菜谱列表为例组件里这样做const fetchRecipes async () { loading.value true; try { const res await api.get(/recipe/list, { params: queryParams }); recipeList.value res.data.rows; total.value res.data.total; } finally { loading.value false; } };“交流”体验上列表卡片需要展示封面、标题、作者昵称、点赞数和收藏数。作者昵称在列表接口中通过联查 t_user 表获得或者菜谱表冗余一个 authorName 字段。冗余的方案在联查很频繁时效率更好但要注意用户改名后冗余字段同步。联调时其实大部分时间不是在写代码而是在核对字段名。前端要的coverImage后端返回了cover_image或者日期时间格式对不上这类问题是新手消耗最多时间的部分。我的习惯是后端统一用驼峰命名返回 JSONMyBatis-Plus 默认配置下数据库下划线字段会自动映射到驼峰属性响应自然也是驼峰前端直接匹配基本零摩擦。5. 常见问题排查与避坑实录这部分都是我在实际做项目中被问得最多、也是学生踩得最多的坑按频率排个队。问题现象根本原因解决方案前端上传图片后访问 404静态资源映射没配置文件写了但无法访问在 application.yml 配置 resources.static-locations或用配置类注册 ResourceHandler登录后访问 /api/recipe/list 返回 401拦截器拦截了需要放行的接口在 WebConfig 的 addInterceptors 中排除白名单比如登录注册、资源目录使用 axios 请求后端 CORS 报错前端端口与后端端口不一致开发环境用 vite proxy不走代理时后端写 CORS 配置类分类列表每次刷新都查数据库没有缓存或缓存过期策略丢失最简单可加 Spring Cache 或手动 Redis 缓存分类点赞后数字不准确出现重复点赞表缺少唯一索引代码只靠查询判断建联合唯一索引 (user_id, recipe_id) 做兜底菜谱表数据到几千条后查询变慢LIKE %keyword% 无法走索引加全文索引或改为前缀模糊注意全表扫描的识别富文本内容用文本域存显示 HTML 标签没有用 Markdown 或富文本编辑器的安全过滤前端引入 v-html 时用 Markdown 转 HTML服务端做内容转义上传大文件直接报错multipart 大小限制没设置在 yaml 中配置 spring.servlet.multipart.max-file-size排第一的是静态资源 404。我给不止一个学生排查过这个问题图片路径正确、文件也确实上传到服务器了但浏览器访问还是 404。原因就是 Spring Boot 默认只把代码里的 static 文件夹当作静态资源根目录你上传到本地磁盘的目录并不在其内。解决方法两个要么用配置类显式加注册要么如上面配置所示加上 static-locations。这个问题在答辩现场演示时如果爆出来场面会很难看所以务必提前写好。排第二的是跨域和拦截器混在一起的问题。学生加了拦截器之后发现不光登录接口能用连浏览器直接请求图片都拦了。我的建议是拦截器的职责只做“需要登录接口”的 token 校验像图片访问这种静态资源交给 Spring Security 的话你有更细粒度的规则但拦截器就是简单粗暴——白名单放行后再逐一排查。还有一类问题不是技术而是习惯代码不写日志。很多学生 debug 用 System.out.println 甚至前端 alert。我强烈建议后端 Service 层关键逻辑加Slf4j的 info/debug 日志。排查问题最快的方式是看日志而不是重新复现。这习惯不一定是答辩加分项但绝对是工作分水岭。6. 从“能跑”到“出彩”加分项与答辩准备6.1 设计模式在项目里怎么落地老师问“项目用了哪些设计模式”时你要么你有要么你过硬编能编最怕的是没编好让老师发现是现背的。厨艺交流平台里天然有几个表适合引出设计模式这些都是实际可落地的策略模式菜谱排序策略。热门榜、最新榜、综合推荐榜是三个不同的算法规则定义一个 RecommendStrategy 接口下面有 HotStrategy、NewStrategy、HybridStrategy通过工厂模式根据前端参数选择不同的策略执行。这比一长串 if-else 看着强太多也好理解。模板方法模式发布内容的前置处理和后续通知。发布一个菜谱、发布一个评论都涉及“校验用户状态、保存内容、更新计数、发送通知”这几个固定步骤可以定义一个 AbstractPublishProcessor 模板方法子类只实现 save 逻辑。观察者模式用户发布菜谱后要通知粉丝。真实系统会引入消息队列但毕设可以用 Spring Context 的事件机制发布菜谱时 publishEvent监听器异步处理。这个设计讲出来老师一般会有点点头。6.2 性能与体验加分项Redis 缓存是最容易展示的性能优化点。对首页热门菜谱和分类列表做缓存缓存失效策略选择热门榜每 30 分钟刷新一次分类列表用Cacheable并在后台改分类时CacheEvict失效。你需要写的代码量极少但对性能的说明能写一整节。分页性能方面MyBatis-Plus 的分页插件配置方法Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }列表页对评论计数、点赞计数使用冗余字段避免每次列表都去 count 大表是应付“大数据量”提问的直接素材。6.3 答辩常问问题预演根据这几年指导经验厨艺交流平台被问到的问题高度集中在这几个第一个“菜谱步骤用 JSON 存为什么不用关联表”你要答出反范式设计的取舍强调这是为了搞复杂对象存储时减少表数量和查询复杂度同时抛出“若需按步骤检索可以再用子表”作为演进方向。第二个“用户密码怎么存储的”答 BCrypt 加密加盐非对称可验证不可逆。千万别答 MD5 加盐后就说安全了现在老师对 MD5 有天然的追问欲。第三个“如果用户量很大哪些表会出问题”这是性能题。答菜谱表为主的热点数据通过 Redis 缓存点赞数更新用异步队列或定时刷盘关注数据库连接池压力。不一定都要实现但能清晰梳理就是高分。第四个“项目的核心难点是什么”这题不能答“没有难点”也不能堆词“高并发、缓存穿透”。你要诚实讲出“评论楼中楼组装复杂”“热度排序策略调参”这类具体问题体现真实开发过程。我个人在带毕设时一直强调一件事答辩老师看重的不是你的项目有多宏大而是你在做项目过程中有没有真实理解每个模块是怎么运转的。把本文提到的细节按顺序吃透每个核心功能你都能说出“为什么这样设计”答辩环节基本稳了。最后分享一个小技巧整个项目尽量提前两周完成主体功能剩余时间专门用来“讲给旁听的人听”。把每个模块用一分钟讲清楚反复练直到不需要思考就能流利回答。你的毕设成果不只是代码更是你能把代码背后的思路清晰转述的能力。祝你顺利。