简介：本资源是一套面向计算机专业本科生的智慧养老领域毕业设计与课程设计实战项目，聚焦社区级老人监护管理场景，解决传统养老信息化程度低、响应滞后、家院协同弱等实际问题。压缩包共474个文件，含141个Java后端业务与接口代码、64个Vue组件页面及交互逻辑、161个SVG图标资源，辅以SQL建表脚本、YML配置、BAT一键部署脚本及演示视频等，整体25.13MB，结构清晰、模块完整，便于分层学习与本地快速运行。已有188人下载学习，适合掌握SpringBoot+Vue前后端分离开发流程的初学者进阶实践。资源提供完整源码、详细部署说明、功能演示视频及源码介绍文档，覆盖老人档案管理、监护人绑定、实时定位监控、跌倒/心率异常报警等核心业务，助力读者理解智慧养老系统架构设计与工程落地细节。 做了几年养老相关的信息化项目，我最大的感受是：这类系统的难点从来不在技术本身，而在于“有没有真的解决一线护理员、家属和管理者的某个具体问题”。现在网上很多基于SpringBoot+Vue的社区智慧养老监护管理平台，功能天花乱坠，但落到实际使用场景里，要么是老人档案变成了纯填表，要么是健康数据只是摆设，压根没人看，更别说形成告警、工单、回访的闭环了。
这套“社区智慧养老监护管理平台”我从技术选型到落地部署完整跑了一遍，含源码、部署说明、演示视频和源码介绍，整体走的是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，设置过期时间，每次请求时校验。第二是存储验证码，登录页的图形验证码存Redis，5分钟有效，防止暴力破解。第三是缓存设备最近一次上报的数据，因为大屏和家属端需要频繁展示“老人现在的心率是多少”，每次都查数据库有点浪费，直接读缓存能省不少压力。
数据一致性方面，我在健康数据写入时会同步更新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.active=prod > app.log 2>&1 &。
前端打包是另一个常见坑点。执行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.000+00:00，前端展示时要么用day.js处理，要么让后端统一格式化。我在项目里配置了Jackson的全局时间格式化，规定日期时间格式为yyyy-MM-dd HH:mm:ss，时区设置为GMT+8。否则前端展示日期会差8小时，或者格式不符。这个问题很隐蔽，尤其做过国际化项目的朋友可能遇到过。
配置方式是在application.yml中加入如下内容：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+86.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页面，数据录进去就没有然后了。但如果你把告警规则的防误报、工单的闭环处理、家属的感知提醒这几个环节做扎实，这套东西才真正具备可落地的基础。另外一个很重要的建议就是：第一版能简单就简单，不要想着把什么功能都做进去，先把一条完整业务链路跑通，后面再逐步迭代，这比什么都强。这也是我通过多次交付踩坑总结出来的经验。
本文还有配套的精品资源，点击获取
