基于Spring Boot的老年人饮食健康档案管理系统实现

前阵子帮一个社区做信息化改造的调研发现他们的老年人饮食健康档案还停留在一张手写出入的纸质表格上。老人今天吃了什么、食堂给不给高血压老人少盐餐、护理员换班后还记不记得哪位老人对花生过敏这些信息全靠人的记忆和纸面流转。后来我用Spring Boot搭了一套基于Java Web的老年人饮食健康档案管理系统把档案、饮食记录、健康指标这几条线串在一起社区的工作人员才真正从翻本子里解放出来。这篇博文把整个项目的设计和实现过程拆开聊聊从需求分析、表结构设计到核心接口落地再到几个让我印象深刻的坑希望能给打算做类似管理系统的人一些参考。1. 这个项目解决的真实痛点老年人的吃为什么需要数字化1.1 和普通餐饮系统的本质区别为什么选老年人饮食健康这个切入点因为在调研时你会发现面向老人的饮食管理体系和普通餐饮系统完全不是一回事。普通餐饮系统的核心是卖出去什么订单、库存、收银三类表一搭流程就通了。但老年人的饮食健康档案核心是吃进去的东西对老人身体意味着什么。第一个要命的地方是慢性病禁忌。高血压老人要低盐糖尿病人要控糖痛风患者要避开高嘌呤食物。而且这些禁忌是动态变化的不是建档案时填一次就结束了。用纸面记录的时候最怕的就是护理员换班新人不知道张大爷不能吃花生误给了含花生的点心这种事故在社区食堂不是没发生过。第二个痛点是长期追踪。老人今天的饮食状态单看一天没有任何意义要看一周、一个月的变化趋势是不是最近食欲下降了体重是不是连续跌了一个月血压有没有因为饮食调整而趋于稳定这些信息散落在纸质表格里时根本没法做趋势分析更谈不上及时干预。第三个痛点是风险预警。一位老人今天没来食堂吃饭是有人代买还是身体不适系统如果能在晚间自动扫描出今日无任何饮食记录的老人提醒工作人员电话回访这种功能在纸面流程里是完全不可想象的。所以在需求梳理阶段我不建议直接抄网上那些通用管理系统的模板。和项目方的前两次需求会重点聊的都不是功能而是三个问题老人出了状况最早可能由谁发现目前是靠什么方式发现的哪些环节最容易断把这三个问题聊透功能清单自然就出来了老人档案、饮食禁忌、每日饮食记录、健康指标、异常预警外加基础的账户权限。这套清单拿出去对方的第一反应是对我们缺的就是这个。1.2 用户画像系统其实是给护理员和家属用的系统名义上叫老年人饮食健康档案管理系统但实际操作者主要是护理员、食堂工作人员和老人家属。老人自己几乎不会打开电脑去提交表单坦白讲让80岁的老人自己去录今天吃了几两米饭这活儿在现实里根本不可行而且存在明显的数字鸿沟。所以设计上要遵循一个原则操作路径越短越好。护理员给老人打饭时手机上用一个页面就能完成今日早餐已打卡配餐人员修改禁忌清单时下拉选择器尽量少滚动。凡是面向老人本人的界面字号要大、按钮要大、一句话能说明白的事绝不放三行提示。这个系统最典型的应用场景是社区食堂和居家养老服务中心白天老人来食堂吃饭工作人员在系统里看到他的饮食禁忌和今日营养摄入情况晚上护理员查房时把当日饮食记录补录完整。家属也可以从远程录入老人居家饮食让照护链条更完整。这个场景决定了数据特征是低频写入、高频查询、长期积累一天最多几百条饮食记录但一条记录要反复查很多次数据要横跨数月甚至数年供营养师和家属做趋势判断。这对技术方案选择有直接影响不需要复杂的分布式架构一台普通服务器加一台MySQL就够但表结构和查询设计必须考虑历史数据的可追踪性。2. 技术选型的取舍为什么这套组合最适合2.1 Spring Boot版本与JDK的实际选择项目用Spring Boot做基础框架基本没有悬念。Java Web项目走到今天Servlet那套手写web.xml、手动打war包的方式不是说不能跑但代码整洁度和开发效率都不适合这种中小型管理系统。Spring Boot版本我选了2.7.18而不是最新的3.x。原因有两个第一个是JDK版本兼容。3.x要求JDK 17起步但很多单位的存量服务器上跑的还是JDK 8社区机房的旧机器更是如此。换成新JDK往往意味着同时升级中间件和运维脚本成本一下子上去。2.7.18是2.x系列的最后一个版本带有大量维护补丁在JDK 8环境下用起来最省心。第二个是生态兼容。很多依赖在3.x里都变了比如javax.servlet换成jakarta.servletSpring Security的配置方式也完全不同。社区项目要的是稳定不是追新。如果是个人的学习项目直接上3.x没问题但如果是给实际运营场景用稳妥压倒一切。2.2 持久层选择MyBatis-Plus的理由持久层我用了MyBatis-Plus。对比一下几种主流方案原生MyBatis要手写大量SQL和ResultMap对这种以CRUD为主、表结构又很明确的系统来说开发效率偏低Spring Data JPA虽然够方便但复杂查询和动态条件的写法比较绕很多人对JPA的懒加载和N1问题也不够熟练。MyBatis-Plus在MyBatis的基础上提供了条件构造器和常规的单表CRUD非常适合字段多但查询条件相对固定的场景。当然MyBatis-Plus不是没有缺点多表关联查询还是得写XML里的SQL。但管理系统80%的操作就是单表条件查询加分页剩下20%的复杂查询手写SQL比在JPA里调试半天来得直接。2.3 前端方案服务端渲染就够前端选了Thymeleaf服务端渲染配合Bootstrap做样式。为什么不搞前后端分离原因很实际这个系统的页面交互复杂度和并发量根本不需要上Vue那套工程化而且服务端渲染天然解决了登录状态共享的问题不用额外做token管理和CORS跨域配置。项目部署也简单打包成一个jar扔到服务器上就能跑。整个架构就是经典的Spring Boot单体式Controller接收请求Service处理业务逻辑Mapper访问数据库Thymeleaf模板渲染页面。看起来不炫但这就是Java Web项目最可靠的形态也是接手人最容易读懂的形态。2.4 数据库与配套工具数据库选了MySQL 8.0。选8.0而不选5.7主要看中几个点窗口函数在写统计报表时能省不少事比如计算老人血压的连续变化JSON字段类型在存储异构的健康指标时很灵活性能在同等配置下比5.7有提升。如果是云数据库8.0已经是各家的默认选项也没有额外成本。配套工具方面接口文档用Swagger分页用MyBatis-Plus内置的分页插件Excel导出用EasyExcel。这套组合的好处是每个组件都有大量现成的踩坑案例网上随便一搜就能找到解决方案对中小型项目的团队非常友好。3. 数据模型设计档案管理的核心是能查能用3.1 五张核心表档案、禁忌、饮食、指标、用户表设计是这类系统的灵魂。一共拆了五张核心表每张表的字段都经过反复斟酌。下面把这次实际用到的表结构整理出来字段含义和设计考量一并说明。老人档案表elder_info是系统的基础一个老人在这里只有一条记录。字段名类型说明idbigint主键雪花IDnamevarchar(50)老人姓名gendertinyint性别1男 2女birth_datedate出生日期phonevarchar(20)联系电话addressvarchar(200)住址emergency_contact_namevarchar(50)紧急联系人emergency_contact_phonevarchar(20)紧急联系人电话chronic_diseasevarchar(500)慢性病史medication_statusvarchar(500)当前用药情况photo_urlvarchar(255)照片地址statustinyint状态1正常 2离世 3转出create_timedatetime创建时间update_timedatetime更新时间饮食禁忌表diet_taboo是预防事故的关键表一个老人可以有多条禁忌。字段包括id、elder_id关联老人、taboo_type过敏/忌口/医嘱禁食、taboo_food具体食材或菜品名称、severity严重程度一般/严重、remark备注比如含花生油的糕点也不行、create_time、update_time。每日饮食记录表daily_diet_record记录老人每顿的饮食情况。字段包括id、elder_id、record_date就餐日期、meal_type早餐/午餐/晚餐/加餐、food_items食材明细用逗号分隔、food_amount摄入量描述如一碗米饭或具体克数、calories估算热量可为空、appetite_status食欲情况较差/正常/较好、operator_id记录人、create_time。健康指标表health_indicator存血压、血糖、体重、心率等数据。字段包括id、elder_id、record_date、record_time、indicator_type指标类型、indicator_value数值、unit单位、remark、create_time。系统用户表sys_user管理账户权限。字段包括id、username、password加密存储、real_name、role角色管理员/护理员/家属/营养师、elder_id家属关联的老人ID可为空、status、create_time。3.2 几个容易忽略的字段设计细节第一饮食记录表里为什么要冗余一个calories字段因为食物摄入量折算热量这件事将来做营养分析可以用但记录的时候算一次比日后拿着食材明细再反推要准确得多。虽然前期可能用不上这个字段却给未来的功能留了扩展点。第二慢性病史这种多值字段为什么用文本存储而不是单独建关联表形式上用文本有点不符合范式但实际使用中工作人员填写时更愿意直接写高血压、糖尿病而不是逐个勾选。这里做了个折中录入界面是多个复选框提交时拼接成带分隔符的字符串展示时再拆分。既保证快速录入也保证查询时可以按关键字模糊匹配。第三也是最容易忽略的所有表都保留create_time和update_time记录类表都带operator_id。这类系统最重要的就是追溯——这条饮食记录是谁在什么时候录的那条健康指标是谁测的。将来做整改检查或理解某条异常数据时这个操作痕迹能省掉无数扯皮。4. 核心功能落地从录入到预警的完整闭环4.1 档案管理模块条件搜索才是重点老人档案管理说起来是增删改查但真正考验人的是查。社区场景下工作人员经常要按姓名、按楼栋、按慢性病类型、按年龄区间组合查询而且支持分页。MyBatis-Plus的LambdaQueryWrapper在这种场景下非常顺手public PageElderInfo searchElders(String keyword, String chronicDisease, Integer minAge, Integer maxAge, int page, int size) { PageElderInfo pageParam new Page(page, size); LambdaQueryWrapperElderInfo wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(keyword)) { wrapper.and(w - w.like(ElderInfo::getName, keyword) .or().like(ElderInfo::getPhone, keyword) .or().like(ElderInfo::getAddress, keyword)); } if (StringUtils.hasText(chronicDisease)) { wrapper.like(ElderInfo::getChronicDisease, chronicDisease); } if (minAge ! null || maxAge ! null) { LocalDate now LocalDate.now(); if (minAge ! null) { wrapper.le(ElderInfo::getBirthDate, now.minusYears(minAge)); } if (maxAge ! null) { wrapper.ge(ElderInfo::getBirthDate, now.minusYears(maxAge)); } } wrapper.orderByDesc(ElderInfo::getCreateTime); return elderInfoMapper.selectPage(pageParam, wrapper); }年龄查询这里藏着一个新手容易犯的错。数据库里存的是出生日期birth_date不是年龄字段age所以查找70岁以上老人要用birth_date 当前日期减去70年而不是直接比较age字段。如果一上来就设计成存年龄第二年年龄就全不对了。4.2 饮食记录模块按天补录和批量操作饮食记录每天每顿都要录入如果让护理员一顿一顿地填操作量大不说还容易漏。所以录入页面设计成按天补录选中某位老人日期默认今天可以分别勾选早餐、午餐、晚餐、加餐四个入口分别填食材和摄入量。后端接口用一个批量保存的逻辑前端传一个JSON数组后端在一次事务里把一天的记录全部写入Transactional public void saveDailyRecords(Long elderId, String recordDate, ListDailyDietRecord records) { LocalDate date LocalDate.parse(recordDate); dietRecordMapper.delete(new LambdaQueryWrapperDailyDietRecord() .eq(DailyDietRecord::getElderId, elderId) .eq(DailyDietRecord::getRecordDate, date)); for (DailyDietRecord record : records) { record.setElderId(elderId); record.setRecordDate(date); dietRecordMapper.insert(record); } }这里先删后插是有讲究的。如果不做幂等处理护理员没注意多点了两次提交一天的数据就会重复先删掉当天已有记录再写入新数据天然保证一天最多一套数据。还有个小技巧前端页面提供了复制上月同日的按钮社区食堂每周的菜谱大差不差护理员能一键把上周某天的记录复制过来再改一两样省下的时间非常可观。4.3 健康指标与异常预警健康指标的录入相对简单但预警逻辑是这个系统里比较出彩的部分。一共做了三条规则。第一条饮食连续缺失预警。如果一位老人当天没有任何饮食记录系统每晚9点自动扫描一次生成一条提醒待办提示工作人员电话回访。这个逻辑用一条定时任务就能实现Scheduled(cron 0 0 21 * * ?) public void scanNoDietRecordToday() { ListElderInfo elders elderInfoMapper.selectList( new LambdaQueryWrapperElderInfo().eq(ElderInfo::getStatus, 1)); for (ElderInfo elder : elders) { Long count dietRecordMapper.selectCount( new LambdaQueryWrapperDailyDietRecord() .eq(DailyDietRecord::getElderId, elder.getId()) .eq(DailyDietRecord::getRecordDate, LocalDate.now())); if (count 0) { alertMapper.insert(new AlertTask(elder.getId(), 今日无饮食记录)); } } }第二条指标超标预警。血压、血糖这类指标录入后系统根据预设阈值自动判断并标记异常比如收缩压超过160。阈值不写死在代码里而是放在配置表里营养师可以按老人的实际情况调整。第三条禁忌关联提示。工作人员在打饭界面录入食材时如果食材命中该老人的饮食禁忌表页面直接弹出红色警告。这个功能逻辑上就是一个exists查询但非常实用也是社区工作人员反馈最不敢出错的功能。预警消息用一张待办表存储工作人员处理完就标记已处理没处理的在首页的告警面板里滚动展示。一开始有人建议用短信或微信通知但考虑到成本和管理人员的习惯先做站内待办运营顺畅后再考虑接入消息推送。4.4 报表导出EasyExcel的轻量实现运营方月底要一份《老人饮食健康汇总表》包括每位老人本月饮食记录条数、体重变化、异常指标次数。最开始用Apache POI写API太啰嗦内存占用也偏高。后来换成了EasyExcel注解式配置简单明了ExcelProperty(老人姓名) private String name; ExcelProperty(本月饮食记录次数) private Long recordCount; ExcelProperty(体重变化(kg)) private Double weightChange;生成报表时按月份分sheet一个sheet放一类的数据。这里有个坑必须提醒导出文件名如果是中文很多浏览器会出现乱码需要把HTTP头的Content-Disposition做一下URL编码处理String fileName URLEncoder.encode(老人饮食健康月报.xlsx, UTF-8); response.setHeader(Content-Disposition, attachment; filename fileName);5. 开发路上踩过的坑翻车记录与排查思路5.1 分页插件不生效第一个坑是MyBatis-Plus分页插件配置后不生效。现象是列表页返回的total永远是0数据明明有十几条。排查链路分成三步。第一步确认Mapper层有没有传Page参数。方法签名写的是selectPage(pageParam, wrapper)这个没问题。第二步检查配置类发现漏掉了分页拦截器的注册。MyBatis-Plus的新版本不支持只引入依赖就自动分页必须手动注入Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }配置补上之后total还是不对。第三步才发现前端传的pageSize参数名没对齐导致用的是默认分页大小10条后端接收的Page对象没有拿到正确的size值。排查到这一步问题定位为参数绑定问题。两层原因叠在一起最初是拦截器缺失导致total0后来是参数名不一致影响了数据量。这类问题给我一个习惯遇到分页异常先检查拦截器是否注册再检查参数是否传到Service层这两步能解决九成问题。5.2 LocalDateTime序列化前后端格式错乱第二个坑是前后端时间格式不一致。Spring Boot默认会把LocalDateTime序列化成ISO格式的字符串比如2025-01-15T10:30:00中间那个T在页面上很碍眼而且和前端日期控件回显格式对不上导致编辑页永远无法正常显示。刚开始以为是前端控件的问题换了两个日期控件都不行。后来打开浏览器Network面板看到响应体里确实是2025-01-15T10:30:00这种带T的格式才确认是后端序列化问题。解决方案是在application.yml里统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8再给实体类的时间字段加一个兜底注解JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private LocalDateTime createTime;这个配置一定要放在全局配置里不要只给个别字段加注解否则其他接口返回的时间格式还是不统一。5.3 MySQL连接串没声明时区导致时间差8小时第三个坑和上一个有点关联但发生在数据库连接层。项目启动后一切正常但往daily_diet_record表里插入数据时数据库存储的时间比本地时间少了8个小时。查下来是数据源连接串没有声明时区MySQL 8.0默认使用的serverTimezone是UTC而本机在东八区。解决方式是连接串上加上serverTimezoneAsia/Shanghaispring: datasource: url: jdbc:mysql://localhost:3306/elder_health?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/Shanghai这个教训的价值在于凡是遇到时间字段差8小时的问题先不要怀疑代码大概率是时区配置。之后我做任何新项目数据源配置里的时区都是优先写好的。5.4 Excel导出遇到的编码与内存问题用POI导出大批量数据时遇到过内存溢出的问题。虽然社区老人可能不到一千人但导出整年的饮食记录就是几十万行POI的SXSSFWorkbook处理起来性能不佳。切到EasyExcel之后用流式写出内存占用一下子降下来了。还有文件名的中文编码问题前面已经提到过。再有就是导出接口要注意设置响应头的Content-Type为application/octet-stream否则个别浏览器会直接在内页里打开乱码的文本。6. 做了这个项目之后我的一些实际复盘6.1 最值得记住的经验这个系统从需求梳理到上线跑了快两个月回看有几个体会非常深。先理业务再写代码。最开始我差点一上来就建表后来强制自己花了两天做需求梳理把饮食禁忌如何动态调整预警消息谁处理、怎么处理这类问题全部过了一遍后面的开发反而顺畅很多。表结构中途只改过一次就是给健康指标表增加了unit单位字段其他都没有返工。架构尽量简单。这个项目用到的技术点没有一项是高精尖Spring Boot、MyBatis-Plus、MySQL、Thymeleaf全是Java Web的常规配置。但正是这种常规配置让项目稳定运行也让别人接手时几乎零门槛。后来团队里另一个同事接手这个项目做二次开发半天就看完了代码结构。时间处理一定要统一。要么全部用Date要么全部用LocalDateTime不要混用所有接口的时间格式统一走全局配置数据库时区、Jackson时区、系统默认时区三者必须一致。现在这个规范已经写进了团队的项目检查清单。6.2 值得考虑的扩展方向如果这个系统要往下演进三个方向我觉得大概率会被提出来。一是结合营养数据库做分析和建议。目前饮食记录里的food_items还是文本将来接一个食物成分表把每餐的蛋白质、脂肪、碳水算出来就能生成周报式的营养分析甚至可以给糖尿病、高血压老人给出调整建议价值会非常明显。二是增加面向家属的可视化页面。家属关心的是爸妈这周吃得好不好、体重有没有波动可以让家属用只读账号查看趋势图和最近异常提醒减少管理人员和家属的线下沟通成本。三是接入消息通知渠道。等站内待办跑顺之后可以接短信或公众号模板消息把今日有老人未就餐这类预警直接推给对应值班人员。这一步要等运营数据积累后再考虑因为推送策略需要根据实际使用频率来定。6.3 系统开发中最重要的分页与权限细节给同样在做管理系统的人提两个容易忽视的细节。第一个是分页查询时前端一定要传pageNum和pageSize两个参数并且后端要做参数校验pageNum不能小于1pageSize不能太大否则会有人通过构造超大size参数一次性查出全表数据既影响性能也有数据泄露风险。第二个是用户权限不能只做菜单隐藏。虽然这个系统简单但接口层面如果没做角色校验知道接口路径的人可以直接调用。建议至少用Spring Security或者一个简单的拦截器校验每个请求的登录状态和角色权限。社区场景下这种风险可能不会立刻显现但一旦暴露就是责任事故该防的还是得防。我在实际交付后最大的体会是项目方拿到系统后不关心你用了哪个框架只关心张大爷明天午餐能不能从系统里看到少盐提醒月底我要的报表是不是一键就能导出来。把这些细节做好这个项目才算真正落地。使用这套Spring Boot方案前期花点时间把表结构和业务规则理顺后面的开发会轻松很多这也是我从这个项目里获得的最大收获。