简介：基于SpringBoot的食物营养分析与推荐网站完整源码包，适合Java Web开发学习者、课程设计或毕业设计参考。项目涵盖食物信息查询、营养成分分析、个性化饮食推荐等核心模块，包含用户注册登录、食物检索、营养分析报告与后台数据管理等功能，采用SpringBoot+MySQL技术栈，前端使用Vue和SVG矢量资源构建交互界面，后端Java源码分层清晰，并附带SQL数据库脚本与一键安装/运行批处理脚本，便于本地快速部署。压缩包共649个文件，包含124个Java、99个Vue、63个JavaScript、51张JPG及43张PNG图片，以及XML/JSON配置、SQL数据库脚本和批处理运行脚本，整体约40MB。目前已有49人学习下载。通过该项目，读者可深入理解SpringBoot在实际业务中的整合方式，掌握食物营养数据建模与推荐算法的实现思路，同时学习前端交互与后台管理的完整开发流程，是实践性较强的入门到进阶参考资源。
1. 拿到这份SpringBoot食物营养推荐项目：先从一次课程设计答辩说起
有次帮同事的弟弟看他的毕业设计，题目就是"基于SpringBoot的食物营养分析与推荐网站"。他在台上演示了半小时，被导师一句话问住了："你这个推荐是推荐了个啥？凭什么推荐它？"他答不上来，因为代码是找学长要的，只改了文件名。后来我把这份压缩包从头到尾拆了一遍，发现它其实把SpringBoot、MySQL和推荐逻辑串成了一条完整链路，只是大部分人没看懂核心那几十行推荐代码。
这份资源是一套可直接运行的SpringBoot课程设计项目，技术栈是SpringBoot + Java + MySQL，前端用模板引擎渲染页面，不需要额外启动Node服务。它解决的问题很具体：录入或查询食物后，系统根据营养素数据做评价，再按用户历史饮食记录推荐下一餐食物。适合两类人——需要交课程设计或毕设的学生，以及想快速搭一套"系统类"项目骨架来练手、学模块拆分的新手Java工程师。
2. 项目整体结构与启动路径：SpringBoot + MySQL到底是怎么串起来的
2.1 分层结构与一次完整请求的流转
这套项目用的是最常见的单体分层架构：Controller层接收页面请求，Service层写业务逻辑，Mapper层操作MySQL数据库，页面放在resources/templates下由Thymeleaf渲染。没有额外的前端工程，这一点对课程设计来说非常友好——你不用装Node、不用配跨域，一个SpringBoot应用包到底。
一次完整请求大概是这样的：用户在页面点"查询食物营养"，浏览器把请求发到Controller层的FoodController，Controller调FoodService里的getNutrientById方法，Service通过FoodMapper去MySQL的food表查数据，返回结果后由Thymeleaf渲染成HTML再回给浏览器。这个链路里，代码量最大、也最容易让答辩老师追问的就是Service层——因为推荐算法的计算逻辑都在那里，Controller和Mapper其实都是模板化代码。
2.2 配置文件里的关键参数：spring.datasource与MyBatis映射
拿到资源包后，第一个要改的就是src/main/resources/application.yml。你需要根据自己本机的MySQL配置调整数据源、端口和时区设置。下面是一份我在拆这个项目时整理的最精简可用配置：
server: port: 8080 servlet: encoding: charset: UTF-8 enabled: true force: true spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/food_nutrition?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: yourpassword thymeleaf: cache: false prefix: classpath:/templates/ suffix: .html mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.foodnutrition.entity configuration: map-underscore-to-camel-case: true先说datasource这部分：serverTimezone=Asia/Shanghai这个参数是最容易踩坑的地方，MySQL 8.x版本如果没有指定时区，连接时会直接报The server time zone value '�й���ʱ��' is unrecognized。characterEncoding=utf8用来保证中文写入和读取不出现乱码，后面我还会专门讲乱码问题。再把map-underscore-to-camel-case设为true，数据库字段food_name就能自动映射到实体类的foodName属性，不用在XML里写一堆resultMap。
2.3 从压缩包到跑起来：完整的启动五步
我建议的操作顺序是下面这样的，按这个顺序能少踩一半启动相关的坑。第一步，用Navicat或命令行创建一个名为food_nutrition的数据库，字符集选utf8mb4，然后导入压缩包里提供的SQL脚本；第二步，修改上面的application.yml，把用户名密码改成你自己的，如果端口8080被占了，改成一个没被占用的，比如8081；第三步，用IDEA打开项目，等Maven把依赖拉完，确认spring-boot-starter-parent的版本和你的JDK版本能对上；第四步，找到FoodNutritionApplication.java这个主类，右键直接运行；第五步，浏览器访问http://localhost:8080/，看到首页就说明基础链路通了。
这里有一个值得注意的细节：SpringBoot版本不要选太高。这个项目打包时用的版本在2.5到2.7之间最常见，搭配JDK 8或JDK 11都很稳。如果你默认选了SpringBoot 3.x，很多课程设计里用的旧版依赖会直接冲突，比如javax.servlet改成jakarta.servlet，代码里所有import javax.*都要改。所以我一般会把SpringBoot版本降到2.7.x再跑，省得给自己找事。
3. 数据库设计复盘：五张核心表与营养字段的取舍
3.1 表结构与关键字段说明
拆完SQL脚本后，我发现这个项目的表结构和字段设计值得单独说一说，因为答辩时老师很喜欢问"为什么这么设计"。整个库一共有五张表：用户表user、食物表food、营养素表food_nutrient、饮食记录表diet_record、推荐日志表recommend_log。
food表存的是食物基本信息，字段包括food_id主键、food_name、category、calory（热量，单位千卡每100克）、protein、fat、carbohydrate、fiber、sodium。你注意，这个表直接把主要营养素字段冗余进来了，而不是单独拆成第三张表。原因很朴素：食物查询是最高频操作，如果每查一次都要去关联另一张表，页面加载会慢，而且课程设计的数据量就几千行，拆表带来的规范化收益远小于查询麻烦。营养素的单位统一是"每100克可食部分"，这是一个需要在代码注释里写清楚的事情，否则后面算人一天摄入量时，单位换算会乱。
diet_record表记录的是一次饮食行为，核心字段是record_id、user_id、food_id、quantity（吃的克数）、meal_type（早/午/晚餐）、record_date。推荐系统查用户历史偏好时，主要就是扫这张表去统计他过去吃什么、不吃什么。
3.2 数据库初始化与联表查询写法
压缩包里的food_nutrition.sql已经初始化了用户数据、几十种常见食物的营养素数据，以及少量测试饮食记录。如果没有这些种子数据，你启动项目后会发现推荐结果永远为空。查食物列表时最常见的联表查询是这样的：
SELECT f.food_id, f.food_name, f.category, fn.protein, fn.fat, fn.carbohydrate FROM food f LEFT JOIN food_nutrient fn ON f.food_id = fn.food_id WHERE f.category = #{category} ORDER BY f.food_id DESC LIMIT #{offset}, #{pageSize}这段SQL用LEFT JOIN而不是INNER JOIN，是因为极少数食物可能没有完整的营养素记录，用内连接会把它们全部过滤掉，页面看起来就像"少了几种食物"。LIMIT #{offset}, #{pageSize}配合前端分页组件，查第二页数据时offset就传(pageIndex-1)*pageSize，这个是我在实际项目中用的最常见分页写法。面试时如果被问到MyBatis分页底层原理，你就说这套是内存分页的简化版写法，生产环境建议换PageHelper，一句话把边界讲清楚就够了。
3.3 索引设计的实际建议
课程设计阶段数据量小，索引没什么存在感，但为了让推荐查询能走索引，我建议在diet_record表的user_id和record_date上建一个联合索引，推荐服务每次都要按用户和时间范围拉历史记录，这个索引能明显降低扫描成本。在建表SQL末尾加上这两条就算补全了：
ALTER TABLE diet_record ADD INDEX idx_user_date (user_id, record_date); ALTER TABLE food ADD INDEX idx_category (category);第一条索引的作用是让"查某个用户在某个时间段内的所有饮食记录"这条高频SQL避免全表扫描；第二条是为了支撑按分类浏览食物的菜单页。别小看这两条，推荐算法后面要用的数据，恰好都落在这两个查询路径上。
4. 营养分析与推荐逻辑：从DRIs基准到TopN推荐的实现
4.1 营养素评估：先算缺口，再谈推荐
整个项目里最有含金量的一段代码，是营养分析模块。它做的事情是：把用户在一天内所有饮食记录汇总，算出蛋白质、脂肪、碳水、热量、钠的实际摄入量，再和参考值做对比。参考值用的是中国居民膳食营养素参考摄入量（DRIs），这份数据在这个项目里以常量类的方式存在，不是数据库表——因为它是标准值，基本不会变。
public class NutritionEvaluator { // DRIs参考值（成人），单位与食物表一致 private static final double DRIs_CALORY = 2140.0; // 千卡 private static final double DRIs_PROTEIN = 70.0; // 克 private static final double DRIs_FAT = 60.0; // 克 private static final double DRIs_CARBOHYDRATE = 300.0; // 克 private static final double DRIs_SODIUM = 2200.0; // 毫克 public static Map<String, Double> evaluate(DietSummary summary) { Map<String, Double> result = new HashMap<>(); result.put("caloryRatio", round(summary.getCalory() / DRIs_CALORY)); result.put("proteinRatio", round(summary.getProtein() / DRIs_PROTEIN)); result.put("fatRatio", round(summary.getFat() / DRIs_FAT)); result.put("carbRatio", round(summary.getCarbohydrate() / DRIs_CARBOHYDRATE)); result.put("sodiumRatio", round(summary.getSodium() / DRIs_SODIUM)); return result; } private static double round(double value) { return BigDecimal.valueOf(value).setScale(2, RoundingMode.HALF_UP).doubleValue(); } }这段代码的核心逻辑是把实摄入量和标准值做比值，比值大于1说明超标，小于1说明有缺口。推荐系统的输入，其实就是这个Map里五个比值——别再费劲去想协同过滤了，这个项目走的路线是"缺口匹配推荐"，解释起来直观，答辩也容易讲清楚。
4.2 推荐评分模型：缺口越大，权重越高
推荐模块是整个项目里最容易被误读的地方。它表面上是"随机给几个食物"，实际上内部有一个评分公式。我拆源码时把它还原成了下面的逻辑：候选食物对某个营养素的贡献度，乘以对应缺口权重，再减去重复惩罚系数，按综合得分排序取前N个。
public List<Food> recommendForUser(int userId, int topN) { Map<String, Double> gap = nutritionGapService.getCurrentGap(userId); List<Food> allFoods = foodMapper.selectAll(); List<Food> recentFoods = dietRecordMapper.selectRecentFoodIds(userId, 7); return allFoods.stream() .filter(food -> !recentFoods.contains(food.getFoodId())) .sorted((f1, f2) -> Double.compare(score(f2, gap), score(f1, gap))) .limit(topN) .collect(Collectors.toList()); } private double score(Food food, Map<String, Double> gap) { double score = 0.0; score += gap.getOrDefault("proteinRatio", 0.0) * food.getProtein() / DRIs_PROTEIN; score += gap.getOrDefault("fatRatio", 0.0) * food.getFat() / DRIs_FAT; score += gap.getOrDefault("carbRatio", 0.0) * food.getCarbohydrate() / DRIs_CARBOHYDRATE; score += gap.getOrDefault("sodiumRatio", 0.0) * (1.0 - food.getSodium() / DRIs_SODIUM); return score; }这个公式的含义是：如果用户当前蛋白质缺口大，那么蛋白质密度高的食物得分就高；如果钠摄入已经超标，那么低钠食物会得到加分。recentFoods过滤逻辑相当于是个"连续7天不重样"的规则，避免用户连着三天被推荐同样的早饭。现在你能理解了，为什么答辩老师会追问"你这个推荐有没有科学依据"——因为缺口匹配理论本身就是营养学里的常规思路。
4.3 推荐结果的落库与展示
推荐结果在页面上展示后，会被写入recommend_log表。这张表字段不多：log_id、user_id、food_id、reason、create_time。其中reason字段保存的是推荐理由，比如"蛋白质摄入不足，建议补充蛋白质含量高的食物"。这个字段别小看，答辩演示时，页面上能看到"为什么推荐这个食物"，比干巴巴列个食物清单有说服力得多。回写日志的操作放在Service的事务方法里，推荐计算和日志插入用同一个@Transactional注解包裹，防止写入一半失败产生脏数据。
5. 常见问题排查：从启动失败到推荐结果异常
5.1 启动时报错：java.sql.SQLException: The server time zone value '�й���ʱ��'
- 现象：启动项目时控制台直接提示无法建立数据库连接，错误信息里出现乱码时区字符。
- 原因：MySQL 8.x的时区默认值是
SYSTEM，而系统时区是Asia/Shanghai，JDBC驱动解析不了这个中文时区标识。 - 解决：在application.yml的JDBC URL末尾加上
&serverTimezone=Asia/Shanghai，如果还不行，执行一条SQLSET GLOBAL time_zone = '+8:00'，两边同时设置最保险。
5.2 数据库表里的中文全部变成问号或乱码
- 现象：用命令行导入SQL后，Food表里的"米饭"显示成"??"，页面查出来也是乱码。
- 原因：建库时没有指定字符集，MySQL默认用了
latin1，中文根本存不进去。 - 解决：把SQL脚本里的
CREATE TABLE语句都加上DEFAULT CHARSET=utf8mb4，或者直接在Navicat里把数据库字符集改成utf8mb4后再重新导入。
5.3 IDEA启动后页面空白，报错提示Template might not exist or might not be accessible
- 现象：后端日志显示404，提示
/templates/index.html不存在，但文件明明在resources/templates下。 - 原因：Thymeleaf默认会去
classpath:/templates/找模板，但有些同学不小心把页面文件放到了src/main/resources/static/templates/里，路径错了一层。 - 解决：确认所有HTML文件都放在
src/main/resources/templates/目录下，同时把静态资源（CSS、JS、图片）放在static目录下，两个目录职责不同，别混放。
5.4 页面能打开，但"查询食物营养"点击后无反应
- 现象：界面正常，一提交表单就报500，控制台有
Invalid bound statement (not found)。 - 原因：MyBatis的Mapper XML文件没有被扫描到。
mapper-locations配置的是classpath:mapper/*.xml，但你的XML文件可能放在了其他地方。 - 解决：检查
src/main/resources/mapper/目录下是否有对应的XML文件，并在启动类上确认有没有加@MapperScan("com.example.foodnutrition.mapper")注解，这两个条件缺一不可。
5.5 推荐结果永远是前几个固定食物，从不变化
- 现象：不管用户有没有历史记录，推荐列表都是同样的N条数据。
- 原因：问题几乎都出在
nutritionGapService.getCurrentGap拿不到用户数据，返回的全是0。缺口全为0时，评分公式退化成按食物固有营养素含量排序，结果自然固定。 - 解决：先去数据库里手动执行
SELECT * FROM diet_record WHERE user_id = 1，确认有没有数据。没有的话，插入几条测试记录，比如连续三天的早餐中餐晚餐记录，让缺口计算有实际输入。
5.6 修改端口后页面能开，但接口全部404
- 现象：端口改了之后，首页倒是出来了，但所有接口请求返回404，页面上的按钮全部失效。
- 原因：页面代码里的AJAX请求或链接写死了
localhost:8080的绝对路径，你改了端口，浏览器还是往旧端口发请求。 - 解决：全局搜索HTML里的
8080和localhost，把它们全部替换成Thymeleaf的路径表达式th:href="@{/food/list}"，这样端口就跟随项目配置自动变化。
6. 把课程设计升级成能稳定演示的项目：测试数据、Actuator与打包部署
6.1 用SQL脚本批量生成多天饮食记录
演示时最尴尬的情况是"推荐页面只有两条数据"——没有历史饮食记录，推荐逻辑就没有输入。与其手点着录入，不如直接执行一段生成脚本，自动在一个月时间范围内批量生成三餐记录：
INSERT INTO diet_record (user_id, food_id, quantity, meal_type, record_date) SELECT FLOOR(1 + RAND() * 2), -- 随机在1号和2号用户之间 FLOOR(1 + RAND() * 25), -- 随机在1到25号食物之间 150 + FLOOR(RAND() * 100), -- 摄入量150到250克 ELT(1 + FLOOR(RAND() * 3), '早餐', '午餐', '晚餐'), DATE_SUB(CURDATE(), INTERVAL seq.day INTERVAL DAY) FROM ( SELECT @row := @row + 1 AS day FROM food, (SELECT @row := 0) r LIMIT 30 ) seq;执行完这段后，两个用户各多出三十天的饮食数据，推荐页面立刻变得"有内容可看"。ELT函数在三餐类型里随机取值，DATE_SUB用来生成连续的过去日期，这比一条条INSERT高效得多。演示时翻一下推荐列表，再对比下营养分析页面的缺口曲线，效果比空列表好得多。
6.2 加一个Actuator端点，答辩时直接展示系统健康
课程设计如果只靠业务页面撑场，容易被追问"你怎么保证系统稳定"。加一个Spring Boot Actuator，立刻能展示健康检查指标。先在pom.xml加依赖，然后在application.yml里暴露端点：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>management: endpoints: web: exposure: include: health,metrics,info启动后访问http://localhost:8080/actuator/health，返回{"status":"UP"}就是正常。actuator/metrics还能看到JVM内存、线程数、接口调用次数。答辩时演示一下这个页面，远比嘴上说"系统正常"专业。
6.3 打包成jar，关掉IDE也能跑
最后一步是打包部署。用Maven打成可执行jar，需要在pom.xml里加上spring-boot-maven-plugin插件，然后执行mvn clean package -DskipTests。打包完成后在target/目录下会生成一个可执行jar，用java -jar food-nutrition.jar就能直接启动，不需要再开IDEA。
这里我习惯的做法是：打包前把application.yml里的密码改成一个环境变量占位符，password: ${DB_PASSWORD:root}，这样jar发给别人时不会把你的数据库密码带出去，对方本地配置对应的环境变量就能跑。从那以后我每次帮人拆课程设计，都会强制先检查一遍这三个地方——数据库连接属性、模板目录路径、时间时区设置，这三处是最容易耗费大量时间翻找的坑。希望这份项目的拆解思路能帮你节省一些时间，也让你在答辩时对每一处代码的实现逻辑更有把握。
本文还有配套的精品资源，点击获取
