企业官网建设流程全解析

简介：面向Java课程设计与毕业答辩的智能健康饮食系统，基于SpringBoot实现后端服务，覆盖用户管理、健康档案、饮食记录、营养建议等典型业务，可参考其分层架构与核心功能设计。压缩包共352个文件，大小约11.75MB；其中88个Java文件承载业务逻辑，74个Vue组件和40个JS文件对应前端界面与交互，46张PNG和33张JPG为图标/图片资源，另有SQL、YML、TXT、MD等数据库脚本、配置与开发说明；目录内含server_code、client_code、manage_code，前后端与管理后台层次分明。目前该资源已有245人学习，适合需要在SpringBoot全栈开发中找完整案例的开发者。通过导入SQL可快速初始化数据表，后端代码模块化程度较高，配合附带的常见问题说明和项目结构文档，能有效减少环境配置与联调排错的时间。可直接用于课程设计或毕业设计的基础版本，也便于在此基础上做二次功能扩展。

1. 智能健康饮食系统不是CRUD，而是一套决策引擎

大多数毕设和练手项目都把“健康饮食系统”做成食谱增删改查加一个食物分类，用户点进去看图片和热量数字，仅此而已。这本质上还是个信息展示系统，跟“智能”没有关系。真正值得做的智能健康饮食系统，核心差异在于它能不能根据用户的身体指标、饮食记录和目标自动算出建议——吃多少、怎么搭配、下一餐缺口在哪。SpringBoot在这里的价值不只是快速搭接口，而是把推荐逻辑、指标计算、数据持久化组织成一条可维护的服务链路。

本篇文章从系统设计角度拆解一个基于SpringBoot的智能健康饮食系统怎么从零落地。内容覆盖数据库建模、SpringBoot核心模块划分、推荐算法与业务规则的结合方式、以及上线前必须处理的异常场景。适合正在做Java毕设、准备SpringBoot面试项目复盘、或者想把自己的CRUD项目升级成有业务深度的工程师阅读。文中的所有代码和SQL都可以直接抄，但更重要的是理解每一层为什么这么设计。

2. 核心领域模型与SpringBoot工程结构设计

2.1 领域模型不是表结构，先划分业务边界

智能健康饮食系统的核心用户旅程是：用户注册 → 填写身体数据（身高、体重、年龄、性别、活动水平）→ 系统计算每日热量和营养目标 → 用户记录一日三餐 → 系统对比实际摄入与目标差距 → 给出调整建议。这个流程决定了系统至少需要这些核心实体：

首先是用餐记录。传统食谱系统以菜品为中心，但智能推荐必须以“吃进去什么”为中心，所以必须有一张独立的饮食记录表，记录用户在某一天某一餐吃了什么食物、份量多少。这才能算得出数据。

其次是食材营养表。中餐不像西餐那样每个菜品都有标准营养标签，所以需要内置一个常见食材的每100克营养数据库，包括热量、蛋白质、脂肪、碳水、钠等字段。菜品与食材之间有多对多关系，菜品营养值由食材分量折算。这样用户记录食物时可以按“份量克数”录入，远比选一道模糊的菜要精确。

第三是健康档案表。用户身高体重、性别、出生日期、活动系数、目标类型（减脂/维持/增肌）都存放在这里。推荐引擎每次计算都以最新档案为准。

2.2 代码分层与SpringBoot工程骨架

工程层面按常见的四层结构划分：Controller接收请求、Service处理业务、Mapper访问数据库、Domain存放实体与值对象。在此基础上额外增加一个recommend包专门放推荐算法相关的类，避免业务代码与算法逻辑混在一起难维护。

// 工程核心包结构 com.health.diet ├── controller // REST接口层 │ ├── UserController.java │ ├── DietRecordController.java │ └── RecommendController.java ├── service // 业务逻辑层 │ ├── UserProfileService.java │ ├── DietRecordService.java │ └── NutritionTargetService.java ├── mapper // MyBatis-Plus数据访问层 │ ├── FoodMapper.java │ ├── DietRecordMapper.java │ └── UserProfileMapper.java ├── domain // 实体与值对象 │ ├── Food.java │ ├── DietRecord.java │ └── NutritionTarget.java └── recommend // 推荐算法与营养计算 ├── CalorieCalculator.java ├── MacroDistributor.java └── RecommendService.java

依赖层面核心只有三个SpringBoot Starter，不会引入多余的东西。Web处理请求，MyBatis-Plus处理数据访问，Validation做参数校验。如果本地测试需要看接口文档，可以再引入springdoc-openapi，但这不是必须的。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.7</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency>

MyBatis-Plus不是必须的选择，但用在这里有两个实际原因。第一是单表CRUD不需要写SQL，BaseMapper直接提供selectById、insert、updateById这些基础方法，能把精力省给推荐逻辑。第二是在做营养分析这类聚合查询时，仍然可以用@Select注解写原生SQL，不冲突。

2.3 表结构设计：饮食记录才是全系统的数据底座

数据库设计采用MySQL 8.x，字符集utf8mb4，排序规则utf8mb4_unicode_ci。核心表一共四张：用户档案表、食材营养表、菜品食材关联表、饮食记录表。以下是核心表的建表SQL与设计说明。

-- 用户健康档案表 CREATE TABLE user_profile ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', user_id BIGINT NOT NULL COMMENT '关联用户ID', gender TINYINT NOT NULL COMMENT '性别: 1男 2女', birth_date DATE NOT NULL COMMENT '出生日期', height_cm DECIMAL(5,1) NOT NULL COMMENT '身高cm', weight_kg DECIMAL(5,1) NOT NULL COMMENT '体重kg', activity_level TINYINT NOT NULL COMMENT '活动系数: 1久坐 2轻活动 3中活动 4高活动', goal_type TINYINT NOT NULL COMMENT '目标: 1减脂 2维持 3增肌', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_user_id (user_id) ) ENGINE=InnoDB COMMENT='用户健康档案';

-- 食材营养表（每100克含量） CREATE TABLE food ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT '食材名称', calories DECIMAL(6,1) NOT NULL COMMENT '热量kcal', protein DECIMAL(6,1) NOT NULL COMMENT '蛋白质g', fat DECIMAL(6,1) NOT NULL COMMENT '脂肪g', carbs DECIMAL(6,1) NOT NULL COMMENT '碳水化合物g', sodium DECIMAL(6,1) DEFAULT 0 COMMENT '钠mg', unit VARCHAR(20) DEFAULT '克' COMMENT '默认计量单位', is_common TINYINT DEFAULT 0 COMMENT '是否常见食材', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_name (name) ) ENGINE=InnoDB COMMENT='食材营养表';

food表字段顺序有讲究：is_common放在最后而不是跟在name后面，因为后续推荐算法会高频查询“常见食材”作为默认推荐池，这个字段后续建议加索引。但索引并不适合在这个阶段就全部建好，等数据量到了万级再根据慢查询日志调优即可。

饮食记录表是整个推荐系统最核心的数据来源，设计上需要同时支持两种查询模式：按用户某天的汇总以及按餐次明细。

CREATE TABLE diet_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT '用户ID', record_date DATE NOT NULL COMMENT '记录日期', meal_type TINYINT NOT NULL COMMENT '餐次: 1早餐 2午餐 3晚餐 4加餐', food_id BIGINT NOT NULL COMMENT '食物ID', food_name VARCHAR(100) NOT NULL COMMENT '冗余食物名称', amount_grams DECIMAL(6,1) NOT NULL COMMENT '实际摄入克数', calories DECIMAL(6,1) NOT NULL COMMENT '实际热量', protein DECIMAL(6,1) NOT NULL, fat DECIMAL(6,1) NOT NULL, carbs DECIMAL(6,1) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_date_meal (user_id, record_date, meal_type) ) ENGINE=InnoDB COMMENT='饮食记录表';

food_name做了冗余设计，目的是查历史记录时不回表查food表。这个字段在业务上意味着菜品改名或者食材删除时，历史记录不受影响。如果做严格的三范式设计，这个字段没必要存在，但实际查询效率和简化逻辑会明显受益。

3. 营养计算核心逻辑与推荐算法设计

3.1 从BMR到TDEE，热量目标的计算公式选择

热量计算是推荐系统的基础数值。常见做法是先算BMR（基础代谢率），再乘活动系数得到TDEE（每日总消耗），最后根据目标类型做增减。BMR计算采用Mifflin-St Jeor公式，比Harris-Benedict更贴近现代人群实测数据：

• 男性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 + 5
• 女性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 - 161

这个公式在计算逻辑里用策略模式实现，性别作为策略选择的依据。下面是Java实现代码：

public class CalorieCalculator { public double calculateBMR(UserProfile profile) { double base = 10 * profile.getWeightKg() + 6.25 * profile.getHeightCm() - 5 * calculateAge(profile.getBirthDate()); return profile.getGender() == 1 ? base + 5 : base - 161; } public double calculateTDEE(UserProfile profile) { double bmr = calculateBMR(profile); // 活动系数: 1.2 久坐, 1.375 轻活动, 1.55 中活动, 1.725 高活动 double[] activityFactors = {1.2, 1.375, 1.55, 1.725}; return bmr * activityFactors[profile.getActivityLevel() - 1]; } public NutritionTarget calculateTarget(UserProfile profile) { double tdee = calculateTDEE(profile); // 减脂缺10%~20%，增肌盈余10%~15%，维持持平 double targetCalories = switch (profile.getGoalType()) { case 1 -> tdee * 0.85; case 3 -> tdee * 1.10; default -> tdee; }; // 蛋白质: 减脂期按体重2.0g/kg，其他按1.6g/kg double proteinRatio = profile.getGoalType() == 1 ? 2.0 : 1.6; double protein = profile.getWeightKg() * proteinRatio; // 脂肪供能占比25%，其余由碳水补齐 double fat = targetCalories * 0.25 / 9; double carbs = (targetCalories - protein * 4 - fat * 9) / 4; return new NutritionTarget( Math.round(targetCalories), Math.round(protein), Math.round(fat), Math.round(carbs) ); } private int calculateAge(LocalDate birthDate) { return Period.between(birthDate, LocalDate.now()).getYears(); } }

calculateTarget方法中有几个关键参数值得展开说明。蛋白质系数 2.0g/kg 只用于减脂期，因为热量缺口下如果没有足够蛋白质，肌肉流失风险会明显增加，这个数值是根据运动营养学实体中的常见范围上限来取的。脂肪按 25% 供能比计算，这是一个中等取值，没有采用生酮饮食模式那种极端比例。碳水作为剩余热量填充项，用(targetCalories - protein*4 - fat*9) / 4计算，因为每克蛋白质和碳水供能4千卡，每克脂肪供能9千卡，这是营养学的基本换算关系。

3.2 推荐算法：基于记录补齐的预判式策略

推荐逻辑不追求复杂的协同过滤或深度学习模型，这是有实际考虑的。第一，毕设或中小型项目拿不到足够的用户行为数据来支撑协同过滤；第二，饮食推荐的核心是“缺什么补什么”，是一个典型的约束满足问题，规则引擎完全可以处理。所以推荐策略采用两层结构：基础推荐池 + 营养缺口补偿。

public List<Food> recommendFoods(Long userId, Integer mealType, int limit) { // 1. 获取用户最近7天所有饮食记录 List<DietRecord> recentRecords = dietRecordMapper.selectRecentByUser(userId, LocalDate.now().minusDays(7)); // 2. 计算7天平均摄入 NutritionSummary avg = aggregate(recentRecords); // 3. 获取用户每日营养目标 NutritionTarget target = getTarget(userId); // 4. 判断缺口比例最大的营养素 NutritionDeficit deficit = findBiggestDeficit(avg, target); // 5. 在对应营养素含量高的食材池中做多样性筛选 List<Food> candidates = foodMapper.selectByNutrientHigh( deficit.getType(), mealType, LIMIT ); // 6. 过滤掉最近3天吃过的食材，保证多样 return candidates.stream() .filter(food -> !recentlyEaten.contains(food.getId())) .limit(limit) .toList(); }

第4步的findBiggestDeficit是这个方法的核心，需要先明确什么才算是真正的“缺口”。直接用“目标 - 实际摄入”的绝对值做比较是有问题的：目标蛋白质是100克，实际吃了80克，缺口20克；目标碳水是250克，实际吃了230克，缺口也是20克。绝对值相同，但20克蛋白质的缺口明显比20克碳水的缺口影响更大。所以这里需要按营养素类型加权，蛋白质权重1.0、脂肪权重0.7、碳水权重0.6，权重越高越优先补齐。

推荐结果返回后，还需要做一道热量校验，防止推荐的食物让用户某餐摄入量超出目标太多。常见做法是限制单餐推荐总热量不超过当日目标的45%，早餐晚餐按30%计算、午餐按40%计算。

4. SpringBoot接口实现与数据统计SQL

4.1 餐饮记录接口：建好参数校验的护城河

控制层在SpringBoot中承担的是协议适配职责，不应该承载任何计算逻辑。接口参数直接用DTO接收并加上@Valid注解做参数校验，减少 Service 层对参数有效性的重复判断。

@RestController @RequestMapping("/api/diet") public class DietRecordController { @PostMapping("/record") public Result<Void> addRecord(@Valid @RequestBody DietRecordDTO dto) { Long userId = SecurityUtils.getCurrentUserId(); dietRecordService.addRecord(userId, dto); return Result.success(); } @GetMapping("/summary") public Result<DailySummaryVO> getDailySummary( @RequestParam String date) { Long userId = SecurityUtils.getCurrentUserId(); return Result.success(dietRecordService.getDailySummary(userId, LocalDate.parse(date))); } }

DietRecordDTO中要校验的字段包括食物ID不能为空、摄入克数必须在1到2000之间、餐次类型必须属于枚举范围。SpringBoot的@Valid注解配合@NotNull、@Min、@Max可以声明式完成校验，但需要注意一点：当校验失败时SpringBoot默认返回400状态码，响应体格式是DefaultHandlerExceptionResolver处理的错误结构。生产建议是用@RestControllerAdvice做全局异常捕获，统一包装成业务错误码。

存储实现中有一个关键细节：前端传入的是食物ID和份量克数，但diet_record表要求冗余存储热量、蛋白质、脂肪、碳水化合物数值。这个计算必须在Service层完成，通过食物ID查出食材营养数据后按比例换算。不要在Controller层做，也不要在前端做，因为前端算的数值是不可信的。

@Service public class DietRecordServiceImpl implements DietRecordService { @Override @Transactional public void addRecord(Long userId, DietRecordDTO dto) { Food food = foodMapper.selectById(dto.getFoodId()); if (food == null) { throw new BusinessException(ErrorCode.FOOD_NOT_FOUND); } // 按实际摄入克数与每100克营养值折算 BigDecimal ratio = dto.getAmountGrams().divide(BigDecimal.valueOf(100), 4, RoundingMode.HALF_UP); DietRecord record = new DietRecord(); record.setUserId(userId); record.setRecordDate(dto.getRecordDate()); record.setMealType(dto.getMealType()); record.setFoodId(food.getId()); record.setFoodName(food.getName()); record.setAmountGrams(dto.getAmountGrams()); record.setCalories(food.getCalories().multiply(ratio).setScale(1, RoundingMode.HALF_UP)); record.setProtein(food.getProtein().multiply(ratio).setScale(1, RoundingMode.HALF_UP)); record.setFat(food.getFat().multiply(ratio).setScale(1, RoundingMode.HALF_UP)); record.setCarbs(food.getCarbs().multiply(ratio).setScale(1, RoundingMode.HALF_UP)); dietRecordMapper.insert(record); } }

这段代码要注意divide方法的精度问题。BigDecimal 做除法时必须指定精度和舍入模式，否则遇到除不尽的小数会抛ArithmeticException。比例计算保留4位小数是为了让后续乘法结果有足够的精度，最后设置热量字段时再四舍五入到1位小数，避免用户看到一长串小数位的热量数字。

@Transactional注解在这里不是必要的，因为只插入一张表。保留它是因为后续如果扩展“记录食物同时更新用户积分”之类的功能，事务边界已经画好。但要注意一点：@Transactional默认只回滚RuntimeException，如果Service方法抛的是受检异常，需要显式设置rollbackFor。

4.2 营养分析SQL：一天吃了什么，一查就知道

按天汇总营养摄入是系统页面展示的基础。这里用MyBatis-Plus的@Select注解写原生SQL，不做ORM封装，因为聚合查询涉及多个字段的SUM操作，用QueryWrapper也可以写但可读性远不如SQL直观。

@Mapper public interface DietRecordMapper extends BaseMapper<DietRecord> { @Select(""" SELECT COALESCE(SUM(calories), 0) AS total_calories, COALESCE(SUM(protein), 0) AS total_protein, COALESCE(SUM(fat), 0) AS total_fat, COALESCE(SUM(carbs), 0) AS total_carbs, COUNT(DISTINCT food_id) AS food_variety FROM diet_record WHERE user_id = #{userId} AND record_date = #{date} """) NutritionSummary selectDailySummary(@Param("userId") Long userId, @Param("date") LocalDate date); }

SQL中使用COALESCE(SUM(...), 0)的意图是：某天用户没有记录任何饮食时，SUM返回NULL，Java Bean 的数值字段接收NULL后可能导致拆箱空指针。用COALESCE把空结果统一为0，这一层防御逻辑放在SQL里比放在Service层更直接。但如果是查询多天数据做趋势图，推荐按周分组统计，这个时候SQL的GROUP BY会和日期函数一起出现：

SELECT DATE_FORMAT(record_date, '%Y-%m-%d') AS day, SUM(calories) AS total_calories, AVG(protein) AS avg_protein FROM diet_record WHERE user_id = #{userId} AND record_date BETWEEN #{startDate} AND #{endDate} GROUP BY DATE_FORMAT(record_date, '%Y-%m-%d') ORDER BY day DESC

这条SQL有两个易错点。第一，GROUP BY的字段必须与SELECT中非聚合字段保持一致，MySQL 在ONLY_FULL_GROUP_BY模式下如果SELECT了未分组的列会直接报错。第二，BETWEEN是闭区间，如果传的结束日期是当天，那么record_date是当天的记录也会被包含进来，需要前端把时间范围校准到自然日而不是时间戳。

4.3 个人健康管理页面的聚合接口

个人健康管理页面需要展示用户的BMI、体脂估算、基础代谢率以及每日摄入达标率。这些数据分布在多张表中，一次接口要返回复合的视图对象，不能用多次查询在Controller里拼接。正确姿势是Service内部聚合后封装为VO返回。

public HealthDashboardVO getDashboard(Long userId) { UserProfile profile = userProfileMapper.selectByUserId(userId); if (profile == null) { throw new BusinessException(ErrorCode.PROFILE_NOT_FOUND); } double heightM = profile.getHeightCm() / 100.0; double bmi = profile.getWeightKg() / (heightM * heightM); NutritionTarget target = calorieCalculator.calculateTarget(profile); NutritionSummary today = dietRecordMapper.selectDailySummary(userId, LocalDate.now()); HealthDashboardVO vo = new HealthDashboardVO(); vo.setBmi(Math.round(bmi * 10) / 10.0); vo.setTargetCalories(target.getCalories()); vo.setTodayCalories(today.getTotalCalories()); // 完成率低于0.8或高于1.2时给出提示，正常区间不打扰 double completionRate = today.getTotalCalories() / target.getCalories(); if (completionRate < 0.8) { vo.setTip("今日热量摄入低于目标，建议补充优质蛋白质或复合碳水"); } else if (completionRate > 1.2) { vo.setTip("今日热量显著超标，建议下一餐增加蔬菜比例"); } else { vo.setTip("今日营养摄入在合理范围，继续保持"); } return vo; }

BMI保留一位小数是通过Math.round(bmi * 10) / 10.0实现的，这比String.format("%.1f", bmi)返回String再转换更干净。完成率判断的阈值 0.8 和 1.2 是经验值，减脂用户偏差容忍度更小，可以在后续版本做成动态配置项，用@ConfigurationProperties注入业务参数。

5. 定时任务与数据初始化的SpringBoot实践

5.1 每天8点的营养日报：定时任务一跑就出

系统需要每天早上生成前一天的营养完成度报告。实现方式选@Scheduled注解而不是引入Quartz，理由是任务逻辑简单、无分布式需求、依赖最少。

@Component public class DailyReportTask { private final DietRecordMapper dietRecordMapper; @Scheduled(cron = "0 0 8 * * ?") public void generateYesterdayReport() { LocalDate yesterday = LocalDate.now().minusDays(1); List<UserProfile> allUsers = userProfileMapper.selectList(null); for (UserProfile profile : allUsers) { NutritionSummary summary = dietRecordMapper.selectDailySummary(profile.getUserId(), yesterday); NutritionTarget target = calorieCalculator.calculateTarget(profile); // 只对热量/蛋白质任一缺口超过20%的用户发送提醒 if (isSignificantDeficit(summary, target)) { reportSender.send(profile.getUserId(), buildReport(summary, target, yesterday)); } } } }

@Scheduled开启需要在启动类上加@EnableScheduling注解，这是刚用SpringBoot做定时任务最容易漏掉的一步。任务类本身加上@Component交给容器管理，才能让@Scheduled生效。这里默认单线程执行，如果任务逻辑耗时较长会阻塞后续任务。

5.2 SpringBoot启动时预置营养数据

CommandLineRunner在SpringBoot应用启动完成后会被自动调用，常见做法是借助它检查并预置基础数据。这个机制很适合给食物营养表做数据初始化：每次系统启动时判断表是否为空，为空就插入初始化数据，不为空则跳过。

@Component public class FoodDataInitializer implements CommandLineRunner { private final FoodMapper foodMapper; @Override public void run(String... args) { Long count = foodMapper.selectCount(null); if (count > 0) { return; } List<Food> initialFoods = FoodDataSeedProvider.getBasicFoods(); for (Food food : initialFoods) { foodMapper.insert(food); } log.info("已初始化 {} 条食材营养数据", initialFoods.size()); } }

SpringBoot的CommandLineRunner是在容器启动完成之后、应用对外接收请求之前执行的，这保证接口被调用时初始数据一定就位。这里的执行时机和@PostConstruct有细微差别：@PostConstruct是在Bean初始化阶段执行，如果它依赖的Mapper还没准备好就会报错。CommandLineRunner的执行时机是在整个ApplicationContext刷新完成之后，依赖全部可用，更适合做数据初始化。

6. 上线前必查的5个SpringBoot配置坑

6.1 YML配置文件的密码密文处理

在application.yml里直接写MySQL密码，意味着任何人拿到代码就能连上数据库。SpringBoot项目更安全的做法是使用Jasypt对密码加密后再写入配置。配置方式：在启动参数中加入-Djasypt.encryptor.password=加密密钥，而yml文件中的密码配置使用加密后的密文。

spring: datasource: url: jdbc:mysql://localhost:3306/health_diet?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: ENC(加密后的密文字符串)

Jasypt集成到SpringBoot只需要两个步骤：引入依赖，然后在配置类上加一行注解。解密器会在数据源初始化之前完成配置属性的解密，不会影响连接池的启动速度。注意jasypt.encryptor.password不要写在yml里，写在启动脚本的环境变量中。

6.2 MyBatis-Plus表不存在时的自动建表策略

热词里有一条提到“springboot+mybatis当表不存在自动建表”，这个需求在项目中确实存在。如果是开发阶段，简单做法是把建表SQL放在schema.sql，然后在application.yml中配置：

spring: sql: init: mode: always schema-locations: classpath:schema.sql

但把schema.sql放进resources后，每次启动都会执行一次，里面必须写上建表语句的幂等写法，核心是加IF NOT EXISTS，但MySQL的CREATE TABLE IF NOT EXISTS只能保证不报错，不会更新已有表结构。

更推荐的方式是把数据库初始化交给Flyway管理，建表SQL写在V1__create_tables.sql中，Flyway通过flyway_schema_history表记录执行版本。这样不仅解决了重复执行问题，后续任何表结构变更都有版本记录可追溯。

6.3 SpringBoot版本过高导致的依赖不兼容

SpringBoot 3.x要求Java 17及以上，如果本机是Java 8环境，引入SpringBoot 3.x会在启动时报UnsupportedClassVersionError。另一个高频坑是SpringBoot 3.x的javax包全部迁移到了jakarta命名空间，旧代码中javax.annotation.Resource、javax.validation.*需要同步改掉。

还有一点容易被忽略的是MyBatis-Plus版本兼容性问题：MyBatis-Plus 3.5.x 在SpringBoot 2.x下运行正常，搭配SpringBoot 3.x时需要确认使用了适配spring-boot-starter的版本（3.5.3以上才支持，且包名不同）。如果老项目升级SpringBoot，先查依赖树再动手。

6.4 用JVM参数区分多环境配置

项目至少有开发、测试、生产三套环境，每套环境的数据库地址和密码不能相同。SpringBoot原生支持多环境配置文件的拆分方式为application-dev.yml、application-test.yml、application-prod.yml三种文件，启动时通过--spring.profiles.active=prod激活对应环境。

生产环境建议在启动脚本中显式指定Profile，而不是依赖IDE的默认配置。可以在启动命令中组合使用环境变量和参数占位符：

java -jar health-diet.jar \ --spring.profiles.active=prod \ --spring.datasource.password=${DB_PASSWORD}

命令行参数优先级高于application.yml中的配置，${DB_PASSWORD}会从系统环境变量中取值，避免密码进入JVM进程参数被ps命令看到。密钥不要写在启动脚本里，放在CI/CD的Secret管理或配置中心更安全。

6.5 更健康的数据同步：用定时器做记录聚合校验

营养成分计算是在写入时完成的，但食材表如果后期调整了营养值，历史记录中冗余存储的热量数据不会自动更新。要保证数据和最新食材表一致，需要运行一个定时补偿任务比较历史记录中的food_name与最新food表数据是否一致。

# 查询最近30天记录中，营养值与当前食材表不一致的数据量 SELECT COUNT(*) FROM diet_record dr JOIN food f ON dr.food_id = f.id WHERE DATEDIFF(CURDATE(), dr.record_date) <= 30 AND ABS(dr.calories - f.calories * dr.amount_grams / 100) > 1;

这条SQL查到的不一致记录，就是定时任务需要重算的补偿数据。系统上线前做数据一致性校验，比上线后再处理要省力得多。

本文还有配套的精品资源，点击获取