SpringBoot美食推荐系统实战：从数据库设计到协同过滤落地

拿到一套“基于SpringBoot的美食信息推荐网站系统”的源码包里面还带着论文、部署文档和配套讲解多数人的第一反应都是赶紧打开IDEAjava -jar跑起来看看效果。但实际你会发现照着部署文档一步步走大概率还是会卡在某些莫名其妙的地方数据库编码、端口冲突、推荐结果不生效甚至论文里写的模块和源码对不上。这篇文章我想站在一个做过类似项目的开发者角度把这套系统的完整脉络拆开讲技术选型为什么是SpringBoot数据库表为什么要这么设计推荐模块到底怎么从“热门榜”演变成“个性化推荐”以及源码、论文、部署文档这几样东西怎么配合使用才算真正交付。1. 先看明白这套交付物的构成源码、论文、部署文档每部分都是干什么的1.1 “美食信息推荐网站”到底是一个什么系统看标题不能只盯着“推荐系统”这四个字。核心其实是美食信息加推荐用户进来不是点外卖、不是下单支付而是浏览菜谱、查看菜品分类、阅读食材和做法顺便收藏、评论。整个网站的核心价值落在“帮助用户从海量美食信息里快速找到自己想吃、想做的菜”。所以功能上至少要覆盖用户注册登录、美食分类浏览、关键词搜索、详情页展示、收藏、评论以及基于用户行为做个性化推荐。这个定位决定了后端接口的设计和数据库表的粒度千万不要一上来就想着做购物车、订单、支付那套东西那是另外一个项目。1.2 源码、论文、部署文档、讲解四件套的关系“源码lw部署文档讲解等”是典型的毕业设计或者课程设计交付结构。源码是核心它承载了所有功能论文是把“为什么这么做”讲清楚让评委知道你的设计思路部署文档是让别人能在自己的电脑上把这个系统跑起来讲解则是答辩演示的底气。四者不是孤立的论文里的模块划分必须和源码包结构对得上部署文档里的每一步都要能和实际命令一一对应。见过太多项目源码写得不错但论文里画的功能模块图和代码目录完全不是一回事答辩的时候被问两句就露馅。1.3 这套项目到底适合谁学如果你是Java初学者想找一个能练手、能写进简历的完整项目这类系统是很好的起点。它技术栈主流、业务逻辑清晰、推荐模块又有亮点可讲不会像纯CRUD的图书管理系统那样显得单薄也不像电商秒杀那种高并发系统难以驾驭。如果你是在准备课程设计或毕业设计这套结构更是直接对标交付要求。每个模块拆开看都不算难但合在一起就构成了一个“系统级”项目这恰恰是很多学习者最缺的整合能力。2. 技术选型怎么定SpringBoot版本、前端方案、核心依赖一次说清2.1 SpringBoot版本别纠结2.7.x 是稳妥选择只要不是在新项目里非要用JDK17的新特性SpringBoot建议直接选2.7.x。原因很现实大多数校园机、旧的服务器环境、网上现成的教程生态都还停留在JDK8 SpringBoot2.x 的组合。SpringBoot 3.0 之后要求JDK17起步虽然性能更好但很多配套依赖版本会变遇到问题很难在百度或者论坛里找到现成解法。对一个需要稳定交付的项目来说“主流生态兼容”比“新版本特性”重要得多。你只要在pom.xml里把版本号定成2.7.18这类稳定版本JDK8下打包运行基本不会出幺蛾子。2.2 前端用Thymeleaf还是前后端分离这是拿到项目后最需要想清楚的一件事因为它直接决定部署方式。Thymeleaf服务端渲染页面由SpringBoot直接渲染整个项目打包成一个jar就能跑部署最简单不需要额外配置Nginx适合前端基础薄弱、想把精力放在后端的同学。Vue Axios 前后端分离后端只提供JSON接口前端单独工程本地开发用Vite/Webpack代理线上部署需要把前端打包后的静态文件扔到Nginx里再由Nginx把/api反向代理到SpringBoot端口多一层配置但更接近企业实际开发模式简历上写“前后端分离项目”更有分量。我个人建议如果目标是完整跑通、顺利答辩用Thymeleaf方案最省心如果目标是想在简历里体现工程化能力那就选前后端分离。两者核心后端代码没有本质区别差的只是接口返回形式和静态资源处理方式。2.3 核心依赖清单和工程结构一套够用又不臃肿的技术栈大概是下面这些用表格列出来方便对照组件版本建议作用SpringBoot2.7.x应用基础框架MyBatis-Plus3.5.xORM简化单表CRUD和分页MySQL5.7 / 8.0主数据库Lombok随Boot管理减少实体类样板代码Hutool5.8.x工具类库加密、日期、随机数JJWT0.9.x登录令牌或者换成Sessionknife4j4.x接口文档答辩演示加分Redis可选任意稳定版缓存热门榜和推荐结果工程结构上建议单独拆出一个recommend包把推荐算法相关的类都放进去而不是散落在service里。这样论文写“推荐模块设计”的时候能直接对上源码包目录答辩也更好讲。后端分层保持经典的controller - service - mapper再加entity、vo、dto、config、common这类辅助包。如果项目里还要处理评论内容的XSS问题顺手加一个全局过滤器处理一下请求参数统一防脚本注入这个在小项目里很加印象分。3. 数据库表结构是推荐算法的地基把这几张表设计好后面推荐才有数据可算3.1 核心表与字段设计我刚拿到项目时先干的事情不是读代码而是看SQL脚本因为表结构直接暴露了系统的数据规模、核心业务和推荐计算的可能性。一套美食信息推荐系统通常要有这样几张表用户表 user用户ID、用户名、密码MD5加盐或BCrypt加密、头像、城市、创建时间。性别和城市这类字段对后面“相似用户”的挖掘有意义可以留。美食表 food美食ID、名称、分类ID、封面图URL、简介、食材、做法、浏览量、收藏数、状态。注意这里的热度字段要加对索引因为热门榜查询会频繁按它排序。分类表 category美食分类川菜、粤菜、烘焙、甜品等让列表页和搜索页有树状导航结构。美食标签关联表 food_tag美食ID、标签名称。也可以直接把标签字段塞在food表里用逗号分隔但为了推荐算法做标签匹配独立关联表更方便聚合查询。用户标签偏好表 user_tag_pref用户ID、标签名、偏好得分。这张表是标签推荐的核心用户的每次浏览、收藏、评论都会折算成分数累加到这里。收藏表 favoriteID、用户ID、美食ID、创建时间加唯一索引(user_id, food_id)避免重复收藏。评论表 commentID、用户ID、美食ID、评论内容、创建时间。浏览记录表 browse_logID、用户ID、美食ID、浏览时间后面做用户协同过滤时要用它构造行为序列。3.2 每张表在推荐链路中的角色定位很多人建表只盯着“功能”把收藏、评论、浏览记录都做成了可有可无的日志表这就浪费了。在这套系统里它们都是推荐算法的数据燃料热门榜冷启动用户刚注册没有行为数据时直接靠food.heat和favorites_count组合排序出默认榜单保证“首页永远有东西可看”。标签偏好计算用户查看某道菜详情时把这道菜的所有标签都累加进user_tag_pref。浏览权重低一点2收藏高一点5评论最高3。用户相似度计算虽然用户没有显式打分但可以从browse_log和favorite里反推用户对美食的隐式评分构造出“用户-美食”矩阵做协同过滤。这张表设计的巧妙程度直接决定了推荐模块的效果上限。如果表设计的时候没留行为采集的位置后面算法写得再好也没有数据喂进去。3.3 建表SQL的几个关键点我摘一段比较关键的建表语句来说明细节CREATE TABLE browse_log ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) DEFAULT NULL, food_id bigint(20) DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_food (user_id,food_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里联合索引很关键因为协同过滤要反复查“某用户看过哪些美食”如果没有索引行为日志表一旦积累几千条数据查询就会明显变慢。另外所有表字符集都建议用utf8mb4它能存emoji表情评论功能里如果用户发了一个表情默认的utf8字符集会直接报错或变问号。4. 推荐功能从热门榜到个性化标签偏好和用户协同过滤的落地代码4.1 第一层冷启动热门榜系统刚上线或者某个新用户没有任何行为记录这个时候推荐系统还没法学最稳妥的方式就是热榜兜底。写一个查询按浏览量和收藏数加权排序取前N条ListFoodVO hotFoods foodMapper.selectList( new LambdaQueryWrapperFood() .orderByDesc(Food::getHeat) .orderByDesc(Food::getFavoritesCount) .last(limit 10) );这段代码没什么技术含量但它的角色很重要任何推荐分支的返回值都不能为空。一旦个性化推荐的候选集是空的就立刻回退到热门榜保证用户永远能看到东西这是推荐模块稳定性的底线。前端也不会因为拿到一个空数组而渲染报错。4.2 第二层基于标签偏好的内容推荐这一步开始真正发生“个性化”。逻辑可以拆成三步第一步从user_tag_pref表里取出当前用户得分最高的几个标签比如这个人喜欢“川菜”“麻辣”“快手菜”第二步根据这些标签去food_tag关联表里找同时命中的美食第三步按命中标签数量和热度排序返回。核心代码示意如下// 1. 取用户偏好前5个标签 ListUserTagPref prefs userTagPrefMapper.selectList( new LambdaQueryWrapperUserTagPref() .eq(UserTagPref::getUserId, userId) .orderByDesc(UserTagPref::getScore) .last(limit 5) ); if (prefs.isEmpty()) { // 兜底走热门榜 return hotFoodList(); } // 2. 根据标签聚合出候选美食ID ListString tags prefs.stream().map(UserTagPref::getTag).collect(Collectors.toList()); ListLong candidateFoodIds foodTagMapper.selectFoodIdsByTags(tags); // 3. 用候选ID集合查询完整美食信息 ListFoodVO recommendList foodMapper.selectBatchIds(candidateFoodIds);行为数据往user_tag_pref里累加的逻辑也不复杂可以在Service层提供一个统一的方法public void addTagScore(Long userId, String tag, int score) { UserTagPref existing userTagPrefMapper.selectOne( new LambdaQueryWrapperUserTagPref() .eq(UserTagPref::getUserId, userId) .eq(UserTagPref::getTag, tag) ); if (existing null) { UserTagPref pref new UserTagPref(); pref.setUserId(userId); pref.setTag(tag); pref.setScore(score); userTagPrefMapper.insert(pref); } else { existing.setScore(existing.getScore() score); userTagPrefMapper.updateById(existing); } }这个实现很朴素但胜在可以稳定运行。高效精确的推荐可以在后面迭代优化第一版先把链路跑通才是正事。4.3 第三层用户协同过滤UserCF标签推荐的最大问题是没有惊喜性它总推同一类东西。用户协同过滤的思路则是找到和当前用户口味相似的一群人把这些人喜欢但当前用户没看过的菜推荐过来。这在论文里是最好写、也最容易被评委认可的算法模块。关键计算是余弦相似度。我把用户对各类标签的偏好得分看成向量两个用户之间的相似度用向量夹角衡量public double cosineSimilarity(MapString, Double userA, MapString, Double userB) { SetString commonTags new HashSet(userA.keySet()); commonTags.retainAll(userB.keySet()); double dot 0.0; double normA 0.0; double normB 0.0; for (String tag : userA.keySet()) { normA userA.get(tag) * userA.get(tag); } for (String tag : userB.keySet()) { normB userB.get(tag) * userB.get(tag); } for (String tag : commonTags) { dot userA.get(tag) * userB.get(tag); } return normA 0 || normB 0 ? 0.0 : dot / (Math.sqrt(normA) * Math.sqrt(normB)); }算完全部用户两两之间的相似度之后取当前用户最相似的TopN用户把这N个人浏览过、收藏过而当前用户没有的菜取出来按出现次数或热度排个序。实现上有个工程化的小技巧这个用户相似度矩阵不必每次请求都现算。用户标签偏好变化频率并不高可以在用户行为变化后异步更新一次再放到Redis里缓存TTL设半小时到一小时。否则每个用户点击一次首页就全量算一遍相似度数据量大了之后接口会越拖越慢。4.4 行为数据怎么采集推荐算法依赖行为数据但行为采集最忌讳的是在每个Controller里手动写打点代码容易漏而且重复。更好的办法是定义一个注解或者直接在一个服务方法里统一处理。最简单落地的方式是在Controller层调Service的详情方法时在详情方法内部统一调behaviorService.record(userId, foodId, BehaviorType.VIEW)。收藏和评论也是各自在对应Service方法里补一条记录。这样采集逻辑全部收拢在一个服务里后续想接MQ或加日志都不会动业务代码。如果项目里想更优雅一点可以抽一个Spring AOP切面给详情、收藏、评论这三个方法加切面统一处理效果一样但代码侵入性更小。4.5 评测推荐效果先看点击率毕设里推荐算法不需要做到精确离线指标但最好留一个“效果观察”的对比逻辑。最简单的做法是在首页分别记录“热门榜曝光点击率”和“个性化推荐曝光点击率”埋两个计数器观察一段时间后如果个性化推荐的点击率明显高于热门榜说明推荐逻辑有效。答辩的时候能用数据说话比空谈算法强太多。5. 部署文档和论文怎么配合源码才能让项目完整交付5.1 部署文档的完整步骤照着顺序来很多项目的部署文档写得像流水账缺少了关键环境变量。我整理一个简洁可用的顺序照着这个顺序基本不会卡壳安装基础环境JDK8、MySQL 5.7/8.0、Redis如果用到了确认java -version和mysql --version命令可用。初始化数据库用Navicat或命令行执行项目里自带的sql/init.sql注意脚本执行顺序先建库再建表。修改配置打开application.yml把数据库地址、账号、密码改成自己本机的Redis地址也要改。很多项目连不上库九成是这一步没改对。启动后端在项目根目录执行mvn clean package成功后进入target目录执行java -jar 项目名.jar。看到“Tomcat started on port(s): 8080”即启动成功。前端部署如果是Thymeleaf方案直接访问http://localhost:8080就行如果是Vue前后端分离需要先npm install、npm run build再把dist目录放到Nginx里并在Nginx配置里加上对/prod-api或其他前缀的反向代理。功能自测注册两个账号分别浏览不同标签的美食过几分钟再看首页推荐列表是否发生了变化。这套步骤看着不难但实际交付的部署文档里最容易漏掉的是数据库初始化脚本的版本兼容。MySQL 5.7和8.0在排序规则和密码加密方式上有差异如果文档里不写明“在8.0以上版本需要额外执行哪条SQL”别人照着做很容易失败。5.2 论文框架如何和源码模块对应论文一般至少得有这些章节绪论研究背景、意义、现状、系统需求分析功能性需求和非功能性需求配用例图、系统设计总体架构、功能模块划分、数据库设计、系统实现每个功能模块的截图和核心代码说明、系统测试测试环境、功能测试用例、部分性能测试数据。这里特别提醒论文的功能模块名称和源码包目录要保持一致。比如论文第三章写“推荐模块设计”源码里就一定要有一个recommend包论文里写“用户行为采集采用AOP实现”源码里就要确实有切面类。评委一旦翻代码发现对不上印象分会大打折扣。如果源码里某个实现和你论文描述不一致建议以源码为准去改论文而不是反过来。5.3 讲解或者答辩演示的节奏控制配套讲解和答辩演示一般控制在十分钟以内按三个环节走比较稳背景功能演示4分钟简单说一句“民以食为天信息过载需要推荐”然后登录、浏览、搜索、收藏各演示一遍。项目架构讲解2分钟画一张简单的模块图说清楚用了SpringBoot MyBatis-Plus MySQL以及为什么用Redis缓存推荐结果。推荐算法亮点4分钟这是最能拉开差距的部分。介绍你的推荐分了两层第一层基于标签偏好算内容推荐第二层用用户协同过滤结合余弦相似度然后现场切数据证明“两个不同行为的用户看到的首页推荐列表不一样”。演示的时候最怕冷场提前把测试账号和测试数据备好千万不要现场注册新用户来看个性化推荐新用户没有行为数据推荐结果必然是热门兜底这个场面会非常尴尬。6. 调试过程中我踩过的坑从中文乱码到推荐结果为空的兜底6.1 中文乱码统一编码是基本功无论是本地跑还是部署到Linux服务器中文乱码都是高频问题。解决思路是三层统一数据库层面建库建表用utf8mb4连接串里明确写useUnicodetruecharacterEncodingutf8IDEA的Project Encoding、File Encoding全设置成UTF-8。三者缺一个都会在某个环节出乱码尤其是评论功能用户输入的字符一旦超出常见范围白屏加乱码瞬间就来了。6.2 MyBatis-Plus分页插件的新旧写法项目里如果用了MyBatis-Plus分页查询不能只引入依赖不配拦截器代码直接分页无效。新版本是配置PaginationInnerInterceptorBean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }旧教程里常写的PageHelper是另一套分页工具不要混着用。分页突然失效、返回值变成全量数据八成是这个配置没加。6.3 用户ID不能直接信前端收藏、评论这类接口如果从前端请求体里取userId拼SQL风险很大。随便抓个包把ID改掉就能替别人收藏、删评论。正确做法是登录后把用户ID存到Session或JWT里后端统一从令牌里解析请求体里带什么都不认。这一点虽然和推荐算法没有直接关系但答辩追问到安全问题时会成为很不错的加分点。6.4 图片路径404Nginx配置和静态资源映射美食网站绕不开图片。本地用IDEA跑的时候图片可能能显示但打包成jar或者部署到服务器后因为图片上传到本地磁盘目录而SpringBoot默认不会把这个目录映射成静态资源导致localhost:8080/images/xxx.jpg直接404。解决办法是在配置类里加一个资源映射器把/images/**映射到实际上传目录如果用Nginx部署前后端分离项目还要确认Nginx的location配置正确对应了静态文件目录并配置好代理转发。6.5 推荐结果为空永远要有兜底逻辑这是推荐模块最容易出现的逻辑漏洞。新用户没有标签偏好、偏好标签下没有美食、协同过滤找不到相似用户任何一个场景都会让推荐方法的返回值变成空集合。空集合意味着首页出现一片空白用户以为系统坏了。我的做法是在推荐Service的统一出口加一层保护if (recommendList null || recommendList.isEmpty()) { return hotFoodList(); }别小看这一行兜底代码它保证了线上稳定性和演示的体面。测试的时候我会专门用一个刚注册的新账号去刷首页确认看到的是热门榜而不是报错白屏。6.6 热门榜被测试数据刷“废”开发期反复点击详情页会给美食表的浏览量字段积累大量测试数据导致热门榜永远被同一批菜霸占看起来非常不真实。解决办法两种一是上线前把测试产生的行为日志表和热度数据清空重来二是给热门榜增加时间衰减逻辑或者干脆用Redis维护一个短时间窗口内的实时热度。毕设答辩前我强烈建议至少做第一步把演示数据整理得干净一些。最后再分享一个实用的小技巧不管你是拿这套项目做毕业设计还是写简历项目动手前先花二十分钟把application.yml、SQL脚本和推荐模块代码通读一遍再决定从哪里开始改。只有摸清别人的数据流和调用链你才能把“别人的源码”真正变成“自己的项目”答辩和面试时讲起来才不会心虚。