我见过太多把“美食分享平台”做成“用户表 菜谱表 评论表”三张表的项目了。标题看着挺全真点开代码就是Spring Boot入门级别的CRUD业务逻辑全靠前端硬撑。但今天要拆的这个厨房达人美食分享平台确实是把“菜谱 笔记”这两个核心场景做出了点值得说的东西。它不只是一个典型的Java Spring Boot毕设项目更是一套完整可落地的“美食社区”样板——从用户体系、内容发布、图片上传到评论互动、搜索聚合每一环都有真实的业务逻辑在推着走而不是空对空的增删改查。对正在做Java课设、毕业设计或者想深入了解Spring Boot全栈开发的人来说这套项目的参考价值在于你能看到“一个功能完整的项目”到底应该怎么组织代码、怎么设计表结构、怎么处理文件上传和事务这类实战问题。我基于这套源码和文档把项目完整跑通过也顺手梳理了它的结构、设计思路和实现细节下面把整个过程拆开讲。1. 立项逻辑从“收藏夹吃灰”到“可沉淀的美食笔记”1.1 真实痛点美食博主的笔记困境先说个小场景。我自己平时做菜最烦的不是不会做而是“收藏了二十个红烧肉教程真正开火的时候不知道哪个靠谱”。更麻烦的是有些平台教程太碎评论区、笔记区、视频区各说各话想针对某道菜补充一句自己的实操心得根本找不到合适的位置。这套系统的立项逻辑其实就是冲着这个痛点去的。它想解决的不是“提供一个发菜谱的地方”而是“让菜谱和笔记形成一套完整的知识沉淀体系”——菜谱是主线笔记是围绕菜谱展开的补充、纠错、改良记录。用户既可以发布完整的菜谱也可以在他人菜谱下写自己的实操笔记把“我今天试了一下糖放少了建议再加10克”这类真实经验留存下来。1.2 功能边界这套系统到底做了哪些事从功能清单上看典型的完整项目模块包括这些用户模块注册、登录、个人信息维护以及基于JWT的登录鉴权菜谱模块菜谱发布、编辑、删除支持封面图和步骤图的上传分类、难度、耗时等元信息维护笔记模块针对菜谱或自己收藏的菜谱写笔记支持追加内容形成类似“厨房手账”的记录互动模块点赞、收藏、评论以及对应的列表展示和数量统计搜索模块按菜谱名称、关键词、分类进行模糊搜索部分版本还会做热度排序。这套功能做出来之后整体就构成了一个“用户—菜谱—笔记—互动”的闭环。用户来了不只是被动浏览还能沉淀自己的实操经验这就比单纯的菜谱展示网站多了一层社区属性。2. 技术选型与工程骨架Spring Boot 项目的搭建思路2.1 为什么是 Spring Boot而不是 SSH 或 Servlet 原生技术选型上这套项目锚定Java Spring Boot是合理的。放到三四年前很多课设项目还在用SSHStruts Spring Hibernate或者Servlet JSP配置繁琐、启动慢、依赖管理混乱。Spring Boot最大的价值在于“约定优于配置”内嵌Tomcat、自动装配、起步依赖让开发者能把精力放在业务代码上而不是折腾XML配置文件。具体来说我用下来觉得Spring Boot 2.x版本在这类项目上非常顺手。它不需要你事无巨细地配置Bean一个SpringBootApplication注解就把组件扫描、自动配置、属性绑定全包了。对于菜谱平台这种业务逻辑清晰、需要快速迭代的项目开发效率提升是肉眼可见的。2.2 配套组件的选型组合完整的项目不可能只靠Spring Boot核心我梳理下来的组合大致是这样模块选型理由持久层MyBatis-Plus既保留了SQL可控性又提供了IService和BaseMapper等现成CRUD能力写业务代码速度极快数据库MySQL 5.7 / 8.0生态成熟部署简单菜谱数据用关系型存储非常合适鉴权JWT Spring Security 或拦截器无状态登录前后端分离场景下比Session更灵活接口文档Swagger / Knife4j生成API文档方便调试接口也用得上前端Vue Element Plus和后端分离页面组件化表格表单开发效率高文件存储本地磁盘 访问映射或MinIO菜谱图片上传场景简单本地目录静态资源映射可以满足学习和毕设需求这里我要多说一句关于文件存储的选择。很多同学一上来就纠结“要不要上OSS、要不要接MinIO”其实在毕设或课程设计阶段本地存储完全够用。Spring Boot里配置一个web.resources.static-locations指向上传目录图片上传后返回相对路径前端直接拼URL访问整个链路简单、可运行、不依赖外部服务。等真正上了生产环境再切换对象存储也不迟。2.3 分层架构与代码组织工程结构上我倾向于经典的四层结构com.example.foodshare ├── controller // 接口层接收参数、返回结果 ├── service // 业务逻辑层处理业务规则 ├── mapper // 数据访问层MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto / vo // 入参和出参对象 ├── config // 配置类如跨域、Swagger、WebMvc ├── utils // 工具类如JWT工具、文件上传工具 └── common // 统一返回结果、异常处理、常量这样做的好处是Controller层很薄只做参数接收和结果包装Service层承载业务逻辑Mapper层专注数据访问。后面调试的时候不管是从接口入口查到SQL执行还是从异常栈定位到业务逻辑都很清晰。特别是答辩的时候评委问“这段业务逻辑在哪”你能直接精准定位到某个Service方法印象分会好很多。3. 数据库建模用户、菜谱、笔记三张核心表的细节3.1 核心表结构与字段设计数据库设计是整个项目的灵魂比堆功能代码更考验对业务的理解。这套系统我梳理下来核心表主要围绕三个业务域展开用户域、菜谱域、笔记域。用户表user字段类型说明idbigint主键自增usernamevarchar(50)登录名唯一passwordvarchar(100)BCrypt加密存储nicknamevarchar(50)昵称avatarvarchar(255)头像URLcreate_timedatetime注册时间statustinyint账号状态1正常 0禁用密码加密这个点很关键。很多初学者直接把明文密码存进数据库这在毕设答辩里是会被问到的。用Spring Security自带的BCryptPasswordEncoder做哈希同一个密码每次加密结果都不同安全性高出一大截而且代码成本极低。菜谱表recipe字段类型说明idbigint主键user_idbigint发布者关联user表titlevarchar(100)菜谱标题cover_imagevarchar(255)封面图categoryvarchar(50)所属分类如川菜、烘焙、凉拌difficultytinyint难度1简单 2中等 3困难cook_timeint烹饪时长单位分钟descriptiontext简介ingredientstext原料清单JSON格式存储stepstext步骤说明JSON格式存储包含步骤图和文字view_countint浏览量created_atdatetime发布时间这里我特别说一下ingredients和steps字段。有同学会把原料拆成一张ingredient表、步骤拆成一张step表用外键关联。从“教科书”角度这没问题但从实际项目角度菜谱的原料和步骤基本是“一次性写入、整体读取”很少有单条修改的需求。用JSON字段存储结构化的原料列表和步骤列表简化了表关系查询时一次取出反而更高效。MyBatis-Plus内置的JacksonTypeHandler可以自动完成JSON字符串和Java对象的互转用起来非常顺。笔记表note字段类型说明idbigint主键user_idbigint笔记作者recipe_idbigint关联菜谱可为空contenttext笔记正文imagesvarchar(1000)笔记配图多个用逗号分隔is_publictinyint是否公开1公开 0仅自己可见created_atdatetime创建时间updated_atdatetime更新时间笔记表的设计是这个项目区别于普通菜谱网站的重点。它允许用户把一个菜谱作为笔记的“主题”例如“可乐鸡翅的改良笔记”然后不断追加内容。所以我在实际设计时会在recipe_id上建索引方便拉取“某道菜下面所有用户笔记”的列表同时配合updated_at做排序让最新更新的笔记排前面。3.2 多对多关系收藏、点赞、标签的处理菜谱和用户之间的收藏、点赞关系是典型的多对多。我的设计是三张独立的关系表favorite表user_id recipe_id 联合唯一记录用户收藏的菜谱like表user_id recipe_id 联合唯一记录点赞记录recipe_tag表和tag表菜谱和标签多对多菜谱可以打多个标签一个标签下也能聚合多个菜谱。这里有个实践建议如果你只是想要收藏数量或者点赞数量可以在recipe表上加一个favorite_count、like_count统计字段每次用户收藏或点赞时在Service层做加减。这样列表页展示数量时不需要实时COUNT查表性能会好很多。当然缺点是统计会有轻微延迟但在这种业务量级下完全不是问题。3.3 设计取舍为什么有些地方不走严格外键我在这个项目里刻意没有在表之间大量使用数据库外键约束。不是说外键不好而是当业务逻辑复杂以后外键会带来很多隐性的性能开销和锁问题。Spring Boot项目的推荐实践是“应用层维护关联关系”——通过user_id、recipe_id字段来关联数据一致性靠Service层控制。比如删除一个菜谱时手动把对应的笔记、收藏、点赞、评论一并清理。虽然多写几行代码但逻辑清晰、可控答辩时也能讲出一套自己的设计思想。4. 核心功能实现拆解从注册登录到菜谱发布再到互动体系4.1 注册登录与JWT鉴权用户模块是整个系统的地基。这里选择的JWT方案核心逻辑可以概括为用户登录成功后后端生成一个Token返回前端前端后续请求把它放在Header的Authorization字段里后端拦截器校验Token有效性和用户状态。具体实现上我用了一个拦截器HandlerInterceptor而不是Spring Security全家桶原因是课设项目里Authorization的需求没那么复杂一个拦截器加上工具类就够了代码量小、也容易讲解。核心流程用户注册时密码用BCrypt加密存入数据库登录时用AuthenticationMapper查出用户BCrypt校验密码校验通过后使用JwtUtil生成Token过期时间设置为24小时需要登录的接口上注册拦截器排除登录、注册、菜谱列表、菜谱详情等公开接口拦截器里解析Token把userId放入ThreadLocal或者Request attribute后续Service层直接用。这里有个细节坑ThreadLocal用完一定要调用remove()清理否则Tomcat线程池复用时用户A的登录信息可能被用户B的请求读到。这个小问题在很多项目里都出现过排查起来还不容易。4.2 菜谱发布图片上传与富文本处理菜谱发布是核心功能中最重的环节。它牵扯到图片上传、表单提交、数据入库三个动作。我实现的上传接口是通用的/api/upload接收MultipartFile校验文件类型和后缀jpg、png、gif等限制大小比如单张不超过5MB然后保存到配置的上传目录。文件名我用UUID重命名避免中文文件名和重名问题。返回结果就是图片的访问相对路径前端拿到后拼上域名即可回显。菜谱表单提交时前端会把原料JSON数组和步骤JSON数组每个步骤含描述和可选图片一起提交到后端。后端用DTO接收Jackson自动把JSON字符串反序列化成ListIngredient和ListStep对象再统一转成JSON字符串存入数据库。我比较推荐这种整体提交的方式而不是分成“先创建菜谱、再逐个提交步骤”的多次请求。因为菜谱是一个整体性很强的业务对象一次事务完成创建能避免中间态数据和部分写入的问题。4.3 美食笔记增量追加的笔记设计笔记功能的“增量追加”是这个项目里比较亮眼的设计。核心思路是用户每做一次菜可以在已有的笔记上追加一段心得而不是每次都新建一条独立记录。实现方式上我在note表里设计了一个parent_id字段或者更直接的做法是复用content字段——每次追加时取出旧内容拼接新内容后用updated_at更新排序权重。为了在界面上看清每次追加的痕迹我会在前端用时间线组件展示第一条是笔记创建时间后续每条追加记录显示“x分钟前更新”。这个设计的业务价值在于它把“碎片化的试做经验”串成了一个完整的迭代记录。用户第一次做某个菜、第二次调整了火候、第三次换了配料全都能在一条笔记链上看到。这种沉淀感是普通“评论”做不到的。4.4 互动体系评论、点赞、收藏的实现互动模块相对标准但有几个细节值得展开。评论我设计了comment表包含recipe_id、user_id、content、parent_id。parent_id为空的是一级评论不为空的指向某条评论做回复逻辑。查询某道菜的评论时先按时间倒序取一级评论再根据parent_id批量查出子评论最后组装成树形结构返回前端。这种组装逻辑放在Service层完成不要在SQL里搞递归查询性能和维护性都更好。点赞与收藏实现上采用上一章节说过的“关系表 冗余统计字段”。点赞接口需要先检查是否已经点过赞联合唯一约束兜底没有就插入记录并对like_count加一已点过则删除记录并减一。这里为了保证数据一致性建议在Service方法上标注Transactional。收藏的逻辑同构只是引导用户进入“我的收藏”列表时有独立接口查询。4.5 搜索与热度排序搜索功能我采用的是MySQL的LIKE模糊匹配WHERE title LIKE CONCAT(%, #{keyword}, %)对名称、原料、简介做多字段匹配。这种方案简单、无需引入Elasticsearch适用于中小数据量场景。如果数据量上去了再考虑引入全文索引或者ES这个在架构演进上是可以接受的。热度排序方面我做了一个加权值的概念view_count * 0.3 favorite_count * 0.4 like_count * 0.3排序时按加权值倒序。这部分是纯Java代码实现算好后拼进查询条件排序即可效果上比单纯按时间排序更容易把优质菜谱顶上来。5. 排错实录Spring Boot 项目里那几个隐蔽的坑5.1 Spring Boot 版本与 JDK 版本冲突第一个坑出现在环境准备。项目的pom指定的是Spring Boot 2.4.x而本地JDK装的是17一启动就报错。Spring Boot 2.4对JDK 17的支持并不好很多反射相关的库直接抛IllegalAccessException。这个问题在官方文档里有说明Spring Boot 2.x建议搭配JDK 8或11。我当时把本地JDK切换到8重新mvn clean package整个项目就顺了。这里要提醒一句拿到源码后第一件事先看pom.xml里的java.version标签和本地JDK版本是否匹配。别急着跑版本不匹配浪费的调试时间远大于切换环境的时间。5.2 图片上传后无法访问上传图片功能单独测没问题但配合前端联调时上传的图片返回的URL在浏览器里直接404。排查下来问题出在静态资源映射。Spring Boot的默认静态资源路径是classpath:/static/而项目配置的上传目录是磁盘上的D:/foodshare/uploadsWindows或/opt/uploadsLinux。Spring Boot不会自动把这个外部目录映射为可访问的静态资源。解决办法是显式配置一个WebMvc映射规则Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/uploads/**) .addResourceHandler(file: uploadDir); }配置好之后访问http://localhost:8080/uploads/xxx.jpg就能拿到图片了。如果是部署到服务器还需要确保uploadDir对应的目录有可读写权限否则文件写入会静默失败很难发现。5.3 事务注解失效菜谱删除后评论还在删除菜谱的功能我在Service里写了清理逻辑删除菜谱主记录、清理收藏记录、清理点赞记录、清理评论。但测试时发现中间某步抛出异常后数据库里菜谱删了、评论还留着。排查时发现两个问题。第一Transactional注解放在了Service接口实现类上但方法是private的。Spring的事务代理基于CGLIB动态代理private方法不会被代理拦截事务完全没生效。第二类内部this调用例如一个public方法里调同类的另一个public方法也会绕过代理。正确的姿势是事务方法必须是public且不能通过类内部直接调用绕过代理。如果必须在同类里调用可以拆一个独立Bean或者注入自身代理。这个坑算是Spring中最经典的隐性坑之一几乎每个项目都会遇到。5.4 跨域问题前端连不上后端接口Vue前端启动在localhost:5173Vite默认Spring Boot后端在localhost:8080一请求接口浏览器直接CORS报错。很多人第一反应是搜“怎么解决跨域”然后抄一段CrossOrigin注解加在Controller上倒也有效但不优雅。我采用的是全局CORS配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这个方案的好处是以后前端域名调整只改一个配置类就行不用动每个Controller。另外注意如果用了Spring Security还需要额外配置跨域过滤器或者放行预检请求否则跨域配置会被安全过滤链拦截掉。6. 交付阶段源码结构、环境配置与验收演示要点6.1 环境准备清单如果要完整跑通这个项目并准备演示下面的环境清单可以直接抄工具版本建议用途JDK8 或 11编译运行Spring Boot后端Maven3.6依赖管理MySQL5.7 或 8.0数据存储Node.js14前端Vue项目运行npm / yarn对应版本前端依赖安装Navicat 或 IDEA Database任一数据库可视化操作拿到源码后步骤顺序是先创建数据库导入sql目录下的建表脚本修改application.yml里的数据库连接信息启动后端项目确认Swagger接口文档页面能打开然后启动前端项目注册账号测试菜谱发布和笔记功能。6.2 代码结构目录与答辩演示思路源码的目录结构一般是前端和后端分开的两个文件夹后端按标准Maven结构组织前端按Vue项目标准组织。讲解视频和运行视频的作用我实际看完之后的体会是运行视频主要演示了从数据库导入、项目启动到关键功能点击的操作路径讲解视频则侧重逐模块解读代码包括表设计、Controller接口、Service实现。答辩或面试的时候建议按这个顺序演示讲背景一句话说清项目解决什么问题菜谱工具散乱、笔记无法沉淀画架构说清前端Vue 后端Spring Boot MySQL的整体链路演示注册登录流程展示JWT Token怎么生成、怎么在后续请求中携带发布一条菜谱上传图片、填写原料和步骤、提交后列表页展示写一条笔记并追加展示“增量追加”的交互和数据变化互动操作点赞、收藏、评论展示数量变化和关系表数据一句话总结个人的技术收获和后续可扩展方向比如接入Redis缓存、引入Elasticsearch搜索等。6.3 项目扩展方向如果我想把它做得更完整如果时间充裕我建议做以下几个扩展性价比最高Redis接入把菜谱详情、热门列表做缓存降低MySQL压力同时演示Redis在项目中的真实用途全文搜索用Elasticsearch替换MySQL模糊查询搜索体验会大幅提升对象存储把图片上传切换到MinIO或云OSS展示生产级文件管理能力消息通知用户菜谱被收藏、评论后加一个站内信或邮件通知功能互动链路更完整后台管理端增加一个Spring Boot管理后台实现用户管理、菜谱审核、数据统计面板这对应聘“全栈开发”类的岗位描述非常加分。我实测跑通这套项目时最深的体会是一个项目的“完成度”不在于功能列表有多长而在于每个功能背后有没有想清楚“为什么这么设计”。菜谱平台本身业务不复杂但把用户体系、内容体系、互动体系之间的边界理清楚把数据模型设计得稳定把事务、权限、文件访问这些细节处理好才是真正体现水平的地方。如果你手头正在做类似的Spring Boot毕设或者准备面试项目拿到源码后别急着跑先自己画一遍表结构再对照源码看实现的差异。这个习惯比单纯跑通Demo有价值得多。这套系统里关于菜谱JSON存储、笔记增量追加、冗余统计字段的设计思路你完全可以移植到其他内容型项目里以后写代码会更顺手。
Spring Boot美食社区实战拆解：菜谱与笔记场景的设计与实现
我见过太多把“美食分享平台”做成“用户表 菜谱表 评论表”三张表的项目了。标题看着挺全真点开代码就是Spring Boot入门级别的CRUD业务逻辑全靠前端硬撑。但今天要拆的这个厨房达人美食分享平台确实是把“菜谱 笔记”这两个核心场景做出了点值得说的东西。它不只是一个典型的Java Spring Boot毕设项目更是一套完整可落地的“美食社区”样板——从用户体系、内容发布、图片上传到评论互动、搜索聚合每一环都有真实的业务逻辑在推着走而不是空对空的增删改查。对正在做Java课设、毕业设计或者想深入了解Spring Boot全栈开发的人来说这套项目的参考价值在于你能看到“一个功能完整的项目”到底应该怎么组织代码、怎么设计表结构、怎么处理文件上传和事务这类实战问题。我基于这套源码和文档把项目完整跑通过也顺手梳理了它的结构、设计思路和实现细节下面把整个过程拆开讲。1. 立项逻辑从“收藏夹吃灰”到“可沉淀的美食笔记”1.1 真实痛点美食博主的笔记困境先说个小场景。我自己平时做菜最烦的不是不会做而是“收藏了二十个红烧肉教程真正开火的时候不知道哪个靠谱”。更麻烦的是有些平台教程太碎评论区、笔记区、视频区各说各话想针对某道菜补充一句自己的实操心得根本找不到合适的位置。这套系统的立项逻辑其实就是冲着这个痛点去的。它想解决的不是“提供一个发菜谱的地方”而是“让菜谱和笔记形成一套完整的知识沉淀体系”——菜谱是主线笔记是围绕菜谱展开的补充、纠错、改良记录。用户既可以发布完整的菜谱也可以在他人菜谱下写自己的实操笔记把“我今天试了一下糖放少了建议再加10克”这类真实经验留存下来。1.2 功能边界这套系统到底做了哪些事从功能清单上看典型的完整项目模块包括这些用户模块注册、登录、个人信息维护以及基于JWT的登录鉴权菜谱模块菜谱发布、编辑、删除支持封面图和步骤图的上传分类、难度、耗时等元信息维护笔记模块针对菜谱或自己收藏的菜谱写笔记支持追加内容形成类似“厨房手账”的记录互动模块点赞、收藏、评论以及对应的列表展示和数量统计搜索模块按菜谱名称、关键词、分类进行模糊搜索部分版本还会做热度排序。这套功能做出来之后整体就构成了一个“用户—菜谱—笔记—互动”的闭环。用户来了不只是被动浏览还能沉淀自己的实操经验这就比单纯的菜谱展示网站多了一层社区属性。2. 技术选型与工程骨架Spring Boot 项目的搭建思路2.1 为什么是 Spring Boot而不是 SSH 或 Servlet 原生技术选型上这套项目锚定Java Spring Boot是合理的。放到三四年前很多课设项目还在用SSHStruts Spring Hibernate或者Servlet JSP配置繁琐、启动慢、依赖管理混乱。Spring Boot最大的价值在于“约定优于配置”内嵌Tomcat、自动装配、起步依赖让开发者能把精力放在业务代码上而不是折腾XML配置文件。具体来说我用下来觉得Spring Boot 2.x版本在这类项目上非常顺手。它不需要你事无巨细地配置Bean一个SpringBootApplication注解就把组件扫描、自动配置、属性绑定全包了。对于菜谱平台这种业务逻辑清晰、需要快速迭代的项目开发效率提升是肉眼可见的。2.2 配套组件的选型组合完整的项目不可能只靠Spring Boot核心我梳理下来的组合大致是这样模块选型理由持久层MyBatis-Plus既保留了SQL可控性又提供了IService和BaseMapper等现成CRUD能力写业务代码速度极快数据库MySQL 5.7 / 8.0生态成熟部署简单菜谱数据用关系型存储非常合适鉴权JWT Spring Security 或拦截器无状态登录前后端分离场景下比Session更灵活接口文档Swagger / Knife4j生成API文档方便调试接口也用得上前端Vue Element Plus和后端分离页面组件化表格表单开发效率高文件存储本地磁盘 访问映射或MinIO菜谱图片上传场景简单本地目录静态资源映射可以满足学习和毕设需求这里我要多说一句关于文件存储的选择。很多同学一上来就纠结“要不要上OSS、要不要接MinIO”其实在毕设或课程设计阶段本地存储完全够用。Spring Boot里配置一个web.resources.static-locations指向上传目录图片上传后返回相对路径前端直接拼URL访问整个链路简单、可运行、不依赖外部服务。等真正上了生产环境再切换对象存储也不迟。2.3 分层架构与代码组织工程结构上我倾向于经典的四层结构com.example.foodshare ├── controller // 接口层接收参数、返回结果 ├── service // 业务逻辑层处理业务规则 ├── mapper // 数据访问层MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto / vo // 入参和出参对象 ├── config // 配置类如跨域、Swagger、WebMvc ├── utils // 工具类如JWT工具、文件上传工具 └── common // 统一返回结果、异常处理、常量这样做的好处是Controller层很薄只做参数接收和结果包装Service层承载业务逻辑Mapper层专注数据访问。后面调试的时候不管是从接口入口查到SQL执行还是从异常栈定位到业务逻辑都很清晰。特别是答辩的时候评委问“这段业务逻辑在哪”你能直接精准定位到某个Service方法印象分会好很多。3. 数据库建模用户、菜谱、笔记三张核心表的细节3.1 核心表结构与字段设计数据库设计是整个项目的灵魂比堆功能代码更考验对业务的理解。这套系统我梳理下来核心表主要围绕三个业务域展开用户域、菜谱域、笔记域。用户表user字段类型说明idbigint主键自增usernamevarchar(50)登录名唯一passwordvarchar(100)BCrypt加密存储nicknamevarchar(50)昵称avatarvarchar(255)头像URLcreate_timedatetime注册时间statustinyint账号状态1正常 0禁用密码加密这个点很关键。很多初学者直接把明文密码存进数据库这在毕设答辩里是会被问到的。用Spring Security自带的BCryptPasswordEncoder做哈希同一个密码每次加密结果都不同安全性高出一大截而且代码成本极低。菜谱表recipe字段类型说明idbigint主键user_idbigint发布者关联user表titlevarchar(100)菜谱标题cover_imagevarchar(255)封面图categoryvarchar(50)所属分类如川菜、烘焙、凉拌difficultytinyint难度1简单 2中等 3困难cook_timeint烹饪时长单位分钟descriptiontext简介ingredientstext原料清单JSON格式存储stepstext步骤说明JSON格式存储包含步骤图和文字view_countint浏览量created_atdatetime发布时间这里我特别说一下ingredients和steps字段。有同学会把原料拆成一张ingredient表、步骤拆成一张step表用外键关联。从“教科书”角度这没问题但从实际项目角度菜谱的原料和步骤基本是“一次性写入、整体读取”很少有单条修改的需求。用JSON字段存储结构化的原料列表和步骤列表简化了表关系查询时一次取出反而更高效。MyBatis-Plus内置的JacksonTypeHandler可以自动完成JSON字符串和Java对象的互转用起来非常顺。笔记表note字段类型说明idbigint主键user_idbigint笔记作者recipe_idbigint关联菜谱可为空contenttext笔记正文imagesvarchar(1000)笔记配图多个用逗号分隔is_publictinyint是否公开1公开 0仅自己可见created_atdatetime创建时间updated_atdatetime更新时间笔记表的设计是这个项目区别于普通菜谱网站的重点。它允许用户把一个菜谱作为笔记的“主题”例如“可乐鸡翅的改良笔记”然后不断追加内容。所以我在实际设计时会在recipe_id上建索引方便拉取“某道菜下面所有用户笔记”的列表同时配合updated_at做排序让最新更新的笔记排前面。3.2 多对多关系收藏、点赞、标签的处理菜谱和用户之间的收藏、点赞关系是典型的多对多。我的设计是三张独立的关系表favorite表user_id recipe_id 联合唯一记录用户收藏的菜谱like表user_id recipe_id 联合唯一记录点赞记录recipe_tag表和tag表菜谱和标签多对多菜谱可以打多个标签一个标签下也能聚合多个菜谱。这里有个实践建议如果你只是想要收藏数量或者点赞数量可以在recipe表上加一个favorite_count、like_count统计字段每次用户收藏或点赞时在Service层做加减。这样列表页展示数量时不需要实时COUNT查表性能会好很多。当然缺点是统计会有轻微延迟但在这种业务量级下完全不是问题。3.3 设计取舍为什么有些地方不走严格外键我在这个项目里刻意没有在表之间大量使用数据库外键约束。不是说外键不好而是当业务逻辑复杂以后外键会带来很多隐性的性能开销和锁问题。Spring Boot项目的推荐实践是“应用层维护关联关系”——通过user_id、recipe_id字段来关联数据一致性靠Service层控制。比如删除一个菜谱时手动把对应的笔记、收藏、点赞、评论一并清理。虽然多写几行代码但逻辑清晰、可控答辩时也能讲出一套自己的设计思想。4. 核心功能实现拆解从注册登录到菜谱发布再到互动体系4.1 注册登录与JWT鉴权用户模块是整个系统的地基。这里选择的JWT方案核心逻辑可以概括为用户登录成功后后端生成一个Token返回前端前端后续请求把它放在Header的Authorization字段里后端拦截器校验Token有效性和用户状态。具体实现上我用了一个拦截器HandlerInterceptor而不是Spring Security全家桶原因是课设项目里Authorization的需求没那么复杂一个拦截器加上工具类就够了代码量小、也容易讲解。核心流程用户注册时密码用BCrypt加密存入数据库登录时用AuthenticationMapper查出用户BCrypt校验密码校验通过后使用JwtUtil生成Token过期时间设置为24小时需要登录的接口上注册拦截器排除登录、注册、菜谱列表、菜谱详情等公开接口拦截器里解析Token把userId放入ThreadLocal或者Request attribute后续Service层直接用。这里有个细节坑ThreadLocal用完一定要调用remove()清理否则Tomcat线程池复用时用户A的登录信息可能被用户B的请求读到。这个小问题在很多项目里都出现过排查起来还不容易。4.2 菜谱发布图片上传与富文本处理菜谱发布是核心功能中最重的环节。它牵扯到图片上传、表单提交、数据入库三个动作。我实现的上传接口是通用的/api/upload接收MultipartFile校验文件类型和后缀jpg、png、gif等限制大小比如单张不超过5MB然后保存到配置的上传目录。文件名我用UUID重命名避免中文文件名和重名问题。返回结果就是图片的访问相对路径前端拿到后拼上域名即可回显。菜谱表单提交时前端会把原料JSON数组和步骤JSON数组每个步骤含描述和可选图片一起提交到后端。后端用DTO接收Jackson自动把JSON字符串反序列化成ListIngredient和ListStep对象再统一转成JSON字符串存入数据库。我比较推荐这种整体提交的方式而不是分成“先创建菜谱、再逐个提交步骤”的多次请求。因为菜谱是一个整体性很强的业务对象一次事务完成创建能避免中间态数据和部分写入的问题。4.3 美食笔记增量追加的笔记设计笔记功能的“增量追加”是这个项目里比较亮眼的设计。核心思路是用户每做一次菜可以在已有的笔记上追加一段心得而不是每次都新建一条独立记录。实现方式上我在note表里设计了一个parent_id字段或者更直接的做法是复用content字段——每次追加时取出旧内容拼接新内容后用updated_at更新排序权重。为了在界面上看清每次追加的痕迹我会在前端用时间线组件展示第一条是笔记创建时间后续每条追加记录显示“x分钟前更新”。这个设计的业务价值在于它把“碎片化的试做经验”串成了一个完整的迭代记录。用户第一次做某个菜、第二次调整了火候、第三次换了配料全都能在一条笔记链上看到。这种沉淀感是普通“评论”做不到的。4.4 互动体系评论、点赞、收藏的实现互动模块相对标准但有几个细节值得展开。评论我设计了comment表包含recipe_id、user_id、content、parent_id。parent_id为空的是一级评论不为空的指向某条评论做回复逻辑。查询某道菜的评论时先按时间倒序取一级评论再根据parent_id批量查出子评论最后组装成树形结构返回前端。这种组装逻辑放在Service层完成不要在SQL里搞递归查询性能和维护性都更好。点赞与收藏实现上采用上一章节说过的“关系表 冗余统计字段”。点赞接口需要先检查是否已经点过赞联合唯一约束兜底没有就插入记录并对like_count加一已点过则删除记录并减一。这里为了保证数据一致性建议在Service方法上标注Transactional。收藏的逻辑同构只是引导用户进入“我的收藏”列表时有独立接口查询。4.5 搜索与热度排序搜索功能我采用的是MySQL的LIKE模糊匹配WHERE title LIKE CONCAT(%, #{keyword}, %)对名称、原料、简介做多字段匹配。这种方案简单、无需引入Elasticsearch适用于中小数据量场景。如果数据量上去了再考虑引入全文索引或者ES这个在架构演进上是可以接受的。热度排序方面我做了一个加权值的概念view_count * 0.3 favorite_count * 0.4 like_count * 0.3排序时按加权值倒序。这部分是纯Java代码实现算好后拼进查询条件排序即可效果上比单纯按时间排序更容易把优质菜谱顶上来。5. 排错实录Spring Boot 项目里那几个隐蔽的坑5.1 Spring Boot 版本与 JDK 版本冲突第一个坑出现在环境准备。项目的pom指定的是Spring Boot 2.4.x而本地JDK装的是17一启动就报错。Spring Boot 2.4对JDK 17的支持并不好很多反射相关的库直接抛IllegalAccessException。这个问题在官方文档里有说明Spring Boot 2.x建议搭配JDK 8或11。我当时把本地JDK切换到8重新mvn clean package整个项目就顺了。这里要提醒一句拿到源码后第一件事先看pom.xml里的java.version标签和本地JDK版本是否匹配。别急着跑版本不匹配浪费的调试时间远大于切换环境的时间。5.2 图片上传后无法访问上传图片功能单独测没问题但配合前端联调时上传的图片返回的URL在浏览器里直接404。排查下来问题出在静态资源映射。Spring Boot的默认静态资源路径是classpath:/static/而项目配置的上传目录是磁盘上的D:/foodshare/uploadsWindows或/opt/uploadsLinux。Spring Boot不会自动把这个外部目录映射为可访问的静态资源。解决办法是显式配置一个WebMvc映射规则Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/uploads/**) .addResourceHandler(file: uploadDir); }配置好之后访问http://localhost:8080/uploads/xxx.jpg就能拿到图片了。如果是部署到服务器还需要确保uploadDir对应的目录有可读写权限否则文件写入会静默失败很难发现。5.3 事务注解失效菜谱删除后评论还在删除菜谱的功能我在Service里写了清理逻辑删除菜谱主记录、清理收藏记录、清理点赞记录、清理评论。但测试时发现中间某步抛出异常后数据库里菜谱删了、评论还留着。排查时发现两个问题。第一Transactional注解放在了Service接口实现类上但方法是private的。Spring的事务代理基于CGLIB动态代理private方法不会被代理拦截事务完全没生效。第二类内部this调用例如一个public方法里调同类的另一个public方法也会绕过代理。正确的姿势是事务方法必须是public且不能通过类内部直接调用绕过代理。如果必须在同类里调用可以拆一个独立Bean或者注入自身代理。这个坑算是Spring中最经典的隐性坑之一几乎每个项目都会遇到。5.4 跨域问题前端连不上后端接口Vue前端启动在localhost:5173Vite默认Spring Boot后端在localhost:8080一请求接口浏览器直接CORS报错。很多人第一反应是搜“怎么解决跨域”然后抄一段CrossOrigin注解加在Controller上倒也有效但不优雅。我采用的是全局CORS配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这个方案的好处是以后前端域名调整只改一个配置类就行不用动每个Controller。另外注意如果用了Spring Security还需要额外配置跨域过滤器或者放行预检请求否则跨域配置会被安全过滤链拦截掉。6. 交付阶段源码结构、环境配置与验收演示要点6.1 环境准备清单如果要完整跑通这个项目并准备演示下面的环境清单可以直接抄工具版本建议用途JDK8 或 11编译运行Spring Boot后端Maven3.6依赖管理MySQL5.7 或 8.0数据存储Node.js14前端Vue项目运行npm / yarn对应版本前端依赖安装Navicat 或 IDEA Database任一数据库可视化操作拿到源码后步骤顺序是先创建数据库导入sql目录下的建表脚本修改application.yml里的数据库连接信息启动后端项目确认Swagger接口文档页面能打开然后启动前端项目注册账号测试菜谱发布和笔记功能。6.2 代码结构目录与答辩演示思路源码的目录结构一般是前端和后端分开的两个文件夹后端按标准Maven结构组织前端按Vue项目标准组织。讲解视频和运行视频的作用我实际看完之后的体会是运行视频主要演示了从数据库导入、项目启动到关键功能点击的操作路径讲解视频则侧重逐模块解读代码包括表设计、Controller接口、Service实现。答辩或面试的时候建议按这个顺序演示讲背景一句话说清项目解决什么问题菜谱工具散乱、笔记无法沉淀画架构说清前端Vue 后端Spring Boot MySQL的整体链路演示注册登录流程展示JWT Token怎么生成、怎么在后续请求中携带发布一条菜谱上传图片、填写原料和步骤、提交后列表页展示写一条笔记并追加展示“增量追加”的交互和数据变化互动操作点赞、收藏、评论展示数量变化和关系表数据一句话总结个人的技术收获和后续可扩展方向比如接入Redis缓存、引入Elasticsearch搜索等。6.3 项目扩展方向如果我想把它做得更完整如果时间充裕我建议做以下几个扩展性价比最高Redis接入把菜谱详情、热门列表做缓存降低MySQL压力同时演示Redis在项目中的真实用途全文搜索用Elasticsearch替换MySQL模糊查询搜索体验会大幅提升对象存储把图片上传切换到MinIO或云OSS展示生产级文件管理能力消息通知用户菜谱被收藏、评论后加一个站内信或邮件通知功能互动链路更完整后台管理端增加一个Spring Boot管理后台实现用户管理、菜谱审核、数据统计面板这对应聘“全栈开发”类的岗位描述非常加分。我实测跑通这套项目时最深的体会是一个项目的“完成度”不在于功能列表有多长而在于每个功能背后有没有想清楚“为什么这么设计”。菜谱平台本身业务不复杂但把用户体系、内容体系、互动体系之间的边界理清楚把数据模型设计得稳定把事务、权限、文件访问这些细节处理好才是真正体现水平的地方。如果你手头正在做类似的Spring Boot毕设或者准备面试项目拿到源码后别急着跑先自己画一遍表结构再对照源码看实现的差异。这个习惯比单纯跑通Demo有价值得多。这套系统里关于菜谱JSON存储、笔记增量追加、冗余统计字段的设计思路你完全可以移植到其他内容型项目里以后写代码会更顺手。
