基于Vue3+Spring Boot的智慧养老云平台开发实战

做智慧养老云服务平台这个项目我在真正动手之前一直以为它就是给养老院做一个信息管理系统。等到后面把需求摸透、把代码写完、再跟着实际业务跑了一轮之后才意识到这个系统真正难的不是CRUD而是怎么把线下那套繁琐的照护流程、异常告警、家属同步、机构管理全部串起来。如果你正打算用Vue3加Spring Boot做类似的平台或者已经接到了相关需求这篇文章应该能帮你少走很多弯路。我尽量把设计思路、核心实操、遇到的坑都讲清楚内容会比较长但每一段都是实际经验。1. 项目定位与整体设计思路1.1 智慧养老平台到底在解决什么问题刚开始接触这个项目需求时需求文档里写了一大堆功能护工排班、老人档案、健康监测、家属App、工单管理看着特别热闹。但我和对接的养老机构负责人聊完之后发现真正要解决的其实是三类问题。第一类是照护过程线上化。以前护工做了什么全凭手写记录老人几点吃药、几点测血压、今天有没有出去活动很多信息晚上才补录。平台要做的就是把排班、工单、护理记录、打卡全部变成线上闭环。第二类是异常可观测。老人独自在家、或者机构里出现跌倒、心率异常、长时间没有活动这些不能等出了问题才被发现。系统必须要有实时告警和通知机制。第三类是服务可追踪。家属想知道老人今天过得怎么样机构管理者需要知道每个护工的工作量监管方要能审计服务记录。平台本质上是在中间串联起老人、家属、护工、管理者这几类角色。所以这个项目虽然技术上是典型的前后端分离应用但业务设计上不能按普通管理系统的方式做。我之前见过有的团队把老人档案表设计成简单的人员表结果后面扩展健康数据和工单时到处改表非常痛苦。这个教训后面我会展开讲。总之第一步一定要把业务角色和核心流程梳理清楚再去想技术拆分。1.2 技术栈选型的关键决策这个项目的技术栈基本是标题里定好的Vue3加Java后端用Spring Boot。但在具体版本和组件选型上还是有几个地方值得细说。后端我用的是Spring Boot 3.xJDK 17这算目前比较稳妥的组合。Spring Boot 3相比2.x最大的变化是Javax变Jakarta如果你之前写过2.x版本迁移的时候要注意导入包的路径。ORM层我选择MyBatis-Plus虽然JPA也可以但在复杂查询和动态SQL上MyBatis-Plus在团队协作中更好控制尤其分页插件和逻辑删除非常省事。数据库用MySQL 8.x缓存用Redis实时消息推送用了WebSocket另外给大屏和看板接了一层ECharts。前端用Vue3加ViteUI框架选了Element Plus。这里多说明一句Vue3搭配TypeScript是更好的选择但如果你团队对TS不熟纯JavaScript也能跑只是后续维护稍微累一点。移动端我是通过H5方式兼容的小程序没有完整重写而是让接口层直接服务多个终端这样工作量可控。几个关键选型对照如下技术点方案选型理由后端框架Spring Boot 3.x生态成熟社区资料多快速搭建JDK17LTS版本长期维护满足Boot 3要求ORMMyBatis-Plus查询灵活分页方便代码量低数据库MySQL 8.x稳定部署简单业务量级完全够用缓存Redis热点数据、分布式锁、Token存储都能用前端框架Vue3 Vite编译快组合式API清晰UI组件Element Plus后台管理类项目最成熟的组件库实时通信WebSocket告警推送、工单状态变化的实时性要求选型的核心逻辑不是我偏执于某个框架而是整个团队能最快上手、出现问题最好排查。尤其是养老平台这种业务逻辑复杂、角色权限多、状态流转多的项目技术应该服务于稳定性和可维护性。1.3 整体模块划分与业务边界我把平台拆成六个核心模块老人管理、照护工单、健康监测、家属互联、系统管理、数据看板。老人管理是基础档案包括老人基本信息、家属联系人、健康档案、能力评估、用药计划。照护工单是日常运营的核心所有护工任务最终都落到工单上。健康监测负责对接智能设备数据同时提供人工录入入口异常数据触发告警。家属互联解决的是家属的知情需求通过绑定老人档案查看动态和接收消息。系统管理包含用户、角色、菜单权限。数据看板面向机构运营者汇总当日工单量、异常事件、护工工作量等核心指标。这种划分方式的优势在于业务边界非常清楚。比如健康监测和照护工单之间通过老人ID关联但彼此不直接操作对方的数据表后期不管是拆服务还是加新终端都方便。如果你把逻辑都堆在Service层互相调用前期倒是快后期加一个需求能改出一堆Bug。2. 核心业务细节与数据设计2.1 老人档案一人一档一码老人档案是整个平台的数据地基。我一开始设计的表结构特别简单就是一张老人基本信息表后来真正接入业务时发现完全不够用。一个完整的老人档案至少需要基础信息子表、能力评估子表、用药计划子表、健康指标子表、家属关系子表和居住地址子表。基础信息表负责身份类、联系人、紧急电话能力评估表记录ADL评分、失能等级用药计划表记录每天吃什么药、什么时间吃、是否已执行健康指标表存血压、心率、血糖等连续记录居住地址表负责机构和居家两种场景的地址信息。这里有一个很关键的设计就是档案快照。老人的能力评估不是永远不变的机构每隔一段时间会重新评测。如果把每次评估结果都直接覆盖到主档案上历史变化就彻底丢了。我在设计时增加了评估记录表每次生成一份评估快照当前状态只取最新记录。这样既能做趋势对比也能出阶段报表。一人一档还要配一码。我给每个老人生成一个唯一二维码打印后贴在床头或者老人随身携带的卡片上。护理员扫码能够快速调出档案家属扫码绑定关系。二维码里只直接放一个老人ID不能放敏感信息扫码之后再通过Token换取访问权限否则二维码一泄露隐私就全没了。2.2 工单调度与状态机的设计工单是平台里最复杂的部分因为它不只是增删改查还有状态流转。我设计的工单状态包括待分配、待开始、进行中、待评价、已完成、已取消、超时未开始。这么多状态必须用状态机来控制不允许随意跳转。比如待分配的工单只能流转为待开始或者已取消待开始只能流转为进行中或者超时未开始进行中只能流转为待评价。如果前端不小心发起了一个非法跳转后端必须拦截。我在代码里写了一套状态流转校验逻辑前端表单的按钮按状态显隐后端Service层再判断一次双重保障。关于自动分配我实现了一个简化版本新工单生成后系统会根据护工技能标签、当天已有工单数、距离三个维度做一个加权计算选择最合适的护工。技能标签在创建护工账号时维护工作量统计当天已有任务数距离则依赖机构范围内的定位数据。算完之后工单进入待分配列表人工也可以手动调整。插单和紧急单的情况很常见。我加了一个紧急级别字段紧急单可以插到某个护工待开始列表的最前面并且触发WebSocket通知。工单流转过程中还要记日志每一条状态变更都写在工单操作记录表里。表结构简单但谁在什么时间做了什么操作后面扯皮查得清清楚楚。2.3 健康监测数据与异常告警的处理健康监测是一个看起来简单、做起来细节极多的模块。设备端比如手环、血压计我统一走HTTP协议上报JSON格式传老人ID、设备类型、指标编码、数值、采集时间。后端收到数据后先做基础校验比如老人是否存在、数值范围是否合理再落入健康数据表。健康数据表我建议按时间序列设计不要按指标类型横向建一堆字段。因为每类设备上报的指标不同今天血压计传血压明天血糖仪传血糖如果字段写死后面加设备会非常痛苦。通用结构是老人ID、设备编码、指标编码、数值、单位、采集时间。查询时按指标编码过滤即可。异常告警是健康监测的核心。我设计了三个层次阈值异常、趋势异常、缺失异常。阈值异常就是数值超过高低限比如收缩压超过180趋势异常指同一指标连续几次持续走高缺失异常指例如手环超过2小时没有上报数据。三个层次触发不同的告警等级。告警产生的具体流程是健康数据入库后处理器判断是否异常如果是就去查老人档案绑定的紧急联系人再根据告警等级走不同触达通道。一般等级发送站内信和App推送严重等级直接触发短信和语音电话。这里必须做好防抖和幂等。比如老人有一次血压异常波动不能一分钟内给家属发10条短信。我加了冷却逻辑同一个老人同类型告警15分钟内只发一条。实际运行中我发现设备数据经常有误报比如手环佩戴位置偏移导致心率异常。所以不能全信设备告警后系统会生成一条待确认任务交给护理员在15分钟内复核只有护理员确认异常才升级为正式告警。这样家属收到的通知可信度高很多。2.4 家属互联与消息触达机制家属互联模块的重点是数据权限和消息触达。一个老人可以绑定多个家属一个家属也绑定了多个老人。绑定关系不能自己随意建立我设计的是老人档案的紧急联系人发起绑定邀请家属端输入手机号加验证码同时机构人员在后台审核。审核通过后家属账号只能看到自己绑定老人的数据不能看其他人。消息触达类型包括告警通知、工单完成通知、健康日报、服务提醒。这些消息必须走固定的内容模板所有触达行为记录在消息日志表里。日志记录接收人、消息类型、通道、内容、发送时间、发送结果不然出了问题无法追溯。这里要特别注意频率限制。比如健康日报每天最多一次工单完成通知每次工单结束发一条告警通知走冷却周期。否则家属在凌晨收到一堆App通知第一反应不是觉得平台智能而是把通知权限直接关掉。那整个系统就白做了。3. 实操过程从Spring Boot后端到Vue3前端3.1 后端公共能力搭建这部分我就直接按照实际项目里搭工程的过程来讲。我习惯先建一个Spring Boot项目用Maven管理依赖然后搭建公共代码层。工程结构大致是controller、service、mapper、entity、dto、vo、config、common。entity对应数据库表dto是入参vo是出参这套分层虽然看起来繁琐但项目一大就体现出好处了。比如老人档案接口的入参可能在管理端和移动端不一样相同entity接不同dto可以非常自然地处理。统一返回体我用的泛型类所有接口都返回标准结构。示例代码如下public class ResultT { private int code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT error(int code, String message) { ResultT result new Result(); result.code code; result.message message; return result; } }全局异常处理用RestControllerAdvice所有业务异常统一抛自定义BusinessException由全局处理器转成统一返回体。这样前端只需处理标准结构不用为每个接口定制返回格式。配置方面MySQL连接、Redis连接、MyBatis-Plus分页插件在启动类或者配置类中注册。特别提醒一下MyBatis-Plus的逻辑删除配置要注意全局生效否则删除操作会变成物理删除真删了数据找不回来。3.2 登录鉴权与权限控制登录鉴权是平台安全的第一道门。我用Spring Security加JWT实现。用户的密码用BCrypt加密存储登录成功后签发Access Token前端在后续请求中放到Authorization头里。JWT的设计上有几个要点token有效期设短一些比如2小时加上Refresh Token机制Access Token过期后用Refresh Token换取新Token避免频繁登录。某些团队为了省事把Token有效期设置成7天一旦泄露风险很大我强烈不建议。权限控制方面我使用了基于角色加菜单权限的方案。用户登录后后端返回用户信息以及可访问的菜单和按钮权限码。前端拿权限码控制页面元素显示后端用Spring Security的PreAuthorize注解校验接口权限。这里有一个关键点前端隐藏按钮只是用户体验后端才是安全边界每个敏感接口都必须有注解校验。数据权限方面比如家属只能看自己绑定的老人数据我用AOP切面实现。在查询老人列表、工单列表时切面根据当前用户角色自动拼接数据过滤条件。管理端查询全量数据家属端自动追加老人ID的IN条件。这个方案侵入性低Service层的代码不用写一堆冗长的权限判断逻辑。3.3 核心接口开发与实操记录我以工单流转为例展示整个开发过程。第一步是实体设计工单表包含工单编码、老人ID、工单类型、护工ID、计划开始时间、计划结束时间、紧急级别、状态、内容描述等字段。第二步是创建工单接口入参里带老人ID、内容、紧急级别Service层先校验老人是否存在且状态正常再生成唯一的工单编码。工单编码我做成规则机构编码加年月日加当天流水号。比如某机构的编码是SO1那20250210当天第1单就是SO120250210001。这个规则看着简单但是后续按编码搜索、按天统计都很方便。第三步是分配工单入参是工单ID和护工IDService层校验工单状态必须为待分配然后执行状态流转。public void assign(Long orderId, Long workerId) { WorkOrder order workOrderMapper.selectById(orderId); if (order null) { throw new BusinessException(工单不存在); } if (!OrderStatus.PENDING_ASSIGN.equals(order.getStatus())) { throw new BusinessException(当前状态不允许分配); } order.setWorkerId(workerId); order.setStatus(OrderStatus.PENDING_START); workOrderMapper.updateById(order); // 写入操作日志 orderLogService.record(orderId, ASSIGN, userId); }第四步是开始工单护工扫码或者点击开始接口校验当前时间与计划时间的差距。这一步有一个容易被忽略的点开始时间不能早于计划开始时间否则护工提前开始会导致后续排班冲突。第五步是完成工单护工填写服务记录、上传照片或者签名系统自动生成一条待评价任务同时通知家属。接口写完后我用Swagger在浏览器里把每个接口的参数和返回结构都过了一遍。这里有个建议写接口时返回的VO字段一定不要直接复用Entity尤其是涉及密码、身份证等敏感字段的实体一旦不小心序列化出去就麻烦了。3.4 Vue3前端工程搭建与核心页面实现前端工程我用Vite创建项目结构大概是views、router、store、api、components、utils。先做axios封装。拦截器里自动携带Token遇到401时跳登录页遇到业务错误码时弹统一提示。这个封装非常关键不然每个页面里都要重复处理错误逻辑。// utils/request.js import axios from axios; import { useUserStore } from /store/user; const request axios.create({ baseURL: /api, timeout: 10000, }); request.interceptors.request.use(config { const userStore useUserStore(); if (userStore.token) { config.headers.Authorization Bearer ${userStore.token}; } return config; }); request.interceptors.response.use( response { const res response.data; if (res.code ! 200) { ElMessage.error(res.message); return Promise.reject(new Error(res.message)); } return res.data; }, error { if (error.response error.response.status 401) { // 跳转登录逻辑 } return Promise.reject(error); } );动态路由是前端一个关键点。不同角色登录后看到的菜单不同我让登录接口返回菜单列表前端用router.addRoute逐个注册。好处是不用的菜单不会出现在包里用户也无法通过手输路径打开无权限页面。当然这只是前端层面的隐藏后端权限校验才是真正的拦截器。老人档案列表页是最常见的后台页面我用Element Plus的表格组件加搜索表单分页组件配合后端分页接口。表格列包括老人姓名、性别、年龄、失能等级、关联护工、最近一次健康评估时间。这个页面开发本身不难但涉及字段多建议列配置抽成一个文件后面加需求改起来顺手。健康监测大屏用的是ECharts。数据按天聚合展示血压折线、心率趋势、告警数量柱状图。ECharts配置项很多我的经验是先确定数据结构再封装一个公共组件把option作为props传进去后面每个页面只需要关注自己的数据处理逻辑。工单管理页面要用到WebSocket。护工端页面接上WebSocket后新单分配时会收到实时通知。Vue3里在onMounted中建立连接onUnmounted中关闭连接注意页面切换时别让连接泄漏。前端开发中最容易踩的坑是和后端的字段命名规范。后端如果用下划线命名前端就必须用下划线取字段或者后端转成驼峰。我建议统一用驼峰并且让后端VO的计算字段在前面完成前端不需要自己拼数据。3.5 打包部署的常见做法这个项目部署分成两部分前端构建后是静态文件后端是一个Spring Boot打包成的Jar包。我把前端构建后的dist目录放到Nginx里并配置反向代理凡是/api开头的请求都转给后端服务。Nginx配置主要部分如下server { listen 80; server_name your-domain.com; location / { root /home/app/dist; index index.html; try_files $uri $uri/ /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; } }try_files配置是必须的否则Vue Router的history模式刷新页面会出现404。生产环境MySQL和Redis建议单独部署。一些机构现场只有一台服务器的情况也可以把MySQL、Redis、后端Jar放一台Nginx放前端静态文件项目初期完全够用。数据库表结构变更我用脚本来管理每个版本一个SQL文件执行过的不允许回滚。这个习惯帮我避免了很多次改错表的尴尬。4. 常见问题与排查技巧实录4.1 联调阶段最容易踩的坑前后端联调是问题最多的时候我整理一下我经常遇到的情况。第一个是时区问题。Java后端默认时区和MySQL时区不一致时数据库里读出的时间相差8小时。解决办法是连接字符串加上serverTimezoneAsia/Shanghai并且Java时间类型统一用LocalDateTime前端展示时做格式化。如果时间字段存成了字符串后续统计和排序都会很难受。第二个是跨域问题。本地开发时前端和后端分属不同端口必然跨域。Vite配置proxy代理是最简单的办法走代理后浏览器看到的请求同源不用后端处理跨域。上线之后有Nginx统一代理也自然规避了跨域。第三个是字段序列化问题。LocalDateTime默认序列化格式是2024-02-10T13:00:00前端直接展示非常难看。我统一在配置里加了Jackson的全局格式化。第四个是参数校验问题。后端接口开发时要大量使用Valid和NotNull前端即使做了校验后端也必须做。否则前端绕过页面直接调接口没法保证数据安全。联调阶段我还习惯把接口文档实时维护好后端写完一个接口就同步更新不让前端来猜。项目小的时候这可能无所谓模块一多文档不同步带来的沟通成本非常高。4.2 数据权限越权的问题权限问题最怕的就是只看菜单权限忽略数据权限。菜单权限决定你能否进入某个页面数据权限决定你在页面里能看到哪些数据。比如家属登录后理论上只能看到自己绑定的老人和相关工单。如果查询接口不带数据权限过滤家属通过修改请求参数里的老人ID就能看到别的老人档案这是严重的隐私事故。我在项目里遇到过一次这个问题排查起来是某个Service层方法没有走切面过滤逻辑直接查了全量数据。后续优化是把数据权限过滤下沉到Mapper层通过自定义拦截器统一处理而不是散落在Service里。这样新同事写代码时也不容易漏掉。4.3 大数据量下的性能优化养老平台看似数据量不大但健康数据是时间序列型数据运行半年之后表记录数可能增长得非常快。第一个问题是N1查询。比如列表页查询老人列表后又循环查询每位老人的最新健康评估和最新工单状态。这个问题可以通过聚合查询、关联查询或者提前批量查Map解决。第二个问题是深分页。MyBatis-Plus分页到几百页之后数据库偏移量大会导致查询变慢。我采取的做法是限制最大分页深度超过500页的数据改用按时间范围或ID范围翻页。第三个问题是热点数据缓存。老人档案、护工信息这种变化频率低的配置在Redis里缓存一份查询先走缓存。但是缓存失效时要防止缓存击穿我用分布式锁控制回源查询。4.4 定时任务与告警推送的可靠性系统里有不少定时任务比如生成健康日报、检测超时未开始工单、自动关闭超时未开始状态。这些任务最怕的就是多实例重复执行。如果后端只部署一个实例Scheduled直接可用。一旦探活发现单实例有风险部署了两个实例每个定时任务就会执行两次。我采用Redis分布式锁解决任务执行前先抢占锁抢不到就直接跳过。public void executeDailyReport() { String lockKey task:dailyReport; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 10, TimeUnit.MINUTES); if (!locked) { return; } try { // 执行任务逻辑 } finally { redisTemplate.delete(lockKey); } }告警推送的可靠性上我遇到的问题主要是大量重复推送。比如同一老人同一时间段手环上报了多次异常每次都触发推送逻辑。处理方式是在告警处理器里做了去重以老人加上告警类型为维度在Redis设置一个15分钟的键键存在就直接忽略。推送成功后要记录日志日志里保存了推送响应结果方便排查第三方短信通道的故障。另外要说的是短信通道和App推送通道的切换我在配置中心里做成可配置的开关。有些机构只需要App推送不需要短信有些则两个都要。做成开关后不用改代码。最后分享一点我做这个项目最大的体会。智慧养老云服务平台的技术架构不算难真正难的是状态流转和业务边界的处理。工单、告警、权限、消息这些功能表面上互相独立实际运行中紧密关联。写代码之前建议花时间把流程图画清楚把每个状态的合法流转写下来代码实现时严格按流程推进。业务上出了偏差技术解决不了但技术上的坑大多是提前设计就能避开的。希望这篇内容能给你做一个可落地的参考如果后续有疑问欢迎按这个过程一步步实践一遍。