每年到了三四月份总能在各个技术群里看到同一类问题SpringBoot毕设到底做什么题目好我当初也被这个问题折磨了很久翻遍了网上所谓的毕业设计题目集十有八九是商城系统、后台管理系统这类做了无数遍的东西技术含量说不上来答辩的时候也很难讲出亮点。后来兜兜转转定了“基于SpringBoot的健康饮食菜谱社区平台”这个方向从选题、搭框架、写业务到最后论文和答辩整整折腾了三个多月。这个项目既覆盖了用户注册登录、菜谱发布、图片上传、评论点赞收藏这类常见功能又能往数据分析和轻食推荐这个差异化方向深入做用来当毕业设计可以说是非常合适了。本文就把这个项目从需求到落地再到答辩的全过程完整拆解一遍尤其是那些网上教程不会告诉你的坑和细节打算做菜谱分享平台的同学可以直接参考。这个系统的核心价值其实不难概括用户可以在平台上浏览菜谱、按分类和标签搜索、自己发布做菜过程也可以收藏、点赞、评论其他人的作品管理员在后台审核和管理内容在此基础上系统还根据用户浏览和收藏的菜谱标签做了一版“轻食推荐”模块专门推荐低热量、高蛋白、素食这类符合健康饮食预期的菜谱。下面我按自己做项目时的推进顺序来写从需求到数据库再到功能实现、推荐逻辑、最后的测试和答辩每一块都会说清楚当时是怎么想的、怎么写更稳妥。1. 毕设选题菜谱社区这个方向是怎么定下来的1.1 为什么我看不上普通的“管理系统”类题目很多毕设题目看起来挺好做比如学生信息管理、图书借阅管理、仓库管理系统本质上就是把一张表做增删改查再加个登录和权限。这类题目有个致命的问题业务逻辑太薄。你辛辛苦苦写了两个月论文里能写的核心内容只有“对X表的CRUD操作”答辩时被问到“你这个系统解决了什么复杂问题”就完全接不上话。我不太建议去做这种题目除非你只想混个及格。相比之下菜谱分享平台天然具备多个维度的复杂度用户体系注册、登录、个人信息、收藏、点赞、评论、关注涉及完整的用户行为数据。内容生产菜谱发布包含多图上传、食材清单、步骤文本、标签分类内容结构比普通文章复杂。交互关系点赞和收藏的幂等处理、评论的层级回复、热门排序这些都是面试和答辩常问的点。业务差异化在这个基础上再加“轻食推荐”模块让系统从一个纯展示型网站变成带推荐逻辑的社区平台论文的档次立刻不一样。所以当时我定方向的核心思路是找到一个能同时覆盖基础功能和进阶功能的业务场景。菜谱平台正好满足——基础功能全进阶场景推荐、数据分析也完全够得着。1.2 从“菜谱分享”到“轻食推荐”的需求演变刚开始我的想法很简单就是做一个菜谱浏览和发布网站。后来和周围几个同学聊了聊又去问了某导师大家的反馈很一致如果只是菜谱分享和美食博客有什么区别你得think出一个让人记住的功能点。于是调研了一圈后发现现在做菜谱App的不少但专门做“轻食推荐”这个细分方向的其实不多。轻食的概念很好理解低油低盐、热量可控、营养均衡代表菜谱就是鸡胸肉沙拉、藜麦饭、全麦三明治、水煮虾仁这类。对于有减脂需求或者健康饮食习惯的用户来说他们不想逛整个菜谱库就想快速找到“热量低于400大卡”“高蛋白”“素食”这几个条件的菜谱。这就出现了明确的用户场景用户进入推荐页面选择“低卡”“高蛋白”“素食”等标签系统返回符合要求的轻食菜谱同时结合用户平时收藏、浏览过的菜谱偏好进行个性化排序。这个需求清晰、可落地、有差异化而且能写进论文的“创新点”部分非常划算。1.3 定稿的功能清单我把第一版需求文档整理成如下功能模块模块功能点角色用户模块注册、登录、个人信息修改、头像上传用户菜谱模块菜谱浏览、分类筛选、关键词搜索、菜谱详情游客/用户发布模块发布菜谱、编辑、删除、图片上传用户交互模块点赞、点踩取消、收藏、评论、回复评论用户轻食推荐模块标签组合筛选、个性化推荐位、热门回退用户管理模块用户管理、菜谱审核、评论删除、推荐位配置管理员数据统计菜谱浏览量统计、点赞收藏数排行管理员这个功能清单基本就是后来系统全部开发的内容。技术上覆盖了认证鉴权、CRUD、文件上传、关联查询、排序统计、简单推荐算法等多个轮子。后面每一步都是照着这个清单往下落地的。2. 技术选型为什么是SpringBoot这一套组合2.1 SpringBoot到底比传统SSH好在哪现在做毕设选框架只要不是特殊情况我都会直接推荐SpringBoot而不是SSHSpring Struts Hibernate或者SSMSpring SpringMVC MyBatis手动配置版。原因很简单SpringBoot把大量样板配置变成了自动装配你只需要关心业务代码。举个例子传统SSM要写数据源配置、事务配置、SpringMVC配置、Web.xml配置稍微弄错一个namespace就起不来。SpringBoot引入starter依赖后数据源、事务、JSON序列化、拦截器这些都自动搞定你只写一个application.yml就能把工程跑起来。更重要的是SpringBoot的生态极其成熟几乎你能想到的功能都有现成的starter。做文件上传有SpringMVC的MultipartFile做接口文档有Swagger或者Knife4j做参数校验有validation starter做缓存有Redis starter。这意味着在毕设周期内你能把时间花在真正的业务逻辑上而不是无尽的配置debug里。2.2 前后端技术栈组合我的技术栈是下面这套特点是比较稳不容易踩出特别冷门的坑层级技术选型选型理由后端框架SpringBoot 2.7 MyBatis-Plus启动快、生态成熟、MP大幅减少SQL编写量认证方案JWT 拦截器无状态、前后端分离友好、答辩能讲出设计思想数据库MySQL 8.0稳定、资料多、索引和事务支持完善缓存Redis做验证码、热点菜谱缓存也可以不接有加分文件存储本地磁盘 Nginx路径映射毕设阶段不用对象存储省事省钱前端Vue 2 Element-UI Axios上手快、组件全、三天能搭出后台页面接口文档Knife4j自动生成在线接口文档论文里能放截图有不少人问我为什么用MyBatis-Plus而不是JPA或者原生MyBatis我的理由是三个字省时间。MyBatis-Plus的BaseMapper让你少写大量单表CRUD SQL分页插件PaginationInnerInterceptor一行配置就支持分页查询。毕设阶段的单表操作至少占了60%这一下就省出了两到三周的时间去做推荐模块和论文。2.3 环境配置里的三个坑提前帮你踩掉在项目启动前有几个环境问题几乎每个人都会遇到。先说一下省得到时候发疑问帖JDK版本SpringBoot 2.7默认适配JDK 8如果你的机器装的是JDK 17那么很多老教程里的javax.*包会报错。建议直接用JDK 8或者JDK 11不要把时间浪费在兼容性上。如果用SpringBoot 3.x那必须JDK 17这个要看清楚。Maven依赖冲突引入MyBatis-Plus和Knife4j时偶尔会出现jackson-databind版本冲突处理方法是统一在pom.xml的dependencyManagement里指定版本号。8080端口被占用Windows上命令行执行netstat -ano | findstr 8080找到占用进程PID任务管理器里结束进程或者直接在application.yml换端口。这些看起来都是小事但一旦卡住会浪费一整天。我的经验是把环境问题放在正式开发前统一解决后面才能安心写业务。3. 数据库设计表结构决定了你后期改代码的频率3.1 数据表总体规划数据库是毕设项目的地基表设计得不好后面做关联查询和统计数据时会痛苦到怀疑人生。我总共设计了9张核心表这里直接放总览表名作用关键字段user用户信息昵称、密码、头像、角色recipe菜谱主表标题、封面、描述、步骤、浏览量category菜谱分类分类名、排序、图标ingredient食材表菜谱关联食材、用量、热量tag标签表标签名低卡、高蛋白等recipe_tag菜谱标签关联表recipe_id、tag_idfavorite_record收藏记录用户、菜谱、时间like_record点赞记录用户、菜谱、时间comment评论表内容、父评论id、楼层这套表结构基本覆盖了全文功能。我没有单独设计推荐记录表而是通过recipe_tag和用户行为表动态计算推荐结果这样代码逻辑更灵活论文里也能写“实时计算”四个字。3.2 核心表的字段细节以recipe表为例我建表的SQL是这样的省略了部分索引CREATE TABLE recipe ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 发布者id, category_id bigint NOT NULL COMMENT 分类id, title varchar(100) NOT NULL COMMENT 菜谱标题, cover_image varchar(255) DEFAULT NULL COMMENT 封面图, description text COMMENT 简介, steps text COMMENT 步骤JSON或Markdown, view_count int DEFAULT 0 COMMENT 浏览量, like_count int DEFAULT 0 COMMENT 点赞数, favorite_count int DEFAULT 0 COMMENT 收藏数, status tinyint DEFAULT 1 COMMENT 1正常 0下架, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_category (category_id), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜谱表;有几个设计点是后来返工总结出来的点赞数、收藏数这类统计字段要提前冗余到主表里。如果每次页面显示都去count关联表数据量一大SQL就会变慢。更新时也不容易出现并发问题一个UPDATE recipe SET like_count like_count 1 WHERE id ?就能搞定。当然严格一点可以做事务和乐观锁毕设阶段用这个够了。steps步骤字段用TEXT存JSON格式类似[{desc: 切菜, img: xxx.jpg}]。你还得再建一张步骤表否则一个菜谱十几个步骤全拆开非常难维护。毕设的评分离不开“合理的设计决策”我会在论文里说明为什么用JSON存储。status状态字段非常关键。管理员审核、用户下架自己的菜谱、违规内容屏蔽全都要靠这个字段对前台隐藏数据。如果不做逻辑删除而直接物理删除数据统计和管理日志就会出问题。3.3 标签与推荐相关表的设计轻食推荐能跑起来核心建立在tag和recipe_tag两张表上。tag表很简单字段就四个id、name、type、sort。type用来区分是“菜系标签”还是“轻食标签”比如“低卡”“高蛋白”“素食”“无麸质”这些轻食标签类型统一为light_food。推荐页的最大作用就是根据这些标签组合来筛选菜谱。recipe_tag关联表则多了一个字段我称为weight权重CREATE TABLE recipe_tag ( id bigint NOT NULL AUTO_INCREMENT, recipe_id bigint NOT NULL, tag_id bigint NOT NULL, weight int DEFAULT 1 COMMENT 标签权重, PRIMARY KEY (id), UNIQUE KEY uniq_recipe_tag (recipe_id, tag_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;weight是我做个性化推荐时的关键字段。什么意思呢比如一道“香煎鸡胸肉沙拉”它同时挂了“高蛋白”“低卡”“轻食”三个标签但它的核心特色是“高蛋白”那么这三个标签的权重可以分别是5、3、1。用户在推荐页只要勾选“高蛋白”这道菜的匹配分就会因为权重高而排在前面。这种简单的带权匹配比起单纯“有或无”的过滤推荐效果要自然得多。3.4 索引设计经验毕设阶段不需要特别复杂的索引优化但你要让答辩老师看到你懂索引。我在三个地方加了索引recipe表的category_id和create_time支持分类页和时间排序。like_record表的(user_id, recipe_id)唯一索引天然防止重复点赞。comment表的recipe_id索引查询某个菜谱评论时不会全表扫描。这里有个小建议做菜谱搜索如果直接用LIKE %关键词%数据量大了会慢。毕设阶段数据量小无所谓但如果你想在论文里提一手可以在title字段建全文索引用MATCH...AGAINST查询就算真上了几千条数据查询也依然很快。4. 核心功能实现注册登录、图文发布和社区互动4.1 JWT登录认证的完整链路用户模块是所有系统的入口我这里选JWT而不是传统的Session主要是两个原因一是前后端分离架构下JWT天然无状态适合Vue页面和后端分开部署二是每次请求带token你可以把JWT的手动校验写进拦截器这个设计在答辩里非常加印象分。JWT的工作链路是用户登录成功后后端生成一个有效期两小时的token包含userId和role信息。前端把token存到localStorage每次请求时在Axios拦截器里加上Authorization: Bearer token。后端定义一个拦截器从请求头取出token解析校验通过后把userId放到ThreadLocal里供后续业务使用。核心拦截器代码大致长这样public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BizException(未登录); } // 解析token这里用jjwt库 Claims claims Jwts.parser() .setSigningKey(你的secretKey) .parseClaimsJws(token.replace(Bearer , )) .getBody(); Long userId Long.valueOf(claims.get(userId).toString()); UserContext.setUserId(userId); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }这里的两个细节我要提醒一下ThreadLocal用完一定要清理否则Tomcat线程池复用时会串用户数据这种bug排查起来非常痛苦。密码必须加密存储用BCryptPasswordEncoder别用MD5。MD5查表秒破答辩老师基本都会问这个问题你用BCrypt回答还能顺带讲一下“加盐哈希”的原理。4.2 菜谱发布图片上传与内容组装菜谱发布是整个系统最核心的内容生产功能。用户在页面上填写菜谱标题、分类、封面图、简介然后按步骤添加文字和对应图片前端最终组装成JSON数据传给后端。图片上传这里有个很容易被忽视的问题文件类型校验必须做两层。前端校验是给用户体验的后端校验才是安全的。后端校验除了看扩展名还要取MultipartFile.getContentType()判断MIME类型最好再限一下文件大小比如单张不超过5MB。否则用户传一个超大图片或者恶意文件到服务器一堆连锁问题就出来了。我当时是在本地建了一个upload/目录存放图片然后通过路径映射的方式在浏览器访问。SpringBoot里设置一个WebMvcConfigurer就可以Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file:你的本地路径/upload/); }菜谱发布请求的Controller层接口大致是PostMapping(/api/recipe/publish) public ResultLong publish(RequestParam(file) MultipartFile cover, RequestParam(data) String dataJson) { // 1. 保存封面图 String coverUrl fileService.save(cover); // 2. 解析dataJson反序列化为RecipePublishDTO // 3. 组装Recipe实体写入recipe表 // 4. 解析食材列表和步骤写入ingredient表 // 5. 解析标签id列表批量写入recipe_tag表 return Result.success(recipeId); }注意菜谱发布这里是多表写入必须加Transactional事务。步骤表、食材表、标签关联表任何一个失败都需要整体回滚否则就会产生“有菜谱主体但没有食材明细”的脏数据。另外菜谱正文的渲染做一下防XSS处理。富文本编辑器的内容最后会以HTML形式展示如果不做过滤用户发一段script标签就能在其他人浏览器里执行这是很严重的安全问题。如果你用了富文本编辑器后端拿到内容后先剥离危险标签或者干脆用Markdown解析器只渲染规范的Markdown语法安全性和体验都不错。4.3 点赞、收藏、评论的三个典型问题这三类是社区交互的核心也是我在调试中花时间最多的地方。问题一怎么防止重复点赞。我第一次写点赞时逻辑是查询有没有记录没有就插入点赞有就取消。看起来没啥问题但两个人同时点赞就会并发插入两条相同的记录。后来改成在like_record表建了(user_id, recipe_id)的唯一索引然后直接执行INSERT ... ON DUPLICATE KEY UPDATE或者先查再插入把兜底交给数据库唯一约束问题彻底解决。问题二点赞状态和数量的更新边界。一个常规操作是用户点击点赞 → 插入like_record→recipe.like_count 1→ 再返回最新状态。这三步一定要放在同一个事务里。开发时最容易犯错的是先把like_count加了但like_record插入失败数据量就对不上了。我的建议是把“写行为表”和“更新统计字段”放到同一个Service方法加Transactional。问题三评论的楼层数和父级回复。评论模块我加了parent_id字段顶级评论的parent_id是0回复某条评论时填对应评论id。前端展示时通过递归组件或一次查询全部评论后在后端组装成树形结构返回。这里的关键是排序顶级评论按create_time升序排列子评论按时间降序这个逻辑要和前端约定好。4.4 菜谱搜索和热门排序的落地方式菜谱搜索可以做得非常简单title LIKE %关键词%然后按create_time desc返回。但配合分类筛选时SQL就变成了动态拼接select idsearchRecipes resultTypecom.example.entity.Recipe SELECT * FROM recipe WHERE status 1 if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %)) /if if testcategoryId ! null AND category_id #{categoryId} /if if testlightFood ! null and lightFood AND id IN (SELECT recipe_id FROM recipe_tag WHERE tag_id IN (轻食标签id集合)) /if ORDER BY ${orderField} ${orderDir} /select热门排序上我采用了“多字段加权”的方式不单纯按浏览量排序。我给推荐页和首页热门版块定义了一个热度分score view_count * 1 like_count * 3 favorite_count * 5 comment_count * 2最后按score降序。如果想要时间衰减可以再乘一个1 / (天数差 2)的衰减因子让老数据慢慢降权。这个公式不复杂但能在答辩中讲清楚设计动机我给几个同学看过他们最后也直接参考了这个思路。5. 轻食推荐模块不堆算法的推荐方案也能出彩5.1 推荐逻辑的定位与召回策略做推荐模块的时候我反复问自己一个问题一个毕设项目到底需要多复杂的推荐算法答案是不需要。真正的推荐系统要考虑用户冷启动、物品冷启动、实时召回、粗排精排那是工业界做的事。毕设阶段更需要的是一个“逻辑闭环”用户在推荐页选择轻食标签系统根据标签匹配分和自己的历史行为返回结果而且推荐结果是可解释的。我的推荐模块拆成了三步召回根据用户选择的一个或多个轻食标签先从recipe_tag表中查出所有挂了这些标签且状态正常的菜谱id集合。如果用户没有选择标签则直接召回所有已上架菜谱。过滤过滤掉用户已经点过踩的菜谱和本人发布的菜谱避免推荐内容太重复。排序根据匹配权重和用户历史行为调整排序。最简单的代码写法是这样public ListRecipeVO recommend(RecommendRequest req, Long userId) { // 1. 按标签召回 ListLong recipeIds recipeTagMapper.selectRecipeIdsByTagIds(req.getTagIds()); if (recipeIds.isEmpty()) { recipeIds recipeMapper.selectAllNormalIds(); } // 2. 过滤 ListLong dislikeIds userBehaviorMapper.selectDislikeRecipeIds(userId); recipeIds.removeAll(dislikeIds); // 3. 加权排序 ListRecipeVO result recipeService.listByIds(recipeIds); result.sort((a, b) - scoreOf(b, userId) - scoreOf(a, userId)); return result; }加权排序的score来源有两部分一是菜谱在选定标签上的权重之和二是用户历史收藏、浏览过的菜谱标签的偏好分。后者的实现是统计用户收藏过的所有菜谱对应的标签分布得到用户对各标签的偏好权重再把当前菜谱的标签权重乘以用户对应偏好权重累加得到最终的个性化得分。5.2 冷启动没有任何历史行为的用户怎么办如果用户是刚注册的没有任何收藏和浏览记录个性化排序就没有数据支撑。此时我采用了两个回退策略如果用户勾选了轻食标签按标签权重总和排序相当于“热门轻食”推荐。如果用户没勾选标签直接返回全局热度分最高的菜谱列表即前面说的热度分公式排序。这个逻辑在论文里叫“冷启动—热门兜底策略”。虽然原理特别简单但它是推荐系统真实场景里必然会遇到的问题答辩老师问到“新用户进来推荐什么”你就可以顺势把这个设计讲出来显得你有完整思考。5.3 推荐模块的实际效果与后续改进空间用几百条mock数据实测下来推荐模块的效果可以分为两种情况用户选了“低卡高蛋白”标签时返回的菜谱基本都是鸡胸肉、虾仁、豆腐类非常精准。用户用个性化推荐无标签时如果历史行为足够推荐结果能看出明显偏好如果历史行为少结果和热门列表几乎一样这也符合预期。我在论文里也承认了这个方案的简单性然后补充了改进方向可以考虑基于协同过滤的UserCF计算用户相似度然后推荐相似用户喜欢的菜谱或者引入更细致的食材热量表让热量区间参与排序。毕设答辩时主动说“这个项目的推荐实现立足于可解释、可落地后续可改进方向是协同过滤和图神经网络”既能体现出你不回避问题又展示了你对推荐系统的了解边界这个度刚好。6. 测试、部署、论文与答辩这些环节比写代码更拉分6.1 测试用例怎么设计才不心虚很多同学做完项目就赶紧去写论文测试只是随手截两张图这在答辩时很容易被问穿。我当时在项目里专门建了一个test目录按照业务模块写了三类测试单元测试针对工具方法、密码加密、推荐打分函数做测试比如“给定一个菜谱标签权重集合打分函数能否正确计算总分”。接口测试用MockMvc直接测试Controller层覆盖登录、发布菜谱、点赞等核心接口的正常和异常路径。并发测试这个能体现深度——可以用Jmeter或者自己写多线程代码模拟100个用户同时点赞同一个菜谱验证数据库唯一索引和事务是否生效like_count是否一致。不用追求覆盖率90%以上那是大厂的要求。但建议核心业务达到70%左右并且测试报告里的截图要放进论文附录。我就靠并发测试那一小节在答辩时至少被问了十分钟。6.2 部署过程中遇到的三类典型问题我把项目部署到云服务器上时踩了三个坑几乎每个人都有份跨域问题。前端Vue跑在8081端口后端跑在8080端口浏览器直接请求就会触发CORS拦截。解决办法是在后端写一个CorsConfig注册跨域映射而最简单的是用过滤器加响应头httpServletResponse.setHeader(Access-Control-Allow-Origin, http://localhost:8081); httpServletResponse.setHeader(Access-Control-Allow-Methods, GET, POST, PUT, DELETE, OPTIONS);数据库连接问题。云服务器上MySQL默认只允许localhost访问如果你想让本地电脑连服务器数据库需要授权远程用户并开放3306端口。毕设演示一般在本地这个坑不一定遇到但保险起见做好。图片路径问题。本地开发时图片路径用的是绝对路径部署到Linux服务器后路径全变了。建议把上传路径写进配置文件然后用一个常量类读取别在代码里写死。6.3 论文结构和答辩演示的脚本设计论文方面我强烈建议按照“选题背景→需求分析→系统设计→功能实现→推荐算法设计→系统测试→总结展望”的结构来写。这其实就是你开发流程的自然映射每一章节都有真实代码和截图作为支撑不会出现临时编造内容的情况。答辩演示时有一个小技巧准备“主演示流程”和“备选演示流程”两套方案。主流程是提前录好的完整视频确保关键功能不出错因为现场演示很可能因为网络、浏览器兼容、环境变量问题翻车。备选流程是如果时间不够或者视频播放失败就直接打开本地的核心页面快速演示登录、发布菜谱、推荐结果三个高光功能每个功能控制在1分钟以内。我当时答辩时评委的第一个问题是“你推荐模块用什么算法”第二个是“怎么保证推荐结果不是随便随机出来的”第三个是“这个系统相比美食社区网站有什么优势”。这三个问题中前两个都能从论文和技术方案中找到完整回答第三个则考察你对行业场景的理解。我的回答是平台聚焦轻食细分领域推荐结果更贴近健康饮食需求同时提供公开的菜谱标注和热量参考。这类回答没有唯一答案但你要能自圆其说。最后再分享几个做这类项目的小心得整个项目做下来我最深的感触是毕业设计不只是为了过查重它更像一次给你三个月时间做一个小产品的训练。选对题目方向后面会越做越顺选错题目每天写代码都是在添堵。SpringBoot菜谱分享平台这个方向覆盖面足够广推荐模块又有一定创新空间无论最后成绩如何做完这个项目你对SpringBoot的依赖注入、拦截器、事务管理、MyBatis-Plus的源码逻辑都一定有一个质变。最后给个很实在的小建议代码里尽量把日志打全。别觉得日志不重要在你部署上线或者答辩前调试的时候一句清晰的日志比看代码快十倍。我那时在点赞接口加了一行log.info(user {} like recipe {}, userId, recipeId)后来追踪并发问题时就靠它定位了顺序。希望这篇拆解能让你少走点弯路。按这个思路做下来你有大概率在答辩时能自信地讲清楚每一个设计决策的来源而不是干巴巴地念PPT。