1. 项目定位与业务模型美食分享系统到底在解决什么问题先聊点实际的。很多人一看到美食分享系统这种名字第一反应是这不又是一个CRUD增删改查项目吗。确实如果只做Food表的新增、删除、修改、查询那它确实只值一个期末考试的分量。但如果你把这个系统放到真实业务场景里去看——本地美食推荐、地方特色挖掘、用户UGC内容生产它的核心价值就不在CRUD本身而在于两件事一是内容的结构化沉淀二是地域维度的信息匹配。我开发这个地方特色美食分享系统时最核心的思路就是不同地方的人对同一种食物的认知是完全不同的。比如肠粉广东人觉得这是早餐日常外地游客却把它当成必打卡的特色小吃。同一个词在不同地域语境下代表着完全不同的搜索意图。所以这个系统的第一设计原则不是做一个美食百科而是做一个基于地域属性的美食分享社区——每个美食条目都必须归属到具体的地区用户围绕地区进行浏览、分享、互动。从需求侧来看这个系统主要解决三个问题信息分散问题本地人才知道的地道美食往往只存在于朋友圈、口口相传或者本地论坛的零散帖子里没有结构化整理。系统提供统一的发布入口让美食信息按区域沉淀。地域匹配问题游客想找XX区有什么特色美食靠搜索引擎得到的结果往往是营销软文。系统按地区维度组织内容可以直接给出这个区的人都在吃什么。互动与信任问题光有内容展示还不够用户需要点赞、收藏、评论来表达态度。一套完整互动机制是社区类系统区别于单纯信息展示系统的分水岭。所以你看这个项目的价值并不在于用了多高深的技术而在于业务模型是否清晰。开发之前先把这三点想清楚后面的表结构和接口设计就有了方向不会写着写着变成四不像。2. 技术选型理由与数据建模12张核心表是怎么设计出来的2.1 为什么是SpringBoot MyBatis-Plus MySQL这套组合选型这件事我直接说结论SpringBoot MyBatis-Plus MySQL Redis可选是这个体量项目的黄金组合没有之一。原因很简单SpringBoot解决的是Java后端开发中配置繁琐的问题。你想想如果没有SpringBoot你要手动配Tomcat、配SpringMVC、配数据源、配事务管理器光这些就能消耗掉两天时间。SpringBoot把这一切变成自动配置我可以在拿到需求后的半小时内把工程骨架搭起来把精力全部留给业务逻辑。MyBatis-Plus解决的是单表CRUD开发效率低的问题。它内置了通用的Mapper方法简单的增删改查连SQL都不用写。美食系统的用户表、地区表、评论表都是典型的单表操作用MyBatis-Plus的ServiceImpl继承就能少写几百行重复代码。MySQL这里不用多说稳定的关系型数据库这个项目的数据模型有明确的外键关联关系用户-帖子-评论-点赞用关系型数据库天然合适。至于Redis在这个项目里不是强依赖。我建议在开发和部署的时候加上但早期的功能验证阶段可以先把逻辑跑通再引入缓存避免步子迈太大扯到蛋。2.2 核心表结构从用户到内容到互动的三层模型整个数据库设计我按用户层 → 内容层 → 互动层三层来拆解共12张表。每张表的存在都是有业务理由的不是DBA强迫症发作。用户层user用户表账号、密码、昵称、头像、个人简介、注册时间。密码必须加密存储这个后面单独说。user_follow用户关注表记录用户之间的关注关系。美食分享系统虽然以内容为核心但关注关系是社区黏性的基本盘。内容层food美食主表这是整个系统的核心。字段包括美食名称、所属地区关联地区表、美食分类、封面图、详细描述、发布者ID、浏览量和状态。food_category美食分类表炒菜、小吃、甜品、饮品等方便用户按分类筛选。region地区表省-市-区三级结构。我这里用的是扁平化加父子ID的方式比单独建三张表更灵活。food_attach美食图片表一个美食条目对应多张图片一对多关系单独建表。strategy攻略文章表除了短图文分享系统还支持长文攻略。这是内容深度的补充。互动层user_like点赞表记录用户对美食内容的点赞关系。user_collect收藏表记录用户收藏的内容。food_comment评论表用户对美食内容的评论包含回复逻辑。notice公告表系统公告比如新增XX地区美食数据。operation_log操作日志表记录关键操作便于管理员做数据审计。这12张表之间最关键的关联逻辑是美食内容必须归属到地区互动行为必须归属到用户评论可以嵌套回复。明确了这三条关联规则后面的Service层代码写起来就非常顺畅。2.3 数据库设计的三个关键决策这里分享三个我在设计时踩过坑后总结出的经验**第一冗余设计要克制。**比如地区表很多人在美食表里直接存广东省/广州市/天河区这种字符串查询倒是方便了但后续想做统计比如哪个区发布的美食最多就非常痛苦。我这里的做法是food表只存region_id需要地区名称时再关联region表。虽然查询多了一次JOIN但换来了数据的一致性和可统计性值。**第二图片地址不要直接存整个Base64编码。**这个坑我见过太多新手踩了——把图片转成Base64字符串直接塞进数据库字段里。你的数据库会瞬间膨胀而且查询速度直线下降。正确做法是图片上传到本地磁盘或对象存储服务数据库里只存访问URL路径。**第三所有时间字段统一用时间戳或者统一的日期格式。**这个项目里的create_time、update_time我都统一用datetime类型并且由后端代码统一填充不依赖MySQL的CURRENT_TIMESTAMP自动填充。原因是如果前后端时间格式不统一展示层会出现各种时区问题统一由Java代码生成时间可控性最强。3. 从发布美食到地域检索核心业务链路的完整实现3.1 用户认证JWT 拦截器整个系统所有的用户相关操作都依赖认证体系。我采用的是JWTJson Web Token方案后端定义一个拦截器统一校验请求头里的Authorization字段。从原理上讲JWT的核心思想是用户登录成功后服务器生成一个包含用户ID和过期时间的签名字符串返回给前端。前端在后续每次请求时把这个字符串放在请求头里后端拦截器验证签名和有效期即可。这个方案的好处是服务器不需要保存session天然支持无状态扩展对前后端分离架构极其友好。实际开发时的核心代码逻辑是在SpringBoot里定义一个WebMvcConfigurer实现类注册一个HandlerInterceptor。拦截器里通过token工具类解析请求头如果token有效就把用户ID存入ThreadLocal供后续业务方法直接获取当前登录用户。这样写的好处是整个系统的Controller层代码不需要在方法签名里反复传userId直接通过ThreadLocal拿就能做判断是否是当前用户发布的这类操作。提示Token过期时间的设置很有讲究。设置太短用户用着用着就被踢下线体验差设置太长盗用风险高。个人经验是客户端项目7天、管理端2小时比较合理。这个项目里我设置的是7天毕竟美食分享是低频操作用户不可能一天刷十几次。3.2 发布美食服务端的完整链路发布美食是系统的核心操作。用户在前端表单里填写美食名称、所属地区三级联动选择、分类、详细描述并上传1-6张图片。后端处理流程分四步参数校验与XSS过滤所有文本字段不能为空描述限制在500字内且需过滤HTML标签。这里我使用了自研的XSS过滤器组件统一拦截处理请求中的危险字符防止存储型XSS攻击。图片上传处理前端先把图片上传到服务器指定目录返回图片URL地址。发布表单里只是携带图片URL字符串发布接口本身不接收图片文件流。这样做的原因是图片上传独立于业务事务避免大文件上传导致整个发布事务长时间占用数据库连接。插入美食主表与图片附表这一步要保证事务一致性。主表插入成功但图片表插入失败怎么办在Transactional注解的保证下要么全部成功要么全部回滚。地区数据更新对应地区的发布计数加一。这个统计字段在地区表里冗余维护展示端直接取用不需要实时统计。整个链路上最容易被忽略的是事务边界的划分。图片上传和主表数据插入绝对不能放在同一个事务里——脱机状态下的文件操作如果参与数据库事务一旦事务回滚文件系统是无法跟着一起回滚的磁盘上就会留下孤儿文件。3.3 按地域检索的SQL与接口设计地域检索是这个系统区别于普通内容聚合项目的最核心特色。我在接口设计上采用的是**条件选取 分页返回**模式GET /api/food/page?pageNum1pageSize10regionId440106categoryId2keyword肠粉这里的regionId是整个检索的核心。为了支持看完整广州市不限定到区和只看天河区精确到区两种检索模式我对region表设计了一个parent_id字段检索时根据传入的regionId先查其子区域列表select idselectFoodPageByRegion resultTypeFoodVO SELECT f.*, r.name AS regionName FROM food f LEFT JOIN region r ON f.region_id r.id WHERE f.status 1 if testregionIdList ! null and regionIdList.size() 0 AND f.region_id IN foreach collectionregionIdList itemrid open( separator, close) #{rid} /foreach /if if testkeyword ! null and keyword ! AND (f.name LIKE CONCAT(%, #{keyword}, %) OR f.description LIKE CONCAT(%, #{keyword}, %)) /if ORDER BY f.create_time DESC /select这段代码的核心逻辑是先根据用户的检索层级确定regionIdList再把这个list传给SQL做IN查询。如果用户选的是省级会把省下所有市级、区级的ID全部查出来一次性匹配如果用户选的是精确区级就只查这一个区域的数据。接口返回时我用的是自定义的FoodVO视图对象它比实体类多出了regionName地区名称、publisherName发布者昵称、coverImage封面图、likeCount点赞数、commentCount评论数、collectCount收藏数这几个需要查询联动才能拿到的展示字段。前端拿到这个VO对象列表后能直接渲染卡片列表不用再次发请求查关联信息。4. 图片上传与内容安全开发中最容易翻车的两个环节4.1 文件上传目录结构、格式校验与访问映射图片上传在开发环境里很简单但一旦上线部署坑一个接一个。我的方案是这样的目录结构设计/usr/local/food-sharing/ ├── upload/ │ ├── images/ │ │ ├── 2025/01/ │ │ │ ├── 1735689600000_abc123.jpg │ │ │ └── ... │ └── avatar/按年月分子目录存储文件名用毫秒时间戳_随机字符串拼接避免文件名冲突同时防止用户原始文件名里带中文、特殊字符导致服务器编码问题。校验逻辑上传接口接收到MultipartFile时要做三件事——校验文件扩展名只允许jpg、jpeg、png、gif、校验文件大小单张不超过5MB、重命名文件。校验不通过直接返回业务异常码。访问映射是这里最容易被新手忽略的。SpringBoot默认的静态资源路径包含classpath:/static/但上传到服务器本地的图片并不在这个路径里。如果你直接把图片URL写成/static/xxx.jpg部署后就会出现404。解决方法是自定义静态资源映射Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:/usr/local/food-sharing/upload/); } }这样前端访问/upload/images/2025/01/xxx.jpg时请求会映射到服务器本地磁盘上的对应文件图片就能正常展示。4.2 XSS攻击防护全局过滤器做输入净化系统里有用户发布内容和评论功能这就意味着必须考虑存储型XSS攻击。我在这方面的做法是写了一个全局的XssFilter继承OncePerRequestFilter对请求体里的字符串参数做统一清洗。原理并不复杂当请求进入Controller之前先经过这个过滤器。过滤器把请求体包装成自定义的XssHttpServletRequestWrapper重写getParameter和getInputStream方法对获取到的值统一做HTML标签过滤转义。比如用户提交scriptalert(xss)/script经过过滤后变成lt;scriptgt;alert(xss)lt;/scriptgt;这些内容再存入数据库就是纯文本不会作为HTML被浏览器解析执行。这里要特别说明网上很多XSS过滤器会直接删掉所有HTML标签但实际业务场景中用户描述里可能包含换行符、加粗标记等常见格式一刀切会让体验大打折扣。我采用的策略是白名单过滤保留p、br、strong、em等安全标签丢弃script、iframe、object、style等危险标签。在给读者讲这部分时我会再提醒一句安全性防御宁可保守也不要激进误杀否则用户反馈描述怎么乱码了比被攻击了更先出现。4.3 SQL注入与越权防护的兜底方案除了XSSSQL注入这个经典问题在MyBatis框架下已经天然免疫了一部分——因为我用的是#{}预编译方式传参不是${}字符串拼接。但开发时依然要有这个意识能不用${}就不用必须用时必须是常量值或者是白名单校验过的内容比如排名字段名。越权防护则是很多同学容易忽略的。比如删除自己发布的美食这个接口如果后端只接收foodId参数就直接执行删除那恶意用户完全可以遍历ID删掉别人的内容。正确的做法是删除前先根据foodId查出这条记录比对记录的publisher_id是否等于当前登录用户ID不一致就返回无权操作。虽然这只是一行if判断但它是防止水平越权的关键防线。5. 互动模块的实现细节点赞幂等、评论排序与消息通知5.1 点赞系统幂等性设计与数据一致性点赞是社区类系统里最简单也最容易写出bug的功能。最简单的实现是前端发一个请求POST /api/food/like/{foodId}后端往user_like表插入一条记录然后把food表的like_count字段加一。但这里埋了两个坑坑一重复点赞。同一个用户对同一条美食点了两次赞第一次插入成功第二次再插入就会违反联合唯一索引用户ID 美食ID直接抛异常。所以我用两条SQL来保证幂等// 先查询是否已点赞 Integer count userLikeMapper.selectCount( new LambdaQueryWrapperUserLike() .eq(UserLike::getUserId, userId) .eq(UserLike::getFoodId, foodId)); if (count 0) { // 已点赞则取消同时数量减一 userLikeMapper.delete(...); foodMapper.decrLikeCount(foodId); } else { // 未点赞则新增同时数量加一 userLikeMapper.insert(...); foodMapper.incrLikeCount(foodId); }坑二并发一致性问题。如果多个用户同时点赞like_count like_count 1这种操作在高并发下会出现丢失更新。虽然美食分享系统的并发量远远达不到这个量级但作为工程实践我依然推荐用SQL原子操作UPDATE food SET like_count like_count 1 WHERE id ?这一步在数据库层面是原子性的不会有中间态能彻底避免并发加1时丢数据的隐患。在项目里我还用了Redis做热点数据缓存详情在第6章说明。5.2 评论模块楼层数与嵌套回复评论模块我采用的是**两表结构**food_comment表里的parent_id字段区分顶级评论和子回复。顶级评论的parent_id为0子回复的parent_id指向被回复的那条评论的ID。接口返回时需要一次性把所有评论拉出来然后在Java内存里构建成树形结构// 1. 查询该美食的所有评论 ListComment allComments commentMapper.selectByFoodId(foodId); // 2. 构建顶级评论 - 子评论的映射 MapInteger, ListComment childMap allComments.stream() .filter(c - c.getParentId() ! 0) .collect(Collectors.groupingBy(Comment::getParentId)); // 3. 组装成树 ListCommentVO rootComments allComments.stream() .filter(c - c.getParentId() 0) .map(c - { CommentVO vo convertToVO(c); vo.setChildren(childMap.getOrDefault(c.getId(), Collections.emptyList())); return vo; }) .collect(Collectors.toList());这里有一个交互细节值得思考子回复到底应该展示回复给谁的信息。如果只显示子评论内容用户根本不知道这条回复是在回应谁。我的做法是在food_comment表里额外加一个reply_user_id字段记录被回复人的用户ID前端在渲染时显示回复某某内容。这种体验上的小细节往往决定了社区产品的口碑。评论排序我用的是时间正序。顶级评论按时间正序排列会让用户读起来有连贯的对话感——先问的先展示后回复的紧接着出现。点赞数高的评论要不要置顶这里我的取舍是初期系统数据量不大时间正序就够用点赞置顶等数据规模大了再加也不迟。5.3 内容审核与发布权限一个系统能不能稳定跑起来的底线美食分享如果不加任何审核机制一天之内平台就会被广告、垃圾信息、色情图片淹没。我设计了一套**先发布后审核**的内容管控策略用户提交的美食内容和评论正常发布但状态默认是pending待审核。管理员在后台看到待审核列表通过后状态变为normal。被打回rejected的内容只有发布者自己可见并提示内容未通过审核请修改后重新提交。这里需要解释一下为什么不能让内容直接发布后再删因为用户发布美食的那一瞬间他的核心诉求是分享这个动作已经完成了即使内容被删他已经获得了表达上的满足感。而先审核后放出的模式虽然内容展示有延迟但对于一个想要长期稳定运营的社区来说这种延迟是值得的。实际开发时我在游客访问的接口SQL里都加了AND status 1的过滤条件保证未过审内容不会被非发布者看到。6. 部署上线与性能优化从开发机到服务器的最后一公里6.1 开发环境、测试环境、生产环境的配置分离这个项目涉及到数据库连接、文件存储路径、日志级别等环境相关配置如果所有环境共用一套application.yml上生产时就会面临改了数据库密码忘了改日志路径这类低级事故。SpringBoot对多环境配置的支持非常成熟。我在项目的resources目录下拆了三份配置文件application.yml # 公共配置 application-dev.yml # 开发环境 application-prod.yml # 生产环境启动时通过--spring.profiles.activeprod指定使用生产配置。生产环境的数据库密码我不建议明文写在配置文件里虽然这个项目体量上不需要引入配置中心但用环境变量方式注入也是一个好习惯spring: datasource: url: ${DB_URL} username: ${DB_USERNAME} password: ${DB_PASSWORD}配套的部署命令是mvn clean package -DskipTests scp target/food-sharing.jar rootserver:/opt/food-sharing/ java -jar food-sharing.jar --spring.profiles.activeprod --server.port80806.2 Redis缓存热点数据浏览量与点赞数美食首页是典型的读多写少场景如果把所有数据每次都从MySQL查询虽然数据量不大时性能不会有明显问题但系统的架构质量一直是衡量工程能力的重要指标。我在首页接口和美食详情接口上做了两层Redis缓存列表页缓存首页美食列表的数据量大但更新频率低。我以页码地区ID为key把查询结果序列化成JSON字符串存到Redis缓存时间5分钟。用户首次访问时查MySQL并写入缓存后续直接命中缓存大大减轻了数据库压力。计数器缓存点赞数、收藏数直接缓存到Redis里每次操作时先更新Redis然后异步同步到MySQL。这样高并发下点赞操作不会打到数据库同时Redis的原子自增操作天然解决并发问题。有一点必须说明Redis缓存引入后数据一致性是新的挑战。我的策略是Cache Aside Pattern先更新MySQL再删除Redis中的对应缓存。下次请求发现缓存不存在自然回源数据库重新加载。这个模式简单可靠不至于出现复杂的双写一致性Bug。6.3 反编译与源码交付这个项目源码该怎么看标题里有附源码05471那我就以这个项目的源码为例给读者讲一讲拿到一套SpringBoot源码后应该从哪里开始看。第一步看pom.xml。它告诉你这个项目用了哪些依赖、版本号多少本质上技术栈的目录。第二步看application.yml。确认数据库连接配置、端口号、文件上传路径等环境信息。如果本地要跑起来先把数据库建好、密码改对。第三步看数据库脚本。项目里通常带有sql文件的初始化脚本按顺序执行创建表和初始数据。第四步从Controller层入手读代码。围绕一个功能点从Controller → Service → Mapper依次往下看理解一个完整的请求是怎么被处理的。第五步找项目启动类右键运行开启你的调试之旅。用这个项目举例启动类在FoodSharingApplication.java需要改成localhost:3306/food_sharing确认数据库名无误。前端接口的本地调试地址是http://localhost:8080/api。拿到源码后这样一步步跑起来整体阅读体验是相当流畅的。7. 项目落地后的测试与验收上线前必须做好的三件事7.1 接口联调前端与后端的分歧怎么处理前后端分离项目中最耗时间的是前端和后端对接口字段名称理解不一致。比如后端返回的字段叫createTime前端以为是created_at页面就会渲染空白。解决方案就是统一API文档规定所有接口的返回结构{ code: 200, message: success, data: { } }详情数据的VO对象统一驼峰命名。在开发阶段我还会开启Swagger-UI这样前端可以随时查看接口的入参和出参格式减少沟通成本。测试时要重点验证的场景包括发布美食的图片上传、二级地区联动查询、重复点赞取消、评论树形结构是否正确、未登录用户访问受保护接口返回408未授权。7.2 性能测试压测结果能到什么水平我个人这台开发机器上用JMeter做了一个基础压测模拟100个用户并发访问首页接口在开启Redis缓存的情况下平均响应时间约80ms吞吐量每秒约800请求。关闭Redis缓存后同样的并发条件平均响应时间上升到400ms左右。这里的数据说明了一个事实——Redis缓存在这个系统里的价值非常明显。MySQL慢查询日志也值得重点观察。我增加了对food表和user_like表的索引food表的create_time建了普通索引region_id和status建了联合索引user_like表在user_id和food_id上建了联合唯一索引。索引设计并不复杂但带来的查询性能提升是数量级的。7.3 上线部署的完整操作清单最后给读者一份可以直接拿来用的上线清单服务器安装JDK 17、MySQL 8.x、Redis 6.x。新建数据库并导入sql/init.sql脚本。配置application-prod.yml里的数据库地址、密码、文件上传路径。用mvn clean package -DskipTests打包。上传jar包到服务器用NoHup命令后台启动。用Nginx做反向代理将/api开头的请求转发到Java服务端口。验证静态图片访问映射是否正常。导入初始地区数据启动后用swagger-ui.html测试接口。关于Maven打包这里多说一句如果你的项目引用了本地自定义jar包直接mvn package可能会报程序包xxx不存在的错。遇到这种情况先执行mvn install:install-file把本地jar包安装到本地Maven仓库再执行打包就可以了。这是我经常在群里看到同学卡住的地方。最后聊聊我对附源码这件事的看法。源码是一套项目的骨血但拿到源码不代表能跑起来。我写这篇分享的出发点是把源码背后那些没有写进注释里的决策过程——包括为什么选这个技术栈、为什么这样设计表、为什么这个接口要这样实现——都摊开来讲清楚。你在复现这个项目时不看也能把系统跑起来但把每个决策背后的逻辑想明白这套源码才算真正属于你自己的东西。