ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

基于SpringBoot的社区慢性病人信息管理系统开发实践

2026/9/12 2:25:26 拓冰建站 浏览量
基于SpringBoot的社区慢性病人信息管理系统开发实践 做计算机毕业设计的时候最怕的不是题目难而是题目看起来大而空。今天聊的这个“springboot社区慢性病人信息管理系统”其实是个很典型的Java选题技术上能覆盖SpringBoot、MyBatis、数据库设计、权限控制、定时任务这些核心知识点业务上又贴近社区医疗、健康档案、慢病随访这几个真实场景。无论你是拿它当毕设还是想练手一个完整的SpringBoot项目都很值得拆开来讲一讲。这个系统能做什么一句话概括围绕社区里需要长期管理的慢性病患者提供从建档、随访、用药提醒到健康指标趋势分析的一整套管理工具。适合谁看一是准备做类似选题的计算机专业学生二是刚接触SpringBoot开发、想找个完整项目练手的人。下面我会从需求拆解、技术选型、核心模块落地到常见问题排查把整个项目按“我能直接抄作业”的标准写给你。1. 先想清楚这系统到底要解决什么问题1.1 社区慢病管理的真实痛点做系统之前别急着写代码先想清楚业务。社区卫生院和社区卫生服务中心里高血压、糖尿病、慢阻肺这类患者数量非常大而且需要长期跟踪。传统的Excel登记和纸质档案有几个很明显的问题患者基础信息重复填写、随访记录容易丢失、某位患者的血压血糖变化趋势要靠人工翻本子才能看出来、医生想统计辖区里有多少人控制不达标非常痛苦。所以这个系统核心不是“增删改查”而是把慢性病患者的全生命周期数据管起来。这里说的全生命周期至少包括患者基本信息、疾病史与过敏史、饮食运动习惯、当前用药方案、历次随访记录、常规生化指标、健康评估结论和健康教育记录。1.2 毕设的功能边界怎么划很多同学一上来就想做得很全结果什么都做不好。我建议把范围控制在三个角色、六个模块以内既够展示水平又不会把自己陷进去。三个角色管理员系统配置、账号管理、医生/社区工作者患者管理、随访录入、档案查询、患者查看自己的健康档案和随访计划或者干脆不做患者端只做一个查看页面。六个模块用户登录认证、患者建档管理、慢病分类登记、随访计划与记录、健康指标录入、统计报表导出。做毕设时“边界清晰”非常重要。比如慢病管理里那些临床路径、医保结算、药品库存这些内容不是不好而是一旦引入数据关系和业务复杂度就会爆炸。把一条主链路做完整比铺十个半成品模块更能拿分。2. 技术选型与骨架搭建SpringBoot为什么够用2.1 技术栈清单与选型理由项目标题已经限定了SpringBoot那技术栈就往它周边靠。我推荐一套比较省心、也符合毕设评审老师预期的组合技术作用选型理由SpringBoot 2.7.x后端基础框架生态成熟跟JDK 8配合最稳网上资料多MyBatis-PlusORM框架单表CRUD不用写SQL代码量少一大截MySQL 5.7/8.0数据库默认选择部署简单Redis可选缓存验证码、登录Token有加分不用也完全不影响主线Spring Security / JWT认证授权做权限控制必备Hutool或EasyExcel工具库/导出导出Excel时非常好用Vue 2 / Element-UI或Thymeleaf前端如果做前后端分离Vue是主流不确定就Thymeleaf一个后端就能跑通这里重点解释两个选择背后的原因。第一SpringBoot版本别追新。你可能会看到SpringBoot 3.x、AI整合这些东西但毕设求稳2.7.x配JDK 8是经过大量项目检验的组合。SpringBoot 3强制要求JDK 17一旦你本机环境不匹配光是折腾环境就要耗掉好几天。第二MyBatis-Plus比原生MyBatis省事得多分页、条件构造器、逻辑删除都是现成的。2.2 项目目录与建表思路项目目录我用标准三层结构controller、service、mapper、entity、config、common这些包一个不少这样答辩的时候也好讲。核心表按我的经验大概需要以下这些-- 用户表 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(120) NOT NULL, real_name VARCHAR(50), role INT DEFAULT 2 COMMENT 1管理员 2医生 3患者, status INT DEFAULT 1, create_time DATETIME ); -- 患者档案表 CREATE TABLE patient ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, gender TINYINT, id_card VARCHAR(18), phone VARCHAR(20), address VARCHAR(200), birth_date DATE, height DECIMAL(5,2), weight DECIMAL(5,2), smoke_status VARCHAR(20), drink_status VARCHAR(20), family_history VARCHAR(500), allergy_history VARCHAR(500), create_time DATETIME ); -- 慢病登记表 CREATE TABLE chronic_disease ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, disease_type VARCHAR(50) COMMENT 高血压/糖尿病/慢阻肺等, diagnosis_date DATE, risk_level VARCHAR(20), current_medication VARCHAR(500), remark VARCHAR(500) ); -- 随访记录表 CREATE TABLE follow_up_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, follow_date DATE, systolic_pressure INT, diastolic_pressure INT, blood_sugar DECIMAL(5,2), weight DECIMAL(5,2), symptom VARCHAR(500), medication_adherence VARCHAR(20), follow_up_result VARCHAR(20), next_follow_date DATE, doctor_id BIGINT, create_time DATETIME );我不建议把各种指标拆得特别散比如一张表放血压、一张表放血糖那样查询的时候Join起来非常麻烦。随访记录表直接冗余几个关键指标字段业务上合理查询也简单Excel导出一行记录就全出来了。3. 核心模块落地从建档到随访的完整链路3.1 患者建档与慢病登记的联动患者建档是整个系统的起点。页面上的表单可以设计得稍微漂亮一点信息项分基础信息和健康信息两块。基础信息就是姓名、性别、身份证号、手机号、住址健康信息要有既往病史、家族史、过敏史、吸烟饮酒情况。这里有一个容易忽略的点身份证号要加唯一约束和校验。Service public class PatientServiceImpl extends ServiceImplPatientMapper, Patient implements PatientService { Override public boolean addPatient(PatientDTO dto) { // 身份证查重 LambdaQueryWrapperPatient wrapper Wrappers.lambdaQuery(); wrapper.eq(Patient::getIdCard, dto.getIdCard()); if (this.count(wrapper) 0) { throw new BizException(该身份证号已存在档案); } Patient patient new Patient(); BeanUtil.copyProperties(dto, patient); return this.save(patient); } }慢病登记放在患者档案底部既可以是一对多的子表也可以简化成一张扩展字段表。我的建议是独立一张chronic_disease表因为一个患者可能同时有高血压和糖尿病这是很常见的共病情况。登记的时候除了病种和确诊时间还要有一个风险等级字段高危/中危/低危这个字段后面会直接影响随访计划的生成频率。这里我踩过一个坑直接把病种存成字符串“高血压”结果统计的时候“高血压”和“原发性高血压”被拆成两类。正确的做法是建一个字典表或者在页面上用下拉框限定病种选项。毕设里不需要太复杂用枚举或者数据字典都能解释清楚。3.2 随访计划与定时任务提醒随访是慢病管理系统的灵魂。它的核心逻辑比较简单医生创建随访计划指定患者和下次随访日期系统在临近日期时自动提醒。实现方式有两种一种是在患者/慢病登记变更时生成下一次随访日期另一种是动态计算到期的患者列表。我更推荐第二种——每天跑一次定时任务把当天需要随访的患者捞出来生成待办通知。这样不会因为修改日期而漏掉记录。Component Slf4j public class FollowUpTask { Resource private FollowUpMapper followUpMapper; Scheduled(cron 0 0 8 * * ?) public void generateTodayFollowUp() { // 找出今天和昨天仍然未完成随访的记录 ListFollowUpRecord list followUpMapper.selectOverdueFollowUp(); for (FollowUpRecord record : list) { // 给对应医生和患者发送站内通知 notifyService.sendRemind(record); log.info(已生成随访提醒患者ID{}, record.getPatientId()); } } }定时任务别忘了在主类加EnableScheduling。你可能会问cron表达式怎么配这里“0 0 8 * * ?”表示每天早上8点执行。实际做毕设的时候可以把这个时间改成测试方便的间隔比如每1分钟跑一次0 */1 * * * ?演示效果更好答辩时能看到真实提醒产生。3.3 指标录入与趋势统计展示有了随访记录还得让数据“看得见”。我做的版本里医生在随访列表里点“录入指标”填写血压、血糖、体重系统自动判断这些指标是否在正常范围。这个判断规则不难比如收缩压大于140就标红空腹血糖大于7.0就提示偏高直接在前端搞定就行。真正花时间的是趋势图。用ECharts做一个折线图按时间显示某个患者近六个月的收缩压/舒张压变化。后端接口返回近半年随访记录前端把数据塞给ECharts。Override public ListFollowUpRecord getTrend(Long patientId, int months) { LocalDate start LocalDate.now().minusMonths(months); LambdaQueryWrapperFollowUpRecord wrapper Wrappers.lambdaQuery(); wrapper.eq(FollowUpRecord::getPatientId, patientId) .ge(FollowUpRecord::getFollowDate, start) .orderByAsc(FollowUpRecord::getFollowDate); return this.list(wrapper); }这个接口其实不用分页因为一个人半年最多也就几次随访记录。前端ECharts折线图的关键在于X轴是随访日期Y轴是血压值两条线分别代表收缩压和舒张压。这个功能很能拉高项目的完成度评审老师一看就知道这不是单纯背CRUD。3.4 权限控制与Excel导出我见过太多毕设项目所有接口都能匿名访问登录界面做了但改一下URL就能绕过这在答辩时容易被追问。最简单可控的方案是Spring MVC拦截器加JWT不走Spring Security那套复杂配置也能把登录校验和角色权限讲清楚。JWT的思路是登录成功后把用户ID和角色放进Token里前端请求时在Header带上Token后端写一个拦截器统一校验。角色介于医生和管理员之间可以用注解或简单判断方法实现。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BizException(未登录请先登录); } Long userId JwtUtil.parseToken(token); if (userId null) { throw new BizException(登录已过期请重新登录); } request.setAttribute(userId, userId); return true; } }导出功能我用的是EasyExcel把随访记录按条件查询出来后直接用注解映射导出。这里有个前提导出数据量不大的时候EasyExcel完全够用。如果数据量大要改为流式查询一页页查出来再写文件防止内存溢出。4. 常见问题与排查技巧实录4.1 IDEA创建SpringBoot项目超时与版本过高这个现象太经典了用IDEA自带的Spring Initializr创建项目一直转圈最后提示connection timed out。原因基本就是访问Spring官方接口超时解法有两个一个是在创建项目时把Server URL改成阿里云的镜像地址https://start.aliyun.com另一个是直接把项目用Maven骨架创建再手动往pom里加SpringBoot依赖。还有同学不小心选了SpringBoot 3.x结果项目启动就报错提示需要JDK 17。如果本机只有JDK 8我建议直接用SpringBoot 2.7.18这个版本是2.x最后的维护版稳定也够用。pom里加上版本号parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent4.2 LocalDateTime序列化问题SpringBoot默认用Jackson处理JSONLocalDateTime如果没配格式化前端拿到的是2025-01-01T10:00:00这种带T的格式很丑前端还不好直接展示。解决方案有两种。局部方案在字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)全局方案在配置类里定义Jackson的ObjectMapper统一处理日期格式和时区。我建议直接全局配置省得每个实体类都加注解。另外MySQL驱动和实体类类型要匹配数据库datetime对应LocalDateTimedate对应LocalDate千万别混用。4.3 中文乱码与Excel导出内存溢出中文乱码分两个位置。第一个是IDEA控制台乱码在IDEA设置里把File Encoding改成UTF-8同时pom里加上project.build.sourceEncoding为UTF-8。第二个是接口返回的JSON中文乱码多半是生产环境没有在application.yml里配置server: servlet: encoding: force: true charset: UTF-8Excel导出内存溢出这个问题通常在生成大数据量的Excel时出现。如果你用的是Apache POI的HSSFWorkbook一次性把几万条数据塞进内存很容易OOM。个人经验是直接用EasyExcel它底层做了分批写入用起来也不复杂。别忘了导出时文件名要做URL编码否则浏览器下载中文文件名直接乱码。4.4 表字段命名踩坑记录这里说一个很隐晦的问题。建表时我用了level字段存风险等级结果查出来的数据一直不对。原因就是level在MySQL里虽然不是严格保留字但在某些版本某些场景下会出问题。同理容易踩坑的还有desc、rank、order我都见过有人踩中。最稳的办法是所有字段都加业务前缀比如risk_level、patient_name、follow_status这样既规范又避免和关键字冲突。另外逻辑删除字段我建议直接用MyBatis-Plus的TableLogic全局配置一个deleted字段查询的时候自动带上deleted0条件比每个Mapper手动写条件省心太多。5. 从毕设到项目的扩展视角这个系统虽然叫“社区慢性病人信息管理系统”但它背后的设计思路可以迁移到很多场景。比如把患者换成学生把慢病随访换成在校健康信息登记把随访记录换成家访记录本质上就是一个健康档案管理类系统。所以做的时候尽量把患者、随访记录、用户角色这些基础表设计得通用一点后面改造成本会低很多。技术上还可以往这几个方向加料接一个第三方OCR识别身份证自动录入档案把随访提醒改成接入微信模板消息或短信发送把血压血糖趋势做成PDF报告导出。这些扩展点不一定要在毕设里全部实现但可以在论文的“后期计划”里写出来显得你对项目的理解是完整且有远见的。踩过几次坑之后我最大的体会是毕设项目最该花时间的不是最新框架而是把业务链路走通、把每一个模块的边界理清楚、把用户看到的东西做得顺眼。SpringBoot只是工具真正拉开差距的是你对数据的组织能力以及对细节的把控。