SpringBoot智能老人生活辅助应用开发实战：从需求到部署

作为一个做过不少SpringBoot毕业设计的过来人，我拿到“智能老人生活辅助应用”这个选题的时候，第一反应是这题目出得挺讨巧。表面上看它是个典型的“管理系统”路子，但仔细拆开之后你会发现，它其实把物联网传感、实时通信、任务调度、消息推送这些SpringBoot生态里最常被面试官问到的点全串起来了。这类项目特别适合做计算机毕业设计，因为它的业务场景清晰，功能边界明确，技术栈又足够主流，从开题到答辩都有话说。

这篇博文我就以我自己实际开发这套“SpringBoot智能老人生活辅助应用”（源码编号42874）的完整经历为主线，把项目的功能设计、数据库建模、核心模块的代码实现、部署细节、还有那些只有自己动手踩过才会知道的坑，全部摊开来讲。不管你是准备拿它当毕业设计参考，还是想把它扩展成真正能落地的小型养老辅助系统，这篇内容都能让你少走不少弯路。

1. 项目思路拆解：这不是一个普通的“增删改查”系统

1.1 需求定位：老人真正需要的是什么

做这类系统最忌讳的就是上来就写代码，结果把页面设计得像后台管理模板一样，老人根本不会用。我在设计这套智能老人生活辅助应用时，先把用户拆成了三类：老人本人、家属或监护人、平台管理员（也可能包含社区护工）。不同角色的使用场景和能力差异非常大，需求自然也不同。

• 老人端：不需要复杂的表单和表格，他们要的是大字体、大按钮、语音提醒、一键求助。核心场景是查看今天的用药计划、收到量血压的提醒、遇到紧急情况时一键SOS。
• 家属端：关心的是老人有没有按时吃药、今天的活动量怎么样、有没有异常告警。他们要的是“不用主动问，系统主动告诉”。
• 管理端：处理的是老人档案、护工任务分配、服务工单流转、数据统计这些后台操作。

所以，这套系统在功能设计上必须同时兼顾“适老化交互”和“后台管理效率”这两个完全不同方向的目标。这也是它区别于一般管理系统的地方，也正好是毕业设计里可以重点包装的创新点。

1.2 功能模块：从需求到功能清单

我按照角色把功能拆成三个端，照着这张表去做开发计划，节奏会非常清晰：

其中，SOS一键告警和服务工单流转是实现难度最高、也最能体现技术含量的两块。SOS背后是WebSocket实时通信加状态流转，服务工单则涉及一个典型的状态机，我在后面会详细拆。

1.3 技术选型：为什么是SpringBoot全家桶

技术选型环节我基本没犹豫，直接定了SpringBoot + MyBatis-Plus + MySQL + Redis + Vue这套组合，理由很实在：

• SpringBoot是当前Java后端绝对的主流，毕业设计用它，答辩时技术认可度高，以后找工作写在简历里也拿得出手。
• MyBatis-Plus能把单表CRUD的代码量砍掉一大半，项目周期短，先把核心业务写完比什么都重要。
• Redis用来做缓存和临时状态存储，尤其是SOS告警的频控和验证码这类场景，直接操作数据库会非常吃力。
• 前端用Vue 3 + Element Plus，组件现成，页面开发效率高，和后端通过JSON交互，职责清晰。

版本选择上我特别提醒一句，SpringBoot不用追新，我用的2.7.x，稳定、资料多、和各种中间件的兼容性都验证过。热词里有人问“SpringBoot版本太高”怎么办，我见过太多因为用3.x导致老版本MyBatis-Plus或某些配置类不兼容，最后折腾一整天的案例。毕业设计求稳，能跑通比什么都强。

2. 数据库与核心设计：先把地基打牢

2.1 核心数据表及关系

数据库结构是这套系统能不能逻辑自洽的关键。我设计了大约12张核心表，这里说几张最有代表性的：老人信息表（elder_info）、家属关联表（family_binding）、健康数据表（health_record）、用药计划表（medication_plan）、用药记录表（medication_log）、告警记录表（alert_record）、服务工单表（service_order）、护工任务表（care_task）。

其中，老人和家属是多对多关系，一个老人可以绑多个家属，一个家属名下也可以有多个老人，所以必须拆出关联表。健康数据表则单独存每次测量的血压、心率、血氧值，每一条记录都绑定老人ID，这样后面做趋势图和异常判断时查询非常方便。

CREATE TABLE elder_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, elder_name VARCHAR(50) NOT NULL, age INT, phone VARCHAR(20), address VARCHAR(255), emergency_contact VARCHAR(50), chronic_disease VARCHAR(255), status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

这张表的设计原则是“高频查询字段冗余，变化数据单独存”。老人姓名、年龄这种基本信息直接放主表，而每次测量的健康数据单独拆表，避免一个人几千条记录把主表撑得又大又慢。

2.2 服务工单与告警的状态流转设计

服务工单和告警是这套系统里最值得展开的业务逻辑。服务工单我定义了这几个状态：待审核、已指派、服务中、已完成、已取消。护工提交完成申请后，管理员确认才能流转到已完成，每一步都记录操作人和时间，方便后续追溯。

告警的状态则分得更细：已触发、待处理、处理中、已关闭。特别要注意的是，告警必须带有“级别”字段，比如SOS是最高级别、心率异常是中级、用药未打卡是提醒级。不同级别的告警对应不同的通知策略：SOS直接WebSocket推送给所有绑定的家属并给管理员弹窗，用药未打卡只记录并定时汇总。

这张状态流转表我建议你在论文的数据库设计章节里也画出来，答辩时老师几乎必问。

2.3 为什么用Redis做告警频控

这里有个实际场景：老人连续误触SOS按钮，如果每次点击都直接生成告警并推送给家属，家属的手机一分钟收十条消息，整个系统就废了。所以我在生成告警之前加了一道Redis频控，同一个老人同一级别告警在60秒内只允许触发一次。

String key = "sos:elder:" + elderId; Boolean canTrigger = redisTemplate.opsForValue().setIfAbsent(key, "1", 60, TimeUnit.SECONDS); if (Boolean.FALSE.equals(canTrigger)) { // 60秒内已触发过，直接忽略重复请求 return Result.error("请勿重复触发"); }

setIfAbsent这个方法天然就是做分布式锁和频控的，一个命令搞定，比先查再写高效得多，也避免了并发问题。这个细节虽然代码量只有几行，但含金量很高，答辩时绝对是个加分项。

3. 后端核心模块的实战实现

3.1 项目初始化与统一返回结构

项目创建我直接用的Spring Initializr，但如果你在IDEA里创建超时（热词里有人提过这个问题），可以直接去start.spring.io下载压缩包，然后导入IDEA，速度稳定得多。依赖选择上，我加了Spring Web、Validation、MySQL驱动、Lombok，后面再手动引入MyBatis-Plus、Redis和JWT相关依赖。

启动类写好后，第一件事不是写业务，而是先搭统一返回结构。没有统一返回结构，前端处理数据会非常痛苦，一会儿返回Map，一会儿返回JSONObject，联调时全是坑。我定义了一个泛型Result类，所有接口统一返回code、message、data三段式结构，code为200表示成功，其他为业务错误码。

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

别小看这个类，整套系统的所有接口都建立在它上面。后续做全局异常处理时，只要在@RestControllerAdvice里捕获异常并返回Result.error()，就能保证前端拿到的永远是结构一致的数据，定位问题快得多。

3.2 登录认证与JWT权限控制

这套系统有三种角色，不可能所有接口都裸奔，所以登录认证我选了JWT方案。流程是：登录成功后后端生成一个token返回给前端，前端每次请求都把它放在请求头里，后端用一个拦截器统一校验。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } // 将用户信息放入请求上下文，后续接口可直接获取 Integer userId = JwtUtil.getUserId(token); request.setAttribute("userId", userId); return true; } }

校通过后，把解析出来的userId放到request attribute里，后续所有接口都能从request里取到当前登录人，省得每次重新解析token。JWT的过期时间我设成2小时，前端每次请求时如果发现后端返回401，就跳回登录页重新登录。这个机制简单可靠，完全够毕业设计用了。

角色权限我用了另一个注解@RequireRole加在方法上，通过AOP拦截判断当前用户角色是否在允许列表里。比如管理端的删除接口只允许admin角色调用，护工不能删除老人档案。

3.3 老人端：用药提醒定时任务怎么设计

用药提醒是这个系统里最能直接体现“智能”的功能。我的方案是：用药计划表里存每个老人每天需要吃几次药、每次几点吃、药品名称和剂量。后端启动一个定时任务，每分钟扫一次当前时间有没有需要触发的用药计划，命中后生成提醒记录，推送消息给老人端和家属端。

@Scheduled(cron = "0 * * * * ?") public void checkMedicationRemind() { String now = LocalTime.now().format(DateTimeFormatter.ofPattern("HH:mm")); List<MedicationPlan> plans = medicationPlanMapper.selectList( new LambdaQueryWrapper<MedicationPlan>() .eq(MedicationPlan::getRemindTime, now) .eq(MedicationPlan::getStatus, 1) ); for (MedicationPlan plan : plans) { // 生成提醒记录 // 推送WebSocket消息给老人端和绑定的家属端 } }

这里有个坑我必须提醒你：@Scheduled默认是单线程执行的，如果一个任务的执行时间超过了调度周期，后续任务会被阻塞。我后来改成了手动注入一个线程池调度器，把不同任务隔离开。而且建议直接在配置类里面设置TaskScheduler的线程池大小，避免定时任务之间互相影响。

3.4 家属端：WebSocket消息实时推送

WebSocket是实现实时告警和消息通知的利器。老人的SOS请求、心率异常、用药未打卡，都需要主动推送到家属端，HTTP轮询完全做不到及时性。我在项目里用SpringBoot的WebSocket模块，定义了一个/ws/{userId}的端点，用户登录后建立长连接。

@Component @ServerEndpoint("/ws/{userId}") public class WebSocketServer { private static final Map<String, Session> SESSIONS = new ConcurrentHashMap<>(); @OnOpen public void onOpen(Session session, @PathParam("userId") String userId) { SESSIONS.put(userId, session); } @OnClose public void onClose(@PathParam("userId") String userId) { SESSIONS.remove(userId); } public static void sendToUser(String userId, String message) { Session session = SESSIONS.get(userId); if (session != null && session.isOpen()) { session.getBasicRemote().sendText(message); } } }

WebSocket的连接管理我用了ConcurrentHashMap，因为高并发场景下普通的HashMap扩容会有并发问题。另外要特别注意，WebSocket的Session不是线程安全的，不能在多个线程里同时用同一个Session发消息，所以我在发送消息时做了同步保护。这套代码封装好之后，SOS告警、服务工单状态更新、健康数据异常提醒，全部可以复用它推送。

3.5 管理后台：数据看板与告警处理闭环

管理后台我做了四个核心页面：老人档案管理、护工任务分配、服务工单审核、数据看板。数据看板是其中一个比较亮眼的功能，它统计了今日告警数、待处理工单数、活跃老人数、用药完成率，用ECharts画成折线图和饼图。这些统计数据的SQL写法并不复杂，关键在于聚合查询的效率。

告警处理闭环是管理后台的核心逻辑。管理员打开告警列表，看到一条SOS告警，点击“处理”，系统要求填写处理结果和现场情况，然后状态从“待处理”变为“处理中”，护工到达现场并上报后再变为“已关闭”。整个链路走下来，任意时刻系统都能明确知道每一条告警到底进展到了哪一步，这不光是一个技术实现，更是这类系统的业务底线。

到这里我已经把后端核心模块基本讲透了，但这类系统真正难的不是“写出来”，而是“跑得顺”。我把整个实操过程中遇到的问题和排查思路整理成了两章，从环境搭建到部署上线全覆盖，耐心看完能帮你省下至少一周的折腾时间。

4. 实操过程与部署上线：从本地跑到服务器

4.1 开发环境准备与版本匹配

环境配置这件事看起来简单，实际上一大半的“启动失败”都是版本不匹配造成的。我整理了一份我自己验证过、稳定运行的版本组合，你照着配基本不会出问题：

有个小细节：MySQL 8.0的驱动类名和5.7不一样，com.mysql.jdbc.Driver已经废弃了，要用com.mysql.cj.jdbc.Driver，而且URL里需要带上serverTimezone=Asia/Shanghai，不然会报时区错误。很多人启动项目报错，问题就出在这几行配置上。

4.2 application.yml核心配置与密码密文化

项目的核心配置集中在application.yml里，包括数据源、Redis连接、JWT密钥、文件上传路径等。我把我实际用的一套配置做个脱敏处理放出来：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/elder_care?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: ENC(xxx加密后的密码) redis: host: localhost port: 6379 database: 0 timeout: 3000ms lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true global-config: db-config: id-type: auto

注意看密码那个ENC()开头的东西。生产环境或演示环境里，数据库密码明文写在配置文件里很不好看，答辩时被问安全问题容易卡壳。我引入了jasypt-spring-boot-starter，把数据库密码加密后再放到配置里，启动时通过环境变量传入解密密钥。这个“配置文件密文存储”的实践方法，在热词里也有人专门搜，说明确实是很多开发者的痛点。做法很简单：先在命令行里用Jasypt生成密文，再把密文填到配置里，代码层几乎无感知。

4.3 MyBatis-Plus自动建表与初始化数据

数据库表结构我保留了两种建表方式：正式发布我习惯手动执行SQL脚本，但开发调试阶段，我更推荐开启MyBatis-Plus的自动建表能力。网上有人问“MyBatis怎么在表不存在时自动建表”，其实MyBatis-Plus本身没有内置这个功能，但它提供了一个扩展机制。我项目中直接引入了一个第三方增强模块，在实体类上用@TableName标好表名，配置好策略后，应用启动时会自动检查表是否存在，不存在就根据实体的字段注解自动建表，开发阶段非常省事。

不过自动建表只能解决“建表”这一步，初始化数据（比如管理员账号、系统字典）还是要靠SQL脚本。我在resources目录下放了一个data.sql，启动时通过spring.sql.init.mode=always自动执行，把admin账号和默认角色一次性写入。

4.4 打包部署：从本地到Linux服务器

部署我用的是最经典的SpringBoot方式：Maven打成可执行jar包，扔到服务器上用nohup java -jar直接跑。有个细节是打包前要确保测试不干扰，执行mvn clean package -DskipTests跳过测试。

mvn clean package -DskipTests scp target/elder-care.jar root@your_server:/opt/app/ cd /opt/app nohup java -jar elder-care.jar --spring.profiles.active=prod > app.log 2>&1 &

启动后我会立刻看一眼日志，重点确认有没有“Started Application”这行字。如果有异常，用tail -100 app.log拉出日志定位问题。这里有个非常实用的命令组合：

# 查看端口是否被占用 lsof -i:8080 # 实时滚动日志 tail -f app.log # 快速排查Java进程状态 jps -l

前端项目打包后是一堆静态文件，我用Nginx托管，同时把/api开头的请求反向代理到后端8080端口。配置文件里加一段location规则，前端就不会有跨域问题了。

如果你在Windows本地开发、想在内网演示给老师看，直接用mvn spring-boot:run跑后端，Vue用npm run dev起前端，然后通过浏览器访问开发服务器地址就行，效果一样。

5. 常见问题与排查技巧实录

5.1 启动阶段：端口被占用、依赖冲突、时区报错

这套项目我前前后后帮几个同学排查过启动问题，出镜率最高的就三个。先是端口占用，8080被其他进程占着，启动直接报Port already in use，解决方法是换端口或者在命令行里用--server.port=8081临时覆盖。然后是依赖冲突，SpringBoot自带的commons-logging有时会和第三方库冲突，这类问题最有效的排查手段是在IDEA的Maven面板里执行mvn dependency:tree查看依赖树，找到重复的包然后在pom.xml里用exclusions排掉。最后是MySQL时区连接报错，大概率是连接URL里没加serverTimezone=Asia/Shanghai，加上就解决。

5.2 WebSocket连不上、频繁掉线

WebSocket的坑主要集中在三个位置。一是端点路径配置不对，前后端必须完全一致。二是连接鉴权问题，WebSocket握手时请求头里的token如何传递，如果前后端约定不一致，后端拦截器会误杀。我的做法是允许token通过URL参数传递，校验通过后建立连接，这样前端实现更简单。三是Nginx代理配置，在nginx.conf的location块里必须显式加上proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";这两行，否则连接会被Nginx当成普通HTTP请求处理，建立后几秒钟就断开，报1006错误关闭码。

如果你遇到连接能够建立、但消息推送不到前端的情况，先别动后端代码，打开浏览器F12看WebSocket的Network面板，连接状态是不是一直Open，然后再看后端日志有没有报ConcurrentModificationException，排查思路会更清晰。

针对WebSocket心跳保活，我也做了一个处理：前端每30秒发一个心跳消息，后端收到后回一个pong，如果连续两次没收到心跳，后端主动断开连接。这样可以把“假连接”清理掉，减少无效资源占用。

5.3 定时任务不生效或执行两次

定时任务不生效，最常见的原因是启动类忘记加@EnableScheduling注解。另一个低级但常见的错误是cron表达式写错，比如把“每天凌晨2点”写成了0 0 2 * * ?（多了一个问号），SpringBoot的cron表达式和Quartz的略有不同。这个我建议你写完表达式后，用一个在线cron校验工具测一下，别凭感觉填。还有一个情况是定时任务在集群环境里执行了两次，如果你部署了两份实例，可以用Redis分布式锁保证同一时刻只有一个实例在执行任务。我项目里就加了这么一把锁：任务开始前尝试用setIfAbsent抢占一个带过期时间的key，抢到才执行，执行完删除，抢不到说明已经有别的实例在处理了。

5.4 前后端联调接口报404或跨域

接口404先检查后端接口路径和前端请求路径是否完全一致，包括大小写。然后看控制器类上有没有加@RequestMapping("/api/xxx")前缀，路径对不上就会404。

跨域问题更典型。前后端分离开发时，前端跑在http://localhost:5173，后端跑在http://localhost:8080，直接请求会触发浏览器的同源策略拦截。后端的解决办法是加一个全局CORS配置类，允许指定来源和请求头访问。我这里放一个我常用的配置模板：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOrigins("http://localhost:5173") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意，如果前端用了axios且开了withCredentials: true，后端的allowedOrigins就不能写*，必须写具体的域名，否则浏览器会拒绝响应。这个问题我见过太多人卡住了，本质是浏览器对携带凭证的跨域请求有更严格的安全限制。生产环境如果有Nginx反向代理，前后端同域名部署，CORS问题自然就消失了，所以我在上一节才推荐用Nginx做一次代理。

6. 项目亮点与答辩扩展建议

如果你现在正在准备毕业设计答辩，这套系统里值得被你反复强调的技术点，除了前面聊到的WebSocket实时推送、JWT身份认证、Redis频控、定时任务调度之外，还有两个方向你可以深挖一下。

第一个是流程引擎的引入。热词里频频出现flowable、springboot整合activemq、springboot整合kafka，这些如果被答辩老师问到“工单流转怎么实现的”，你可以坦然说自己是用状态机和事务实现的一套轻量级流转，同时复习一下flowable的设计思想，回答时说明“如果以后有多级审批、复杂会签的场景，可以替换成流程引擎”的演进思路。这个问题回答得好，能体现你对技术选型的思考深度，而不是背代码。

第二个是智能问答能力。热词里出现hanlp分词在springboot的使用，这套系统如果扩展一个功能——“语音助手”或“智能客服”，能让老人通过语音输入问题，后端用HanLP做分词和关键词匹配，从服务知识库里检索答案。比如老人说“我今天该吃什么药”，系统分词后匹配到“我”“今天”“该”“吃”“什么药”，再结合时间和老人档案返回对应的用药计划。这种功能不复杂，但是加分效果很明显。

再比如文件上传下载。老人的体检报告、病历资料往往是大文件，热词里也有人搜“springboot如何上传下载大文件”，我项目中预留了上传接口，用MultipartFile接收文件，存到本地磁盘或对象存储，上传时限制单文件大小，下载时用ResponseEntity把文件流写回给前端。如果你想把性能做得更好，还可以参考分片上传的设计，把大文件切成多个块分别上传，再在后端合并。这块可以作为“系统扩展点”写进论文的总结与展望里。

最后提醒一句：源码拿到手，第一件事不是启动，而是先过一遍application.yml里的配置、数据库SQL脚本和README文档，确认环境信息都了解了再动手。代码只有自己亲手跑通一遍、改过几个地方，答辩的时候心里才有底。到答辩现场，老师问的往往不是某一行的语法，而是“这个模块为什么这么设计”“如果数据量大十倍你会怎么优化”，你只要能答出设计思路和优化方向，这套毕业设计的评分就不会低。

最后再分享一点个人体会：做这类选题，千万不要把精力全花在堆功能上。一个SOS告警闭环做得完整、演示流畅，远比列出十个半成品功能更能打动答辩组老师。系统的核心价值在于“关键时刻能不能把消息可靠地送达”，所以实时通信和告警状态流转，值得你反复打磨，这也是整个项目里最能讲出故事的部分。等你毕业以后回头再看，这段为了调通一条WebSocket推送熬到深夜的经历，恰恰是你从“会写接口”到“能搞定完整系统”迈出的最重要一步。