1. 火锅文化网站到底要做什么功能模块与系统边界说实话这个题目乍一看是个课程设计标准款但真正动手做的时候你会发现火锅文化网站和普通的CRUD管理系统完全是两码事。我最初接手这个项目时以为就是菜品增删改查后台管理结果深入了解需求后才知道文化展示类网站真正的难点不在增删改查而在内容组织、视觉呈现和用户浏览体验上。先说清楚这个系统解决的核心问题。火锅文化是一个非常大的概念它包含火锅的历史起源、地域流派川渝麻辣锅、潮汕牛肉锅、北京铜锅涮肉、云南菌子锅、食材知识、蘸料文化、用餐礼仪等。这些东西如果只是堆在页面上用户根本看不下去。所以这个系统的核心价值在于把散落的火锅文化知识点结构化、系统化地呈现给用户同时给管理员提供一个方便维护内容的后台。从实际开发角度看这个项目适合三类人一是正在做Java课程设计或毕业设计的在校生二是想通过一个完整前后端分离项目巩固SpringBoot和Vue技术栈的初学者三是想做一个拿得出手的作品集项目的求职者。它麻雀虽小五脏俱全覆盖了用户端内容浏览、搜索、评论互动管理端内容维护、数据统计等常见业务场景。我把整个系统的功能模块做了如下划分用户端前台门户火锅文化首页轮播与推荐、文化文章列表与详情、火锅分类浏览按地域流派、按食材类型、食材百科、蘸料搭配推荐、评论区互动、站内搜索、个人中心浏览记录、收藏、评论管理。管理端后台管理管理员登录与权限校验、文化文章与分类管理、食材信息管理、用户管理禁用/启用、评论审核与删除、首页轮播图配置、基础数据统计文章量、用户量、评论量。这里要特别说明一个容易被忽略的设计决策为什么要分用户端和管理端而不是只做一个展示网站因为火锅文化的内容是持续更新的——今天可以加一篇重庆火锅的九宫格讲究明天可以补一种沙茶酱的调配秘方。如果内容全靠前端写死管理员每次更新都要改代码重新部署这在实际使用中是不可接受的。所以后台内容管理是这个系统的刚需而不是多余的功能。2. 数据库设计的完整拆解从文化内容到互动功能数据库设计是这个项目最先要动工的部分也是我后来返工最多的地方。第一次设计的时候我按惯性建了用户表、文章表、评论表结果写到一半发现漏了食材表、蘸料表和收藏表又回头改表结构浪费了不少时间。这里我把最终定稿的表结构完整拿出来讲想省事的同学可以直接抄。2.1 核心业务表用户、分类、文章用户表user是所有业务的基础我保留了最基本的字段没有过度设计字段名类型说明idbigint主键自增usernamevarchar(50)登录名唯一索引passwordvarchar(100)BCrypt加密后的密码nicknamevarchar(50)昵称avatarvarchar(255)头像路径默认给一张火锅图片phonevarchar(20)手机号可空statustinyint0禁用 1正常create_timedatetime注册时间分类表category用于管理文化内容的归类我设计成了单层分类而不是树形结构。因为火锅文化内容的分支归类用父子层级会让前端实现复杂很多而实际需求下单层分类完全够用——比如历史渊源地域流派食材百科蘸料文化火锅礼仪五个分类清清楚楚。字段名类型说明idbigint主键namevarchar(50)分类名称descriptionvarchar(255)分类描述sortint排序值越小越靠前create_timedatetime创建时间文章表article是整个文化网站的核心字段比普通博客系统要多几个。这里特别要注意content字段用text类型还是longtext类型的问题。火锅文化文章经常有大量配图和长段落一篇中国火锅流派图鉴的文章可能轻松上万字text类型上限是64KB在某些字符集下中文只能存两万字左右所以我建议直接用longtext避免后期发现文章被截断的尴尬。文章表的另一个关键是status字段。我做的是0草稿、1已发布、2下线三种状态。这个字段的价值在于管理员编辑一篇长文章时不需要一口气写完可以存草稿慢慢改改完再发布。如果不做草稿状态后台编辑体验会非常糟糕。字段名类型说明idbigint主键category_idbigint关联分类表titlevarchar(200)文章标题summaryvarchar(500)摘要列表页展示用contentlongtext正文内容cover_imagevarchar(255)封面图路径authorvarchar(50)作者名view_countint浏览量like_countint点赞数statustinyint0草稿 1已发布 2下线create_timedatetime创建时间update_timedatetime更新时间2.2 互动业务表评论、收藏、轮播图评论表comment设计时我踩了一个典型的坑——一开始只设计了帖子级评论没考虑回复功能。火锅文化文章下面经常有用户互相交流你们那的麻酱是这样的吗我们潮汕人从不吃麻酱这种对话场景没有楼层回复根本聊不起来。所以我加了一个parent_id字段为0表示顶级评论不为0表示回复某条评论在前端做缩进展示即可。这个方案比单独建回复表简单得多查询时按时间倒序把同一个parent_id的回复捞出来就行。字段名类型说明idbigint主键article_idbigint关联文章表user_idbigint关联用户表parent_idbigint0为顶级评论否则为回复的评论idcontentvarchar(500)评论内容限制500字防止灌水statustinyint0待审核 1展示 2隐藏create_timedatetime评论时间收藏表favorite和浏览记录我放在了同一个逻辑里。收藏表的唯一约束是 (user_id, article_id) 这个联合索引这样用户对同一篇文章只能收藏一次后端要加校验也好写。浏览记录不建表我用Redis的ZSet按用户维度存储member是文章idscore是点击时间的时间戳这样拉取最近浏览时直接按score倒序取前N条即可天然带着时间排序不用额外排序逻辑。轮播图表banner很简单就是管理后台配置首页大图的字段包含图片路径、跳转链接、排序值、状态。这个模块的意义在于运营人员可以自助换图而不是每次都求开发改代码别小看这个功能它是后台系统可用性的重要标志。2.3 一个值得借鉴的关联查询设计思路做文化类网站时前端列表往往需要同时展示文章信息和作者昵称。最开始我用了MyBatis-Plus的TableField(exist false)加VO类的方式在Service层手动查用户表补全昵称结果就是循环调用查询文章一多性能惨不忍睹。后来我改成SQL联表查询直接用LEFT JOIN把用户表的数据带过来。SELECT a.id, a.title, a.summary, a.cover_image, a.view_count, a.like_count, a.create_time, c.name AS category_name FROM article a LEFT JOIN category c ON a.category_id c.id WHERE a.status 1 ORDER BY a.create_time DESC LIMIT #{offset}, #{pageSize}这种写法的好处是一次查询拿到列表页需要的所有字段不需要在Java代码里做二次查询而且SQL的可读性也比代码中拼装数据好得多。实际项目中建议遵循列表页用联表查询、详情页用单表查询Redis缓存的策略简单有效。3. SpringBoot后端核心接口的开发细节后端部分我用的标准组合是SpringBoot 2.7.x MyBatis-Plus MySQL 8.0 Redis。为什么选MyBatis-Plus而不是JPA因为文化网站的业务增删改查非常套路化MyBatis-Plus的BaseMapper直接提供了单表CRUD和分页插件能省掉大量重复的XML配置。但如果你的项目查询逻辑复杂建议该手写SQL时不要偷懒联表查询这种操作BaseMapper帮不了你。3.1 统一响应体与全局异常处理的必要性这是每个SpringBoot项目都要做的基础设施但我见过太多课程设计代码直接返回Map或者裸的JSON前端拿到数据一脸懵。我自己搭项目的习惯是建一个Result类作为所有接口的统一返回体public class ResultT { private Integer code; // 200成功500失败401未登录 private String message; // 提示信息 private T data; // 业务数据 }对应地在Controller里所有接口都返回Result类型前端axios拦截器统一处理code非200统一弹message。这样前后端联调时的沟通成本会低很多而且出错时排查链路清晰。全局异常处理我直接用RestControllerAdvice捕获Exception区分业务异常和系统异常业务异常返回400和友好提示系统异常返回500并记录日志。没有这套东西后期的联调体验真的是噩梦。3.2 首页聚合接口的设计一次请求搞定首屏火锅文化网站的首页信息密度很大顶部轮播图、热门文章推荐、分类导航、最新文章。如果让前端发5个请求去拼首屏不仅慢而且后面想调整布局都要改前端逻辑。我设计了一个聚合接口 /api/home一个请求返回所有首屏数据内部逻辑是组合多个Service方法GetMapping(/home) public ResultHomeVO getHomeData() { HomeVO vo new HomeVO(); vo.setBanners(bannerService.listEnabled()); vo.setHotArticles(articleService.listHot(5)); vo.setCategories(categoryService.listAll()); vo.setNewArticles(articleService.listLatest(10)); return Result.success(vo); }这个接口写在Controller里看起来简单但Service层的listHot和listLatest需要走Redis缓存不然首页每次刷新都打数据库流量稍大一点MySQL的QPS很快就撑不住了。我用的方案是查询结果手动缓存到RedisKey为home:hot:articles过期时间30分钟后台管理员发布新文章时主动删除相关缓存这样能保证新增内容及时看到又不会频繁打库。3.3 管理员后台上传与内容合规处理后台管理系统里图片上传是绕不开的。我先说结论图片存本地磁盘不存数据库数据库只存路径字符串。上传接口我用MultipartFile接收文件校验文件类型jpg/png/webp限制大小为5MB重命名规则用UUID加原始文件后缀然后按日期分目录存储例如 upload/2025/06/01/uuid.jpg。这里有一个很实在的问题SpringBoot的默认单文件上传大小限制是1MB如果不管这个配置上传稍微大一点的火锅菜品图片就会直接报MaxUploadSizeExceededException。需要在application.yml里放开限制spring: servlet: multipart: enabled: true max-file-size: 10MB max-request-size: 20MB还有一个前端联调时经常遇到的坑静态资源映射。图片存到了本地磁盘但用户访问不到因为SpringBoot默认只处理classpath下的static目录。必须配置资源映射器把本地磁盘路径映射成URL访问路径Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); } }另外提醒一句管理后台编辑器上传的内容必须做XSS过滤像