SpringBoot社区老人健康管理系统：从数据库到部署全解析

最近不少同学在找“社区老人健康管理系统”这类毕设项目，网上能搜到的代码仓库看起来不少，但真正结构清楚、能跑通、还能附带完整文档的，确实需要挑一挑。我这里说的这套，是基于SpringBoot的社区老人健康管理系统，我本地完整跑通过，从数据库初始化、登录鉴权到体检数据上传、定时用药提醒，链路都摸了一遍。这篇文章不是写广告，而是把源码和文档背后的设计思路、表结构、关键实现、部署步骤，以及那些只有真正动手才会踩到的坑，一次性讲清楚。

如果你正在做Java毕业设计，或者想通过一个完整项目把SpringBoot、MyBatis-Plus、Redis、JWT这些技术串起来，这篇内容可以直接当“实习笔记”看。下面我按项目落地的顺序来拆。

1. 项目整体设计与技术选型思路

1.1 社区老人健康管理系统到底解决什么问题

做项目之前先别急着写代码，想清楚场景比什么都重要。社区老人健康管理的痛点很具体：老人分散在各个小区，社区工作人员上门登记纸质档案效率低，体检报告散乱，家人对老人的健康变化不清楚，社区医生又很难持续跟踪慢病情况。

这套系统要解决的，就是把“纸质档案+手工登记”变成“数字化档案+持续跟踪”。核心业务可以浓缩成一条闭环：老人建档、体检数据录入、健康指标异常预警、用药提醒、家属或社区医生查看跟踪。围绕这条闭环，再去设计模块和页面，就不会出现“做了一个管理系统但不知道管理什么”的空洞感。

这个系统适合的人群也很明确：Java方向的高校毕业生、想积累SpringBoot实战经验的初学者、以及需要给社区或养老机构做内部健康管理小系统的技术同学。对于毕设来说，它的业务复杂度刚刚好——既不是一个“简单增删改查”的项目，也不会复杂到几个人都写不完。

1.2 技术栈为什么这么选

技术栈的选择直接决定开发效率和答辩说服力。这套系统推荐的核心组合是：SpringBoot + MyBatis-Plus + MySQL + Redis + MinIO（或本地存储），前端可以用Thymeleaf配合Bootstrap，也可以单独用Vue3做前后端分离。

SpringBoot版本这里值得多说一句。我建议优先选择SpringBoot 2.7.x系列，搭配JDK8或JDK11。原因很实际：大部分毕业设计答辩环境不会专门装最新JDK，2.7.x对javax命名空间、旧教程和插件兼容性都很好。如果你非要上SpringBoot 3.x，那就要用JDK17，并且要注意javax.servlet要改成jakarta.servlet，很多网上老代码会直接报错。用新不用旧没有错，但稳定性优先。

MyBatis-Plus比原生MyBatis更适合这类项目的理由，就是开发效率。单表CRUD不用写XML，自带分页插件，逻辑删除、自动填充字段都有现成注解。社区老人健康管理的表结构大多是单表操作加简单关联查询，用MyBatis-Plus能把工作量降一个档次。至于为什么不选JPA，我只能说，对于这种业务，JPA的实体关系映射反而增加了学习成本和不确定性。

Redis在这个项目里不是主角，但很有存在感。登录验证码、Token黑名单、老人列表页的缓存，都可以交给Redis。注意一点，本地开发时Redis必须启动，否则项目启动可能报连接超时。MinIO则是用来存体检报告图片或PDF的，如果不想多维护一个中间件，初期可以用本地磁盘目录加静态资源映射，后面我会给两种方案。

1.3 项目目录与模块规划

我见过不少同学把Controller、Service、Mapper、Entity堆在四个包里就开写，结果两三百行代码之后就乱了。对于这种管理类系统，单模块Maven工程足够，但一定要按功能包拆分，而不是按技术层次铺开。

推荐的结构形态是这样：

com.example.health ├── config // 配置类，比如跨域、拦截器、MyBatis-Plus分页配置 ├── controller // 接口层 ├── service // 业务层 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 请求和响应对象 ├── common // 统一返回结果、异常处理、常量 └── utils // JWT工具、日期工具等

模块划分上，我会把系统拆成三个端：管理后台、社区医生端、老人或家属端。管理后台负责老人档案管理、用户管理、数据统计；社区医生端负责录入体检数据、查看异常预警、处理随访任务；老人端或家属端主要看健康档案和用药提醒。这样拆完之后，每个模块内部再做Controller和Service，代码结构就非常清楚。答辩时老师问“你的系统有哪些角色、每个角色能干什么”，你按模块讲三分钟就够了。

2. 核心功能拆解与数据库设计

2.1 梳理核心业务表

数据库表的设计决定了这套系统能走多远。先看常规做法：一个“老人档案表”存基本信息，一个“体检记录表”存每次体检的项目结果，一个“慢病管理表”记录高血压、糖尿病这类长期跟踪项，外加“用药提醒表”和“预警记录表”。另外还需要用户表、角色表，甚至菜单权限表，用于登录和权限控制。

表面上看表不多，但每张表的字段要设计合理。比如老人档案表里，紧急联系人、过敏史、既往病史、是否独居、社区网格员这几项，是社区场景特有的关键字段，一定要有。体检记录表里，除了血压、血糖、心率、身高体重这些常规指标，还要记录体检日期、录入医生、医生备注。用药提醒表则要区分药品名称、剂量、频次、提醒时间、是否已确认。

2.2 关键表结构示例

老人基础信息表可以这样设计：

体检记录表的核心字段包括：elderly_id、checkup_date、height、weight、heart_rate、blood_pressure_high、blood_pressure_low、blood_sugar、cholesterol、uric_acid、bmi、doctor_remark、doctor_name。注意这里bmi其实可以由身高体重计算出来，但存储下来可以方便历史对比，不需要每次查询都现场算。

索引设计容易被忽略，但很重要。id_card、phone这种查询条件字段，建议加普通索引，不然数据量上来之后，条件查询会有明显的性能问题。用MyBatis-Plus逻辑删除时，记得在表里加deleted字段，并在实体上使用@TableLogic注解。

2.3 健康指标预警体系的设计

健康预警是这套系统的“灵魂”。体检数据录进去之后，要能和正常范围比对，超出阈值就生成一条预警记录，并推送给相关角色。

具体实现上，不建议把阈值硬编码死，建议做一个预警配置表或者干脆用常量类维护。比如血压分级：收缩压大于等于140mmHg或舒张压大于等于90mmHg判定为异常偏高；血糖空腹大于7.0mmol/L为异常。每次新增体检记录时，通过一个规则判断方法，将异常项写入health_alert表，预警记录可以关联老人、异常指标、实际值、正常范围、严重等级、处理状态。

这里有个细节，预警不是生成就结束了，社区医生还需要对预警做“处理回执”，比如“建议复查”“已电话沟通”“转诊”。这样整个闭环才算完整。如果有短信或邮件推送需求，可以用Spring事件发布机制，在预警生成后异步发送通知，避免阻塞主流程。

2.4 多角色权限模型怎么做

这类系统角色至少分三种：系统管理员、社区医生、老人家属。权限模型建议用RBAC，角色表、菜单表、角色菜单关联表、用户角色关联表都属于常规配置。

后端接口层面，我建议使用Spring Security或者更轻量的Sa-Token来实现登录鉴权，也可以直接用JWT加拦截器。毕业设计阶段，如果不想引入太重的东西，JWT配合HandlerInterceptor是最好理解的方式。前端根据登录返回的角色，动态渲染菜单按钮。注意一点：前端隐藏按钮只能提升体验，真正的权限校验一定要在后端接口上做，否则任何请求都可以绕过页面直接调用接口。

3. 源码核心逻辑与关键代码实现

3.1 SpringBoot核心配置

拿到源码之后，第一件事就是看application.yml。这套系统的配置大致如下：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/health_community?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 redis: host: localhost port: 6379 database: 0 servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

特别注意MyBatis-Plus的分页插件，这也是高频坑。分页插件一定要在配置类中显式声明，不然page查询返回的总条数永远是0：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

如果发现分页查出来的记录数不对，先检查是不是少了这段配置。还有数据库时区问题，url里最好显式带上serverTimezone=Asia/Shanghai，不然程序会按默认时区解析时间，出现差8小时的情况。

3.2 登录与JWT鉴权实现

登录接口的逻辑不复杂：接收用户名密码，从数据库查用户，校验密码，然后签发JWT，最后返回Token给前端。密码存储不要用明文，至少用MD5加盐或者BCrypt。

JWT工具类的核心方法很简单，大概是这样：

@Component public class JwtUtils { @Value("${jwt.secret}") private String secret; public String generateToken(String username, String role) { return Jwts.builder() .setSubject(username) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody(); } }

有了工具类，还需要在拦截器里统一校验。定义一个HandlerInterceptor，在preHandle方法中从Header里取Authorization，解析Token，解析失败直接返回401，不放行请求。然后在WebMvcConfigurer中注册拦截器，并放行登录接口和静态资源。这样每个需要登录的接口都自动有鉴权保护。

3.3 健康档案分页查询与条件搜索

社区医生管理老人档案，最常见的就是条件搜索加分页。页面上输入姓名或身份证号模糊查询，接口接收pageNum、pageSize和查询条件，MyBatis-Plus写起来很舒服：

public Page<ElderlyUser> pageElderly(int pageNum, int pageSize, String keyword) { LambdaQueryWrapper<ElderlyUser> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(keyword), ElderlyUser::getName, keyword) .or(StringUtils.hasText(keyword)) .like(StringUtils.hasText(keyword), ElderlyUser::getIdCard, keyword) .orderByDesc(ElderlyUser::getCreateTime); Page<ElderlyUser> page = new Page<>(pageNum, pageSize); return elderlyUserMapper.selectPage(page, wrapper); }

这里有两个要点。一是like条件要配合StringUtils判断，避免keyword为空时拼出“%%”导致全表查询；二是search条件如果涉及两张以上表，建议直接写一个VO查询，而不是强行LambdaQueryWrapper。毕业设计阶段，单表搜索完全够用。

3.4 体检附件上传：本地存储还是MinIO

体检报告往往是一张图片或者一份PDF，上传是避不开的功能。最简单的实现是上传到本地目录，然后做静态资源映射。比如配置一个上传目录/upload/health/，上传接口接收MultipartFile，保存到磁盘，返回访问路径。

@PostMapping("/upload") public R<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return R.fail("请选择文件"); } String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String newName = UUID.randomUUID().toString().replace("-", "") + suffix; String datePath = new DateTime().toString("yyyy-MM-dd"); File dir = new File("upload/" + datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir.getAbsolutePath() + "/" + newName)); return R.ok("/upload/" + datePath + "/" + newName); }

本地存储方案简单直接，但有两个问题：重启后需要保证上传目录还在，以及多实例部署时文件不共享。如果系统要演示分布式或生产环境，建议引入MinIO。整合MinIO的核心是引入依赖、配置桶、封装一个存储服务，然后上传代码改成调MinIO客户端API。我个人的建议是：先本地跑通，再根据余力决定要不要切MinIO，不要让对象存储成为启动项目的阻碍。

3.5 用药提醒的定时任务与消息落地

老人用药提醒是这个项目里比较出彩的功能。最简单的方式是Spring自带的定时任务，在启动类上加@EnableScheduling，然后在提醒任务类中写一个方法。

@Component public class MedicationReminderTask { @Resource private MedicationReminderService reminderService; @Scheduled(cron = "0 0 8 * * ?") public void sendMorningReminder() { List<MedicationReminder> reminders = reminderService.getTodayValidReminders(); for (MedicationReminder reminder : reminders) { // 生成消息记录，必要时通过短信或微信服务号推送模板消息 } } }

cron表达式0 0 8 * * ?表示每天上午8点执行。任务里不要直接发外部请求，更推荐的做法是：先把这批提醒写入消息表，前端登录后通过站内信角标展示。如果项目想做到“主动推送”的效果，可以再加WebSocket通知前端刷新角标，但这个属于加分项，不是核心必需。

这里有个容易被忽略的问题：定时任务默认是单线程阻塞执行，如果你在任务里做了大量数据库查询，上一次任务还没跑完，下一次到点就会跳过。对毕设来说，把任务拆短、只做查询和消息入库就够。如果后续数据量大，可以考虑用XXL-Job或者引入ActiveMQ做消息异步解耦，把提醒消息发到队列里，再由消费者去落库。

4. 部署运行与把Jar反编译回项目的思路

4.1 本地从零跑通完整流程

拿到源码和文档之后，最焦虑的问题是“怎么跑起来”。按我的经验，按照下面这个顺序操作不会错。

首先检查环境：JDK8或JDK11、Maven 3.6+、MySQL 5.7或8.0、Redis 5+、IDEA。然后导入项目，IDEA里选择File -> Open，选中pom.xml所在目录，等Maven下载依赖。依赖下载阶段经常卡住，建议配置阿里云镜像。接下来用Navicat或命令行执行项目根目录下的init.sql脚本，初始化数据库。改配置里的数据库账号密码，最后启动Redis和MySQL，运行启动类的main方法。

启动成功后，访问接口文档地址或者前端页面地址。如果端口不是8080，注意看日志中的Tomcat端口。这一步能过，项目基本就没有大问题了。

4.2 打包与上线部署

演示或者部署到服务器，一般是打个可执行Jar包。直接在项目根目录运行：

mvn clean package -DskipTests

这里建议跳过测试，因为有些项目里的测试类需要连接数据库，如果测试环境没有数据库，打包会直接失败。打包完成后，target目录下会生成一个xxx.jar文件，运行命令是：

java -jar target/health-community-0.0.1.jar

如果需要指定端口：

java -jar target/health-community-0.0.1.jar --server.port=8081

服务器上如果内存有限，可以加-Xms256m -Xmx512m限制堆内存。后台运行用nohup java -jar xxx.jar > logs.log 2>&1 &，注意2>&1的日志要定期清理，不然几个月后磁盘会被打满。

4.3 怎么把SpringBoot Jar反编译成项目

这个问题很实际：你拿到了一个可执行的Jar包资源，又想要它的源码结构分析，该怎么做？

两步走。第一步直接用反编译工具看代码逻辑，常用的有JD-GUI、Luyten和CFR。JD-GUI是图形化工具，打开Jar包就能看到类文件反编译后的源码。CFR是命令行工具，适合批量反编译。比如：

java -jar cfr.jar health-community-0.0.1.jar --outputdir ./src

第二步，把反编译得到的Java文件手动导入到一个新建的Maven项目里，补齐pom.xml依赖、resources下的配置文件、mapper XML、静态资源和数据库脚本。由于编译后的class文件不会保留注释和resources目录的原始结构，反编译出来的代码只能参考，不能直接“一键还原成项目”。正确做法是把反编译源码当作阅读思路的辅助，然后参照它重新搭工程、贴代码，这样得到的项目才真正可控。

有一点必须强调：反编译只能用于学习、分析自己合法获得的代码，以及排查线上问题。别人的商业项目源码，未经授权做二次发布属于侵权行为，这个边界不要碰。

4.4 高频报错与排查速查表

跑项目的过程就是“踩坑-填坑”的过程。下面这些报错是我实际操作中频率最高的，整理成速查表：

还有两个比较容易忽略的启动报错：一个是Failed to configure a DataSource，通常是因为SpringBoot自动配置找不到数据源，检查配置文件格式；另一个是ClassNotFoundException: javax.servlet.*出现在SpringBoot 3.x项目中，说明你正在用JDK17兼容环境跑旧代码，注意命名空间差异。

5. 配套文档怎么组织与论文写作参考

5.1 一套完整项目文档应该包含哪些内容

标题里写了“附源码+文档”，文档质量决定这套资源的含金量。好的项目文档至少包含五块：需求分析文档、数据库设计文档、系统详细设计文档、接口文档和部署运行文档。

需求分析文档要写清楚系统背景、角色、功能模块、业务流程。数据库设计文档要把每张表的含义、字段、关联关系写明白，最好配上ER图。详细设计文档主要描述核心功能的处理流程，比如“体检异常是如何触发预警的”。接口文档可以手写，也可以借助工具生成。部署运行文档则要写清楚环境版本、启动步骤、配置修改项。文档不是流水账，它代表你是否真正理解了项目的整体逻辑。

5.2 用Knife4j快速生成接口文档

接口文档手写最容易过时，建议直接集成Knife4j，它是SpringDoc/Swagger的增强UI方案。引入依赖之后，只需要少量配置：

springdoc: api-docs: enabled: true swagger-ui: path: /swagger-ui.html

访问/doc.html页面后，能看到所有接口的请求参数、返回结构，还能在线调试。对于新人来说，这比Postman挨个手填参数方便得多。把接口文档导出给答辩老师看的时候，也更有说服力。

5.3 论文和答辩中可以增加的加分点

如果你还有时间打磨，以下几个功能点非常推荐加上：给老人档案生成二维码，手机扫码就能看到基础健康信息和紧急联系人；体检趋势折线图展示血压血糖变化；用WebSocket推送预警站内信；角色权限加上数据范围控制，比如社区医生只能看到自己负责网格的老人。

这些功能本质上都是围绕核心业务的合理扩展，答辩的时候老师一看到“有异常检测、有消息通知、有数据权限”，就会认定你不是随便找了一个模板。相反，如果花时间去做刷脸登录、支付积分这种跟场景无关的功能，反而显得画蛇添足。

系统运行起来之后，还可以考虑把项目文档结构化成一个独立的目录，用Markdown维护，按“需求、设计、接口、部署、测试”归档，后续交付给别人时，也显得专业。

整套系统从设计到落地走下来，我个人最大的体会是：这类健康管理项目，技术本身并不难，难的是把表结构和业务闭环想清楚。如果你刚开始接触，建议先跑通“登录+建档+体检录入+预警查看”这一条主链路，其他功能再逐步补。我做这套项目时踩过一次比较深的坑，就是一开始急着写代码，把用药提醒和体检记录两个模块的表设计得过度耦合，后期改造费了不少功夫。先画好表和状态关系，再动手写Java，效率会高很多。

最后再分享一个实操小技巧：拿项目源码的时候，不要只看能不能跑起来，先看它的database脚本里有没有中文注释、有没有初始化数据。一套适合学习的源码，脚本里一定带了不同社区、不同健康状况的示例老人数据，这样页面上展示出来才不会空荡荡，排查问题也更有针对性。如果你拿到的项目一启动全是空表，那多半是原作者没有认真构造演示数据，这样的项目做二次开发会很痛苦。