基于SpringBoot+Vue的社区智慧养老监护管理平台设计与实现

简介本资源是一套面向计算机专业本科生的智慧养老领域毕业设计与课程设计实战项目聚焦社区级老人监护管理场景解决传统养老信息化程度低、响应滞后、家院协同弱等实际问题。压缩包共474个文件含141个Java后端业务与接口代码、64个Vue组件页面及交互逻辑、161个SVG图标资源辅以SQL建表脚本、YML配置、BAT一键部署脚本及演示视频等整体25.13MB结构清晰、模块完整便于分层学习与本地快速运行。已有188人下载学习适合掌握SpringBootVue前后端分离开发流程的初学者进阶实践。资源提供完整源码、详细部署说明、功能演示视频及源码介绍文档覆盖老人档案管理、监护人绑定、实时定位监控、跌倒/心率异常报警等核心业务助力读者理解智慧养老系统架构设计与工程落地细节。 做了几年养老相关的信息化项目我最大的感受是这类系统的难点从来不在技术本身而在于“有没有真的解决一线护理员、家属和管理者的某个具体问题”。现在网上很多基于SpringBootVue的社区智慧养老监护管理平台功能天花乱坠但落到实际使用场景里要么是老人档案变成了纯填表要么是健康数据只是摆设压根没人看更别说形成告警、工单、回访的闭环了。这套“社区智慧养老监护管理平台”我从技术选型到落地部署完整跑了一遍含源码、部署说明、演示视频和源码介绍整体走的是SpringBoot Vue的前后端分离路线角色覆盖管理员、护理员、老人家属三类人核心功能包含老人档案管理、健康监护数据接入、异常告警推送、护理工单流转以及给管理层看的数据大屏。如果你正愁毕业设计选题或者想给中小型社区养老机构做一套能真正用起来的信息化小系统这篇拆解值得你花几分钟看完。1. 平台整体设计与技术选型1.1 核心需求拆解养老系统到底在管什么社区智慧养老监护管理平台名字听着很重拆开来看其实就四件事老人档案、健康监护、异常告警、服务工单。老人入驻社区后建立基础档案关联家属通过智能手环或血压计等设备持续采集健康指标后端定时分析这些数据超出阈值自动触发告警告警产生后流转给护理员生成工单护理员处理完填写结果家属端能看到状态。整个链路走下来才算一个完整的管理闭环而不是单纯做个增删改查。我在设计时把角色分成三类系统管理员负责全局配置和账号管理护理员负责处理日常监护任务和工单家属只关心老人的实时健康状态和告警通知。权限上采用RBAC模型前端根据角色渲染不同的菜单后端通过拦截器校验接口权限两侧一起控制避免只做菜单隐藏的漏洞。1.2 技术栈选定为什么是SpringBoot Vue而不是别的后端选了SpringBoot 2.7.x搭配MyBatis-Plus作为ORM框架数据库用MySQL 8.0缓存用Redis鉴权用JWT实时消息用WebSocket。前端用Vue 2 Element UI ECharts因为这套组合最稳文档最全遇到问题搜一圈基本都能解决。为什么不选SpringBoot 3.x因为3.x强制要求JDK 17且部分第三方库比如一些物理分页插件的兼容性还需要额外排查在这个项目里没必要冒这个险。这里想多说一句很多初学者纠结“要不要上微服务、要不要用Spring Cloud”。社区养老平台这种业务规模单体应用完全够用上微服务只是增加部署和运维成本。架构一定要跟着业务走不是跟着简历走。如果你真想在简历上写微服务可以后续把告警推送单独拆成一个模块但第一版就老老实实做单体。1.3 工程结构划分前后端如何分工协作工程上我分成两个独立目录backend和frontend。后端是标准的maven多模块结构common放通用工具类和异常处理system管用户、角色、菜单elder管老人档案和家属关系monitor管设备和健康数据alert管告警规则和记录order管工单。前端按页面模块划分router集中配置路由api目录统一封装请求views目录按功能块组织页面。为了开发效率前端开发时通过Vite或Webpack的proxy代理把/api开头的请求转发到本地后端8080端口避免开发时反复处理跨域。部署时则由Nginx统一处理静态资源和反向代理线上不存在跨域问题这点后面部署章节会详细讲。2. 数据库设计与核心表结构2.1 数据模型总览先画清实体关系在写第一行代码之前先把表结构设计好后面能省一半的返工时间。这个平台的核心实体包括用户、老人、家属关系、设备、健康记录、告警记录、工单。用户和老人的关系不是简单的归属关系要允许一个老人关联多个家属一个家属也可以关注多个老人比如一个子女照顾两位父母所以做了一个关联表来表达多对多。用户表我用的是通用设计id、username、password、real_name、phone、role、avatar、status。密码存的是BCrypt加密后的密文绝对不允许明文入库。这里有个容易被忽视的点role字段我直接存字符串ADMIN/NURSE/FAMILY虽然不满足严格的范式但对当前规模来说最直观、最好维护没必要在系统初期就上user_role、role_menu整套中间表。2.2 核心表设计要点与字段说明老人档案表是整个业务的数据基石。除了姓名、性别、出生日期、身份证号、联系电话之外还必须有紧急联系人、紧急联系电话、入住房间号、既往病史、过敏史、当前健康状态这几个字段。其中既往病史和过敏史是护理员在工单处理和日常监护时的重要参考很容易被遗漏。健康记录表是实时数据汇聚的高频表我按设备维度设计elder_id关联老人device_code记录设备编号heart_rate心率、blood_oxygen血氧、blood_pressure_high收缩压、blood_pressure_low舒张压、body_temp体温collect_time是设备采集时间。这张表的数据量会比较大建议按月做分区或者定期归档不然一年以后查询会明显变慢。告警记录表需要重点设计的是处理状态流转0待处理、1处理中、2已完成、3已忽略。每次告警都关联到具体的老人和处理人处理结果必须写备注这样才能形成完整的追溯链。工单表和告警表可以设计成一对多关系一个告警可以生成多个工单但实际场景中通常一个告警对应一个工单就够了保留扩展余地即可。2.3 Redis在平台中的三个核心应用场景把Redis加进来不是跟风是实际有需求。第一是存储登录态JWT本身是无状态的但有时候需要主动让某个token失效比如修改密码后踢掉旧登录所以我把token的jti唯一标识存一份到Redis设置过期时间每次请求时校验。第二是存储验证码登录页的图形验证码存Redis5分钟有效防止暴力破解。第三是缓存设备最近一次上报的数据因为大屏和家属端需要频繁展示“老人现在的心率是多少”每次都查数据库有点浪费直接读缓存能省不少压力。数据一致性方面我在健康数据写入时会同步更新Redis里的最新值读取时先查Redis查不到再回源数据库。单机Redis在这个场景下完全够用不需要引入分布式缓存方案。3. 后端SpringBoot核心实现3.1 登录鉴权JWT结合拦截器的完整实现后端鉴权我采用的是JWT Spring拦截器的方式。登录接口校验用户名密码和验证码之后生成token返回给前端前端每次请求在请求头里带Authorization: Bearer token。后端写一个AuthInterceptor继承HandlerInterceptorAdapter在preHandle方法里解析token校验通过则把用户信息放入ThreadLocal放行请求校验失败则返回统一的401错误码。这里有个关键细节拦截器要配置放行路径比如登录接口、验证码接口、健康数据上报接口设备没有token其余接口都要被拦截。健康数据上报接口单独用deviceCode sign做接口鉴权这样既能保证安全又不影响设备直接上报数据的场景。生成JWT时secret的配置不要硬编码在代码里我放在application.yml中并通过环境变量覆盖防止源码泄露后被恶意伪造token。过期时间设置的是8小时前端在拦截器里检测到401时自动跳转登录页并清除本地token。3.2 健康数据接入模拟设备上报与阈值判定项目里没有真实硬件所以我额外写了一个设备模拟器模块用定时任务模拟老人心率、血氧等数据每隔5秒随机漂移一次模拟真实场景下的生理波动。上报接口设计成POST /api/monitor/report接收JSON格式的数据包含deviceCode、heartRate、bloodOxygen等字段。后端收到数据后做三层处理校验设备是否存在并绑定老人将原始数据入库执行阈值规则判定。阈值规则我参照了常见临床标准心率正常区间60-100血氧不低于95%收缩压90-140舒张压60-90体温36.0-37.3。如果连续两次采集值都超出阈值就判定为异常避免单次偶发波动造成误报。这个“连续两次”的逻辑非常重要不加的话老人翻个身可能都会触发告警护理员会烦到直接关掉系统。3.3 告警链路规则判定到WebSocket实时推送告警记录入库后需要实时推送到前端。这里我选了WebSocket实现因为告警对时效性要求高轮询不仅浪费资源还会有秒级的延迟。SpringBoot接入WebSocket比较直接编写一个WebSocketServer类使用ServerEndpoint注解前端连接时把用户id作为参数传给后端后端维护一个session映射。告警生成时根据老人关联的家属和负责的护理员找到对应的session通过session.getBasicRemote().sendText()推送告警通知。实际操作中要注意一点在WebSocket握手阶段把token校验做了不要等到业务层再校验身份不然非法连接会一直挂着消耗资源。另外Nginx部署时WebSocket的升级请求需要进行特殊配置增加Upgrade和Connection头部的透传否则前端会一直报WebSocket connection failed后面部署段落会给出具体配置。3.4 点餐式工单流转告警变成可执行的任务告警产生后系统自动生成一条工单指派给老人的责任护理员。工单状态分成待处理、处理中、已完成。护理员在手机H5端或PC端看到待处理工单点击接单后开始处理处理完填写处理说明和老人当前状态点击完成。工单完成后系统会给家属推送一条结果通知同时更新告警记录状态为已处理。为了保证环节完整我在工单创建时生成了业务编号格式为YYYYMMDDHHMMSS加随机四位方便线下沟通时快速定位工单。同时做了待办提醒登录后首页展示当前用户待处理工单数量护理员端高亮显示避免工单被忽略。这个细节在实际使用中很提升好感度。4. 前端Vue核心页面与交互实现4.1 前端项目结构与路由组织前端我用Vue CLI创建的项目src目录下分成api、assets、components、router、store、utils、views。路由集中管理统一使用懒加载方式引入页面组件避免首屏加载过慢。整体路由设计如下登录页独立登录后进入Layout布局组件内部嵌套各个功能页。Layout包含顶栏、侧边栏、面包屑和主内容区全部是后台管理系统的标配。路由守卫是权限控制的前端第一道关卡我在全局前置守卫中判断是否已登录未登录一律跳转到登录页已登录则根据角色判断是否有权限访问当前路由。这里有个小坑Vue Router 3.x的addRoutes方法在动态加路由时如果刷新页面路由会丢掉所以我在刷新时会重新拉用户信息并重新生成动态路由。如果你的项目用的是Vue 3 Vue Router 4逻辑类似但api略有差异。4.2 核心页面拆解数据大屏、告警中心、老人档案数据大屏是整个平台的门面也是演示视频里最出彩的部分。大屏我设计了三块区域中间是社区老人总体概况显示总人数、今日新增、当前在线设备数左侧是健康指标分布用饼图展示各状态区间老人占比右侧是实时告警滚动列表和近7天告警趋势用了ECharts的折线图和滚动列表组件。大屏的数据接口定时轮询每30秒刷新一次保证数据不过期。告警中心页面做成表格形式默认展示未处理的告警按告警级别排序。告警级别分为紧急红色、警告橙色、一般黄色在列表中用tag标签区分护理员可以一眼看到优先级。针对紧急告警我做了一个声音提示功能页面接收到WebSocket消息后播放一段提示音有效解决护理员没盯屏幕的问题。老人档案页面不仅有基本信息表单还增加了“健康趋势”页签点击某个老人后展示他近7天的心率曲线和血氧曲线。这个功能对家属来说非常直观也是系统区别于普通管理系统的亮点之一。曲线图我用了ECharts的line图X轴是时间点Y轴是指标值超出正常范围的区间用markArea标红视觉上很明显。4.3 axios封装与WebSocket客户端实现axios封装是整个前端的基础工程我在utils/request.js里做了统一处理请求拦截器中从localStorage取token设置到Authorization头响应拦截器中判断HTTP状态码401跳转登录页403提示无权限其它错误通过Element UI的Message进行提示。所有接口都通过api目录下按模块导出的函数调用页面组件里不直接引用axios方便统一维护和后续替换。WebSocket客户端的封装需要额外小心浏览器环境下WebSocket会因为网络波动或服务端重启而断开必须做断线重连机制。我的实现思路是在onclose回调里判断是否手动关闭通过一个标志位控制如果不是手动关闭就使用setTimeout延迟2秒后重新连接同时设置最大重连次数避免无限重连浪费资源。连接成功后通过消息类型分发处理告警类型消息触发弹窗和提示音工单类型消息刷新待办数量。4.4 Vue项目里的监控视频播放方案现在很多养老平台会接入卫生间、走廊等公共区域的监控设备这就需要在前端播放HLS流的视频。市面上不少摄像头输出的是m3u8格式的流地址在Vue里播放m3u8常用方案是video.js配合videojs-contrib-hls插件或者直接用hls.js库。我比较推荐hls.js因为它更轻量而且支持低延迟模式。实际使用中我遇到了一个坑部分摄像头的m3u8流是HTTP协议的如果平台部署的是HTTPS浏览器会阻止混合内容加载导致无法播放。解决方法是手动加载直播流时把地址改成HTTPS协议或者在Nginx层面对该路径做HTTP到HTTPS的代理转换。这个小问题折腾了我一个下午建议做类似功能的朋友提前规划好摄像头流地址的协议一致性。5. 部署落地从开发机到云服务器5.1 部署环境准备与版本选型说明这套平台部署我用的是一台2核4G的云服务器操作系统CentOS 7.9。部署之前需要装好以下基础软件JDK 1.8对应SpringBoot 2.7.x、MySQL 8.0、Redis 5.0及以上、Nginx 1.20。这里想提醒一下JDK别急着装最新的SpringBoot 2.7.x用JDK 8最稳项目pom.xml里配置的maven.compiler.source和target也都是1.8版本不一致会遇到编译或运行时的奇怪问题。MySQL安装后有几个必做的设置数据库字符集用utf8mb4兼容emoji和生僻字连接数调大一些开启binlog后续如果做数据分析和备份都方便。Redis安装后建议设置requirepass密码并且不要用默认端口直接暴露公网否则很容易被黑客扫描利用。我在安全组里只开放了80和443端口Redis和MySQL只允许内网访问。5.2 项目打包详细步骤前端与后端后端的打包相对简单在backend目录执行mvn clean package会在target目录下生成一个jar包。注意打包时建议使用-DskipTests跳过测试避免单元测试因为环境问题导致打包失败。打出来的jar包用java -jar app.jar即可启动但生产环境我推荐使用nohup后台运行并配合日志输出nohup java -jar app.jar --spring.profiles.activeprod app.log 21 。前端打包是另一个常见坑点。执行npm run build后dist目录下会生成静态文件。这里要特别注意Vue Router如果是history模式打包后必须配合Nginx配置try_files回退到index.html否则刷新页面会404。如果你不想折腾服务器配置直接把路由改成hash模式也能解决但url上会多个#号看起来不够专业。我能接受在Nginx里加一行配置就选了history模式。5.3 Nginx配置实战静态文件与反向代理Nginx在整个部署过程中承担两个角色托管前端静态文件和反向代理后端接口。服务器上先把dist目录下的文件上传到/opt/platform/dist然后配置Nginx的server块root指向这个目录。location /api/开头的请求全部proxy_pass到本地8080端口的SpringBoot服务其余请求走静态文件并尝试回退到index.html。WebSocket的配置必须额外处理在location /api/ws这个路径下要增加proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection upgrade这两行否则前端WebSocket连接会失败。完整配置如下server { listen 80; server_name your-domain.com; client_max_body_size 50m; root /opt/platform/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /api/ws { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } location / { try_files $uri $uri/ /index.html; } }配置完后执行nginx -t检查语法再nginx -s reload生效。这里提醒一下client_max_body_size建议配置大一些因为后续可能涉及家属上传老人照片、体检报告PDF等文件默认的1M很容易上传失败。5.4 Docker Compose一键部署方案如果你有多台服务器或者想统一管理环境使用Docker Compose是更优雅的方案。我给项目写了docker-compose.yml里面包含四个服务mysql、redis、app、nginx。mysql和redis镜像直接使用官方镜像app服务基于openjdk:8-jdk-alpine构建镜像nginx基于nginx:alpine构建并在镜像内把前端dist目录COPY进去。使用docker-compose up -d命令可以一键启动全部服务。需要注意的是容器之间的网络通信要用服务名而不是localhost比如app服务里配置的数据库连接地址要写成jdbc:mysql://mysql:3306/platform因为每个容器是隔离的网络空间。这个细节经常坑到初用Docker的人启动日志报连接超时排查半天发现是配置了127.0.0.1。5.5 演示视频录制要点讲清流程而不是堆功能项目交付时附带演示视频目的不是把每个页面都扫一遍而是讲清楚“一个业务场景是怎么走完的”。我用OBS录制的1080P视频设定好了录制脚本先用管理员登录创建一位老人档案并关联家属切换到大屏页面展示数据用模拟器生成一条健康异常数据触发告警切换到护理员账号查看告警并生成工单处理完成后提交最后切到家属于系统查看通知和健康趋势。整套流程录下来大概8分钟左右节奏不拖沓。录制时我建议先把页面字体调大因为视频在手机上看时小字根本看不清另外就是录制前关闭无关的浏览器标签页和软件弹窗避免干扰观看体验。一个干净的演示视频比什么都重要我见过不少项目因为视频里弹出了微信消息让评审老师印象分大跌。6. 常见问题与排查技巧实录6.1 开发环境下的跨域问题前后端分离开发时前端跑在8081端口后端跑在8080端口前端请求后端接口直接报跨域错误。我的处理方式是在前端vue.config.js里配置devServer的proxy把/api开头的请求通过代理转发到后端。这种方式的好处是前端代码里不需要把baseURL写成http://localhost:8080统一写成/api即可部署时不需要改动代码。module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };如果不想用代理也可以在后端加CORS配置但代理方式开发时最接近线上环境推荐优先使用。6.2 接口返回时间格式不兼容问题Java后端默认返回的时间格式是2024-01-01T12:00:00.00000:00前端展示时要么用day.js处理要么让后端统一格式化。我在项目里配置了Jackson的全局时间格式化规定日期时间格式为yyyy-MM-dd HH:mm:ss时区设置为GMT8。否则前端展示日期会差8小时或者格式不符。这个问题很隐蔽尤其做过国际化项目的朋友可能遇到过。配置方式是在application.yml中加入如下内容spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT86.3 WebSocket连接不稳定和断线重连WebSocket连接在线上环境经常会出现异常断开尤其是部署在Nginx后面时。我遇到的典型情况是长时间没有消息交互Nginx默认的proxy_read_timeout是60秒连接空闲超过这个时间就会被断开。解决方案是在Nginx配置中增大timeout时间并设置WebSocket的心跳机制前端每隔30秒发送一个ping消息后端返回pong保持连接活跃。前端断线重连的核心代码我放在utils/websocket.js中使用指数退避策略第一次失败后等2秒重连第二次等待4秒第三次8秒最多延迟60秒这样既能快速恢复临时断线又不会在服务器宕机时产生大量无效请求。6.4 打包后刷新404问题前端部署后如果你直接访问某个子路由地址比如http://domain/alert/list刷新后会出现404。这是因为Nginx没有找到对应的静态资源也没有把它交给前端路由处理。在Nginx配置的location /块中增加try_files $uri $uri/ /index.html;让所有无法匹配到真实文件的请求都回退到index.html由前端路由接管。6.5 线上内存溢出问题排查系统跑了一个月后出现一次频繁的OutOfMemoryError排查步骤如下先用jmap -heap 查看堆内存大小再用jstack查看线程状态最后用jmap -histo查看对象实例数发现是告警消息的WebSocket发送队列积压导致的。原因是某个时间点网络出问题大量消息堆积在内存中后来通过引入有界队列和消息丢弃策略解决。这里提醒大家线上服务一定要加JVM参数-Xms和-Xmx初始堆和最大堆保持一致避免堆空间动态伸缩时停顿。排查命令记录一下jps -l jmap -heap 12345 jstat -gcutil 12345 1000 jstack 12345 thread_dump.log6.6 设备数据突然不再上报的排查方向如果模拟器或者其他设备上报突然停止按照以下顺序排查先看设备状态是否在线再看后端的日志有没有接收到请求然后检查数据库连接是否正常。实际中遇到最多的情况是服务器凌晨做安全扫描时重启了Redis但SpringBoot的缓存客户端没有自动重连成功需要重启应用解决。所以我在项目里给Redis配置了自定义的连接工厂开启了故障自动重连。整个项目从设计到部署跑完我个人最大的体会是养老监护平台的技术门槛并不高真正有价值的是你如何理解“告警-处理-反馈”这个业务闭环。很多人做这类系统最后做完就是一堆CRUD页面数据录进去就没有然后了。但如果你把告警规则的防误报、工单的闭环处理、家属的感知提醒这几个环节做扎实这套东西才真正具备可落地的基础。另外一个很重要的建议就是第一版能简单就简单不要想着把什么功能都做进去先把一条完整业务链路跑通后面再逐步迭代这比什么都强。这也是我通过多次交付踩坑总结出来的经验。本文还有配套的精品资源点击获取