苏三公子做Java Web开发这些年，管理系统确实写了不少，但大多数时候都在处理"登录注册、增删改查、列表展示"这类确定性很强的业务。真正让我觉得有意思的，是"智能推荐"这种带点算法味道的垂直场景。这个基于SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0的智能推荐卫生健康系统，前后端分离、带完整文档，是最近我梳理过最顺手的一套源码。它不光是常规的用户管理加CRUD，还真正实现了"用户填健康档案、系统算推荐分数、自动生成饮食和运动方案"的完整闭环。对正在做毕业设计的学生、想系统学习前后端分离实战的开发者，或者准备做健康内容推荐类产品原型的技术人员来说，这套东西的参考价值都很高——既有SpringBoot2后端分层的规范写法，也有Vue3组合式API的完整落地，还有MySQL8.0在真实业务场景下的表结构和查询设计。这篇文章我就把项目从选型到落地再到部署踩坑，完整拆开讲一遍。
1. 智能推荐卫生健康系统：它在解决什么真实问题
1.1 项目缘起：体检数据和人工建议之间的断层
我接触过不少体检机构、社区健康管理站的技术需求，最大的共性是：数据都在，但没人用。体检报告出来了，食材库、食谱库、运动方案也在库里躺着，可真要给用户提建议的时候，靠的还是人工翻资料。用户问一句"血压偏高平时该吃什么"，运营人员得翻半天食材表才能凑出一个答复，效率低、不够个性化，也很难规模化。
这套系统的定位就是解决这个断层。它把用户的基础信息、体质数据、疾病史、过敏原、饮食习惯这些信息收拢成一份结构化健康档案，再由推荐引擎根据档案自动计算匹配分数，生成一份"这个用户当下应该怎么吃、怎么动"的个性化方案。整个过程不需要人工介入，用户打开页面就能看到结果，而且结果不是瞎推荐的，每条建议都能追溯到具体的健康因子，可解释性比较强。
1.2 核心功能模块拆解
我从功能上把整套系统画了个总图，大致是五个模块：
- 用户中心：注册、登录、个人信息维护，JWT做无状态认证。
- 健康档案：录入身高、体重、年龄、性别、疾病史、过敏原、饮食习惯、运动频率等数据，这是推荐算法的核心输入。
- 智能推荐：根据健康档案实时计算推荐分数，生成饮食和运动方案，并保存推荐历史，方便用户回溯。
- 内容管理：食材库、食谱库、运动库、健康资讯的后台维护，属于典型的运营后台功能。
- 数据统计：用图表展示用户健康指标变化趋势和推荐记录，直观看到体质改善情况。
这五个模块串起来，才构成一个完整的"数据输入-算法加工-结果输出-效果反馈"链路。如果只做前两个模块，那就只是个信息管理系统，谈不上"智能"；加上推荐引擎之后，这个项目才真正有了自己的核心价值。
1.3 这套源码适合谁，不适合谁
我梳理完之后的感觉是，它的定位介于"教学项目"和"可上线系统"之间，不是那种只能用来答辩的玩具项目，但也没有堆到微服务那么大。适合三类人：
- Java Web方向毕业设计的学生，文档、表结构、接口设计都是现成的，可以照着改造，替换模块主题也不难；
- 想弄懂SpringBoot2+Vue3前后端分离完整协作流程的开发者，两边代码都全，能对照着看请求怎么从页面走到数据库再返回；
- 准备做健康类、内容推荐类产品技术方案的人员，推荐逻辑虽然不复杂，但已经是一套可解释的落地实现，比单纯拿协同过滤算法糊弄业务方要实在得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术栈选型：这套组合为什么凑在一起
2.1 后端用SpringBoot2而不是SpringBoot3的原因
这个项目选了SpringBoot2，不是最新的SpringBoot3，很多人会问为什么。我的结论很直白：稳定生态比版本追新重要。SpringBoot2.x的starter丰富，MyBatis-Plus和各类中间件与它的适配方案在网上有大量验证过的踩坑记录；而且SpringBoot2用JDK8完全够跑，在很多学校和企业的现有环境下，JDK8依然是事实标准。SpringBoot3强制JDK17起步，虽然性能和新特性有提升，但对这个体量的系统来说属于"杀鸡用牛刀"，还平白增加了部署环境的迁移成本。基于SpringBoot2开发一套健康推荐系统，两三天就能把骨架搭起来，这套时间性价比在选型决策里是决定性的。
2.2 前端Vue3带来的实际变化
后端定了SpringBoot2之后，前端我选了Vue3。Vue3的Composition API对这类系统的开发体验提升是实打实的。健康档案表单和推荐结果页面都有"加载、请求、渲染、异常处理"这一套逻辑，用组合式函数能把公共状态和副作用抽出来复用，不用再跟Vue2时代的mixin较劲。项目还配合了Pinia做状态管理、Vite做开发构建，热更新速度明显优于Webpack那套老配置。实际开发里我最喜欢的是Vue3的响应式基于Proxy实现，数组和动态新增属性直接赋响应式能力，不用再靠this.$set这种别扭写法。
2.3 MyBatis-Plus为什么能省一半工作量
数据访问层选型我几乎没有犹豫，就是MyBatis-Plus。这套系统的数据访问大部分是单表查询加条件过滤，比如"按用户ID查健康档案""分页查询食材列表""根据标签集合筛选运动方案"。这些场景用BaseMapper自带的selectById、selectList配合LambdaQueryWrapper就能解决，每张表都不需要单独写XML，连结果映射都是自动的。多表关联和复杂统计自己写SQL，单表CRUD全交给框架，硬生生把我的代码量砍掉一半还多。后面我会用专门的篇幅讲批量插入和条件构造器这两个高频用法，这两个都是平时最容易用出问题的点。
2.4 MySQL8.0不只是"能用"，它还影响了设计
选择MySQL8.0不是跟风，而是它的新特性确实改变了我的表结构设计思路。推荐记录的趋势统计，我用窗口函数LAG()计算环比变化，这在MySQL5.7里得写子查询嵌套，语义很难维护；用户的饮食偏好和过敏原，我用JSON字段存了一组标签，查询时用JSON_CONTAINS直接过滤，省掉了原本可能要建的关联表。还有很重要的一点，MySQL8.0默认字符集是utf8mb4，中文、特殊符号、emoji都能正常存储，以前那种"中文变成问号"的坑基本绝迹了。既然是新项目，数据库就该选能支撑更现代写法的版本，而不是为了迁就老环境把设计剪裁得别扭。
3. 推荐引擎落地：从用户健康档案到个性化方案的计算逻辑
3.1 为什么卫生健康场景不能只用协同过滤
很多人一提推荐就想到协同过滤，但放到卫生健康这个场景，纯协同过滤是行不通的。协同过滤的思路是"和你相似的人喜欢什么，就把什么推给你"，这在娱乐内容推荐里没问题，可健康建议是有客观标准的，不能因为一堆相近体质的用户都爱吃麻辣火锅，就把麻辣火锅推荐给一个有胃溃疡病史的人。所以我在这套系统里用的是混合推荐策略：基于内容匹配为主，规则评分为辅，再叠加一个简化的相似用户补充逻辑。这样出来的结果第一不会违反健康常识，第二才有真正的个性化。
3.2 特征建模与推荐分数公式
推荐引擎的输入是结构化健康档案，我把它提炼成几个关键特征维度：BMI指数、疾病史标签、过敏原标签、饮食偏好标签、运动频率、年龄性别。输出是一个推荐分数，公式设计成加权求和加过滤条件：
code复制score = 基础分60
+ BMI适配分(-10 ~ 15)
+ 疾病匹配加分(0 ~ 20)
+ 饮食偏好命中加分(0 ~ 15)
+ 运动频率适配分(0 ~ 10)
过敏原和疾病禁忌走的是硬过滤，只要命中，直接排除对应的食材或运动方案，不参与评分。什么是硬过滤？就是用户对花生过敏，哪怕花生酱的营养评分再高，也必须从候选集里移除。另一类负向因素，比如"正在控制体重"对应的食材搭配偏好，则通过减分来压低排序，而不是直接移除。这套"负向硬过滤+正向加权"的组合逻辑，保证了推荐结果既安全又有区分度。
3.3 推荐流程的完整链路
一次真实的推荐请求，在系统里走完的链路是这样的：
- 用户打开推荐页面，前端请求后端
/api/recommend/today接口； - 后端从token中解析用户ID，查出当前用户的健康档案；
- 如果用户档案不完整，返回提示并引导补全信息，这是冷启动降级；
- 档案完整，推荐服务加载食材库和运动库的候选集，按过敏原和禁忌做硬过滤；
- 对剩余候选逐条计算评分公式，按分数倒序排列；
- 取分数最高的前5条食材、前3个运动方案组装成返回结果；
- 同时把当次推荐内容写入推荐记录表，供后续统计和效果回溯。
这套链路从接口设计到算法执行都不是黑盒，每一步都能用日志和测试数据验证，这也是它适合作为学习项目的重要原因——你看得懂推荐结果是怎么算出来的。
3.4 推荐服务的核心代码结构
推荐服务我用了一个策略接口加多个评分器实现的方式，比把所有判断塞在一个Service里清晰得多：
java复制public interface ScoreEvaluator {
boolean support(HealthProfile profile, RecommendItem item);
double evaluate(HealthProfile profile, RecommendItem item);
}
// 示例：饮食偏好评分器
@Service
public class DietPreferenceEvaluator implements ScoreEvaluator {
@Override
public boolean support(HealthProfile profile, RecommendItem item) {
return item.getType().equals("FOOD");
}
@Override
public double evaluate(HealthProfile profile, RecommendItem item) {
List<String> prefs = profile.getDietPreferences();
if (prefs == null || prefs.isEmpty()) {
return 0;
}
double hitScore = prefs.stream()
.filter(pref -> item.getTags().contains(pref))
.count() * 5;
return Math.min(hitScore, 15);
}
}
主流程用List<ScoreEvaluator>按顺序执行，把每个评分器返回的分数累加，再配合过滤链把不合格的候选去掉。后续要调整推荐算法，只需要新增一个评分器实现，不用改动主流程代码，维护成本很低。
3.5 冷启动和数据不足怎么办
新用户注册后没有完整健康档案，推荐引擎拿不到足够的特征输入，这时候硬算分数没有意义。我的处理方案是降级推荐：当档案里的必填字段缺失超过一半时，不调用推荐算法，而是返回系统默认的"均衡膳食方案"，同时前端弹窗引导用户完善档案。等到档案补充完整，下一次推荐请求再进入正常算法流程。这套降级逻辑在代码里就是一个状态判断，但它是决定用户第一次体验好不好的关键细节。
4. 数据库设计：卫生健康场景下的表结构与MySQL8.0特性应用
4.1 核心表整体规划
这个系统的核心表我用一张表来梳理职责：
| 表名 | 核心职责 | 关键字段 |
|---|---|---|
| user | 账号体系 | id, username, password, nickname |
| health_profile | 健康档案 | user_id, height, weight, bmi, disease_tags, allergy_tags, diet_preferences, exercise_freq |
| food | 食材库 | id, name, calories, protein, fat, tags, suitable_for |
| recipe | 食谱库 | id, name, food_ids, total_calories, description |
| exercise | 运动库 | id, name, intensity, tags, unsuitable_for |
| recommend_record | 推荐记录 | id, user_id, content_type, content_id, score, recommend_date |
用户和健康档案是一对一关系，健康档案里的多值属性用JSON数组存储；推荐记录和用户是多对一关系，这张表支撑后续所有统计分析。
4.2 健康档案表的建表SQL与JSON字段
健康档案表是整个推荐系统的数据基石，建表SQL里最能体现MySQL8.0设计思路的是disease_tags和diet_preferences这两个JSON字段：
sql复制CREATE TABLE health_profile (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL UNIQUE,
height DECIMAL(5,2) NOT NULL COMMENT '身高/cm',
weight DECIMAL(5,2) NOT NULL COMMENT '体重/kg',
bmi DECIMAL(4,2) GENERATED ALWAYS AS (weight / (height/100 * height/100)) STORED,
disease_tags JSON COMMENT '疾病史标签',
allergy_tags JSON COMMENT '过敏原标签',
diet_preferences JSON COMMENT '饮食偏好标签',
exercise_freq VARCHAR(20) COMMENT '运动频率',
created_time DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户健康档案表';
BMI字段我用了MySQL8.0的生成列，由身高体重自动计算，避免应用层算完再存一遍造成的脏数据。多值标签用JSON而不是关联表，一是这套系统的标签集合规模有限，二是读写路径简单，不用为了一次查询联三张表。
4.3 基于窗口函数的统计查询
推荐记录的趋势统计，我用窗口函数解决了老版本里非常啰嗦的环比问题。比如要看某个用户最近5次推荐的评分趋势：
sql复制SELECT content_type, score, recommend_date,
LAG(score, 1) OVER (ORDER BY recommend_date) AS prev_score,
ROUND((score - LAG(score, 1) OVER (ORDER BY recommend_date))
/ NULLIF(LAG(score, 1) OVER (ORDER BY recommend_date), 0) * 100, 2) AS change_percent
FROM recommend_record
WHERE user_id = ?
ORDER BY recommend_date DESC
LIMIT 5;
说实话，这种SQL在MySQL5.7里写起来非常痛苦，要么套多层子查询，要么在应用层循环算。8.0直接一个窗口函数搞定，语义一目了然，这也是我在新项目里坚定选MySQL8.0的原因。
4.4 索引规划与高频查询优化
这个系统的查询模式很集中，我把索引也设计得比较克制。health_profile.user_id加唯一索引，因为一个用户只允许一条档案；recommend_record表针对高频查询"按用户查历史"建了(user_id, recommend_date)联合索引；食材库和运动库的标签过滤，因为标签存在JSON里，JSON_CONTAINS走不了常规索引，但这类基础表的行数不大，全表扫描在合理范围内。遇到类似项目，我建议先把高频查询SQL列出来，再反推索引，而不是提前给每张表都堆满索引，那样只会拖慢写入。
5. 后端实战：SpringBoot2+MyBatis-Plus核心接口的实现细节
5.1 工程结构与分层规范
后端工程我采用的是标准的Controller-Service-Mapper三层结构，另外加了entity、vo、common三个包放实体、视图对象和公共工具。分层的核心目的是每层只干一件事：Controller只管参数接收和结果包装，Service写业务逻辑和事务控制，Mapper只管SQL。推荐引擎里的ScoreEvaluator评分器接口放到了strategy子包下，和数据访问层完全解耦。这样的结构对后来的扩展非常友好，比如想新增一个"季节推荐"策略，新增一个实现类就好，不用动其他代码。
5.2 通用CRUD与LambdaQueryWrapper实战
MyBatis-Plus让我最舒服的是LambdaQueryWrapper，类型安全，不用手写字符串列名。比如查询某个用户最近7天的推荐记录：
java复制LambdaQueryWrapper<RecommendRecord> wrapper = Wrappers.lambdaQuery();
wrapper.eq(RecommendRecord::getUserId, userId)
.ge(RecommendRecord::getRecommendDate, LocalDate.now().minusDays(7))
.orderByDesc(RecommendRecord::getRecommendDate);
List<RecommendRecord> records = recommendRecordMapper.selectList(wrapper);
如果换成原生MyBatis，得先写好SQL和XML映射，为了这种单表查询专门维护一段XML确实不划算。BaseMapper提供的insert、updateById、selectList覆盖了系统里80%的数据访问需求，剩下20%涉及多表统计的再写自定义SQL。
5.3 批量插入食材库的性能优化
食材库初始化往往一次要导入几百条数据，如果循环调用insert逐条插入，性能非常难看。MyBatis-Plus自带的saveBatch虽然方便，但底层是拆成单条执行，数据量一上来同样拉胯。我实测一次性插入500条食材数据，两种方式耗时能差3倍以上，最终用了自定义XML的foreach批量插入：
xml复制<insert id="insertBatch" parameterType="list">
INSERT INTO food (name, calories, protein, fat, tags, suitable_for)
VALUES
<foreach collection="list" item="item" separator=",">
(#{item.name}, #{item.calories}, #{item.protein}, #{item.fat},
#{item.tags, typeHandler=com.example.handler.JsonTypeHandler},
#{item.suitableFor})
</foreach>
</insert>
这里有个容易踩的坑：JSON字段要配合类型处理器，否则tags这个List字段在写入时会被MyBatis当成字符串处理，要么报类型转换错，要么存进去是一段乱格式文本。我在JSON类型处理器上花的时间，比写批量SQL本身还多。
5.4 统一返回与全局异常处理
接口返回格式我统一用一个Result<T>包装类，结构是{ code, message, data }。成功时code=200，业务异常时code按场景区分。配合@RestControllerAdvice全局异常处理器，所有未捕获异常都会被转成统一JSON，避免出现那种直接把堆栈信息甩给前端的尴尬情况。这套东西看起来基础，但我见过太多小系统出了一个异常，前端弹窗显示一堆英文异常的，问题根源就是没做全局异常兜底。
5.5 定时推荐与缓存
推荐结果如果每次都实时计算，在用户量小的时候没问题，但考虑到后续扩展，我用Spring Task加本地缓存做了一天一次的预计算。凌晨2点定时任务把当天所有活跃用户的推荐结果算好存入缓存映射表，用户白天访问推荐页时直接读缓存，响应时间从平均200毫秒降到了30毫秒以内。对于这种"每天结果基本不变"的业务场景，定时预计算比实时计算要合理得多。如果下次再往高并发方向演进，再把本地缓存换成Redis就行，核心逻辑不需要动。
6. 前端实战：Vue3组合式API下的页面搭建与交互
6.1 工程初始化与依赖选择
前端用Vite创建Vue3工程，依赖选择上我控制得比较克制：vue-router管路由、pinia管全局用户状态、axios管HTTP请求、element-plus做UI组件库、echarts做统计图表。没有引入重型脚手架，保证新人在理解和改造时不会面对一堆积淀下来的"祖传代码"。创建命令就是标准的npm create vite@latest health-fe -- --template vue，装完依赖直接跑通项目骨架，再开始逐页搭建。
6.2 路由守卫与Axios封装
登录状态管理走的是Pinia加路由守卫组合。在beforeEach路由守卫里判断userStore.token是否存在，没有就重定向到登录页。Axios封装的关键是两个拦截器：请求拦截器在每次请求头里带上JWT，响应拦截器统一处理Result结构，遇到code=401就清除登录态并跳转登录页。这样一个登录状态就能贯穿整个应用的访问控制，比在每页单独判断要省事得多。
6.3 健康档案表单的校验与动态行
健康档案表单是这个前端项目的核心交互，贴合场景总结了几个细节：
reactive定义整个表单模型，多值标签用el-checkbox-group绑定，JSON数组提交前做一次JSON.stringify；- 日期校验用Element Plus的
rules规则，比如"体检日期不能晚于今天"这类校验； - 饮食偏好支持动态添加删除行，用户可随时增删一条偏好标签，前端用数组的
push和splice驱动界面更新，得益于Vue3的Proxy响应式，数组索引操作不再有检测不到的问题； - 提交前做前端校验，拦截必填项缺失的请求，减少无效接口调用。
6.4 推荐结果展示与图表联动
推荐结果页我拆成三块：顶部的健康档案摘要卡片，中间是推荐食材和食谱列表，底部是运动方案卡片。列表展示时用Element Plus的el-card加标签展示推荐原因，每条结果后面都跟一句"为什么推荐"，比如"因您BMI为28.1超重，推荐低热量高纤维食材"。图表部分用ECharts展示近7天推荐分数的变化趋势，数据来自推荐记录接口，和列表用同一个数据源，切换日期区间时联动刷新。这种"有推荐必须有解释"的展示方式，直接呼应了后端可解释推荐的设计，用户信任度会明显提升。
7. 部署启动与踩坑记录：从MySQL8.0到全栈项目跑通
7.1 MySQL8.0的安装与连接配置
部署环境我用Docker直接拉起MySQL8.0，命令整理如下：
bash复制docker run --name mysql8 \
-e MYSQL_ROOT_PASSWORD=root123456 \
-e MYSQL_DATABASE=health_recommend \
-p 3306:3306 \
-d mysql:8.0
启动后创建库并执行初始化脚本。连接层最容易踩的坑有两个：第一个是驱动类必须用com.mysql.cj.jdbc.Driver，老的com.mysql.jdbc.Driver在MySQL8.0下直接不可用；第二个是URL里一定要配allowPublicKeyRetrieval=true和serverTimezone=Asia/Shanghai，否则连上数据库时会报Public Key Retrieval is not allowed或时区错误。这俩我在不同项目里都遇到过不止一次，属于MySQL8.0常见连接坑的标准配置。
7.2 application.yml配置要点
后端的核心配置我放在一块，照着配基本不会出问题：
yaml复制spring:
datasource:
url: jdbc:mysql://localhost:3306/health_recommend?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
username: root
password: root123456
driver-class-name: com.mysql.cj.jdbc.Driver
jackson:
date-format: yyyy-MM-dd HH:mm:ss
time-zone: Asia/Shanghai
mybatis-plus:
mapper-locations: classpath*:mapper/**/*.xml
configuration:
map-underscore-to-camel-case: true
global-config:
db-config:
logic-delete-field: deleted
logic-delete-value: 1
logic-not-delete-value: 0
逻辑删除配置是我力推的一个点，加上之后所有删除操作自动转成更新，推荐记录这种需要回溯的数据不会物理消失，业务安全性高很多。
7.3 前端跨域与Vite代理
前端开发环境和后端接口通信，跨域问题我用Vite的proxy解决，不用在后端单独开CORS。配置在vite.config.js里：
js复制server: {
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
}
}
}
这样前端请求/api/recommend/today时，开发服务器会自动转发到后端的8080端口，浏览器端完全感知不到跨域存在。上线部署时再用Nginx统一转发，前后端各自都不用暴露给外网。
7.4 实测高频报错与解决办法
我把整套系统从零启动过程中遇到的高频问题整理成一个表格，每个都是实际踩过的：
| 报错现象 | 根因 | 解决办法 |
|---|---|---|
| Public Key Retrieval is not allowed | MySQL8.0默认认证插件要求显式允许 | URL加allowPublicKeyRetrieval=true |
| MyBatis-Plus分页失效，查出全表 | 缺少分页插件 | 配置MybatisPlusInterceptor并注册PaginationInnerInterceptor |
| JSON字段查询报语法错误 | 类型处理器未生效 | 自定义JsonTypeHandler并在@TableField中指定 |
| Vue3修改数组索引页面不更新 | 未正确使用reactive/ref | 确保数组声明在reactive中或用ref管理 |
| Prop传对象修改报警告 | 直接改了父组件传入的prop | 使用computed或本地副本进行修改 |
每一项都在项目里有对应的实际场景。特别是分页插件这个，很多人加了MyBatis-Plus依赖就以为分页自动可用，实际必须在配置类里显式注册分页拦截器，否则Page对象被当成普通参数处理，查出来的还是全量数据。
7.5 我对这套系统的后续优化方向
整套系统跑通之后，如果还想着继续演进，我个人认为有几个方向可以延伸：推荐算法层引入更精细的营养目标规划，比如设定减肥目标后动态调整每日卡路里预算；缓存层把本地缓存换成Redis以支撑更大并发；新增管理后台的推荐干预功能，运营人员可以手动调整某些食材的推荐权重。每一次演进都不需要推翻现有架构，这也是我当初坚持分层设计和策略模式而不是随手写业务代码的原因。做项目不仅要看今天能不能跑通，更要看明天想扩展时，代码结构接不接得住新需求。