SpringBoot+Vue3养老平台源码解析：业务闭环与工程实践

我曾不止一次在源码交易平台、技术社区里看到这类标题：Java SpringBoot+Vue3+MyBatis 养老智慧服务平台系统源码，前后端分离加MySQL。如果只把它当成又一个CRUD后台管理系统，可能看不出什么名堂；但如果你把它丢进真实的养老运营场景，会立刻意识到这套系统的难点根本不在某个框架的API用法，而在于它要同时处理好老人状态监测、家属通知、护工工单、服务记录之间的业务闭环。

技术栈本身确实经典：SpringBoot负责后端接口和业务组织，MyBatis管SQL映射，MySQL做数据落地，Vue3搭前端界面，前后端通过JSON接口通信。这个组合在Java生态里非常成熟，拿来学习和二次开发都很顺手。适合谁看？第一种是正在做毕业设计或面试项目，需要完整业务案例的Java全栈学习者；第二种是准备接手养老类平台源码，想快速理解项目结构和改造点的开发者；第三种是想评估一套现成源码值不值得买的团队负责人。下面我从工程视角把这类项目的里里外外拆开讲，包括业务建模、后端实现、数据库设计、前端工程、联调排错，以及后续迭代方向，全是实际开发中会遇到的判断和坑。

1. 先搞清“谁在用、用在哪”：养老智慧服务平台的用户角色与业务主线

养老平台和普通后台管理系统最大的区别在于，它的核心链路不是“录数据、查数据、改数据”，而是要把线下的养老服务动作搬到线上，并形成可追踪的闭环。拿到的源码如果连这条主线都没理清楚，后面的代码基本就是在堆页面。

1.1 平台上的三类角色和一张关系网

养老智慧服务平台通常不是给单一角色用的，而是围绕“老人—家属—服务方”三方来设计。老人是被服务对象，家属是远程关注者，服务方则包括护工、护士、管理员、值班人员。三方各自的诉求差异很大：

• 老人侧：需要便捷的呼叫方式、健康数据的自动采集，或者由护工代为上报状态。
• 家属侧：最关心的是老人今天是否异常、有没有按时吃药、睡得好不好、有没有跌倒告警，最好还能在线看到服务记录。
• 服务方侧：关心的是每天有哪些工单需要处理、谁负责哪个区域、老人档案是否完整、异常事件有没有及时处置和记录。

源码里的功能模块，几乎都围绕这个三角关系展开。比如“家属绑定”模块，背后是一个典型的多对多关系：一位老人可以绑定子女、亲属多个账号，一个家属账号也可能同时关注两位老人，所以必须用一张独立的老人家属关系表去维护，而不是直接在老人表里加一个“家属ID”字段就完事。

1.2 “智慧”二字体现在什么地方

很多项目把“智慧”做成了噱头，但落到数据流上看，智慧主要体现在两条线上：

第一条是状态感知线。老人的健康指标、活动状态、设备告警数据不断进入系统。比如血压计上传的数值、床垫传感器检测到的离床时间过长、一键呼叫按钮按下的事件，这些原始数据落到数据库里，如果只是存下来，那叫“数据采集”；只有当系统根据规则自动判断“这个数值异常”或“这个事件需要人工介入”，并生成一条待处理记录时，才叫“服务触发”。

第二条是服务执行线。触发产生的记录不能停留在数据库里，而是要被服务方看到、接单、处理、填写结果。处理完毕后，系统还要通知发起方或家属，这个闭环才算完整。

源码里最值得看的，就是这两条线是怎么通过表结构和接口逻辑接起来的。如果拿到源码后第一反应是去看“登录模块怎么写的”，那方向就偏了；正确的顺序是先找到“告警记录表”和“工单表”，顺着它们之间的字段关系倒推业务流，整个项目结构会清晰很多。

1.3 业务流程决定表结构

从业务视角梳理，养老平台最少需要覆盖几个核心域：入住与档案管理、护工排班与考勤、服务工单、健康监测、告警与处置、家属沟通与通知。每一个域内部都有状态变化，域之间也有引用关系。比如一条服务工单可能关联护工ID、老人ID、服务项目ID、发起人ID；一条告警记录可能关联设备ID、老人ID、处置结果表。

所以你在源码里大概率会看到几十张表，而这几十张表可以归成几类：资源类（老人、护工、用户、设备）、活动类（工单、排班、告警、随访记录）、关系类（老人家属绑定、护工老人分配、角色权限）。理解了类别，数据库建模就不容易乱，这也是后面几章展开的基础。

2. SpringBoot分层与MyBatis动态SQL：一个管理端接口的真实落地过程

后端部分，标题里出现了SpringBoot、MyBatis两个关键词，这两个确实是Java后端的主干。SpringBoot负责把HTTP请求接收下来，交给Service层处理，再通过MyBatis访问MySQL。源码质量高不高，看分层和SQL组织就知道。

2.1 分层结构：Controller、Service、Mapper各管一段

一个规范的SpringBoot工程，Controller层会做参数接收、基础校验和结果包装，不会写太多业务代码。Service层承载业务规则，比如“新增一条健康预警时，如果老人当时处于免打扰状态，要不要延迟通知家属”这种判断就会写在Service里。Mapper层只管和数据库交互，一个方法对应一条SQL逻辑。

值得留意的细节是DTO和VO的使用。很多初级项目喜欢直接把数据库实体类Entity返回给前端，省事但隐患大：实体类里的字段可能包含数据库内部字段，比如创建人ID、逻辑删除标记，一旦暴露给前端，既不安全又容易导致接口字段和前端需要的不一致。合格的做法是Controller接收DTO，Service处理后返回VO对象。看源码时可以先确认目录结构里有没有这两个包，如果源码一概不分，说明代码质量可能不太好。

请求响应体的统一也值得关注。我见过的规范化项目都会用一个Result类包裹返回结果，里面包含code、message、data三个字段：

java复制public class Result<T> {
    private Integer code;
    private String message;
    private T data;
    // getter/setter 省略
}

前端拿到响应后，先判断code是否为200，再取data。好处是全局异常处理器可以把各种错误翻译成统一的code返回给前端，前端拦截器只需要处理几种固定情况，不需要每个接口单独判空报错。

2.2 一个带条件筛选的分页接口，最能看出MyBatis功底

养老平台里最频繁的一类接口，就是后台列表的分页查询。比如“健康预警记录列表”，需求可能是这样的：按老人姓名模糊查、按预警级别筛选、按时间段筛选、分页返回，还要统计出符合条件的总数。这种需求放到MyBatis里，最直观的做法是动态SQL。

很多初学者写动态条件时习惯拼接字符串，再用“where 1=1”兜底，这在老项目里非常常见，但不够优雅。MyBatis提供了标签方案：

xml复制<select id="selectWarningPage" resultType="com.example.vo.WarningVO">
    SELECT
        w.id,
        w.old_man_id,
        o.name AS oldManName,
        w.warning_type,
        w.warning_level,
        w.status,
        w.create_time
    FROM warning_record w
    LEFT JOIN old_man o ON w.old_man_id = o.id
    <where>
        <if test="oldManName != null and oldManName != ''">
            AND o.name LIKE CONCAT('%', #{oldManName}, '%')
        </if>
        <if test="warningLevel != null and warningLevel != ''">
            AND w.warning_level = #{warningLevel}
        </if>
        <if test="startTime != null">
            AND w.create_time &gt;= #{startTime}
        </if>
        <if test="endTime != null">
            AND w.create_time &lt;= #{endTime}
        </if>
    </where>
    ORDER BY w.create_time DESC
    LIMIT #{offset}, #{pageSize}
</select>

这段XML里有几个关键点值得展开。

第一个是<where>标签会自动处理掉第一个条件前面的AND，比手动加“where 1=1”安全得多。第二个是模糊查询用了CONCAT拼%号，而不是直接写成LIKE '%${oldManName}%'，后者存在SQL注入风险，属于典型反面教材。第三个是时间比较用了>=和<=，因为在XML里>和<是特殊字符，直接写会解析报错。第四是LEFT JOIN关联查询老人姓名，避免在前端再根据oldManId二次请求，这也是关系型数据库在列表页场景的常规操作。

如果要统计总数，再写一条不带LIMIT的count查询，把相同的<where>条件复制进去即可。这里有个隐患：有些团队图省事，在一条SQL里用COUNT(*) OVER()窗口函数直接返回总数，虽然能少写一个方法，但在数据量大、分页偏移深的时候容易踩性能问题，而且不一定所有MySQL版本都支持。为了稳定和可读性，分页查询和count查询分开写是更稳妥的习惯。

2.3 MyBatis配置层容易被忽略的三个参数

工程里application.yml中MyBatis的配置有四处经常被忽略，但影响极大。第一处是mapper XML文件的位置：

yaml复制mybatis:
  mapper-locations: classpath:mapper/*.xml
  configuration:
    map-underscore-to-camel-case: true

如果不配mapper-locations，MyBatis默认只扫描同包下的XML，很可能启动后报“Invalid bound statement”。如果不开启map-underscore-to-camel-case，数据库的create_time字段就映射不到实体的createTime属性上，查询结果全是null，新手排查半天都找不出原因。第二处是打印SQL日志，在开发和联调阶段务必开启：

yaml复制logging:
  level:
    com.example.demomapper: debug

注意这里的包名要改成你自己的Mapper接口所在包。开了之后，MyBatis会把每条执行的SQL、参数、返回值行数全部打到控制台，接口查不出数据时先用日志确认SQL和数据量，比瞎猜字段名高效得多。第三处是逻辑删除配置，如果源码里用的是通用Mapper或MyBatis-Plus，逻辑删除字段的全局配置要确认好，否则会出现“明明数据还在却查不出来”或“删不掉数据”的情况。

还有一个许多人踩过但经常忽视的点：SpringBoot版本和JDK版本强相关。如果用的Spring Boot 3.x，JDK必须是17及以上，同时javax.*包名要换成jakarta.*；很多入门教程和讲师电脑上还是JDK 8，那就要选Spring Boot 2.7.x。标题没有写明具体版本，实际拿到源码后第一件事要看pom.xml里的parent版本，避免本地环境搭好了项目却起不来。

3. 数据库设计不比表数量，比状态流转：核心表结构与业务流程如何对应

很多初学者看到几十张表就头大，但数据库设计的好坏从来不是看表多不多，而是看关键业务状态能不能被清晰表达和正确流转。养老平台里最典型的就是告警处置流程。

3.1 一张告警记录表背后的状态机设计

假设系统里有一条来自智能床垫的“离床超时”告警，这条记录从产生到关闭，正常要经历以下几个状态：待处理、处理中、已处理，还可能有一个“误报关闭”的终态。设计表结构时，最简单的做法就是在记录表上加一个status字段，用数字1、2、3分别表示不同状态。

代码如下（简化的建表语句）：

sql复制CREATE TABLE warning_record (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    old_man_id BIGINT NOT NULL COMMENT '老人ID',
    device_id BIGINT COMMENT '设备ID',
    warning_type VARCHAR(50) NOT NULL COMMENT '告警类型：离床/跌倒/心率异常等',
    warning_level TINYINT NOT NULL COMMENT '1低 2中 3高',
    content VARCHAR(255) COMMENT '告警内容描述',
    status TINYINT NOT NULL DEFAULT 0 COMMENT '0待处理 1处理中 2已处理 3误报',
    handler_id BIGINT COMMENT '处理人护工ID',
    handle_time DATETIME COMMENT '处理时间',
    handle_note VARCHAR(500) COMMENT '处理备注',
    create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

status字段虽然简单，但配套的更新SQL要特别小心。护工点击“接单”时，如果只写UPDATE warning_record SET status = 1 WHERE id = 123，那就埋了一个并发隐患：两个护工同时看到同一条待处理告警，都点了接单，后提交的人把前面那个人的处理人覆盖掉。正确做法是把旧状态也放进WHERE条件里：

sql复制UPDATE warning_record
SET status = 1, handler_id = #{handlerId}
WHERE id = #{id} AND status = 0

如果更新影响的行数是0，说明这条告警已经被别人抢单了，后端就可以返回“该告警已被处理”。这种用状态作为乐观锁条件的思路，在很多业务状态变更场景里比引入Redis分布式锁轻量得多，也够用。

3.2 核心表分类与常见关系

从源码的表结构可以大致看出设计者的业务理解程度。一般完整一些的养老平台，表会分这么几个域：

• 人员档案域：老人档案表、家属表、护工表、系统用户表。老人档案表的字段很有行业特色，除了姓名、身份证号、联系方式之外，还会有入住时间、床位号、护理等级、紧急联系人、既往病史、过敏药物等。护理等级是业务关键字段，因为它是后续排班和计费的参照。
• 业务与工单域：服务工单表、护工排班表、服务项目表、缴费记录表。工单表和告警记录表一样，有自己的状态流：待派单、已接单、服务中、已完成、已取消。
• 健康与设备域：设备信息表、老人设备绑定表、健康测量记录表、告警记录表。健康测量记录通常量很大，按时间维度的查询非常频繁，所以一般都会在老人ID和时间字段上建联合索引。
• 关系与权限域：老人家属关系表、角色表、用户角色关联表、菜单权限表。家属关系表的典型设计是包含两个ID：old_man_id和family_id，再带上一个绑定状态标记，因为“家属申请绑定老人”在真实业务中要有审核环节，不会一绑就立刻生效。

表之间最常见的关系是老人作为被服务主体，几乎被所有业务表引用。所以old_man表的ID会被大量冗余到工单表、告警表、健康表里。这样设计在读写上是合理的，既符合范式又没有过度拆分，查询时用JOIN就能把老人姓名带出来。

3.3 业务查询中两个“看起来简单、写起来容易翻车”的场景

第一个场景是查询每个老人的最新一条健康记录。常见需求是后台首页展示“最近一次测量的血压/心率”，如果对SQL不熟，容易写成GROUP BY old_man_id后直接取measure_value，但MySQL在ONLY_FULL_GROUP_BY模式下这种查询会直接报错，就算不报错，取到的值也不一定是每个分组里最新的一条。解决办法是先用子查询查出每个老人最大的记录时间，再关联回去取完整记录：

sql复制SELECT m.*
FROM health_measure_record m
INNER JOIN (
    SELECT old_man_id, MAX(measure_time) AS max_time
    FROM health_measure_record
    GROUP BY old_man_id
) t ON m.old_man_id = t.old_man_id AND m.measure_time = t.max_time

第二个场景是一对多关联导致的分页总数不准。比如查询“老人及其最近工单”，如果直接在SQL里LEFT JOIN工单表，一个老人有三条工单，结果集就会变成三行，再用COUNT统计时总数也变成了三倍。如果需求真的要展示列表，通常要拆成两条SQL：先分页查老人，再根据老人ID集合批量查工单，在内存里做组装，而不是指望一条大JOIN搞定一切。

4. Vue3端容易被低估的“明细活”：路由、鉴权、请求封装与图表展示

前端部分，Vue3的技术栈本身不算复杂，但一个养老管理后台的前端，实际工作量往往被严重低估。它不只是“写几个页面”，而是要把系统权限、接口状态、数据可视化、表单校验这些明细活全部理顺。

4.1 项目结构和代码组织

Vue3工程现在普遍基于Vite构建，配合Vue Router和Pinia。Pinia替代Vuex成为官方推荐的状态管理库，store写法更简洁，也天然支持TypeScript。源码里如果要区分“这个项目是不是上心的”，可以先看store目录划分。好的做法是按业务拆分：userStore管用户信息和登录状态，dictStore管字典项，appStore管侧边栏折叠和主题配置，而不是把所有状态堆在一个store里。

页面目录建议按照业务模块划分：view/login、view/dashboard、view/oldMan、view/warning、view/workOrder、view/family，每个目录下再放index.vue和对应的子组件。组件和页面混乱放置最让人头疼，后面接手的开发连找一个弹窗都要全局搜索半天。

4.2 登录鉴权和Axios拦截器

登录成功后，后端一般会返回一个token，前端把token存到localStorage或Pinia里。关键代码在路由守卫里，每次跳转路由前检查token是否存在：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.path !== '/login' && !token) {
    next('/login')
  } else {
    next()
  }
})

这个机制简单但实用。如果做得更细，还可以在守卫里根据meta.roles判断当前用户角色是否能访问该页面，能拦截掉一部分“手动改URL越权访问”的情况，但真正严格的数据权限还是要靠后端接口校验，前端跳转控制更多是提升体验。

Axios拦截器是另一个必看的点。推荐统一创建request.js文件，在请求拦截器里附加token，在响应拦截器里统一处理业务code和HTTP错误码：

javascript复制service.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = `Bearer ${token}`
  }
  return config
})

service.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code !== 200) {
      if (res.code === 401) {
        localStorage.removeItem('token')
        router.push('/login')
      }
      return Promise.reject(new Error(res.message || '请求失败'))
    }
    return res
  },
  error => {
    return Promise.reject(error)
  }
)

有这段拦截器兜底，页面里写接口调用时就不需要每个方法都处理401跳转了。很多半成品的源码没有统一封装，每个页面里都把axios复制一遍，header漏加、错误码不统一的问题会非常折磨人。

4.3 Element Plus是主角，但真正的细节在“表格+查询”体验

管理端页面最常用的是Element Plus组件库，比如el-table、el-form、el-dialog、el-pagination。功能看起来简单，但体验差异藏在这些地方：列表页的筛选条件要不要在刷新页面后保留？表格列宽能不能自动适配？操作列按钮的权限能不能按角色显示？这些都是开发过程中反复确认的需求。

一个很值得做的优化是让筛选表单和URL query参数同步。用户填了筛选条件、翻到第5页，刷新页面后条件还在，这个细节在养老平台这类需要频繁查询历史告警的页面上特别实用。实现上可以用onMounted时从route.query里恢复筛选表单，点击查询时调用router.replace把条件写入query。代码量不大，但体验提升非常明显。

Vue3里computed属性也是高频使用点。举个例子，后台表格里展示性别，数据库存的是0和1，界面上要显示“男”或“女”，如果每次都用方法函数去转换，模板会写得很啰嗦，而且每次渲染都会重新执行。用computed或者直接在el-table的formatter回调里处理都行，核心是不要在模板里堆一大串三元表达式。

健康监测数据的展示往往要用到图表。ECharts是主流选择，Vue3里建议通过封装一个Chart组件来使用，组件负责初始化实例、监听option变化、处理窗口resize和组件卸载时的销毁。养老板块最常用的是折线图展示血压/心率趋势，柱状图展示每日告警数量，饼图展示告警类型分布。首页的大屏看板如果要做，通常还会用到时间轴动画和实时轮询，轮询代码要记得在组件卸载时清除定时器，否则页面切走接口还在刷，属于很常见的性能问题。

4.4 跨域问题与开发环境配置

开发时前端跑在Vite默认的5173端口，后端跑在8080，直接请求肯定跨域。Vite提供了proxy配置，在vite.config.js里把/api开头的请求代理到后端地址：

javascript复制server: {
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true
    }
  }
}

生产环境下，通常由Nginx托管前端静态文件，同时把/api反向代理到后端服务。这时候要注意，如果后端接口没做跨域处理，但Nginx已经加了代理和跨域头，前端依然能正常请求；如果后端也配置了全局跨域，两边同时叠Buff，反而可能出现重复的响应头导致部分浏览器报错。排错时要先确认一条请求最终是在哪一层被处理的，不要前端报跨域就在后端一顿乱加注解。

5. 前后端联调与部署阶段排错：我的固定排查顺序和一份配置清单

源码在本地能不能跑起来、联调顺不顺，往往是评价这套源码价值的直接标准。很多功能看起来完整，真正部署的时候全是环境问题。我习惯按固定顺序排查，能省下大量时间。

5.1 高频问题一：项目启动不起来，先分三层排查

启动报错可以分成三类。

第一类是依赖和环境问题，比如SpringBoot版本太高，JDK版本不够；或者下载依赖时Maven仓库网络不稳定导致jar包损坏。排查方法很简单，先看pom.xml里的spring-boot-starter-parent版本，再java -version确认JDK版本。Spring Boot 2.x系列要求JDK 8或以上，Spring Boot 3.x要求JDK 17，很多笔记本电脑默认装了高版本JDK，反而要用Spring Boot 3才能跑起来。

第二类是数据库连接问题。报错信息里如果出现Access denied，基本是MySQL用户名密码不对；出现Unknown database，说明建库语句没执行；出现Public Key Retrieval is not allowed，要在JDBC连接串后面加allowPublicKeyRetrieval=true。另外，MySQL 8.x和5.x的驱动类不一样，driver-class-name建议写com.mysql.cj.jdbc.Driver，5.x则用com.mysql.jdbc.Driver。连接串里的serverTimezone=Asia/Shanghai最好也加上，不然8.x时区设置不匹配会把时间差8小时。

第三类是MyBatis映射问题，报错通常是Invalid bound statement (not found)。此时检查Mapper接口和XML文件是否同包同名，以及application.yml里mapper-locations路径写没写对。

5.2 高频问题二：接口通但数据不对，先看SQL日志再猜逻辑

本地启动成功后，前后端联调最常见的现象是：页面能打开，登录也成功了，但某张列表是空的，或者数据跟数据库里对不上。这时候千万不要先去前端代码里找bug，正确顺序是先打开浏览器开发者工具的Network面板，看接口请求的URL和响应内容。如果响应里code是200但data为空，再去后端日志里看MyBatis打印的SQL语句，拿着SQL到数据库客户端手动执行一遍。只要SQL能查出数据，那问题大概率是参数没有传到SQL里，或者返回的VO字段跟前端对不上；如果SQL本身就查不出数据，那再排查表和业务条件。

联调阶段还有一类经典问题：接口返回了，但实体里有循环引用，转JSON的时候直接报StackOverflow。比如老人对象里引用了家属列表，家属对象里又引用了老人，Jackson默认序列化会无限递归。解决方法是在一端的实体引用上加上@JsonIgnore注解，或者把返回对象改成VO，彻底避免实体关联关系泄漏到接口层。我倾向用VO方案，接口层不直接返回实体，既解决循环引用，又避免把数据库内部字段暴露出去。

5.3 高频问题三：登录后一段时间接口就401了

这个问题通常和token有效期、刷新机制有关。很多教学项目把token直接放在localStorage里，过期时间设得很短，一旦过期再请求接口就返回401。Axios拦截器里确实写了401统一跳登录，但用户体验是从“我正在填写一个表单”突然被踢回登录页，填了一半的内容全部丢失。更友好的方案是在响应拦截器里捕获401后，尝试用refreshToken刷新token，刷新成功就重放刚才的请求；刷新失败再跳登录。

当然，如果源码里压根没有refreshToken机制，也别急着喷设计有问题。很多内部管理系统把token过期时间设成24小时甚至更长，换来的是实现复杂度大幅下降。中小型项目要不要引入refreshToken，本质是“安全性和开发成本”的取舍，没有一定之规。

5.4 我的一份部署配置清单

结合多次部署经验，一份实用的部署配置清单大致是这样：

这些看起来零散，但每一条背后都是真实翻车换来的经验。平时多花几分钟把配置查清楚，比上线前一晚上通宵改配置值太多。

6. 后续版本我会优先做的三个增强方向

一套养老智慧服务平台如果只是停留在这个技术栈的CRUD状态，能跑，但不够“抗打”。真要在实际场景里用起来，有几个增强方向值得优先考虑。

第一个方向是异步通知能力的引入。现在告警记录产生了，只靠登录系统的人看到是不够的。系统应该自动把告警信息推送给值班护工，甚至通过短信或微信模板消息推送给家属。在现阶段如果不想引入消息队列，可以先用SpringBoot自带的定时任务，每隔十几秒扫一次告警表，把状态为待处理且未通知过的记录捞出来，调用短信服务商的接口发出去，同时更新通知状态字段。这样做简单、可控。等并发量上来之后，再考虑引入消息队列削峰，把“告警产生”和“家属通知”解耦。但无论如何，通知记录不要只打在日志里，一定要有独立的通知记录表，方便后续排查“家属到底收到没有”。

第二个方向是热点数据缓存。老人首页看板每次刷新都要统计今日告警数、待办工单数、服务完成率，每次都去MySQL里实时COUNT一遍，数据量大了之后性能肯定下降。处理方式是把这类统计结果在内存里缓存30秒到1分钟，或者定时计算后放到缓存里。引入Redis并不是目的，解决重复查询才是目的；如果没有Redis，用一个带过期时间的本地缓存也能顶上。但要注意缓存的一致性问题，像“告警状态变更”这类写操作发生时，相关缓存的key要主动删除或更新，避免页面显示的数据和真实状态脱节。

第三个方向是隐私与操作审计。老人的健康数据、家属联系方式、护工个人信息都属于敏感信息。列表页展示家属手机号的时候，中间四位应该脱敏显示，只有有权限的人点进详情才能看到完整号码；导出Excel、查看健康报告这类高风险操作要记录操作日志，留痕可追溯。这个方向不会直接影响业务功能跑通，但它决定了系统能不能真正在机构里落地。技术实现上其实不复杂，后端在返回数据时做一层脱敏工具处理，操作日志通过AOP切面统一记录即可，但很多源码恰恰忽略了这个环节。

最后说一点我梳理此类项目的个人习惯

拿到一套SpringBoot+Vue3的养老源码，我不会先双击启动，而是先打开数据库脚本，把核心表之间的关系画出来，确认状态字段流转的完整性；接着看后端MyBatis的XML，判断SQL组织是否规范；然后才会去看前端的鉴权和请求封装。这个顺序帮我避开了很多“表面繁华”的坑——有些源码页面做得漂漂亮亮，点进去才知道接口全是假数据，或者前端绕过了权限直接请求后端。

养老智慧服务平台这类项目的本质，是让老人的健康和服务状态变得可见、可控、可追踪。技术栈只是承载它的工具，SpringBoot、Vue3、MyBatis、MySQL这套组合成熟稳定，只要业务建模和状态设计到位，就能支撑起一个真正能用的系统。希望在读这篇文章的你，无论是学习还是二次开发，都能少走一些我走过的弯路。