小泉水1. 项目背景与核心需求拆解
这段时间帮几个学弟学妹看毕业设计，发现“糖尿病患者健康数据分析及饮食推荐系统”这个题目出现的频率特别高。一开始我以为是巧合，仔细聊下来才发现，这个选题之所以热门，不是因为好做，而是因为它在医疗健康和软件开发之间找到了一个非常舒服的平衡点——既有数据分析的深度，又有推荐算法的落地场景，还牵扯到用户管理和可视化展示，几乎是给计算机专业学生量身定做的综合实训项目。
先说清楚这个系统到底解决什么问题。糖尿病患者的日常管理，最大的痛点不是“吃药”，而是“吃”。很多患者拿到诊断报告之后，医生只会告诉你“少吃糖、多运动、注意饮食”，但具体到三餐怎么搭配、升糖指数高的食物怎么替换、今天血糖超标了明天该吃什么，没有人给出一个可操作的方案。这个系统的核心价值就落在这里：把患者的血糖数据、体重指数、用药情况汇总起来，通过一套规则引擎和推荐逻辑，在食材库的基础上生成个性化的每日饮食建议，让患者打开系统就知道“早晨吃燕麦、中午吃荞麦面配清蒸鱼、晚上吃粗粮粥加凉拌黄瓜”，而不是面对一堆营养学理论无从下手。
整个项目适合谁来看？如果你是正在准备毕业设计的本科生，或者想用 Java 生态做一套完整业务系统的初级开发者，这个案例分析基本覆盖了你需要掌握的全部知识点。从 Spring Boot 的项目搭建，到 MyBatis-Plus 的数据库操作，再到 ECharts 的数据可视化和推荐规则的算法实现，每一环都是实际工作中会用到的技术。最关键的是，它不是一个纯 CRUD 的“空壳系统”，而是有真实业务逻辑支撑的项目，这在答辩的时候非常加分——评委看到的是你理解业务，而不是简单堆代码。
另外说一句，标题里提到的“源码”确实是个吸引人的点。我见过太多学生到答辩前一周还在到处找现成代码，结果找到的不是跑不起来就是缺东少西。这个项目的完整源码和数据库脚本我已经整理好了，里面包含了前端页面、后端接口、SQL 建表语句和推荐算法的完整实现，需要的可以在文末找我拿。不过我更建议你先跟着这篇文章把设计思路捋清楚，然后再去看代码，这样后面改动起来才顺手。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与整体架构设计
2.1 为什么选 Spring Boot + Vue 这套组合
这套系统的技术选型，我一开始就定死了 Java 生态，原因很简单：第一，国内高校的课程体系里 Java 是绝对主力，学生上手快，答辩时老师也不会刁难你用的框架太偏门；第二，Spring Boot 的生态成熟度极高，社区资料多，遇到问题一搜就有解决方案，不会像一些小众框架那样卡住就彻底卡住。
具体来说，后端我用的是 Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.0，前端用的是 Vue 2 + Element-UI + ECharts。这套组合算得上是国内中小型管理系统的“标准答案”，几乎每一个 Java 方向的毕业设计都能看到它的身影。Spring Boot 负责把业务逻辑封装成 RESTful API，MyBatis-Plus 简化了数据库的增删改查操作，Vue 负责页面的渲染和交互，ECharts 用来画血糖趋势折线图和饮食结构饼图。
你可能会问，为什么不用 JSP + Servlet 这种更基础的方案？说实话，JSP 那套东西写起来是真的痛苦，页面和 Java 代码耦合在一起，后期维护想死的心都有。前后端分离的好处在于，前端只管渲染，后端只管数据，接口一对接就能跑起来，开发效率完全不在一个量级上。而且 Vue 那套组件化的思路，在答辩的时候展示起来也更“现代化”，能体现出你跟上技术潮流的意识。
2.2 项目分层：Controller-Service-Mapper 三层架构
这套系统的代码结构，我按照标准的 MVC 模式来组织。很多人写毕业设计的时候不分层，所有逻辑全堆在 Controller 里，几百行代码一个方法，看着就头大。实际上，分层的核心目的是降低耦合度，让每一层只关注自己的职责。
Controller 层只负责接收请求参数、调用 Service 层的方法、把结果封装成统一的 JSON 格式返回给前端。Service 层是业务逻辑的核心，比如血糖数据的统计分析、饮食推荐规则的匹配、用户每日摄入热量的计算，都在这一层完成。Mapper 层（也就是 DAO 层）通过 MyBatis-Plus 内置的方法或者自定义 SQL 来操作数据库。
我举个例子来说明这样分层的价值。假设你要做一个“根据血糖值推荐早餐”的功能，如果逻辑全部写在 Controller 里，那么 Controller 既要查数据库、又要算热量、还得写推荐规则，代码会异常臃肿。而分层的做法是：Controller 接收用户 ID，调用 dietService.getBreakfastRecommendation(userId)，Service 内部去查询用户最近的血糖记录、调用 calculateCalories() 方法计算热量、再从食材库中匹配符合条件的食材组合，最后返回推荐结果。这样一来，每个方法的职责都非常清晰，代码可读性也大大提升。
项目的整体包结构大概是这样的：
code复制com.example.diabetes
├── controller # 前端接口入口
│ ├── UserController
│ ├── HealthDataController
│ └── DietRecommendController
├── service # 业务逻辑层
│ ├── impl
│ │ ├── HealthDataServiceImpl
│ │ ├── DietRecommendServiceImpl
│ │ └── UserServiceImpl
│ └── HealthDataService.java（接口）
├── mapper # 数据访问层
│ ├── UserMapper
│ ├── HealthRecordMapper
│ └── FoodItemMapper
├── entity # 数据库实体类
├── vo # 前端视图对象
├── util # 工具类（如血糖值判断工具）
└── config # 配置类（如跨域配置、拦截器配置）
这样的结构，你在简历里写“采用分层架构设计，实现业务逻辑与数据访问的解耦”，一看就是有真正经验的表述，而不是只会调 API 的初学者。
3. 数据库表结构与核心业务逻辑
3.1 五张核心表的设计思路
数据库的设计直接决定了后期开发的顺畅程度。我在设计这套系统的表结构时，前后调整了三版才定稿。核心表一共五张：用户表（user）、血糖记录表（blood_glucose_record）、饮食记录表（diet_record）、食材信息表（food_item）、推荐规则表（diet_rule）。下面逐一说明每张表的设计思路和关键字段。
用户表是最基础的表，除了常见的 id、username、password 之外，我特意加了一些跟健康管理相关的字段，比如 age、gender、height、weight、diabetes_type（糖尿病类型，分为 1 型和 2 型）、exercise_level（运动强度）。这些字段不是摆设，后面计算 BMI、估算每日基础代谢率、调整推荐热量摄入都会用到。特别是 diabetes_type，1 型和 2 型患者的饮食策略差异很大，1 型患者需要严格匹配胰岛素剂量，2 型患者更多依赖饮食和运动控制，推荐结果必须区别对待。
血糖记录表是整个数据分析模块的数据基础。字段包括：record_id、user_id、glucose_value（空腹血糖值）、measure_time（测量时间）、period（时间段，如早餐前、早餐后、睡前）、note（备注，可以用来记录当天的饮食、情绪、运动情况）。这里有一个很重要的设计细节：glucose_value 的数据类型在 MySQL 里我用了 DECIMAL(5,2)，而不是 FLOAT 或 DOUBLE。原因在于浮点数在计算机中无法精确表示，容易产生精度偏差，而血糖值是医疗数据，一点点误差都可能影响判断。DECIMAL 可以精确保留两位小数，从源头上避免了这类问题。
食材信息表是饮食推荐模块的“弹药库”。我准备了 200 多种常见食材，每种食材包含 food_name、category（分类，如蔬菜、水果、主食、肉类）、calories（每 100 克热量）、glycemic_index（升糖指数）、protein（蛋白质含量）、fiber（膳食纤维含量）。glycemic_index 是个关键字段，升糖指数低的食物（比如燕麦、荞麦、绿豆）消化吸收慢，血糖上升平缓，适合糖尿病患者；升糖指数高的食物（比如白米饭、馒头、西瓜）容易导致血糖骤升，推荐时就要谨慎甚至排除。
饮食记录表记录用户每天实际吃了什么，包含 record_date、meal_type（早餐、午餐、晚餐、加餐）、user_id、content（记录内容）、total_calories（本次摄入总热量）。这张表的意义在于，系统可以对比“推荐的饮食”和“实际的饮食”，帮助用户直观地看到偏差，也方便后续做饮食结构分析。
推荐规则表是推荐逻辑的核心。我用 rule_type 来区分不同场景的规则，比如 high_fasting_glucose（空腹血糖偏高）、normal_glucose（血糖正常）、low_glucose（低血糖）等。每个规则有对应的 suitable_food_ids（推荐食材 ID 列表）和 avoid_food_ids（避免食材 ID 列表），用逗号分隔存储。这样设计的好处是，推荐规则可以随时调整，医生或者管理员在后台就能维护，不需要改代码重新部署。
3.2 血糖状态判断与饮食推荐的核心逻辑
推荐逻辑是这套系统的灵魂，也是答辩时最容易展现亮点的部分。我用一句话来概括整个逻辑：先看血糖状态，再看个体指标，最后匹配食材规则，生成营养均衡的饮食方案。
先说血糖状态判断。根据临床上的通用标准，空腹血糖在 3.9 到 6.1 mmol/L 之间属于正常范围，6.1 到 7.0 mmol/L 属于空腹血糖受损（糖尿病前期），超过 7.0 mmol/L 就达到了糖尿病诊断标准。我在代码里封装了一个 BloodGlucoseUtil 工具类，输入血糖值和测量时间段，返回对应的状态枚举，分别是 NORMAL（正常）、HIGH（偏高）、LOW（偏低）。这里补充一下，我是综合考虑了中华医学会糖尿病学分会发布的《中国2型糖尿病防治指南》里的参考范围，大家做这个项目时，数值边界不需要太纠结，关键是逻辑要清晰。
然后是每日热量摄入的计算。这里用了基础代谢率（BMR）的简化公式——Mifflin-St Jeor 公式：
code复制男性：BMR = 10 * 体重(kg) + 6.25 * 身高(cm) - 5 * 年龄 + 5
女性：BMR = 10 * 体重(kg) + 6.25 * 身高(cm) - 5 * 年龄 - 161
算出基础代谢率之后，再根据运动强度乘以活动系数。久坐少动的人群系数是 1.2，轻度活动是 1.375，中度活动是 1.55，重度活动是 1.725。对于糖尿病患者来说，一般建议将每日总热量摄入控制在 BMR 乘以活动系数的结果上，再根据减重目标适当下调 10% 到 20%。
推荐逻辑的实际执行过程是这样的：首先从饮食记录表里查出用户最近 7 天的平均摄入热量，跟计算出的目标热量做一个对比。如果现有摄入已经超标，系统就会推荐热量更低的食材组合；如果没有超标，就维持正常热量水平。同时，根据最近一次血糖数据判断状态：如果血糖偏高，系统会在食材匹配时排除高 GI 值食材，并且提高膳食纤维类食材的比例；如果血糖偏低，反而会推荐一些中等 GI 值的食物，避免低血糖风险。
这个逻辑说起来简单，但实际上要考虑的边界情况很多。比如用户第一次使用系统，还没有任何血糖数据，推荐逻辑就必须有兜底方案。我的做法是，在没有历史数据时默认使用正常状态下的推荐规则，同时在页面上提示用户先补充健康数据。
4. 核心功能模块的实现与实操
4.1 健康数据录入与血糖趋势分析
健康数据录入模块解决的问题很简单：让用户方便地记录自己每天的血糖值和体重，然后系统自动生成趋势图，让用户一眼看出自己的血糖变化趋势。听起来简单，但实际操作中有一堆细节需要考虑。
常见的时间段选项我分成了五个：早餐前（空腹）、早餐后两小时、午餐前、午餐后两小时、睡前。这几个时间点基本覆盖了糖尿病患者日常监测的主要节点。为什么不是任意时间随意记录？因为临床医生在分析血糖数据时，非常看重“同一时间点的纵向对比”。你今天早餐前是 5.8 mmol/L，昨天早餐前是 6.2 mmol/L，这两个数据比较起来才有意义。如果你今天起床测一次、明天吃完饭测一次，后天睡前测一次，数据之间完全没有可比性，趋势分析也就失去了价值。
血糖趋势图我用了 ECharts 的折线图来实现。后端提供一个接口：GET /api/health/trend?userId=xxx&days=7，返回最近 7 天的血糖记录，按测量时间排序。前端拿到数据之后，用 ECharts 的 line 系列来渲染，横轴是日期，纵轴是血糖值。这里我加了一个很实用的功能——在图表上画了两条参考线，一条是 3.9 mmol/L 的低血糖警戒线，一条是 7.0 mmol/L 的高血糖警戒线。这样一来，用户看一眼图表就能判断自己哪些时间点的血糖超出了安全范围，而不是对照着数字半天反应不过来。
这个模块的后端实现上，有一个分页查询的细节值得注意。如果用户记录的数据特别多，一次性把全部数据查出来返回给前端，不仅网络传输压力大，前端渲染也会卡顿。所以我把接口设计成分页格式：GET /api/health/list?userId=xxx&pageNum=1&pageSize=10，返回内容包括 total（总记录数）、records（当前页数据）、pages（总页数）。前端用 Element-UI 的分页组件 el-pagination 来配合展示，切换页码时重新请求数据。
4.2 饮食推荐功能的完整实现流程
饮食推荐是整套系统里让我花时间最多的地方。这里先给出一段核心代码，展示推荐逻辑的实现思路，然后我再用文字详细拆解这段代码背后的业务思考。
java复制public List<FoodItemVO> generateRecommendation(Long userId, String mealType) {
// 1. 获取用户信息，包括身高、体重、年龄、运动强度等
User user = userMapper.selectById(userId);
// 2. 获取用户最近的血糖记录，判断当前血糖状态
BloodGlucoseRecord latestRecord =
bloodGlucoseRecordMapper.findLatestByUserId(userId);
// 3. 根据用户信息计算每日推荐总热量
double bmr = calculateBMR(user);
double targetCalories = bmr * getActivityFactor(user.getExerciseLevel());
// 4. 根据血糖状态匹配对应的推荐规则
GlucoseStatus status =
BloodGlucoseUtil.judgeStatus(latestRecord.getGlucoseValue());
DietRule rule = dietRuleMapper.findByRuleType(status.getRuleType());
// 5. 从推荐食材中筛选符合当前餐次热量要求的组合
List<FoodItem> suitableFoods =
parseFoodIds(rule.getSuitableFoodIds(), mealType);
List<FoodItem> selectedFoods = matchFoods(suitableFoods, targetCalories * 0.3);
// 6. 组装返回结果
return selectedFoods.stream()
.map(food -> new FoodItemVO(food))
.collect(Collectors.toList());
}
这段代码的每一行都有它的业务价值。第一步查用户信息，是为了拿到身高体重年龄来计算 BMR；第二步查最近血糖记录，是为了判断当天的推荐策略，如果血糖已经偏高了还推荐高热量食物，那这个系统就是在帮倒忙；第四步根据血糖状态匹配不同规则，是推荐逻辑最核心的分流点。
在匹配食材这一步，我做了热量拆分。一个成年人一天的总热量需求，一般建议分配到三餐的比例是 3:4:3，也就是早餐占 30%、午餐占 40%、晚餐占 30%。matchFoods 方法做的事情就是：从符合条件的食材列表中，随机挑选几种食材排列组合，使得组合后的总热量尽可能接近目标值，同时每种食材的克数在合理范围内。
这里有个小技巧，也可能是在答辩时评委比较感兴趣的点：食材热量的计算是按“每 100 克”来统计的，比如大米的热量是 346 千卡/100 克，那么推荐 50 克大米，实际热量就是 173 千卡。所以推荐结果里必须包含食材的推荐克数，而不是只给出食材名称。我在 selectedFoods 返回的对象中加了一个 recommendedWeight 字段，前端页面上展示“燕麦 50g”，这样用户才知道具体该吃多少。
4.3 可视化报表与用户管理模块
可视化报表模块用的是 ECharts，我做了三个图表：血糖趋势折线图、饮食结构饼图、体重变化柱状图。这三个图表分别对应了糖尿病管理的三大核心指标——血糖、饮食、体重。
饮食结构饼图的数据来源是食谱表里最近 7 天的记录。后端接口返回比例时，我用了一个 SQL 聚合查询，统计各类食材（主食、蔬菜、水果、肉类、乳制品）在总记录中的占比。然后前端用 ECharts 的 pie 系列来渲染，每块扇区显示对应分类的占比百分比。为什么这个图表有价值？因为糖尿病饮食的核心原则之一是碳水化合物占比要控制在 45% 到 60% 之间。
如果用户连续一周的碳水化合物占比达到了 70% 以上，系统会通过颜色告警的方式在图表上标红，提示用户减少主食类食材的摄入比例。
用户管理模块主要体现在管理员端。管理员登录后台后，可以查看注册用户的列表、查看每个用户的数据记录、禁用违规账号。这个模块在功能上不复杂，但有一个安全隐患必须处理好——密码存储。我强烈建议不要用明文存密码，至少也要用 MD5 加盐的方式处理。Spring Security 可能对毕设来说太重了，但用 DigestUtils.md5DigestAsHex() 加一个固定盐值处理一下，成本很低却能在答辩时避免“系统无安全性设计”的批评。
5. 常见问题与排查技巧实录
5.1 数据库连接与时区问题
这个错误几乎每个用 MySQL 8.0 的人都会遇到。启动项目时报 The server time zone value '�й���ʱ��' is unrecognized，看着一堆乱码就头大，其实原因很简单：MySQL 8.0 默认时区跟 JDBC 驱动的时区不一致。解决办法是在数据库连接串上显式指定时区：
code复制jdbc:mysql://localhost:3306/diabetes?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
这里注意 serverTimezone=Asia/Shanghai 是必须的。还有 useSSL=false 也要加上，本地开发环境没有配置 SSL 证书，不加这个参数会报 SSL 连接警告。
很多人在数据库里建表时用了 datetime 类型，结果发现 Java 实体对应的 LocalDateTime 字段查询出来跟数据库里的时间差了 8 个小时。这个问题的根源还是时区。解决方式有两种：一是统一在数据库连接串上指定时区，二是把数据库表的时间字段类型改成 timestamp，让 MySQL 自动帮你处理时区转换。我自己的实践是两者结合，连接串写 serverTimezone=Asia/Shanghai，同时所有时间字段都用 datetime，查询出来的结果就不会有偏差了。
5.2 数据类型选择与精度陷阱
前面提到血糖值的字段类型要选 DECIMAL(5,2)，这里再展开说说。如果你用了 FLOAT 或者 DOUBLE 类型，存入 5.8，查询出来可能变成 5.799999952316284。这个浮点数精度问题在 Java 的 double 类型中同样存在。如果你在代码里用 double 来做血糖值比较，比如判断 glucoseValue > 7.0，极小的精度偏差可能导致判断结果不符合预期。
正确的做法是：数据库字段用 DECIMAL，Java 实体类对应的属性用 BigDecimal，所有的比较操作通过 BigDecimal.compareTo() 来进行，而不是直接用 >、< 运算符。这是一个非常容易忽略但在医疗数据场景下致命的细节，答辩时主动讲出来，评委老师会觉得你考虑问题很周到。
5.3 推荐逻辑的边界情况处理
推荐逻辑最常见的 bug 是空指针异常。比如用户第一次使用系统，还没有任何血糖记录，这时候 latestRecord 就是 null，直接调用 latestRecord.getGlucoseValue() 就会抛异常。我的处理办法是在调用前先判空，同时准备一套默认规则。类似地，如果用户没有填写完整的个人信息（比如体重、身高），BMR 计算也会返回异常值，所以我给体重和身高字段设置了默认值，并在前端页面上做了必填校验。
还有一个容易被忽视的问题：食材数据不够时，推荐结果会显得非常“贫瘠”。比如某种条件下符合条件的食材只有两种，推荐的菜谱永远只有“燕麦粥”和“全麦面包”，用户用几天就腻了。解决方法是往食材库里多填充不同分类的食材，同时在推荐算法里引入随机性，每次从候选集合中随机选择若干种组合，让推荐结果有变化，用户才不会觉得这个系统“死板”。
5.4 前端跨域与接口联调问题
前后端分离开发模式下，Swagger 或者 Postman 调试接口时一点问题没有，但浏览器里打开前端页面去调用接口，就会报跨域错误 No 'Access-Control-Allow-Origin' header is present on the requested resource。这个问题的根源是浏览器的同源策略，本质上前端域名和后端域名不一致，浏览器就默认阻止了跨域请求。
解决方式是后端配置一个全局跨域过滤器。Spring Boot 里最简单的做法是写一个 WebMvcConfigurer 的实现类，重写 addCorsMappings 方法：
java复制@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOriginPatterns("*")
.allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
.allowedHeaders("*")
.allowCredentials(true)
.maxAge(3600);
}
这段配置允许所有来源的请求访问后端接口、允许常见的 HTTP 方法、允许所有请求头、允许携带 Cookie，并且设置预检请求的缓存时间。注意 allowedOriginPatterns("*") 和 allowedOrigins("*") 的区别，后者在携带凭证时会有兼容性问题，前者从 Spring 5.3 版本开始推荐使用，兼容性更好。
6. 实战操作：从零搭建到跑通全流程
6.1 环境准备与初始化
动手之前先把环境准备好。我用的开发环境是：JDK 1.8 + Maven 3.6 + Spring Boot 2.7.0 + MySQL 8.0 + Node.js 14。JDK 版本建议用 1.8，虽然现在已经有很多新版本了，但 1.8 在高校和企业里仍然是主流，兼容性问题最少。
启动项目后的初始化步骤大概是这样的：第一步，在 MySQL 中创建数据库 diabetes_db，然后执行项目里的 diabetes_db.sql 脚本，表结构和初始化数据就自动创建好了。里面我预置了测试账号 admin（管理员）和 2024001（普通用户），方便你直接登录体验完整功能。第二步，在 IDEA 中导入后端项目，等待 Maven 把依赖下载完毕，修改 application.yml 里的数据库用户名密码，然后运行启动类。第三步，在命令行进入前端目录，执行 npm install 安装依赖，然后 npm run dev 启动前端开发服务器，默认端口一般是 8080。
跑起来之后，登录界面能看到完整的注册、登录表单，注册时要求填写身高、体重、年龄、糖尿病类型等信息。注册完成后跳转到首页，首页是一张数据总览仪表盘，展示了最近一次血糖值、7 日血糖平均值、推荐每日摄入热量、今日饮食完成度等指标卡片。
6.2 核心模块的编码实战：血糖记录与趋势分析
这里我挑一个模块完整展示编码过程，以血糖记录的接入与趋势分析为例。后端接口一共要写两个：一个是保存血糖记录的 POST /api/health/add，一个是查询趋势数据的 GET /api/health/trend。
先看保存接口的实现。我定义了一个 HealthRecordVO 作为接收前端参数的视图对象，字段包括 userId、glucoseValue、period、measureTime、note。Controller 接收到参数后调用 healthDataService.addRecord(vo)。在 Service 实现类里，除了把参数转成实体类保存到数据库之外，还会做两件事：一是基于新记录判断当前血糖状态，把判断结果写入返回的提示信息里；二是如果血糖值超过警戒线，自动生成一条健康提醒。
趋势分析接口稍微复杂一点。我做了多时间维度的支持，可以用 days 参数控制查询最近 7 天、14 天还是 30 天的数据。SQL 查询用了一个条件构造器：
java复制LambdaQueryWrapper<BloodGlucoseRecord> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(BloodGlucoseRecord::getUserId, userId)
.ge(BloodGlucoseRecord::getMeasureTime,
LocalDateTime.now().minusDays(days))
.orderByAsc(BloodGlucoseRecord::getMeasureTime);
List<BloodGlucoseRecord> records = mapper.selectList(wrapper);
核心点是用 ge 方法来限定时间范围，用 orderByAsc 把记录按时间升序排列，前端按照顺序画折线图，横轴时间就是单调递增的，不会出现折线乱跳的问题。
前端这块，我用 ECharts 的折线图渲染数据。为了实现超高血糖参考线，我在 series 数组中增加了两个 markLine 配置项：
javascript复制markLine: {
silent: true,
data: [
{ yAxis: 7.0, name: '高血糖警戒线', lineStyle: { color: '#f56c6c' } },
{ yAxis: 3.9, name: '低血糖警戒线', lineStyle: { color: '#e6a23c' } }
]
}
这样图表上就会自动画出两条横向的警戒线，水平延伸覆盖整个绘图区。用户看到折线在红色警戒线上方的时候，一眼就能知道自己血糖高了，不用再去对比数值。
6.3 推荐模块的本地调试技巧
推荐模块的逻辑相对复杂，调试时需要关注每一步的运行结果。这里分享一个很实用的调试方法：在 Service 方法的关键节点用日志输出中间数据。
比如 generateRecommendation 方法，我在计算 BMR 之后输出一条日志：计算得到BMR=××，目标摄入热量=××；在匹配食材之前输出：当前血糖状态=××，命中推荐规则=××。这样每次运行项目，控制台都会打印出推荐逻辑的“思考过程”，一旦结果不对，立刻能定位到是哪一步出了问题。
还有一个很常见的场景是：推荐结果里出现了升糖指数很高的食物。排查步骤是这样的：先看血糖状态判断是否正确，再看推荐规则表里配置的 suitable_food_ids 是否正确，最后确认食材信息表里对应食材的 GI 值字段是否录入正确。绝大多数问题都出在数据配置上，而不是代码逻辑上。所以，如果这个系统你后期要拿去填数据或演示，食材基础数据的质量直接决定了推荐结果的合理性。
7. 系统性优化与后续扩展方向
系统跑通之后，不要急着收工。实际教学中我观察到，能拿优秀等级的毕设，往往是在基础功能之外做了额外的工作。哪怕你只做了一点点扩展，答辩时展示出来的效果也完全不一样。
最容易做的一个扩展是健康报告导出功能。用 POI 库把用户的血糖分析结果、饮食推荐方案、体重变化趋势导出成 PDF 或者 Word 文档，让用户下载下来打印或者分享给医生。这个功能代码量不大，但实用价值很高，而且能体现你对数据落地的思考。具体实现上，创建一个 ReportService，将数据填充到模板中，调用 POI 的 API 生成文档，再把文件流返回给前端。
另一个值得做的扩展是合理的用户反馈机制。在食疗推荐页面，你可以增加一个“对本次推荐满意吗”的评价按钮，把用户反馈收集起来存到数据库。这些反馈数据可以用来做后续的推荐效果分析，甚至可以用简单的统计方法验证推荐逻辑的有效性。这对于有“机器学习”背景诉求的毕设题目来说，是一个跟 AI 方向对接的引子。
如果你后续想把这个系统往“智能化”方向推，可以考虑引入聚类算法。目前推荐逻辑基于的是硬编码规则，优点是可控、可解释性强，但缺点是缺乏个性化。实际情况下，同样是空腹血糖偏高，体重偏胖和体重正常的患者，适合的饮食方案其实差异很大。用 K-Means 或者 DBSCAN 把相似的用户聚成一类，再针对每个类配置不同的推荐规则，整个系统的智能化程度就上了一个台阶。
说到这个话题，我顺手推荐一个后续进阶的路径：把用户数据攒到一定量级之后，用轻量级机器学习库（比如 Weka）跑一个简单的分类器，预测用户的血糖变化趋势。虽然业务上一个规则引擎可能已经足够了，但是加上这个部分，项目从“管理系统”就升级成了“智能辅助决策系统”，性质完全不同。
8. 最后的实操建议
这套系统从构思到最终跑通，我捋了一遍，最难的点其实不是代码，而是“业务理解”。很多同学做毕设，上来就找代码、建表、写接口，结果写到最后发现完全不知道自己在做一个什么系统。跳出来先想清楚“糖尿病患者到底需要什么”，再动手写代码，很多设计决策就会自然浮出水面。
如果你打算基于这套系统做二次开发，我的建议是：优先打磨推荐模块的逻辑，扩充食材库，把数据做扎实，而不是花大量时间调整按钮的样式。毕竟这是一个以“功能”和“逻辑”取胜的系统，界面只要干净、清晰、布局合理就足够了。你贴出“推荐系统背后有 BMR 计算 + GI 值过滤 + 热量拆分三层逻辑”的时候，评委的关注点就已经完全转移到方案本身了。
源码和数据库脚本我已经打了压缩包，里面还配了一个简单的部署说明文档，有需要的直接来拿就行。拿到之后自己跑一遍，遇到问题可以在评论区留言，我看到会回复。后面我还会拆解几个类似体量的毕业设计项目，比如校园失物招领系统、闲置物品交易平台那些，都是同一个套路，文章里写清楚核心逻辑，你们自己改改就能用。