1. 项目整体设计与技术选型1.1 为什么选Spring Boot做美食分享系统我接手过不少相似的分享类项目这个“基于Spring Boot的河南特色美食分享系统”最打动我的地方在于它是一个特别典型的“非电商类内容平台”样本。没有复杂的订单流、没有支付回调、没有库存锁但恰恰因为业务边界清晰反而能把Spring Boot的核心能力——自动配置、Starter机制、分层架构——用到极致。先说技术选型的底层逻辑。市面上做这类系统常见路线有三条一是传统的SSMSpring Spring MVC MyBatis二是Spring Boot单体重应用三是Spring Boot 微服务全家桶。我个人的建议是如果只是学校毕设或小型个人项目老老实实选Spring Boot单体就够别一上来就整Nacos、Gateway那套。为什么因为项目的核心价值在“内容展示、UGC分享、检索体验”而不是分布式治理。微服务带来的服务拆分、链路追踪、配置中心在这个体量下纯属给自己挖坑。Spring Boot最划算的地方在于自动装配。比如你引入spring-boot-starter-web内嵌Tomcat直接给你配好引入spring-boot-starter-data-redis连接工厂、模板对象全都自动注册。我们不需要关心DispatcherServlet怎么映射、RedisConnectionFactory怎么建连接只要关注业务本身。我用一句话概括这类项目的选型心法能用Starter解决的绝不手写配置能用默认配置的绝不自定义Bean。这套系统我最终定的技术栈是Spring Boot 2.7.5 MyBatis-Plus 3.5.2 Redis MinIO文件存储 Thymeleaf服务端渲染。数据库选的MySQL 8.0JDK用的1.8。这里有个容易被忽略的坑Spring Boot 2.x系列和3.x系列在javax与jakarta命名空间上不兼容很多老教程还在用2.x的写法如果你不小心创建了3.x项目import javax.servlet直接编译报错。所以先锁定版本再动手写代码这比什么都重要。1.2 从标题反推出来的隐性需求“河南特色美食分享”这个题目表面上是一个内容展示站但拆开看其实藏着好几个子需求用户侧游客可以浏览美食列表、查看详情、搜索注册登录后能点赞、收藏、评论、发布自己的美食笔记。管理侧管理员要能管理美食分类、审核用户发布的分享、管理用户状态、统计数据。内容侧每道美食要有名称、所属城市、分类、图片、简介、做法步骤、食材清单最好还能绑定历史典故。检索侧支持按名称模糊搜索、按分类筛选、按热度排序还有关键词分词。这些需求一列出来系统的边界就清楚了。我做设计时没有贪多把“用户-内容-互动”作为三条主线所有表结构、接口、页面都围绕这三条线展开。比如用户和美食之间是收藏关系用户和评论之间是一对多关系美食和分类是多对一关系。理清这些关系后面建表、写Mapper、设计VO都不会乱。另外一个容易被忽视的点是“区域特色”的表达。河南美食不是铁板一块开封灌汤包、洛阳水席、郑州烩面、逍遥镇胡辣汤各有各的“地盘”。所以在设计美食表时我专门加了一个city字段标识所属城市并且支持按城市维度做筛选页。这个小设计在答辩和实际体验中都非常加分会让系统看起来是懂行的而不是简单的CRUD堆积。2. 数据库设计与核心表结构2.1 五张核心表的建模思路数据库设计是整个系统的地基我见过太多项目在表结构上偷懒后面写SQL写到怀疑人生。这个项目我最终落地的表一共七张核心五张user用户表字段包括id、username、passwordBCrypt加密存储、nickname、avatar、role0普通用户/1管理员、status、create_time。category美食分类表字段包括id、name、sort、description。food美食主表字段包括id、name、category_id、city、cover_image、description、ingredients食材清单用JSON或长文本、steps做法步骤长文本、view_count、like_count、favorite_count、status、create_time。comment评论表字段包括id、food_id、user_id、content、parent_id支持楼中楼回复、create_time。user_favorite收藏关系表字段包括id、user_id、food_id、create_time。建表时有几个细节值得说道说道。第一个是计数器的处理。view_count这类字段我建议直接冗余在主表里而不是每次用COUNT(*)去统计。原因很简单详情页每次刷新都要查评论数、收藏数、点赞数如果用聚合查询数据量大了以后会越来越慢而冗余字段只需要做原子自增UPDATE food SET view_count view_count 1 WHERE id ?性能差好几倍。第二个是parent_id的设计。评论回复如果只做一层用parent_id指向根评论即可。查询时先查根评论再根据根评论的id批量查子评论在内存中组装成树形结构。这里千万不要用递归SQLMySQL 8.0虽然支持WITH RECURSIVE但这个场景下两层评论用两次查询完全够写法简单还容易维护。第三个是user_favorite表要加唯一索引。UNIQUE KEY uk_user_food(user_id, food_id)这是防止重复收藏的兜底手段。你可能会说“我在代码里判断过了”但只要并发请求一到代码判断就形同虚设。数据库层面的唯一约束才是最可靠的。2.2 MyBatis-Plus的实用性选择关于ORM这一层我用的是MyBatis-Plus而不是原生MyBatis。原因很实在这个项目的单表CRUD占了七八成MyBatis-Plus的BaseMapper直接把这些操作封装好了selectById、insert、updateById开箱即用能省掉大量重复的XML映射文件。但要注意MyBatis-Plus的“反直觉”点。最典型的是updateById默认策略是NOT_NULL也就是实体中为null的字段不会更新。这在大多数场景下是好事但如果你想把某个字段置空直接传null是行不通的。我当时在实现“管理员下架美食”功能时就踩了这个坑我用updateById想设置status 0但实体里的status传的确实是0因为0不是null所以能更新成功可一旦想把audit_remark清空传null就无功而返。解决方案是在对应字段上加TableField(updateStrategy FieldStrategy.IGNORED)或者干脆用LambdaUpdateWrapper显式set。分页查询是另一个实操重点。MyBatis-Plus的PaginationInnerInterceptor必须显式配置否则Page对象查出来只是假分页——所有数据都查出来了只是帮你切了一刀。我习惯把分页插件、乐观锁插件、字段自动填充处理器放在同一个MybatisPlusConfig配置类里统一定义。自动填充这块配合TableField(fill FieldFill.INSERT)创建时间字段就能在insert时自动塞值不用每个Mapper方法都手动setCreateTime。3. 后端功能模块的层层拆解3.1 用户体系从注册到登录的完整闭环用户模块是“麻雀虽小五脏俱全”的典型案例。注册接口的核心逻辑是三步参数校验、用户名唯一性检查、密码加密入库。密码我用的BCryptBCryptPasswordEncoder是Spring Security自带的不需要额外引包。有些人偷懒用MD5加盐说“反正毕设没人攻击”我劝你善良。BCrypt的好处不仅仅是不可逆它的salt是随机生成的意味着同一个密码每次加密结果都不一样即便数据库泄露彩虹表也毫无用武之地。登录的Token方案我纠结了一下。用JWT的话无状态、跨域友好但存在一个尴尬问题无法主动让Token失效。用Redis存Session的话服务重启用户登录态丢失但可以随时踢人、随时续期。最后我选择的是“JWT Redis黑名单”组合方案正常登录发Token退出登录时把Token扔进Redis黑名单剩余有效期内有效既保留了无状态的好处又解决了注销问题。这个设计在答辩时稍微解释一下就能体现出你思考过“权衡取舍”而不是照搬教程。需要留意的是登录接口要加防刷机制。我当时的做法是同一个用户名5分钟内失败超过5次锁定15分钟。代码上用Redis的INCR配合EXPIRE实现计数器逻辑简单但非常管用。如果你懒至少也要加一个简单的验证码校验否则随便一个脚本就能把你登录接口打成筛子。3.2 美食列表与详情页的缓存策略美食列表页是这个系统访问量最大的接口没有之一。首页包括推荐位、分类导航、最新分享、热门排行。如果每次都查数据库扛不住是早晚的事。我在列表接口上做了两层优化第一层是Redis缓存。把整个首页数据序列化成JSON存进Rediskey设计为food:index:{categoryId}:{page}:{size}缓存时间5分钟。这样5分钟内不管有多少人访问首页压力全在Redis上数据库基本不被打扰。第二层是热榜缓存。热门排行榜我单独维护了一个Redis ZSetscore就是浏览量每当详情页被访问时ZINCRBY一次。排行榜接口直接ZREVRANGE取前N名完全绕开数据库。注意缓存更新的时机。最怕的是缓存和数据库不一致。我的策略是写操作发生时主动删除相关缓存而不是更新缓存。为什么因为写操作频率远低于读操作而且更新缓存需要重新组装数据成本高删除缓存只需要一个DEL命令等下一次读取时再回源数据库重建缓存简单又不容易出错。这也是业界最常见的Cache Aside Pattern。3.3 搜索功能的“够用就好”搜索是个大坑如果要做全文检索Elasticsearch是工业标准但成本和复杂度都不小。毕设场景下我的建议是能用MySQL解决的先用MySQL解决。我在food表的name字段上建了普通索引用LIKE CONCAT(%, #{keyword}, %)做模糊匹配配合LIMIT分页。对于几百条数据的小表这个查询耗时在毫秒级用户根本感知不到区别。不过“河南特色美食”这个题目有个提升空间河南本地人搜索“胡辣汤”可能直接搜“胡辣”到郑州可能搜“烩面”而不是“羊肉烩面”。如果要让搜索更“懂行”可以引入分词。热词里提到了HanLP一个开源的Java中文NLP库。我在搜索接口里加了一个可选升级点用HanLP对关键词做分词再把分词结果拼成多个LIKE条件。比如用户搜“开封灌汤包”分词后得到“开封”“灌汤包”SQL就变成WHERE name LIKE %开封% OR name LIKE %灌汤包%。这里要提醒的是引入HanLP之前先掂量一下JAR包体积。HanLP的依赖和数据文件加起来有三四十兆如果只是做模糊搜索可能得不偿失。我的最终方案是把它做成一个独立工具类通过配置开关控制是否启用默认关闭。这样代码里保留了升级路径但又不会给基础版本增加无谓的复杂度。3.4 图片上传选MinIO而非本地存储美食分享系统最核心的交互就是“发图”。不管是用餐实拍还是食材全家福几乎每个用户都会上传图片。图片存储这个环节如果直接把文件写到服务器本地磁盘项目部署时的迁移、备份、扩容都会被拖累。我选的是MinIO一个兼容Amazon S3协议的开源对象存储服务启动一个Docker容器就是一套完整的存储服务。接入MinIO的步骤很简单在application.yml里配置endpoint、accessKey、secretKey、bucketName。注入MinioClient上传时调putObject返回文件路径。给上传接口加一个文件类型和大小校验。踩过的坑有两个。第一个是MinIO的Endpoint坑在本地用http://localhost:9000没问题部署到服务器后如果endpoint还写localhost前端的图片就全挂了。正确做法是把endpoint配置成服务器IP或域名这样生成的图片URL才能被公网访问。第二个是Bucket的访问权限默认情况下Bucket是私有的直接拿URL访问会报AccessDenied。我建议在MinIO控制台把Bucket的访问策略设为public因为这些都是公开分享的美食图片没必要走预签名URL的逻辑。3.5 全局异常与参数校验的规范写法代码规范性上最能拉开差距的就是异常处理。我的做法是定义一个BusinessException运行时异常配合RestControllerAdvice全局异常处理器。业务代码里只需要throw new BusinessException(用户名已存在)异常处理器捕获后统一包装成Result.fail(code, msg)返回状态码统一200 HTTP业务状态码用自定义code区分。参数校验推荐用javax.validation的注解体系NotBlank、Size、Email。Controller入参上加Validated注解校验失败会被MethodArgumentNotValidException捕获再翻译成友好的提示信息返回给前端。这一套下来代码既整齐又能防止脏数据入库一举两得。热词里还提到了XSS攻击过滤这个在分享系统里确实存在隐患——用户的评论、分享内容都是富文本如果不过滤一个scriptalert(1)/script就能让你页面崩掉。我的建议是对用户的文本输入做统一过滤在全局请求体切面里把、等危险字符转义成HTML实体存进数据库的是安全内容输出时利用Thymeleaf的自动转义特性th:text默认转义双保险。4. 前端页面与交互设计落地方案4.1 服务端渲染还是前后端分离这个项目我选了Thymeleaf服务端渲染而不是Vue前后端分离。说下决策理由第一Thymeleaf天然支持服务端渲染SEO友好搜索引擎能直接抓到你每个美食页面的完整HTML第二Java后端可以无缝控制页面数据不涉及跨域问题开发调试心智成本低第三对于这个体量的系统前端复杂度不高杀鸡不用牛刀。热词里大量出现“springboot vue前后端分离”说明这是当前的主流趋势。但我要泼一盆冷水前后端分离不是目的是手段。如果你的团队没有专业前端、没有部署CDN的需求、没有移动端复用API的需求强行分离只会给自己增加两份工作——一套接口文档要维护一个前端项目要构建打包。尤其是当地址从index.html切到/food/1这种页面时历史回退、路由守卫的配置每一项都是时间黑洞。最终页面上用了Bootstrap 5 Thymeleaf模板继承。写页面时注意Thymeleaf的th:href拼接URL比如{/food/detail/{id}(id${food.id})}语法很简洁但新手经常在{}和${}的嵌套上犯迷糊。建议把所有公共片段导航、页脚抽到layout.html用th:replace统一引用。4.2 首页信息架构的“美食感”营造首页是用户对系统的第一印象信息架构上我参考了美食点评类App的布局顶部导航栏Logo 分类导航 搜索框 登录/用户信息。首屏轮播位推荐三道河南硬菜大图展示提升视觉冲击力。“地道河南味”分类入口八个分类图标每类带代表菜名如面食类烩面、饸饹面、汤类胡辣汤、豆沫、小吃类灌汤包、炒凉粉。本地热门榜单按浏览量Top10展示“打卡人数”。最新用户分享瀑布流卡片突出刚发布的美食笔记。有一个小设计很值得推荐每个美食卡片上除了图片和名称我还放了产地城市标签比如“郑州”“开封”“洛阳”。用户扫一眼就能感知到“河南各地美食”的覆盖面这也是紧扣项目主题的隐性表达。4.3 详情页的富文本回显与Markdown转换详情页是流量主战场。我在设计上分了三块左侧是美食图片和基本信息中间是做法步骤和食材清单右侧是评论区。其中做法步骤这一块用户发布时用的是textarea纯文本但存进数据库后我用了CommonMarkJava的Markdown解析库渲染成HTML再输出到页面上。这样管理员录入的“1. 和面2. 醒面3. 拉条”就能自动带有序号排版而不是挤成一大段。评论区我支持了楼中楼。根评论按时间正序排序子评论按时间倒序最新的回复排最上面。这个交互细节非常影响体验很多人做评论就一个list平铺所有评论结果楼层乱七八糟完全没有社交氛围。组装数据的代码不复杂先查根评论再按parent_id IN (根评论id集合)批量查子评论内存中分组即可。5. 部署、性能与安全加固的落幕5.1 Docker一键部署的完整配置项目写完后我把它做成了Docker Compose一键启动。部署文件包含三个镜像MySQL、Redis、MinIO外加应用本身的Dockerfile。下面是我用的核心配置version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: food_share_db ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql command: --default-authentication-pluginmysql_native_password redis: image: redis:7.0 ports: - 6379:6379 minio: image: minio/minio command: server /data --console-address :9001 ports: - 9000:9000 - 9001:9001 volumes: - minio_data:/data app: build: . depends_on: - mysql - redis - minio ports: - 8080:8080 environment: SPRING_PROFILES_ACTIVE: prod volumes: mysql_data: minio_data:应用层的Dockerfile要注意构建两次第一次用Maven容器编译打包第二次用JRE镜像运行。多阶段构建能让最终镜像体积从500MB降到200MB以内。基础镜像选择eclipse-temurin:8-jreJDK8和Spring Boot 2.7是绝配。5.2 那些只有上线才会暴露的问题项目部署到云服务器后我遇到了几个本地永远测不出来的问题。第一个是MySQL时区问题。本地MySQL默认时区是CST连接串上写了serverTimezoneAsia/Shanghai一切正常服务器上如果没配时区存进去的时间和实际时间差了8小时。解决方案是在Docker环境变量里设置TZAsia/Shanghai再在JDBC连接串加上useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai。第二个是Linux下MySQL的lower_case_table_names参数。Windows开发时表名大小写不敏感到了Linux默认大小写敏感我建的表叫Food但MyBatis-Plus自动生成的SQL查的是food直接报Table doesnt exist。解决方法是建表时统一用小写表名MySQL 8.0修改这个参数需要在初始化时指定没法直接ALTER。第三个是Redis持久化。默认RDB快照策略下服务器突然断电会丢失部分缓存数据。对于这个项目来说缓存丢了问题不大重新回源即可但对用户Session数据来说就不一样了直接全部掉线。解决方案是把Redis配置改成appendonly yes开启AOF至少每秒钟落盘一次。5.3 性能优化的三板斧性能优化这件事一定要先量化再动手。我的压测目标是Jmeter模拟200个并发用户持续跑5分钟接口P95响应时间不超过500ms。第一板斧是Thymeleaf的页面缓存。生产环境开启spring.thymeleaf.cachetrue模板解析后的AST对象会被缓存首次访问后页面渲染性能提升明显。注意开发环境要关掉它不然改个HTML都要重启应用。第二板斧是MySQL连接池。默认的HikariCP我调整了三个参数maximumPoolSize20、minimumIdle5、connectionTimeout30000。太小会让并发高时线程等待太大又消耗数据库资源。20是单机能承载的合理值不要迷信越大越快。第三板斧是全局懒加载。对于Food列表页如果直接查full_description这种大字段网络传输和解析都会变慢。我在实体类上用TableField(select false)把大字段排除只在详情页显式查询。这个优化肉眼可见——列表接口的响应体大小能减少一半以上。6. 写在最后的实操心得每次帮别人看这类Spring Boot毕设项目最常听到的一句话是“我按教程写了但不知道哪里不对”。这话我太熟了——因为教程只教你写正确的代码没人教你调试错误的代码。但我还是想说遇到报错不要慌先看异常栈顶去搜那段异常信息的前两百个字符八成能找到答案。这个项目做下来我个人最大的体会是设计比实现更重要边界比功能更重要。你不需要把所有技术栈都堆上去但你要把选型的理由想清楚——为什么用Redis为什么用MinIO为什么不用微服务。答辩时老师问的不是“你会用什么”而是“为什么用这个、不用那个”。能说出所以然这个项目就成了。最后再分享一个小技巧项目里所有的自定义配置一律抽到application.yml里做成可配置项不要在代码里写死任何魔法值。MinIO地址、缓存过期时间、分页大小全部用Value读取。这也是“可维护性”最直观的体现。 Spring Boot+Redis+MinIO打造河南特色美食分享系统
1. 项目整体设计与技术选型1.1 为什么选Spring Boot做美食分享系统我接手过不少相似的分享类项目这个“基于Spring Boot的河南特色美食分享系统”最打动我的地方在于它是一个特别典型的“非电商类内容平台”样本。没有复杂的订单流、没有支付回调、没有库存锁但恰恰因为业务边界清晰反而能把Spring Boot的核心能力——自动配置、Starter机制、分层架构——用到极致。先说技术选型的底层逻辑。市面上做这类系统常见路线有三条一是传统的SSMSpring Spring MVC MyBatis二是Spring Boot单体重应用三是Spring Boot 微服务全家桶。我个人的建议是如果只是学校毕设或小型个人项目老老实实选Spring Boot单体就够别一上来就整Nacos、Gateway那套。为什么因为项目的核心价值在“内容展示、UGC分享、检索体验”而不是分布式治理。微服务带来的服务拆分、链路追踪、配置中心在这个体量下纯属给自己挖坑。Spring Boot最划算的地方在于自动装配。比如你引入spring-boot-starter-web内嵌Tomcat直接给你配好引入spring-boot-starter-data-redis连接工厂、模板对象全都自动注册。我们不需要关心DispatcherServlet怎么映射、RedisConnectionFactory怎么建连接只要关注业务本身。我用一句话概括这类项目的选型心法能用Starter解决的绝不手写配置能用默认配置的绝不自定义Bean。这套系统我最终定的技术栈是Spring Boot 2.7.5 MyBatis-Plus 3.5.2 Redis MinIO文件存储 Thymeleaf服务端渲染。数据库选的MySQL 8.0JDK用的1.8。这里有个容易被忽略的坑Spring Boot 2.x系列和3.x系列在javax与jakarta命名空间上不兼容很多老教程还在用2.x的写法如果你不小心创建了3.x项目import javax.servlet直接编译报错。所以先锁定版本再动手写代码这比什么都重要。1.2 从标题反推出来的隐性需求“河南特色美食分享”这个题目表面上是一个内容展示站但拆开看其实藏着好几个子需求用户侧游客可以浏览美食列表、查看详情、搜索注册登录后能点赞、收藏、评论、发布自己的美食笔记。管理侧管理员要能管理美食分类、审核用户发布的分享、管理用户状态、统计数据。内容侧每道美食要有名称、所属城市、分类、图片、简介、做法步骤、食材清单最好还能绑定历史典故。检索侧支持按名称模糊搜索、按分类筛选、按热度排序还有关键词分词。这些需求一列出来系统的边界就清楚了。我做设计时没有贪多把“用户-内容-互动”作为三条主线所有表结构、接口、页面都围绕这三条线展开。比如用户和美食之间是收藏关系用户和评论之间是一对多关系美食和分类是多对一关系。理清这些关系后面建表、写Mapper、设计VO都不会乱。另外一个容易被忽视的点是“区域特色”的表达。河南美食不是铁板一块开封灌汤包、洛阳水席、郑州烩面、逍遥镇胡辣汤各有各的“地盘”。所以在设计美食表时我专门加了一个city字段标识所属城市并且支持按城市维度做筛选页。这个小设计在答辩和实际体验中都非常加分会让系统看起来是懂行的而不是简单的CRUD堆积。2. 数据库设计与核心表结构2.1 五张核心表的建模思路数据库设计是整个系统的地基我见过太多项目在表结构上偷懒后面写SQL写到怀疑人生。这个项目我最终落地的表一共七张核心五张user用户表字段包括id、username、passwordBCrypt加密存储、nickname、avatar、role0普通用户/1管理员、status、create_time。category美食分类表字段包括id、name、sort、description。food美食主表字段包括id、name、category_id、city、cover_image、description、ingredients食材清单用JSON或长文本、steps做法步骤长文本、view_count、like_count、favorite_count、status、create_time。comment评论表字段包括id、food_id、user_id、content、parent_id支持楼中楼回复、create_time。user_favorite收藏关系表字段包括id、user_id、food_id、create_time。建表时有几个细节值得说道说道。第一个是计数器的处理。view_count这类字段我建议直接冗余在主表里而不是每次用COUNT(*)去统计。原因很简单详情页每次刷新都要查评论数、收藏数、点赞数如果用聚合查询数据量大了以后会越来越慢而冗余字段只需要做原子自增UPDATE food SET view_count view_count 1 WHERE id ?性能差好几倍。第二个是parent_id的设计。评论回复如果只做一层用parent_id指向根评论即可。查询时先查根评论再根据根评论的id批量查子评论在内存中组装成树形结构。这里千万不要用递归SQLMySQL 8.0虽然支持WITH RECURSIVE但这个场景下两层评论用两次查询完全够写法简单还容易维护。第三个是user_favorite表要加唯一索引。UNIQUE KEY uk_user_food(user_id, food_id)这是防止重复收藏的兜底手段。你可能会说“我在代码里判断过了”但只要并发请求一到代码判断就形同虚设。数据库层面的唯一约束才是最可靠的。2.2 MyBatis-Plus的实用性选择关于ORM这一层我用的是MyBatis-Plus而不是原生MyBatis。原因很实在这个项目的单表CRUD占了七八成MyBatis-Plus的BaseMapper直接把这些操作封装好了selectById、insert、updateById开箱即用能省掉大量重复的XML映射文件。但要注意MyBatis-Plus的“反直觉”点。最典型的是updateById默认策略是NOT_NULL也就是实体中为null的字段不会更新。这在大多数场景下是好事但如果你想把某个字段置空直接传null是行不通的。我当时在实现“管理员下架美食”功能时就踩了这个坑我用updateById想设置status 0但实体里的status传的确实是0因为0不是null所以能更新成功可一旦想把audit_remark清空传null就无功而返。解决方案是在对应字段上加TableField(updateStrategy FieldStrategy.IGNORED)或者干脆用LambdaUpdateWrapper显式set。分页查询是另一个实操重点。MyBatis-Plus的PaginationInnerInterceptor必须显式配置否则Page对象查出来只是假分页——所有数据都查出来了只是帮你切了一刀。我习惯把分页插件、乐观锁插件、字段自动填充处理器放在同一个MybatisPlusConfig配置类里统一定义。自动填充这块配合TableField(fill FieldFill.INSERT)创建时间字段就能在insert时自动塞值不用每个Mapper方法都手动setCreateTime。3. 后端功能模块的层层拆解3.1 用户体系从注册到登录的完整闭环用户模块是“麻雀虽小五脏俱全”的典型案例。注册接口的核心逻辑是三步参数校验、用户名唯一性检查、密码加密入库。密码我用的BCryptBCryptPasswordEncoder是Spring Security自带的不需要额外引包。有些人偷懒用MD5加盐说“反正毕设没人攻击”我劝你善良。BCrypt的好处不仅仅是不可逆它的salt是随机生成的意味着同一个密码每次加密结果都不一样即便数据库泄露彩虹表也毫无用武之地。登录的Token方案我纠结了一下。用JWT的话无状态、跨域友好但存在一个尴尬问题无法主动让Token失效。用Redis存Session的话服务重启用户登录态丢失但可以随时踢人、随时续期。最后我选择的是“JWT Redis黑名单”组合方案正常登录发Token退出登录时把Token扔进Redis黑名单剩余有效期内有效既保留了无状态的好处又解决了注销问题。这个设计在答辩时稍微解释一下就能体现出你思考过“权衡取舍”而不是照搬教程。需要留意的是登录接口要加防刷机制。我当时的做法是同一个用户名5分钟内失败超过5次锁定15分钟。代码上用Redis的INCR配合EXPIRE实现计数器逻辑简单但非常管用。如果你懒至少也要加一个简单的验证码校验否则随便一个脚本就能把你登录接口打成筛子。3.2 美食列表与详情页的缓存策略美食列表页是这个系统访问量最大的接口没有之一。首页包括推荐位、分类导航、最新分享、热门排行。如果每次都查数据库扛不住是早晚的事。我在列表接口上做了两层优化第一层是Redis缓存。把整个首页数据序列化成JSON存进Rediskey设计为food:index:{categoryId}:{page}:{size}缓存时间5分钟。这样5分钟内不管有多少人访问首页压力全在Redis上数据库基本不被打扰。第二层是热榜缓存。热门排行榜我单独维护了一个Redis ZSetscore就是浏览量每当详情页被访问时ZINCRBY一次。排行榜接口直接ZREVRANGE取前N名完全绕开数据库。注意缓存更新的时机。最怕的是缓存和数据库不一致。我的策略是写操作发生时主动删除相关缓存而不是更新缓存。为什么因为写操作频率远低于读操作而且更新缓存需要重新组装数据成本高删除缓存只需要一个DEL命令等下一次读取时再回源数据库重建缓存简单又不容易出错。这也是业界最常见的Cache Aside Pattern。3.3 搜索功能的“够用就好”搜索是个大坑如果要做全文检索Elasticsearch是工业标准但成本和复杂度都不小。毕设场景下我的建议是能用MySQL解决的先用MySQL解决。我在food表的name字段上建了普通索引用LIKE CONCAT(%, #{keyword}, %)做模糊匹配配合LIMIT分页。对于几百条数据的小表这个查询耗时在毫秒级用户根本感知不到区别。不过“河南特色美食”这个题目有个提升空间河南本地人搜索“胡辣汤”可能直接搜“胡辣”到郑州可能搜“烩面”而不是“羊肉烩面”。如果要让搜索更“懂行”可以引入分词。热词里提到了HanLP一个开源的Java中文NLP库。我在搜索接口里加了一个可选升级点用HanLP对关键词做分词再把分词结果拼成多个LIKE条件。比如用户搜“开封灌汤包”分词后得到“开封”“灌汤包”SQL就变成WHERE name LIKE %开封% OR name LIKE %灌汤包%。这里要提醒的是引入HanLP之前先掂量一下JAR包体积。HanLP的依赖和数据文件加起来有三四十兆如果只是做模糊搜索可能得不偿失。我的最终方案是把它做成一个独立工具类通过配置开关控制是否启用默认关闭。这样代码里保留了升级路径但又不会给基础版本增加无谓的复杂度。3.4 图片上传选MinIO而非本地存储美食分享系统最核心的交互就是“发图”。不管是用餐实拍还是食材全家福几乎每个用户都会上传图片。图片存储这个环节如果直接把文件写到服务器本地磁盘项目部署时的迁移、备份、扩容都会被拖累。我选的是MinIO一个兼容Amazon S3协议的开源对象存储服务启动一个Docker容器就是一套完整的存储服务。接入MinIO的步骤很简单在application.yml里配置endpoint、accessKey、secretKey、bucketName。注入MinioClient上传时调putObject返回文件路径。给上传接口加一个文件类型和大小校验。踩过的坑有两个。第一个是MinIO的Endpoint坑在本地用http://localhost:9000没问题部署到服务器后如果endpoint还写localhost前端的图片就全挂了。正确做法是把endpoint配置成服务器IP或域名这样生成的图片URL才能被公网访问。第二个是Bucket的访问权限默认情况下Bucket是私有的直接拿URL访问会报AccessDenied。我建议在MinIO控制台把Bucket的访问策略设为public因为这些都是公开分享的美食图片没必要走预签名URL的逻辑。3.5 全局异常与参数校验的规范写法代码规范性上最能拉开差距的就是异常处理。我的做法是定义一个BusinessException运行时异常配合RestControllerAdvice全局异常处理器。业务代码里只需要throw new BusinessException(用户名已存在)异常处理器捕获后统一包装成Result.fail(code, msg)返回状态码统一200 HTTP业务状态码用自定义code区分。参数校验推荐用javax.validation的注解体系NotBlank、Size、Email。Controller入参上加Validated注解校验失败会被MethodArgumentNotValidException捕获再翻译成友好的提示信息返回给前端。这一套下来代码既整齐又能防止脏数据入库一举两得。热词里还提到了XSS攻击过滤这个在分享系统里确实存在隐患——用户的评论、分享内容都是富文本如果不过滤一个scriptalert(1)/script就能让你页面崩掉。我的建议是对用户的文本输入做统一过滤在全局请求体切面里把、等危险字符转义成HTML实体存进数据库的是安全内容输出时利用Thymeleaf的自动转义特性th:text默认转义双保险。4. 前端页面与交互设计落地方案4.1 服务端渲染还是前后端分离这个项目我选了Thymeleaf服务端渲染而不是Vue前后端分离。说下决策理由第一Thymeleaf天然支持服务端渲染SEO友好搜索引擎能直接抓到你每个美食页面的完整HTML第二Java后端可以无缝控制页面数据不涉及跨域问题开发调试心智成本低第三对于这个体量的系统前端复杂度不高杀鸡不用牛刀。热词里大量出现“springboot vue前后端分离”说明这是当前的主流趋势。但我要泼一盆冷水前后端分离不是目的是手段。如果你的团队没有专业前端、没有部署CDN的需求、没有移动端复用API的需求强行分离只会给自己增加两份工作——一套接口文档要维护一个前端项目要构建打包。尤其是当地址从index.html切到/food/1这种页面时历史回退、路由守卫的配置每一项都是时间黑洞。最终页面上用了Bootstrap 5 Thymeleaf模板继承。写页面时注意Thymeleaf的th:href拼接URL比如{/food/detail/{id}(id${food.id})}语法很简洁但新手经常在{}和${}的嵌套上犯迷糊。建议把所有公共片段导航、页脚抽到layout.html用th:replace统一引用。4.2 首页信息架构的“美食感”营造首页是用户对系统的第一印象信息架构上我参考了美食点评类App的布局顶部导航栏Logo 分类导航 搜索框 登录/用户信息。首屏轮播位推荐三道河南硬菜大图展示提升视觉冲击力。“地道河南味”分类入口八个分类图标每类带代表菜名如面食类烩面、饸饹面、汤类胡辣汤、豆沫、小吃类灌汤包、炒凉粉。本地热门榜单按浏览量Top10展示“打卡人数”。最新用户分享瀑布流卡片突出刚发布的美食笔记。有一个小设计很值得推荐每个美食卡片上除了图片和名称我还放了产地城市标签比如“郑州”“开封”“洛阳”。用户扫一眼就能感知到“河南各地美食”的覆盖面这也是紧扣项目主题的隐性表达。4.3 详情页的富文本回显与Markdown转换详情页是流量主战场。我在设计上分了三块左侧是美食图片和基本信息中间是做法步骤和食材清单右侧是评论区。其中做法步骤这一块用户发布时用的是textarea纯文本但存进数据库后我用了CommonMarkJava的Markdown解析库渲染成HTML再输出到页面上。这样管理员录入的“1. 和面2. 醒面3. 拉条”就能自动带有序号排版而不是挤成一大段。评论区我支持了楼中楼。根评论按时间正序排序子评论按时间倒序最新的回复排最上面。这个交互细节非常影响体验很多人做评论就一个list平铺所有评论结果楼层乱七八糟完全没有社交氛围。组装数据的代码不复杂先查根评论再按parent_id IN (根评论id集合)批量查子评论内存中分组即可。5. 部署、性能与安全加固的落幕5.1 Docker一键部署的完整配置项目写完后我把它做成了Docker Compose一键启动。部署文件包含三个镜像MySQL、Redis、MinIO外加应用本身的Dockerfile。下面是我用的核心配置version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: food_share_db ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql command: --default-authentication-pluginmysql_native_password redis: image: redis:7.0 ports: - 6379:6379 minio: image: minio/minio command: server /data --console-address :9001 ports: - 9000:9000 - 9001:9001 volumes: - minio_data:/data app: build: . depends_on: - mysql - redis - minio ports: - 8080:8080 environment: SPRING_PROFILES_ACTIVE: prod volumes: mysql_data: minio_data:应用层的Dockerfile要注意构建两次第一次用Maven容器编译打包第二次用JRE镜像运行。多阶段构建能让最终镜像体积从500MB降到200MB以内。基础镜像选择eclipse-temurin:8-jreJDK8和Spring Boot 2.7是绝配。5.2 那些只有上线才会暴露的问题项目部署到云服务器后我遇到了几个本地永远测不出来的问题。第一个是MySQL时区问题。本地MySQL默认时区是CST连接串上写了serverTimezoneAsia/Shanghai一切正常服务器上如果没配时区存进去的时间和实际时间差了8小时。解决方案是在Docker环境变量里设置TZAsia/Shanghai再在JDBC连接串加上useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai。第二个是Linux下MySQL的lower_case_table_names参数。Windows开发时表名大小写不敏感到了Linux默认大小写敏感我建的表叫Food但MyBatis-Plus自动生成的SQL查的是food直接报Table doesnt exist。解决方法是建表时统一用小写表名MySQL 8.0修改这个参数需要在初始化时指定没法直接ALTER。第三个是Redis持久化。默认RDB快照策略下服务器突然断电会丢失部分缓存数据。对于这个项目来说缓存丢了问题不大重新回源即可但对用户Session数据来说就不一样了直接全部掉线。解决方案是把Redis配置改成appendonly yes开启AOF至少每秒钟落盘一次。5.3 性能优化的三板斧性能优化这件事一定要先量化再动手。我的压测目标是Jmeter模拟200个并发用户持续跑5分钟接口P95响应时间不超过500ms。第一板斧是Thymeleaf的页面缓存。生产环境开启spring.thymeleaf.cachetrue模板解析后的AST对象会被缓存首次访问后页面渲染性能提升明显。注意开发环境要关掉它不然改个HTML都要重启应用。第二板斧是MySQL连接池。默认的HikariCP我调整了三个参数maximumPoolSize20、minimumIdle5、connectionTimeout30000。太小会让并发高时线程等待太大又消耗数据库资源。20是单机能承载的合理值不要迷信越大越快。第三板斧是全局懒加载。对于Food列表页如果直接查full_description这种大字段网络传输和解析都会变慢。我在实体类上用TableField(select false)把大字段排除只在详情页显式查询。这个优化肉眼可见——列表接口的响应体大小能减少一半以上。6. 写在最后的实操心得每次帮别人看这类Spring Boot毕设项目最常听到的一句话是“我按教程写了但不知道哪里不对”。这话我太熟了——因为教程只教你写正确的代码没人教你调试错误的代码。但我还是想说遇到报错不要慌先看异常栈顶去搜那段异常信息的前两百个字符八成能找到答案。这个项目做下来我个人最大的体会是设计比实现更重要边界比功能更重要。你不需要把所有技术栈都堆上去但你要把选型的理由想清楚——为什么用Redis为什么用MinIO为什么不用微服务。答辩时老师问的不是“你会用什么”而是“为什么用这个、不用那个”。能说出所以然这个项目就成了。最后再分享一个小技巧项目里所有的自定义配置一律抽到application.yml里做成可配置项不要在代码里写死任何魔法值。MinIO地址、缓存过期时间、分页大小全部用Value读取。这也是“可维护性”最直观的体现。