简介：面向Java开发者和健康管理应用初学者，这款基于Java平台的老年人健康管理应用设计源码，完整展示了从用户登录到健康数据分析的落地实现。项目围绕用户登录、健康数据录入、数据整理分析、个性化建议生成等核心功能，采用Controller-Service-Mapper三层架构，覆盖血压、血糖、心率等指标的采集与可视化展示。压缩包共36个文件，以30个Java源文件为主，辅以3个XML配置、Git忽略文件、项目模块文件及说明文档，整包仅120KB，目录结构清晰，便于快速定位。源码按bean、mapper、controller、service等分包组织，涉及用户、药品、检查、用药等多个业务模块，还包含用户界面设计和业务逻辑处理代码，完整度较高。已有260人浏览学习，适合用于课程设计、毕业设计或Java项目实战参考，可帮助理解老年人健康管理的业务闭环、数据流转方式与工程化代码组织思路。
1. 数据分层的健康管理应用：先把结构立住
人口老龄化让健康管理从一个概念变成了具体工程问题，而这个问题的复杂度并不在算法，而在数据流怎么组织：血压、血糖、体检报告、用药记录分属不同采集频率，又都挂在同一个老人名下。基于Java平台的这套老年人健康管理应用设计源码，用30个Java文件把注册登录、健康数据录入、风险提示、用药与检查记录完整串了起来，适合正在跟Java Web项目、想理解Controller-Service-Mapper分层和关联查询边界的开发者。源码包共35个文件，readme.txt里写明了项目说明，7个Mapper按业务域拆分，这一点可以直接借鉴到其他Java项目里。
2. 模块划分与分层设计：从30个Java文件看职责边界
拿到源码压缩包，第一件事不是打开IDE，而是先把Java文件按包归类。外层结构很清晰，包名已经说明了职责：bean包存放数据载体，controller包处理请求入口，service包承载业务逻辑，mapper包负责数据访问。这样的命名规范意味着所有者可以按文件名直接定位到某一层，排查问题的范围会小很多。
2.1 从类名对应关系反推业务模块
把源码里的类和数据库操作映射关系整理出来，可以得到一张完整的模块表。user_info表为核心，health_info存日常健康指标，exam_info存检查报告，medication_info存用药计划，correlation_info存跨模块的关联结果。
| 业务模块 | Controller | Service | Mapper | Bean |
|---|---|---|---|---|
| 用户管理 | UserController | UserService | UserMapper | UserInfo |
| 注册链路 | RegisterController | RegisterService | RegisterMapper | UserInfo |
| 健康指标 | HealthInfoController | HealthInfoService | HealthInfoMapper | ElderhealthInfo |
| 检查报告 | ExamController | ExamService | ExamMapper | ExamInfo |
| 用药管理 | MedicationController | MedicationService | MedicationMapper | MedicationInfo |
| 药品字典 | MedicineController | MedicineService | MedicineMapper | MedicineInfo |
| 关联查询 | CorrelationController | CorrelationService | CorrelationMapper | CorrelationInfo |
| 登录认证 | LoginController | UserService | UserMapper | UserInfo |
注意RegisterMapper和UserMapper同时存在。RegisterMapper承载用户名查重和注册写入，UserMapper承载登录校验和用户信息维护，职责分离的收益在后续扩展时体现：注册链路要做图形验证码时，只改RegisterMapper和RegisterService，不影响登录侧。
2.2 一次健康数据保存的完整调用链
Controller、Service、Mapper三层之间调用关系如下：Controller接收请求，Service做业务处理，Mapper只负责单表读写。以健康数据保存为例，常见的实现方式是这样的：
// HealthInfoController.java @RestController @RequestMapping("/health") public class HealthInfoController { private final HealthInfoService healthInfoService; @PostMapping("/save") public Result save(@RequestBody HealthInfo healthInfo) { // Controller 只做参数接收与结果包装，不写业务判断 return healthInfoService.saveHealthInfo(healthInfo); } }// HealthInfoService.java public Result saveHealthInfo(HealthInfo healthInfo) { // 1. 补全业务字段 healthInfo.setRecordDate(new Date()); // 2. 交给 Mapper 落库 healthInfoMapper.insert(healthInfo); // 3. 返回带主键的结果 return Result.ok(healthInfo.getId()); }典型的业务链路如下：前端提交JSON，Controller绑定到HealthInfo对象，Service层补录时间戳与用户ID，Mapper执行INSERT。注意Service层在这一步没有做健康数据区间判定，因为判定逻辑属于另一层职责，减少耦合。
提示：如果Controller里出现了SQL拼接、日期格式化、循环判断，说明业务逻辑放错了位置。正确的做法是Controller保持单薄，复杂判定下沉到Service层。
2.3 分层乱掉的常见信号
分层设计最大的风险不是不会分，而是分着分着就乱了。观察源码里这些类名能看出原作者有意维持边界，但实际项目里最常见的误用有三种：Service层直接返回Mapper查询结果，没有任何业务加工，整层变成透传；Controller里同时操作多个Mapper，绕过了Service层的聚合能力；Bean里夹杂数据库字段以外的展示字段，导致表和前端耦合。如果发现你的项目里出现了这些信号，需要及时重构。
3. Mapper层映射与Correlation关联查询的具体写法
源码包里7个Mapper接口分布在src/mapper目录，这层是数据访问的大门。理解这层代码的关键在于一个判断：哪些查询应该走单表映射，哪些必须走关联SQL。拆分依据不是表数量，而是查询场景。
3.1 单表Mapper的标准实现与基础配置
以UserMapper为例，常见的单表查询用XML或注解实现。下面给出XML方式的常见写法：
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> <mapper namespace="com.health.mapper.UserMapper"> <select id="findByUsername" parameterType="string" resultType="com.health.bean.UserInfo"> SELECT id, username, password, salt, real_name, age, phone FROM user_info WHERE username = #{username} </select> </mapper>Java接口中对应的方法是UserInfo findByUsername(String username)，底层通过MyBatis的Mapper代理机制，将接口方法名与XML中select的id绑定。#{username}是预编译占位符，相比字符串拼接能防止SQL注入。resultType指定返回类型，前提是数据库下划线字段与Java驼峰属性映射正确，需要在MyBatis配置中开启mapUnderscoreToCamelCase=true，否则real_name查出来赋值不到realName上。
3.2 CorrelationMapper的设计：一次查询聚合多模块数据
Correlation是这个项目中较有信息量的部分。CorrelationController调用CorrelationService，最终落到CorrelationMapper的关联查询上。核心场景是：主页要展示某位老人某一天的健康档案，需要同时看到血压、血糖、检查结论、用药计划。如果分四次查询再在Service里组装，会产生多次网络往返。
SELECT u.id AS userId, u.real_name AS realName, h.systolic_pressure, h.diastolic_pressure, h.blood_sugar, e.result_summary, m.medication_name, m.take_time FROM user_info u LEFT JOIN health_info h ON h.user_id = u.id AND h.record_date = #{queryDate} LEFT JOIN exam_info e ON e.user_id = u.id AND e.exam_date = #{queryDate} LEFT JOIN medication_info m ON m.user_id = u.id AND m.plan_date = #{queryDate} WHERE u.id = #{userId}这段SQL用三个LEFT JOIN分别关联健康指标、检查报告、用药记录。为什么要用LEFT JOIN而不是INNER JOIN？因为某一天老人可能没测血压，但吃了药，INNER JOIN会把用药记录也丢掉。两个细节值得注意：关联条件里带上日期过滤，避免先全表JOIN再过滤造成的中间结果膨胀；查询条件里的userId从登录会话中获取，不信任前端传参。
提示：关联查询不是越多越好。当JOIN超过两张表且出现大量重复数据时，拆成多次单表查询再在Service层用Java内存聚合，往往更快。决定用哪种方式之前，先看一眼执行计划。
3.3 驼峰映射、别名与分页的实战坑位
关联查询中最容易翻车的点有两个：重复列名和分组问题。上面的SQL中已经为每个字段起了别名，避免resultType映射时找不到列。分页方面，单表查询常见做法是LIMIT #{offset}, #{pageSize}，这里的offset不是页码而是偏移量，计算方式是(pageNum - 1) * pageSize。
另一个常被忽视的问题是N+1查询。在循环里调用Mapper查详情，比如遍历10个老人每人查一次关联健康数据，会产生1条主查询加10条子查询共11次数据库往返。常见的解决方案是：先用IN查出基本信息，再在Service里按userId分组后内存组装。这也是CorrelationService中相对Java基础且代码量较多的部分。
4. 健康数据判定与建议生成的核心业务逻辑
健康管理应用跟普通CRUD项目的最大区别在于业务逻辑层必须能回答问题：血压多高算异常？异常了给什么建议？这套逻辑在源码里主要落在HealthInfoService和CorrelationService中，原理难度不高，但边界条件多。
4.1 指标范围表的设计与选取依据
健康指标判定的第一步是定义范围。常见的参考区间如下表，注意这些数值仅用于演示业务逻辑，不能替代医生诊断。
| 指标 | 字段名 | 正常范围 | 警告条件 |
|---|---|---|---|
| 收缩压 | systolic_pressure | 90-139 mmHg | 高于等于140 |
| 舒张压 | diastolic_pressure | 60-89 mmHg | 高于等于90 |
| 空腹血糖 | blood_sugar | 3.9-6.1 mmol/L | 高于等于7.0 |
| 静息心率 | heart_rate | 60-100 次/分 | 高于100或低于50 |
4.2 血压判定代码的写法与优先级
下面是一段从HealthInfoService中常见的判定逻辑，采用逐级判断，先拦截高风险，再处理轻度异常：
// HealthInfoService.java public HealthAdvice evaluateBloodPressure(int systolic, int diastolic) { if (systolic >= 180 || diastolic >= 110) { return new HealthAdvice(Level.HIGH_RISK, "血压达到危险水平，请立即联系家人或拨打急救电话"); } if (systolic >= 140 || diastolic >= 90) { return new HealthAdvice(Level.WARNING, "血压偏高，连续三天同一时段复测，减少盐分摄入"); } if (systolic < 90 || diastolic < 60) { return new HealthAdvice(Level.WARNING, "血压偏低，注意起身动作放慢，避免体位性低血压"); } return new HealthAdvice(Level.NORMAL, "血压处于正常范围，保持当前作息规律"); }判定顺序有讲究：先判危险水平再判偏高偏低，最后返回正常。如果把正常判断写在开头，高风险场景就会被提前短路。Level使用枚举而不是字符串常量，避免魔法值散落各处。这里的输入参数是用户当天录入值，在进入判定前需要确保非空且是合法数字，否则会出现空指针异常。
4.3 警告去重与频次控制
连续多次警告对老年用户是打扰而不是帮助。早晨量血压偏高，系统提醒一次就够了，如果每次保存记录都弹警示，用户可能放弃录入。常见的做法是在警告逻辑中增加时间窗口控制：
// 30 分钟内同一指标不重复报警 private static final long WARNING_INTERVAL_MILLIS = 30 * 60 * 1000L; public boolean shouldAlert(int userId, String metricKey, long nowMillis) { String cacheKey = userId + ":" + metricKey; Long lastAlertAt = alertCache.get(cacheKey); if (lastAlertAt == null || nowMillis - lastAlertAt > WARNING_INTERVAL_MILLIS) { alertCache.put(cacheKey, nowMillis); return true; } return false; }这段代码的本质是把「是否提醒」从业务判断中剥离出来，用一个时间戳缓存控制频次。实际项目中alertCache可以替换为Caffeine或Redis，规则抽成配置项后，调整提醒频率不需要重新编译。
4.4 周维度报告怎么聚合
日常健康管理不能只看单次测量，一周趋势比单次数值更有参考意义。常见的实现是在HealthInfoService中增加周报告聚合：查出最近7天记录，按指标分组求平均值，再用平均值调用一次判定逻辑。这样做的好处是复用单次判定代码，缺点是丢失了波动幅度信息，血压从120飙到150再回到120，平均值可能显示正常。更稳妥的做法是同时返回最大值和波动次数。
5. 注册登录链路：从RegisterMapper到LoginController的认证实现
注册、登录、会话保持这条链路涉及RegisterMapper、UserMapper、LoginController、IndexController四个类，虽然功能常见，但源码里的模块划分方式值得展开：注册和登录使用不同的Mapper接口，密码处理逻辑独立成方法。
5.1 注册流程中的用户名查重与密码加盐
注册链路的核心逻辑在RegisterService中，至少包含三步：用户名查重、密码加盐哈希、写入新用户。常见实现如下：
// RegisterService.java public Result register(UserInfo user) { // 1. 查重，避免并发注册相同用户名 if (registerMapper.countByUsername(user.getUsername()) > 0) { return Result.fail("用户名已存在"); } // 2. 生成随机盐值，计算哈希 String salt = generateSalt(); String hashed = sha256(user.getPassword() + salt); user.setSalt(salt); user.setPassword(hashed); // 3. 落库 registerMapper.insert(user); return Result.ok(); }这里的核心是加盐哈希处理。直接对密码做MD5或SHA-256不安全，因为彩虹表已经覆盖常见弱口令。加盐的作用是让同一个密码在不同用户下产生不同哈希值。generateSalt用SecureRandom生成16字节随机数即可，sha256可以用JDK自带的MessageDigest，不要自己写加密算法。Java基础里最常见的错误是用字符串拼接盐值时忽略编码问题，固定用UTF-8。
5.2 登录校验与会话保持
登录逻辑在LoginController中，流程是：接收用户名密码，调用UserMapper查询用户信息，取出盐值重新计算哈希比对，一致则建立会话。代码段如下：
// LoginController.java @PostMapping("/login") public Result login(@RequestBody LoginRequest request, HttpSession session) { UserInfo user = userMapper.findByUsername(request.getUsername()); if (user == null) { return Result.fail("用户不存在"); } String hashed = sha256(request.getPassword() + user.getSalt()); if (!hashed.equals(user.getPassword())) { return Result.fail("密码错误"); } session.setAttribute("currentUser", user); return Result.ok(user); }这里有两个常用做法值得注意：比对哈希时用MessageDigest.isEqual而不是字符串的equals，后者在哈希值不匹配时立即返回，存在时间侧信道风险；会话建立后其他接口通过session.getAttribute获取当前用户，前端传任何userId参数都不作为信任依据。如果走的是前后端分离架构，这里可以替换为JWT或Token方案，生成随机token存Redis并设置过期时间。
提示：登录接口不要返回完整UserInfo对象，至少去掉salt字段，否则密码盐值直接泄露给前端。
5.3 登录失败次数限制与空值边界
暴力破解是登录接口绕不开的问题，RegisterService和LoginController里如果完全没有失败次数限制，接口很容易被脚本刷。常见的轻量实现是维护一个登录失败计数器：连续失败5次锁定10分钟，锁定时长和次数阈值抽成常量，用ConcurrentHashMap存储计数。这个实现不依赖外部存储，重启后计数清零，对单体应用够用。真正需要留意的边界是：user为null时先返回用户不存在，再返回密码错误，两种返回信息分开会导致用户名可枚举，安全要求高的场景应统一为「用户名或密码错误」。
6. 源码包还原、运行验证与三个扩展点
最后这章落地到实操。拿到压缩包后运行不起来的原因通常不是代码问题，而是目录结构和环境配置不一致。
6.1 还原标准工程目录
源码包里的文件是平铺的，需要恢复成Maven或Gradle标准布局。使用如下命令：
mkdir -p src/main/java/com/health/{bean,controller,service,mapper} mkdir -p src/main/resources/mapper mv bean/*.java src/main/java/com/health/bean/ mv controller/*.java src/main/java/com/health/controller/ mv service/*.java src/main/java/com/health/service/ mv mapper/*.java src/main/java/com/health/mapper/ mv src/mapper/*.xml src/main/resources/mapper/执行完检查readme.txt里声明的JDK版本和数据库连接参数，缺pom.xml时手动创建一个Spring Boot或纯Servlet依赖的pom文件。注意Main.java所在包路径决定了Spring Boot的扫描根目录，启动类放错位置会导致Controller全部404。
6.2 数据库初始化与启动验证
根据Mapper方法名反推，至少需要user_info、health_info、exam_info、medication_info、medicine_info五张表。常见的初始化方式是在MySQL中先建库再导SQL：
CREATE DATABASE IF NOT EXISTS elder_health DEFAULT CHARACTER SET utf8mb4;连接串务必加上useUnicode=true&characterEncoding=utf8，否则中文用户名和健康备注写入后乱码。启动Main.java后依次验证五步：注册一个测试用户；用该用户登录；录入一条血压和血糖；查询当天关联档案；重启应用再次查询确认数据已落库而不是存在内存里。
6.3 三个可以直接落地的扩展点
项目预留的扩展方向很明确，其中用药提醒最优先。在MedicationService中添加定时任务，每天8点查询当天需要服药且尚未标记已服用的记录，生成提醒列表。Spring环境下用@Scheduled(cron = "0 0 8 * * ?")即可，这个cron表达式从左到右依次是秒、分、时、日、月、周，?表示不指定具体星期几。定时任务不要在Controller里用线程池实现，服务重启后线程丢失且无法统一管理。
第二个扩展点是关联查询的可视化。把CorrelationMapper的结果集转换成前端图表数据时，注意用LinkedHashMap保证字段顺序，避免JSON序列化后字段位置随机。第三个扩展点是远程问诊，源码中的CorrelationService已经聚合了用户健康档案，扩展时只需要增加一个问诊记录表，再把关联查询的结果作为附件传给医生端接口。三个扩展点都不需要改动已有的健康判定逻辑，这是当初按模块拆分Mapper的红利。
本文还有配套的精品资源，点击获取
