社区智慧养老平台：SpringBoot+Vue全栈实现与权限业务解析

简介：这是一份基于SpringBoot的社区智慧养老监护管理平台完整项目源码包，面向Java初学者、课程设计/毕业设计学生及养老信息化研究者。平台围绕老年人健康监护、生活照护、紧急响应、社交互动等场景，整合SSM框架，实现了多角色权限、健康数据录入分析、服务预约与通讯录管理等模块。资源共477个文件，约28.12MB，核心包含141个Java后端源码、64个Vue前端组件、161个SVG图标，另有SQL数据库脚本、bat部署脚本、Word版论文与mp4演示视频，可直接导入运行并对照学习。配套的SQL脚本与论文文档有助于理解数据库设计和系统架构，Vue组件与SVG素材方便二次开发，安装脚本与演示视频可快速查看效果。当前已有130人学习，适合需要获取可运行Web项目、掌握前后端分离开发流程、撰写毕业设计/课程设计文档的学习者，是一套兼具实用性与参考价值的综合案例。

1. 拿到zip先别急着解压：这是个“前端成品+SpringBoot骨架”的交付物

解压“社区智慧养老监护管理平台”的zip，如果只看到dist目录、三个bat脚本和论文.doc，别以为资源缺货——这是课程设计交付最常见的形态：Vue前端已构建成静态文件，SpringBoot后端以标准Maven工程存在src目录下，bat脚本把“装依赖—启动—打包”串成流水线。你要做的不是逐行读页面代码，而是先把启动链路跑通，再把多角色权限和养老业务模块讲清楚。这个平台覆盖健康监测、生活照护、紧急呼叫、社区数据分析等场景，适合做Java课程设计或毕业设计，也适合想练习“接手现成项目”的开发者。下文按启动链路、权限模型、核心业务三条线拆开，每一段都会落到能直接执行的命令和配置上。

2. 从zip到可运行：SpringBoot后端与前端dist的整合链路

2.1 先看懂三个bat脚本，再决定要不要自己敲命令

压缩包里的1-install.bat、2-run.bat、3-build.bat是三个不同阶段的入口，常见内容如下表：

这三个脚本只是把Maven命令包装了一层，真正干活的是pom.xml和SpringBoot自动配置。课程设计交付时前端已经build成dist，所以3-build.bat多数情况下只打包后端。如果1-install.bat里既有mvn又有npm，建议先在命令行分别单独执行一遍，避免脚本里的命令和你本机环境互相干扰。

双击2-run.bat后窗口一闪而过，九成是JDK版本与SpringBoot版本不匹配。SpringBoot 2.x对应JDK8/11，SpringBoot 3.x要求JDK17及以上；课程设计里最常见的组合是JDK8配SpringBoot 2.7.x，springboot版本太高反而会带出一堆编译问题。先用java -version确认JDK版本，再去看pom.xml里的parent版本，两者对不上时优先改pom里的版本号。

2.2 前端构建产物为什么能直接嵌进SpringBoot

SpringBoot默认把classpath:/static、classpath:/public等目录映射为静态资源根目录。Vue构建后的dist内容（index.html、app.46deebe8.css、chunk-vendors.a72b0961.css、favicon.ico）拷贝到src/main/resources/static后，jar包同时提供页面和API，单端口运行，省去单独部署Nginx或第二个Tomcat的麻烦。对课程设计答辩来说，这是最稳妥的前后端分离交付方式。

注意dist目录下带哈希的文件名：app.46deebe8.css和chunk-vendors.a72b0961.css是构建工具根据内容生成的哈希名，只要前端源码改动过，重新build后哈希就会变。如果后端没动而页面样式不对，先检查static目录里这两个文件名和index.html里引用的是否一致——这是前后端分离项目最常见的“页面白屏”原因。

application.yml的核心配置：

server: port: 8080 spring: application: name: community-elderly-care web: resources: static-locations: classpath:/static/ mybatis-plus: mapper-locations: classpath:/mapper/*.xml configuration: map-underscore-to-camel-case: true global-config: db-config: id-type: auto

参数说明：server.port是后端监听端口，前端页面通过/api/xxx同源访问时不需要再写端口；static-locations显式指定静态资源根目录，jar包启动时从这里读取index.html；mapper-locations指向MyBatis/MyBatis-Plus的XML文件路径，这个配置漏掉时项目能正常启动，一执行SQL就报Invalid bound statement；map-underscore-to-camel-case把数据库下划线字段自动映射成Java驼峰属性，避免为每个字段写resultMap；id-type: auto对应数据库主键自增。

论文.doc里的SSM通常指Spring+SpringMVC+MyBatis这套经典组合，SpringBoot本质上是这套技术栈的自动配置化封装。答辩时能说清“MyBatis-Plus是MyBatis的增强工具，只做增强不做改动”，比单纯背概念得分高。

2.3 自定义静态资源映射：什么时候需要写Java配置

把dist放进static后首页仍404，常见原因有三个：项目配置了spring.mvc.servlet.path改变了接口前缀；dist被放进了target/classes而不是src/main/resources；或者maven打包时把static目录过滤掉了。这时候显式写一个资源映射配置类更可控：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/**") .addResourceLocations("classpath:/static/"); } }

addResourceHandler("/**")表示所有未匹配到Controller的路径都交给静态资源处理器；addResourceLocations声明资源的实际位置。这个配置只影响静态资源匹配，不会覆盖@RestController的接口路由。配置完仍然404，直接打开target/classes/static目录检查index.html是否存在——很多项目改了src下的文件，却忘了重新mvn compile。

2.4 把脚本改成自己项目适用的样子

1-install.bat的常见内容是安装依赖并跳过测试：

@echo off cd /d %~dp0 mvn -f pom.xml clean install -DskipTests pause

cd /d %~dp0切换到脚本所在目录，防止双击启动时工作目录在别处；-DskipTests跳过测试执行但会编译测试类，如果连测试代码都不想编，改成-Dmaven.test.skip=true。2-run.bat建议直接启动jar包：

@echo off cd /d %~dp0 java -jar target\community-elderly-care.jar pause

用java -jar启动时日志直接在窗口输出，光标停在Caused by那一行就是排查入口。用mvn spring-boot:run虽然也能启动，但它会二次编译整个工程，答辩现场网络不稳定时容易卡在重新下载依赖。

3. 多角色权限与数据模型：老人、家属、服务人员如何安全地共用一套系统

3.1 RBAC还是简单角色字段：课程设计阶段的取舍

社区智慧养老平台有老人、家属、养老服务人员、社区管理者四类角色，直接引入Spring Security + OAuth2会把工期拖长。我一般建议课程设计用“用户表+角色字段+拦截器”的最小RBAC模型，论文中写“基于角色的访问控制”即可；如果想让技术栈更完整，再用Spring Security托管登录认证。

这个权限矩阵是后端校验的依据，前端菜单隐藏只影响体验，不能作为安全边界。答辩时能说出这句话，说明你理解权限控制的本质。

3.2 五张核心表和密码存储

对应上面角色，数据库最少要有member老人、family家属、staff服务人员、user_account登录账号、service_order服务工单五张表。user_account里用role字段存MEMBER/FAMILY/STAFF/ADMIN字符串，比数字字典直观；password_hash列用BCrypt加密存储，不要存明文。

member表通过guardian_id关联family表，user_account通过member_id关联member表。建表时给user_account.username加唯一索引，status字段默认值设1代表启用。很多课程设计答辩翻车就翻在username没加唯一约束，并发注册时产生重复账号，页面一登录就报错。如果想让SpringBoot在启动时自动建表，可以在yml里配置数据库初始化脚本，但我更建议手写一份SQL文件，答辩时拿出来讲表结构比讲自动建表更扎实。

3.3 拦截器实现角色校验的最小闭环

用HandlerInterceptor做权限校验，少引入依赖，也容易在答辩时讲清楚：

@Component public class RoleInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String role = (String) request.getSession().getAttribute("role"); String uri = request.getRequestURI(); if (uri.startsWith("/api/admin") && !"ADMIN".equals(role)) { response.setStatus(HttpServletResponse.SC_FORBIDDEN); return false; } if (uri.startsWith("/api/staff") && !"STAFF".equals(role) && !"ADMIN".equals(role)) { response.setStatus(HttpServletResponse.SC_FORBIDDEN); return false; } return true; } }

preHandle返回false时请求直接终止，Controller不会执行。这里从Session取角色，实际项目可以换成从JWT的claims里解析；判断顺序很重要，/api/admin规则要写在前面，否则STAFF角色可能绕过限制访问/admin路径。注册拦截器时注意放行登录接口：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new RoleInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/api/health/report"); } }

addPathPatterns限定只拦截/api/下的请求；excludePathPatterns放行登录接口和健康数据上报接口，否则设备没法上报数据。排查时先用浏览器直接访问受保护接口：返回403说明拦截器生效，返回404则要检查路径映射是否有误。

3.4 @ConfigurationProperties统一管理平台参数

角色权限之外，平台还有很多全局参数，比如SOS超时秒数、管理员初始账号。用@Service里十几个@Value散落管理会越改越乱，用@ConfigurationProperties批量绑定better：

@Component @ConfigurationProperties(prefix = "care.platform") public class CarePlatformProperties { private List<String> adminAccounts = new ArrayList<>(); private int sosTimeoutSeconds = 30; // getter和setter省略，IDE自动生成 }

对应yml：

care: platform: admin-accounts: - admin - manager sos-timeout-seconds: 30

prefix="care.platform"对应yml里的配置路径；adminAccounts是List 类型，yml里用短横线列表赋值；sosTimeoutSeconds会自动从字符串"30"转换为int。绑定失败时项目在启动阶段就报错，比运行时才拿到null更友好。注意@Component和@EnableConfigurationProperties二选一，两处都写会导致重复加载。

4. 健康监测、照护工单与SOS紧急呼叫：养老业务模块的落地实现

4.1 健康数据采集：设备上报与异常阈值判断

健康监测在课程设计里通常是模拟设备上报请求。Controller接收JSON格式的deviceId、memberId、heartRate、bloodOxygen、timestamp，Service层先落库再判断是否触发告警。落库和告警推送必须在一个事务里，否则会出现“数据存进去了但家属没收到通知”的脏场景：

@Service public class HealthRecordService { private final HealthRecordMapper healthRecordMapper; private final AlertService alertService; public HealthRecordService(HealthRecordMapper healthRecordMapper, AlertService alertService) { this.healthRecordMapper = healthRecordMapper; this.alertService = alertService; } @Transactional public void handleRecord(HealthRecord record) { record.setCreateTime(LocalDateTime.now()); healthRecordMapper.insert(record); if (record.getHeartRate() > 120 || record.getBloodOxygen() < 90) { alertService.pushSos(record.getMemberId(), "健康指标异常"); } } }

@Transactional保证insert和pushSos要么都成功要么都回滚；阈值120/90是示例值，应该放进CarePlatformProperties做成配置。设备上报接口是高频写入，生产环境应该把告警推送做成异步，否则一个家属短信接口变慢会拖垮整个上报链路。课程设计阶段用同步实现可以接受，但答辩时要能说清“异步改造”的方向。

4.2 照护工单状态机：把服务流程变成可审计的流转

生活照护包含家政、送餐、护理预约。核心不是CRUD，而是状态流转。PENDING待接单、ACCEPTED已接单、IN_SERVICE服务中、COMPLETED已完成、CANCELLED已取消，用枚举管理状态码避免魔法数字。

更新状态时先查原状态再更新，防止并发下把已取消订单改成服务中。MyBatis-Plus的updateById不做乐观控制，需要手写Mapper SQL带WHERE status = #{currentStatus}。课程设计阶段能把这条写出来，证明你真正理解了状态机不是简单的字段赋值。

4.3 定时任务扫掉超时未服务的工单

服务人员接了单却一直不开始，需要定时任务自动取消。先在启动类加@EnableScheduling，再用@Scheduled定义执行周期：

@Component public class OrderTimeoutJob { private final OrderMapper orderMapper; public OrderTimeoutJob(OrderMapper orderMapper) { this.orderMapper = orderMapper; } @Scheduled(cron = "0 */5 * * * ?") public void cancelTimeoutOrders() { List<ServiceOrder> timeoutOrders = orderMapper.selectTimeoutOrders(30); for (ServiceOrder order : timeoutOrders) { order.setStatus(OrderStatus.CANCELLED.getCode()); orderMapper.updateById(order); } } }

cron表达式“0 */5 * * * ?”表示每5分钟执行一次，秒位固定0，分钟位每5分钟触发。selectTimeoutOrders的SQL里用accept_time与当前时间比较，只查“已接单且超过30分钟未开始”的订单。定时任务在集群部署时会重复执行，生产环境要加分布式锁，或者把SQL改成原子更新：

UPDATE service_order SET status = 4 WHERE status = 1 AND start_time IS NULL AND accept_time < DATE_SUB(NOW(), INTERVAL 30 MINUTE)

一条UPDATE把满足条件的订单置为取消，返回的影响行数可以直接用来生成取消通知，天然避免两个节点重复处理同一单。这个写法值得在答辩时主动讲出来，能明显加分。

4.4 SOS紧急呼叫与Redis去重

紧急呼叫最怕同一老人误触后1秒发10次请求，家属电话会被打爆。用Redis的SETNX做幂等去重：

public boolean tryAcquireSos(String memberId) { Boolean success = redisTemplate.opsForValue() .setIfAbsent("sos:lock:" + memberId, "1", Duration.ofMinutes(5)); return Boolean.TRUE.equals(success); }

setIfAbsent是SETNX命令的Spring封装，key存在时返回false；5分钟过期表示同一老人在5分钟内只允许触发一次SOS，误触后也不至于长时间无法再次呼救。返回值用Boolean.TRUE.equals(success)判断，而不是== true，避免自动拆箱时空指针。RedisTemplate的序列化器决定key是否多出前缀，如果项目里同时存了其他类型数据，建议单独注入StringRedisTemplate处理SOS锁，防止key序列化不一致导致锁失效。

4.5 数据分析：用一句GROUP BY代替循环查询

社区管理者要看“本周各社区工单完成率”。新手容易在Java里先查出全部订单，再按communityId循环统计，数据量上千后接口明显变慢。正确做法是把聚合下推到数据库：

SELECT community_id, COUNT(*) AS total, SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS completed FROM service_order WHERE create_time >= #{startTime} GROUP BY community_id;

COUNT(*)统计总单量，SUM(CASE WHEN status = 3 ...)把完成状态转成1/0后求和，得到已完成数量；completed除以total就是完成率。如果查询仍然慢，给create_time和status建联合索引。MyBatis-Plus里虽然可以用Wrapper的selectCount，但这种多行聚合还是XML里的原生SQL更直观。

5. 交付前的一轮体检：配置密文、HeapDump定位与接口幂等验证

5.1 把数据库口令从yml里挪走

答辩演示时，老师大概率会打开application.yml看配置。数据库密码明文写在yml里是最常见的扣分点。简单做法是引入jasypt-spring-boot-starter，把yml里的密码改成密文ENC(xxx)。生成密文的命令：

java -cp jasypt-1.9.3.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI \ input="root" password=your-salt algorithm=PBEWithMD5AndDES

input是数据库明文密码，password是自定义盐值，jar包版本以你pom.xml里实际引入的为准。命令输出的ENC密文贴进yml：

spring: datasource: password: ENC(加密后的字符串)

加盐的password通过环境变量JASYPT_ENCRYPTOR_PASSWORD传入，不要写死在yml里。JDK17下jasypt要选1.9.3以上版本，否则会报illegal key size。

5.2 性能问题先抓HeapDump再猜

SpringBoot服务内存飙升时，先抓堆转储文件再分析，避免乱加参数试错：

management: endpoints: web: exposure: include: health,heapdump,threaddump

include指定暴露的端点，health用于存活检查，heapdump下载堆转储文件，threaddump抓线程快照。heapdump端点配置后，浏览器直接访问/actuator/heapdump就能下载.hprof文件，用MAT分析大对象；线程dump则用来排查死锁和阻塞。课程设计可以在内网演示开放，但答辩时要说明：生产环境不能把heapdump暴露到公网，这正是springboot heapdump敏感信息泄露漏洞被利用的前提。

5.3 用Idempotent-Key验证SOS和设备上报接口

线上重试不可避免，SOS接口尤其需要幂等。做法是客户端每次请求带一个唯一Idempotent-Key，服务端先查Redis，不存在才执行业务逻辑并写入标记：

public boolean tryAcquireSos(String memberId, String idempotentKey) { Boolean success = stringRedisTemplate.opsForValue() .setIfAbsent("sos:idem:" + idempotentKey, "1", Duration.ofMinutes(10)); return Boolean.TRUE.equals(success); }

幂等键和memberId用不同key前缀，前者按请求去重，后者按成员时间窗去重，两者叠加后即使设备重复上报10次也只产生一次SOS通知。改造完成后用curl连续发10次相同Idempotent-Key的调用：

for i in $(seq 1 10); do curl -X POST http://localhost:8080/api/sos \ -H "Idempotent-Key: test-20240601" \ -H "Content-Type: application/json" \ -d '{"memberId": 101}' done

观察Redis中sos:idem:test-20240601只被写入一次，数据库里SOS记录只有一条。这是接口具备幂等性的直接证据，也是比“页面能正常打开”更有说服力的交付验证。

本文还有配套的精品资源，点击获取