1. 项目概述与需求拆解1.1 这个系统到底解决什么问题先说结论这是一套面向社区居家养老场景的数字化管理平台技术栈是SpringBoot Vue3 MyBatis MySQL形态是前后端分离的Web应用。我为什么会盯上这个标题因为智慧社区居家养老健康管理听起来名字长但拆开看其实非常清晰智慧社区是场景居家养老是业务健康管理是核心系统是载体。这几年老龄化趋势明显社区养老、居家养老逐渐成为主流方向而这类系统要做的就是把老人的健康数据、社区服务、家属沟通、应急响应这些环节用数字化的方式串起来让社区运营者、家属、护理人员三方都能实时掌握老人状态。从源码角度来说这是典型的Java后端 Vue3前端 MySQL存储项目。SpringBoot负责提供RESTful APIMyBatis负责数据库操作Vue3负责页面交互MySQL负责数据落地。技术栈非常主流几乎就是目前中小型管理系统项目的标准配置跟着这套代码过一遍等于把“Java面试八股文”里常考的那几块SpringBoot自动配置、MyBatis动态SQL、Vue组件通信、MySQL索引优化全部实战了一轮。这类系统的目标用户通常有三类社区管理端运营人员需要看到辖区老人的基本档案、健康评估、服务工单。家属端用户希望远程了解父母的健康状况、服务记录、异常预警。护理人员或健康管理师需要录入健康数据、查看服务计划、跟进工单。一个完整系统至少要覆盖这三类角色的核心诉求缺了任何一环都只是在做“信息登记”而不是“健康管理”。1.2 技术选型背后的逻辑先讲一个很多人容易忽略的点为什么用SpringBoot而不是传统Spring MVC项目为什么用Vue3而不是Vue2为什么用MyBatis而不是MyBatis Plus或JPA。SpringBoot的核心价值在于“约定优于配置”。你要搭建一个Web服务传统Spring项目需要配置web.xml、spring-mvc.xml、数据源、事务管理器还要手动管一堆依赖版本。SpringBoot把这些全部自动化了一个启动类加几个注解就能跑起来。对于智慧养老这种偏业务型的系统开发效率是第一位的SpringBoot天然合适。而且SpringBoot 2.7.x和3.x是目前市场的主流版本岗位需求量大出了问题社区资料也全。Vue3相比Vue2最大的变化是Composition API和响应式系统的重构。管理系统这种场景页面逻辑复杂、组件复用频繁用Options API写久了组件之间共享状态比较费劲。Vue3的setup函数配合ref、reactive处理跨组件状态、自定义hook都顺手得多。再加上Vite带来的开发体验冷启动和热更新基本是秒级的开发时不用等编译心情都会好很多。MyBatis的选择更有意思。有些人可能会说这种系统用MyBatis Plus更快内置BaseMapperCRUD都不用写SQL。但MyBatis原生版本的SQL可控性更强尤其在多表关联查询、复杂统计报表这些场景下手写SQL反而更清晰。并且项目标题明确写了MyBatis说明作者是刻意保持技术栈的经典性方便学习或二次开发。很多人面试时会背“#{}和${}的区别”在这个项目里你会真正用上这两者的场景条件查询用#{}防注入排序字段用${}动态拼接列名。1.3 适用人群和前置要求想从这套系统源码里真正学到东西我建议至少有这样几个基础会Java基础语法知道类、接口、继承、Lambda这些概念最好能看懂简单的Stream操作。用过Maven知道依赖坐标和本地仓库是怎么回事。懂MySQL基本操作会建库、建表、写增删改查SQL。前端方面知道HTML、CSS、JavaScript基础能理解Vue的单文件组件结构。至少跑通过一个SpringBoot的Hello World项目。如果这些条件还不满足建议先把Java基础和MySQL基础补一下。不是说不能边学边做而是这个系统的定位是实战进阶基础不牢的话会花大量时间在配置排错上反而不容易体会到系统设计本身的亮点。2. 系统核心功能模块拆解2.1 老人档案与健康档案管理这是整个系统的数据基础。每位老人都有一个主档案里面包含基本信息、居住信息、紧急联系人、既往病史、过敏史、用药情况等。健康档案需要在主档案基础上扩展出历次体检记录、慢病随访记录、健康评估结果。在数据库设计上老人主表elderly_info和健康档案表health_profile是一对一关系而体检记录health_check_record、随访记录follow_up_record和主表是一对多关系。用MyBatis处理这种关系时建议直接用多表联查的VO对象来承接结果而不是在一对多映射上过度纠结。这里有一个实际开发中很容易踩的坑不要把所有的健康信息塞进一张大宽表里。我见过有同学把体检指标、心理评估、生活能力评估全部建成一张表结果字段多达数十个后期加一个指标就要改表结构。正确的做法是纵向拆分一类指标一张表通过老人ID和记录类型关联。这样每次新增评估维度只需要新建一张表或者加一个record_type不影响已有数据结构。2.2 健康数据录入与趋势分析护理人员或健康管理师登录系统后可以录入老人每天的血压、血糖、心率、体温等关键指标。这些数据落到健康指标记录表health_index_record一张典型的数据表结构大概是这样CREATE TABLE health_index_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elderly_id BIGINT NOT NULL COMMENT 老人ID, index_type VARCHAR(20) NOT NULL COMMENT 指标类型blood_pressure/blood_sugar/heart_rate/temperature, index_value VARCHAR(50) NOT NULL COMMENT 指标值, measure_time DATETIME NOT NULL COMMENT 测量时间, operator_id BIGINT NOT NULL COMMENT 录入人员ID, remark VARCHAR(255) COMMENT 备注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT 健康指标记录表;需要注意一个设计细节index_value用的是VARCHAR而不是DECIMAL或INT。为什么因为血压的典型值是120/80这种格式血糖可能是6.2体温可能是36.5如果每种指标单独建一个数值字段反而把表结构搞得极其复杂。用字符串存储原始测量值需要做趋势分析时再在代码层或SQL层解析灵活性最高。趋势分析本质上是对时间序列数据的聚合。比如要查某位老人最近30天的血压走势SQL可以这样写SELECT measure_time, index_value FROM health_index_record WHERE elderly_id #{elderlyId} AND index_type blood_pressure AND measure_time DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY measure_time ASC;然后在后端将查询结果封装成前端ECharts折线图需要的格式Vue3端用ECharts渲染即可。时间字段一定要用DATETIME而不是字符串不然后续做范围查询、按天分组统计时会非常痛苦。这是很多初学项目最容易踩的坑建表时贪图方便用varchar存日期上线一个月后做报表那酸爽只有自己知道。2.3 服务工单与派单流程居家养老服务不只是健康监测还包括上门助洁、助餐、陪诊、康复护理等具体服务。这些服务需要以工单的形式流转否则就变成了口头约定管理上容易扯皮。工单模块的业务流程大概是家属或护理人员在系统发起服务申请社区管理员审核后派单给对应的服务人员服务人员接单后上门服务结束后填写服务完成情况家属可以确认并对服务进行评价。这个流程在数据库层面最少需要三张表服务工单表service_order、服务项目表service_item、工单状态流转表order_status_log。状态流转表很多人会忽略但它其实是审计追踪的关键。如果哪天家属和护理员对服务次数有争议状态流转表就能完整还原整个工单的生命周期谁在什么时间把工单从什么状态改成了什么状态一目了然。状态字段建议用整数枚举而不是中文。例如0代表待审核1代表已派单2代表服务中3代表已完成4代表已取消5代表已评价。用整数存状态的好处后端做状态判断干净利落前端用字典翻译成中文展示不会出现中文编码导致的低级问题。2.4 预警提醒与异常处理智慧养老系统真正的价值不只是记录数据而是在异常发生时能主动提醒。比如老人血压连续两天偏高或者某位独居老人当天没有健康打卡记录系统都应该触发预警。预警规则的实现思路并不复杂。可以在服务层写一个定时任务比如每天9点扫描昨天没有健康记录的独居老人列表生成预警记录并推送给家属端。更实时的指标异常判断可以在健康数据录入接口里直接做规则校验一旦发现超出阈值的记录立即生成预警消息。预警数据表至少需要包含老人ID、预警类型、预警内容、触发时间、是否已处理、处理人、处理时间这些字段。前端的处理方式是弹窗提示加消息中心家属端和个人端都要能看到未处理预警的红点提醒。我建议不要把预警做成只管一次的弹窗而是做成可追溯的消息列表因为养老场景里健康预警会反复出现需要留痕。3. 数据库表设计要点与实操3.1 核心表结构规划综合上面拆解的几个模块一个最小可用的智慧养老系统数据库层面至少需要这些表表名用途关键字段sys_user系统用户表id、username、password、real_name、rolesys_role角色表id、role_code、role_namesys_user_role用户角色关联表id、user_id、role_idelderly_info老人基本信息表id、name、gender、birthday、address、contacthealth_profile健康档案表id、elderly_id、blood_type、allergy_history、chronic_diseasehealth_check_record体检记录表id、elderly_id、check_date、check_resulthealth_index_record健康指标记录表id、elderly_id、index_type、index_value、measure_timeservice_item服务项目表id、item_name、item_type、priceservice_order服务工单表id、order_no、elderly_id、item_id、status、assignee_idorder_status_log工单状态流转表id、order_id、from_status、to_status、operator_id、create_timewarning_record预警记录表id、elderly_id、warning_type、content、is_handledfamily_member家属关联表id、elderly_id、user_id、relation从这个表结构能看出系统的领域模型是比较清晰的。用户、角色权限是一套老人及健康数据是一套服务工单是一套预警是一套。分模块后团队成员可以并行开发互不干扰。3.2 自制一个轻量权限模型对于这种系统很多人一上来就引入Spring Security或者Shiro结果配置复杂学习成本也高。其实中小型后台完全可以自己做一个简单的拦截器加角色判断的权限控制而且能更清楚地理解权限控制的核心逻辑。具体做法用户表中存role字段比如0代表管理员1代表护理人员2代表家属。然后在HandlerInterceptor中判断当前登录用户的角色是否允许访问某个路径比如/admin/**只有管理员能访问/family/**只有家属角色能访问。前端再配合Vue Router的路由守卫做菜单级别的控制。用自定义拦截器讲清楚权限控制的原理后后续需要更细粒度的权限控制时再升级到Spring Security JWT方案。你先理解了“什么人能干什么事”这件事看安全框架的所有概念都会轻松很多不然容易在过滤器和拦截器的配置细节里绕昏头。3.3 索引优化与慢查询预防养老系统数据量初期不大但健康指标表和工单状态流转表的数据增长会很快。拿健康指标记录来说一个老人每天可能产生3条记录一个社区500位老人一年就是五十多万条数据。这时候索引的重要性就体现出来了。create_time和elderly_id组合做联合索引是常见做法。因为大多数查询都是先过滤老人ID再按时间排序。SQL大概是ALTER TABLE health_index_record ADD INDEX idx_elderly_time (elderly_id, measure_time);创建完索引之后一定要用EXPLAIN看一下执行计划。我见过不少项目上线之后才发现查询走了全表扫描就是因为建索引的时候没有结合实际的WHERE条件来设计。另外order_status_log表要按order_id做索引预警表按elderly_id和is_handled做联合索引这些都是高频查询路径。索引不是越多越好每次写入都要同步维护索引索引过多会拖慢写入速度。实际项目中先针对慢查询日志中真正慢的SQL去建索引不要凭感觉建。4. 后端SpringBoot核心实现解析4.1 项目结构与启动类一个规范的SpringBoot项目结构应该是清晰的。虽然很多教学项目喜欢把全部代码塞进一个包但真实项目建议按业务模块分包com.example.eldercare ├── config ├── controller ├── service ├── mapper ├── entity ├── dto ├── vo └── commoncontroller层只负责参数接收和结果返回service层处理业务逻辑mapper层负责数据库操作entity对应数据库表结构dto是请求参数的封装vo是响应给前端的对象。这种层次划分在团队协作时特别重要大家各改各的层冲突概率会小很多。启动类本身没有太多好说的标准的SpringBootApplication加main方法。这里一个容易踩的坑是包扫描启动类必须放在所有子包的父包下否则ComponentScan扫描不到各个子模块的Bean启动直接报错“无法注入Mapper”。4.2 MyBatis的常见用法与XML动态SQL在MyBatis的使用上不同开发者有不同风格的写法。有些项目用XML文件管理SQL有些项目用注解直接写在Mapper接口上还有的项目用MyBatis Plus的BaseMapper。这个系统用原生MyBatis做演示的话我更推荐XML方式。原因很简单复杂SQL在XML里面可读性更高改动SQL不用重新编译Java代码而且MyBatis的XML映射是这套框架的核心能力面试也常考。一个典型的Mapper接口长这样public interface HealthIndexRecordMapper { ListHealthIndexRecordVO selectRecordsByElderlyId(Param(elderlyId) Long elderlyId, Param(startTime) String startTime, Param(endTime) String endTime); }对应XML里面的查询语句select idselectRecordsByElderlyId resultTypecom.example.eldercare.vo.HealthIndexRecordVO SELECT id, elderly_id, index_type, index_value, measure_time, remark FROM health_index_record WHERE elderly_id #{elderlyId} if teststartTime ! null and startTime ! AND measure_time gt; #{startTime} /if if testendTime ! null and endTime ! AND measure_time lt; #{endTime} /if ORDER BY measure_time DESC /select注意一个细节XML中大于小于号必须写转义字符比如要写成。这个坑我见过太多次了很多新手写了号直接导致XML解析报错排查半天找不到原因。MyBatis还有一个容易被忽略的缓存问题。默认情况下MyBatis的一级缓存是SqlSession级别的同一个SqlSession里两次相同的查询会命中缓存。但在SpringBoot整合环境中每个Mapper方法执行完都会关闭SqlSession所以一级缓存基本感知不到。二级缓存默认不开启如果开启了需要注意查询结果发生变更时缓存同步的问题。网上说“MyBatis缓存导致脏数据”的坑多半是在开启二级缓存后没有做好缓存刷新策略。4.3 事务管理与全局异常拦截健康数据录入、工单状态更新这种场景必须加事务控制。SpringBoot里最简单的做法就是在Service方法上标注Transactional注解。比如录入一条健康指标的同时要更新健康档案的最后评估时间这两个操作要么同时成功要么同时回滚。例外的一种情况工单状态流转这种写日志的操作不建议和主流程在同一个事务里强制绑定。因为日志记录即使主操作失败也应该保留否则排障的时候根本不知道流程走到了哪一步。这种情况可以把日志写入放到独立的事务传播行为里比如REQUIRES_NEW或者直接不参与事务。全局异常处理用RestControllerAdvice加ExceptionHandler就可以搞定。Controller层不用每个方法都try-catch代码会干净很多。返回结构统一用Result对象包装里面包含code、message、data三个字段前端拿到之后统一处理。我习惯把业务异常比如参数校验失败、老人不存在和系统异常分开处理业务异常返回业务错误码系统异常返回500并记录完整堆栈。5. 前端Vue3实现要点5.1 项目初始化与路由配置Vue3项目的基础搭建建议使用Vite安装命令npm create vitelatest elderly-web -- --template vue装完之后安装vue-router和pinia作为路由和状态管理库。在智慧养老系统里状态管理主要用来存登录用户信息、权限菜单、未读预警数量这类全局数据。用Pinia比Vuex更轻量API设计也更符合Vue3的组合式风格。路由守卫这里要重点说。前端权限控制除了控制菜单展示还要防止用户直接输入URL跳过权限。在router.beforeEach里判断当前用户是否有权访问目标路由没有权限就重定向到登录页或者404页。这个逻辑虽然简单但很多系统前端只是隐藏了菜单没有做真正的路由守卫导致越权访问漏洞。实测中很多从零学习Vue3的同学第一次在控制台看到“Cannot read properties of undefined”时毫无头绪其实多半是路由守卫里拿到的用户信息为空或者Pinia store没有正确初始化。5.2 页面组件拆分与复用养老系统的页面大体可以分为三类数据看板、列表管理页、表单录入页。数据看板用ECharts渲染各类图表列表管理页用Element Plus的Table组件加分页表单录入页就是各种Form加校验。一个建议在开发前就规划好的事情是通用组件。比如老人信息卡片、健康指标趋势图、预警消息弹窗这些组件在多处都会用到提前抽象成公共组件后面能省很多事。Vue3里自定义组件用defineProps接收参数用defineEmits向外抛事件。具体到健康趋势图父组件只需要传入elderlyId子组件内部自己调用接口拿数据然后用watch监听elderlyId变化重新请求。这种设计让组件变得非常独立换一个老人就刷新一份数据。同样的思路还可以用在“家属绑定老人”这个业务场景里家属端的首页组件接收不同的老人ID展示不同老人的健康概况。5.3 前后端联调与Axios封装Axios请求层一定要统一封装。基础的配置包括baseURL、超时时间、请求拦截器、响应拦截器。请求拦截器里统一加token响应拦截器里统一处理后端返回的Result对象。如果code401说明登录过期直接跳转登录页如果code500用Element Plus的Message组件弹出后端异常信息。跨域问题是前后端分离开发绕不开的坑。开发环境下Vite的dev server可以配置proxy把请求转发给后端比如把/api开头的请求转发到localhost:8080。这样浏览器访问的是前端开发服务器的地址不存在跨域问题。生产环境用Nginx做反向代理把/api路径转发到后端服务。我见过不少同学在开发环境直接改axios的baseURL为后端地址然后被CORS报错折磨一下午其实一个proxy配置就能解决。6. 部署上线与运维经验6.1 本地环境准备开发这个系统本地环境至少要装JDK 8或11、Maven 3.6、MySQL 5.7或8.0、Node.js 16。JDK版本和SpringBoot版本要适配比如SpringBoot 2.7.x一般用JDK 8或11SpringBoot 3.x要求JDK 17。版本不匹配启动直接报错这个问题在初学阶段出现频率极高。MySQL的安装方式有安装版和免安装版两种。免安装版下载压缩包后解压、配置my.ini、执行mysqld --initialize-insecure初始化然后启动服务。这个方案适合希望完全掌握环境细节的同学。能跑起来之后用Navicat或命令行工具执行项目里的sql脚本一次性建好表结构和初始化数据。项目配置文件里的数据库连接串长这样spring: datasource: url: jdbc:mysql://localhost:3306/eldercare?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver这里两个最容易出错的地方一是serverTimezone必须显式指定否则时间字段读写可能偏差8小时二是useSSL建议设为false本地开发环境用不上SSL开了反而可能报警告日志。6.2 打包部署从本地到服务器前端项目打包后是纯静态文件运行npm run build之后生成dist目录。这个目录可以交给Nginx托管同时Nginx配置反向代理把/api路径的请求转发到后端服务的8080端口。后端项目打包则用Maven的package命令打jar包然后java -jar启动。生产环境部署的一个关键点是跨域问题。开发环境前端Vite的dev server可以配置proxy转发请求避免跨域。生产环境更推荐用Nginx统一处理前端静态资源和后端接口通过同域路径区分这样前端代码里axios的baseURL可以留默认值部署更省心。Nginx的关键配置大概是server { listen 80; server_name yourdomain.com; location / { root /opt/eldercare/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这行很关键Vue Router的history模式刷新页面时是请求真实路径如果不配置try_files刷新一个二级路由页面就会404。这个问题在部署Vue3单页应用时几乎必遇。6.3 运维期常见问题系统正式运行后最先遇到的往往是数据库连接数不够。SpringBoot默认的HikariCP连接池最大连接数是10如果前端页面并发请求稍高连接池容易被打满。建议在application.yml里调整最大连接数同时把数据库本身的max_connections也调大一些。另一个高频问题是时区问题。数据库连接串里配置serverTimezoneAsia/Shanghai否则时间字段的读写会出现8小时偏差。这个问题排查起来很隐蔽因为不是所有接口都受影响只有查询某段时间范围的接口才会暴露出来。日志管理方面建议引入Logback的滚动策略按天生成日志文件保留最近30天。日志里一定要把请求URL、操作人ID、耗时打出来后期排查线上问题能不能快速定位基本就靠这些日志。我习惯在Controller的返回值前面加一个AOP切面统一打印接口入参、出参和耗时排查问题的时候效率提升非常明显。7. 常见问题排查速查表现象可能原因解决思路后端启动报DataSource相关错误数据库没启动或连接串配置错误检查MySQL是否启动配置的账号密码权限是否正确前端请求接口返回404Nginx或Vite代理路径配置不对确认/api前缀是否正确是否匹配后端的RequestMapping中文乱码数据库字符集不是utf8mb4建表语句统一CHARSETutf8mb4连接串加characterEncodingutf8token失效提示频繁前端没有把token带到请求头检查Axios请求拦截器是否生效MySQL连接超时连接池配置和数据库wait_timeout不匹配调整连接池的maxLifetime小于数据库wait_timeoutMyBatis SQL报错XML或注解SQL有语法问题打开MyBatis的SQL日志把打印出的SQL复制到数据库客户端执行前端启动报依赖错误Node版本过高或依赖版本冲突统一Node版本删除node_modules和package-lock后重新install这些都是我在实际项目里踩过的坑。比如字符集问题如果建库的时候没有指定utf8mb4初始数据没问题一旦提交带表情符号或中文生僻字的记录直接报错。再比如Nginx代理问题很多人配完发现前端能打开但接口请求全部失败其实就是location路径的斜杠和proxy_pass的路径拼接规则没有搞清楚。多看几遍Nginx的location匹配规则实测一次基本就不会再犯。8. 从源码到二次开发的经验总结拿到这套源码我建议的学习路径是先把数据库脚本跑起来看所有表的结构从表的字段反推业务模块。然后启动后端用Postman逐个调用核心接口理解请求和响应结构。接着启动前端走一遍完整的业务操作流比如给某位老人录入一条健康数据、发起一个服务工单、处理一条预警。最后再回到代码把每个模块的Controller、Service、Mapper串起来读一遍。二次开发时最常见的一类需求是新增健康指标类型。改动点包括字典表新增指标项、健康指标录入页面增加一个Tab、趋势分析页面增加对应的图表配置、后端硬编码的阈值校验条件是否需要补充。只要表结构设计合理这类扩展并不会伤筋动骨。根据我自己的实操经验还有几个细节值得留意。一是MyBatis的批量写操作如果一次要批量插入几十上百条健康指标记录用foreach标签拼接成一个大的INSERT语句比逐条插入快得多但SQL长度和参数数量要控制超过MySQL的max_allowed_packet会报错。二是Vue3的tabs标签页样式Element Plus默认样式偏素实际项目中往往要覆盖样式建议用CSS变量或者深度选择器统一处理不要每个页面写死内联样式。三是接口返回给前端的日期格式建议统一为yyyy-MM-dd HH:mm:ss可以全局配置Jackson的格式化规则否则前端还要额外处理。这套系统的价值在于它把一块真实的业务场景完整落地了而不是停留在增删改查练习层面。把这块源码吃透你对SpringBoot、MyBatis、Vue3这三件套的理解以及前后端分离项目的整体把控能力都会有一个比较明显的提升。后续再去做其他管理类系统你会发现很多套路是相通的只是换了一批表、换了一批页面而已。 基于SpringBoot+Vue3的智慧养老健康管理系统开发实战
1. 项目概述与需求拆解1.1 这个系统到底解决什么问题先说结论这是一套面向社区居家养老场景的数字化管理平台技术栈是SpringBoot Vue3 MyBatis MySQL形态是前后端分离的Web应用。我为什么会盯上这个标题因为智慧社区居家养老健康管理听起来名字长但拆开看其实非常清晰智慧社区是场景居家养老是业务健康管理是核心系统是载体。这几年老龄化趋势明显社区养老、居家养老逐渐成为主流方向而这类系统要做的就是把老人的健康数据、社区服务、家属沟通、应急响应这些环节用数字化的方式串起来让社区运营者、家属、护理人员三方都能实时掌握老人状态。从源码角度来说这是典型的Java后端 Vue3前端 MySQL存储项目。SpringBoot负责提供RESTful APIMyBatis负责数据库操作Vue3负责页面交互MySQL负责数据落地。技术栈非常主流几乎就是目前中小型管理系统项目的标准配置跟着这套代码过一遍等于把“Java面试八股文”里常考的那几块SpringBoot自动配置、MyBatis动态SQL、Vue组件通信、MySQL索引优化全部实战了一轮。这类系统的目标用户通常有三类社区管理端运营人员需要看到辖区老人的基本档案、健康评估、服务工单。家属端用户希望远程了解父母的健康状况、服务记录、异常预警。护理人员或健康管理师需要录入健康数据、查看服务计划、跟进工单。一个完整系统至少要覆盖这三类角色的核心诉求缺了任何一环都只是在做“信息登记”而不是“健康管理”。1.2 技术选型背后的逻辑先讲一个很多人容易忽略的点为什么用SpringBoot而不是传统Spring MVC项目为什么用Vue3而不是Vue2为什么用MyBatis而不是MyBatis Plus或JPA。SpringBoot的核心价值在于“约定优于配置”。你要搭建一个Web服务传统Spring项目需要配置web.xml、spring-mvc.xml、数据源、事务管理器还要手动管一堆依赖版本。SpringBoot把这些全部自动化了一个启动类加几个注解就能跑起来。对于智慧养老这种偏业务型的系统开发效率是第一位的SpringBoot天然合适。而且SpringBoot 2.7.x和3.x是目前市场的主流版本岗位需求量大出了问题社区资料也全。Vue3相比Vue2最大的变化是Composition API和响应式系统的重构。管理系统这种场景页面逻辑复杂、组件复用频繁用Options API写久了组件之间共享状态比较费劲。Vue3的setup函数配合ref、reactive处理跨组件状态、自定义hook都顺手得多。再加上Vite带来的开发体验冷启动和热更新基本是秒级的开发时不用等编译心情都会好很多。MyBatis的选择更有意思。有些人可能会说这种系统用MyBatis Plus更快内置BaseMapperCRUD都不用写SQL。但MyBatis原生版本的SQL可控性更强尤其在多表关联查询、复杂统计报表这些场景下手写SQL反而更清晰。并且项目标题明确写了MyBatis说明作者是刻意保持技术栈的经典性方便学习或二次开发。很多人面试时会背“#{}和${}的区别”在这个项目里你会真正用上这两者的场景条件查询用#{}防注入排序字段用${}动态拼接列名。1.3 适用人群和前置要求想从这套系统源码里真正学到东西我建议至少有这样几个基础会Java基础语法知道类、接口、继承、Lambda这些概念最好能看懂简单的Stream操作。用过Maven知道依赖坐标和本地仓库是怎么回事。懂MySQL基本操作会建库、建表、写增删改查SQL。前端方面知道HTML、CSS、JavaScript基础能理解Vue的单文件组件结构。至少跑通过一个SpringBoot的Hello World项目。如果这些条件还不满足建议先把Java基础和MySQL基础补一下。不是说不能边学边做而是这个系统的定位是实战进阶基础不牢的话会花大量时间在配置排错上反而不容易体会到系统设计本身的亮点。2. 系统核心功能模块拆解2.1 老人档案与健康档案管理这是整个系统的数据基础。每位老人都有一个主档案里面包含基本信息、居住信息、紧急联系人、既往病史、过敏史、用药情况等。健康档案需要在主档案基础上扩展出历次体检记录、慢病随访记录、健康评估结果。在数据库设计上老人主表elderly_info和健康档案表health_profile是一对一关系而体检记录health_check_record、随访记录follow_up_record和主表是一对多关系。用MyBatis处理这种关系时建议直接用多表联查的VO对象来承接结果而不是在一对多映射上过度纠结。这里有一个实际开发中很容易踩的坑不要把所有的健康信息塞进一张大宽表里。我见过有同学把体检指标、心理评估、生活能力评估全部建成一张表结果字段多达数十个后期加一个指标就要改表结构。正确的做法是纵向拆分一类指标一张表通过老人ID和记录类型关联。这样每次新增评估维度只需要新建一张表或者加一个record_type不影响已有数据结构。2.2 健康数据录入与趋势分析护理人员或健康管理师登录系统后可以录入老人每天的血压、血糖、心率、体温等关键指标。这些数据落到健康指标记录表health_index_record一张典型的数据表结构大概是这样CREATE TABLE health_index_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elderly_id BIGINT NOT NULL COMMENT 老人ID, index_type VARCHAR(20) NOT NULL COMMENT 指标类型blood_pressure/blood_sugar/heart_rate/temperature, index_value VARCHAR(50) NOT NULL COMMENT 指标值, measure_time DATETIME NOT NULL COMMENT 测量时间, operator_id BIGINT NOT NULL COMMENT 录入人员ID, remark VARCHAR(255) COMMENT 备注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT 健康指标记录表;需要注意一个设计细节index_value用的是VARCHAR而不是DECIMAL或INT。为什么因为血压的典型值是120/80这种格式血糖可能是6.2体温可能是36.5如果每种指标单独建一个数值字段反而把表结构搞得极其复杂。用字符串存储原始测量值需要做趋势分析时再在代码层或SQL层解析灵活性最高。趋势分析本质上是对时间序列数据的聚合。比如要查某位老人最近30天的血压走势SQL可以这样写SELECT measure_time, index_value FROM health_index_record WHERE elderly_id #{elderlyId} AND index_type blood_pressure AND measure_time DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY measure_time ASC;然后在后端将查询结果封装成前端ECharts折线图需要的格式Vue3端用ECharts渲染即可。时间字段一定要用DATETIME而不是字符串不然后续做范围查询、按天分组统计时会非常痛苦。这是很多初学项目最容易踩的坑建表时贪图方便用varchar存日期上线一个月后做报表那酸爽只有自己知道。2.3 服务工单与派单流程居家养老服务不只是健康监测还包括上门助洁、助餐、陪诊、康复护理等具体服务。这些服务需要以工单的形式流转否则就变成了口头约定管理上容易扯皮。工单模块的业务流程大概是家属或护理人员在系统发起服务申请社区管理员审核后派单给对应的服务人员服务人员接单后上门服务结束后填写服务完成情况家属可以确认并对服务进行评价。这个流程在数据库层面最少需要三张表服务工单表service_order、服务项目表service_item、工单状态流转表order_status_log。状态流转表很多人会忽略但它其实是审计追踪的关键。如果哪天家属和护理员对服务次数有争议状态流转表就能完整还原整个工单的生命周期谁在什么时间把工单从什么状态改成了什么状态一目了然。状态字段建议用整数枚举而不是中文。例如0代表待审核1代表已派单2代表服务中3代表已完成4代表已取消5代表已评价。用整数存状态的好处后端做状态判断干净利落前端用字典翻译成中文展示不会出现中文编码导致的低级问题。2.4 预警提醒与异常处理智慧养老系统真正的价值不只是记录数据而是在异常发生时能主动提醒。比如老人血压连续两天偏高或者某位独居老人当天没有健康打卡记录系统都应该触发预警。预警规则的实现思路并不复杂。可以在服务层写一个定时任务比如每天9点扫描昨天没有健康记录的独居老人列表生成预警记录并推送给家属端。更实时的指标异常判断可以在健康数据录入接口里直接做规则校验一旦发现超出阈值的记录立即生成预警消息。预警数据表至少需要包含老人ID、预警类型、预警内容、触发时间、是否已处理、处理人、处理时间这些字段。前端的处理方式是弹窗提示加消息中心家属端和个人端都要能看到未处理预警的红点提醒。我建议不要把预警做成只管一次的弹窗而是做成可追溯的消息列表因为养老场景里健康预警会反复出现需要留痕。3. 数据库表设计要点与实操3.1 核心表结构规划综合上面拆解的几个模块一个最小可用的智慧养老系统数据库层面至少需要这些表表名用途关键字段sys_user系统用户表id、username、password、real_name、rolesys_role角色表id、role_code、role_namesys_user_role用户角色关联表id、user_id、role_idelderly_info老人基本信息表id、name、gender、birthday、address、contacthealth_profile健康档案表id、elderly_id、blood_type、allergy_history、chronic_diseasehealth_check_record体检记录表id、elderly_id、check_date、check_resulthealth_index_record健康指标记录表id、elderly_id、index_type、index_value、measure_timeservice_item服务项目表id、item_name、item_type、priceservice_order服务工单表id、order_no、elderly_id、item_id、status、assignee_idorder_status_log工单状态流转表id、order_id、from_status、to_status、operator_id、create_timewarning_record预警记录表id、elderly_id、warning_type、content、is_handledfamily_member家属关联表id、elderly_id、user_id、relation从这个表结构能看出系统的领域模型是比较清晰的。用户、角色权限是一套老人及健康数据是一套服务工单是一套预警是一套。分模块后团队成员可以并行开发互不干扰。3.2 自制一个轻量权限模型对于这种系统很多人一上来就引入Spring Security或者Shiro结果配置复杂学习成本也高。其实中小型后台完全可以自己做一个简单的拦截器加角色判断的权限控制而且能更清楚地理解权限控制的核心逻辑。具体做法用户表中存role字段比如0代表管理员1代表护理人员2代表家属。然后在HandlerInterceptor中判断当前登录用户的角色是否允许访问某个路径比如/admin/**只有管理员能访问/family/**只有家属角色能访问。前端再配合Vue Router的路由守卫做菜单级别的控制。用自定义拦截器讲清楚权限控制的原理后后续需要更细粒度的权限控制时再升级到Spring Security JWT方案。你先理解了“什么人能干什么事”这件事看安全框架的所有概念都会轻松很多不然容易在过滤器和拦截器的配置细节里绕昏头。3.3 索引优化与慢查询预防养老系统数据量初期不大但健康指标表和工单状态流转表的数据增长会很快。拿健康指标记录来说一个老人每天可能产生3条记录一个社区500位老人一年就是五十多万条数据。这时候索引的重要性就体现出来了。create_time和elderly_id组合做联合索引是常见做法。因为大多数查询都是先过滤老人ID再按时间排序。SQL大概是ALTER TABLE health_index_record ADD INDEX idx_elderly_time (elderly_id, measure_time);创建完索引之后一定要用EXPLAIN看一下执行计划。我见过不少项目上线之后才发现查询走了全表扫描就是因为建索引的时候没有结合实际的WHERE条件来设计。另外order_status_log表要按order_id做索引预警表按elderly_id和is_handled做联合索引这些都是高频查询路径。索引不是越多越好每次写入都要同步维护索引索引过多会拖慢写入速度。实际项目中先针对慢查询日志中真正慢的SQL去建索引不要凭感觉建。4. 后端SpringBoot核心实现解析4.1 项目结构与启动类一个规范的SpringBoot项目结构应该是清晰的。虽然很多教学项目喜欢把全部代码塞进一个包但真实项目建议按业务模块分包com.example.eldercare ├── config ├── controller ├── service ├── mapper ├── entity ├── dto ├── vo └── commoncontroller层只负责参数接收和结果返回service层处理业务逻辑mapper层负责数据库操作entity对应数据库表结构dto是请求参数的封装vo是响应给前端的对象。这种层次划分在团队协作时特别重要大家各改各的层冲突概率会小很多。启动类本身没有太多好说的标准的SpringBootApplication加main方法。这里一个容易踩的坑是包扫描启动类必须放在所有子包的父包下否则ComponentScan扫描不到各个子模块的Bean启动直接报错“无法注入Mapper”。4.2 MyBatis的常见用法与XML动态SQL在MyBatis的使用上不同开发者有不同风格的写法。有些项目用XML文件管理SQL有些项目用注解直接写在Mapper接口上还有的项目用MyBatis Plus的BaseMapper。这个系统用原生MyBatis做演示的话我更推荐XML方式。原因很简单复杂SQL在XML里面可读性更高改动SQL不用重新编译Java代码而且MyBatis的XML映射是这套框架的核心能力面试也常考。一个典型的Mapper接口长这样public interface HealthIndexRecordMapper { ListHealthIndexRecordVO selectRecordsByElderlyId(Param(elderlyId) Long elderlyId, Param(startTime) String startTime, Param(endTime) String endTime); }对应XML里面的查询语句select idselectRecordsByElderlyId resultTypecom.example.eldercare.vo.HealthIndexRecordVO SELECT id, elderly_id, index_type, index_value, measure_time, remark FROM health_index_record WHERE elderly_id #{elderlyId} if teststartTime ! null and startTime ! AND measure_time gt; #{startTime} /if if testendTime ! null and endTime ! AND measure_time lt; #{endTime} /if ORDER BY measure_time DESC /select注意一个细节XML中大于小于号必须写转义字符比如要写成。这个坑我见过太多次了很多新手写了号直接导致XML解析报错排查半天找不到原因。MyBatis还有一个容易被忽略的缓存问题。默认情况下MyBatis的一级缓存是SqlSession级别的同一个SqlSession里两次相同的查询会命中缓存。但在SpringBoot整合环境中每个Mapper方法执行完都会关闭SqlSession所以一级缓存基本感知不到。二级缓存默认不开启如果开启了需要注意查询结果发生变更时缓存同步的问题。网上说“MyBatis缓存导致脏数据”的坑多半是在开启二级缓存后没有做好缓存刷新策略。4.3 事务管理与全局异常拦截健康数据录入、工单状态更新这种场景必须加事务控制。SpringBoot里最简单的做法就是在Service方法上标注Transactional注解。比如录入一条健康指标的同时要更新健康档案的最后评估时间这两个操作要么同时成功要么同时回滚。例外的一种情况工单状态流转这种写日志的操作不建议和主流程在同一个事务里强制绑定。因为日志记录即使主操作失败也应该保留否则排障的时候根本不知道流程走到了哪一步。这种情况可以把日志写入放到独立的事务传播行为里比如REQUIRES_NEW或者直接不参与事务。全局异常处理用RestControllerAdvice加ExceptionHandler就可以搞定。Controller层不用每个方法都try-catch代码会干净很多。返回结构统一用Result对象包装里面包含code、message、data三个字段前端拿到之后统一处理。我习惯把业务异常比如参数校验失败、老人不存在和系统异常分开处理业务异常返回业务错误码系统异常返回500并记录完整堆栈。5. 前端Vue3实现要点5.1 项目初始化与路由配置Vue3项目的基础搭建建议使用Vite安装命令npm create vitelatest elderly-web -- --template vue装完之后安装vue-router和pinia作为路由和状态管理库。在智慧养老系统里状态管理主要用来存登录用户信息、权限菜单、未读预警数量这类全局数据。用Pinia比Vuex更轻量API设计也更符合Vue3的组合式风格。路由守卫这里要重点说。前端权限控制除了控制菜单展示还要防止用户直接输入URL跳过权限。在router.beforeEach里判断当前用户是否有权访问目标路由没有权限就重定向到登录页或者404页。这个逻辑虽然简单但很多系统前端只是隐藏了菜单没有做真正的路由守卫导致越权访问漏洞。实测中很多从零学习Vue3的同学第一次在控制台看到“Cannot read properties of undefined”时毫无头绪其实多半是路由守卫里拿到的用户信息为空或者Pinia store没有正确初始化。5.2 页面组件拆分与复用养老系统的页面大体可以分为三类数据看板、列表管理页、表单录入页。数据看板用ECharts渲染各类图表列表管理页用Element Plus的Table组件加分页表单录入页就是各种Form加校验。一个建议在开发前就规划好的事情是通用组件。比如老人信息卡片、健康指标趋势图、预警消息弹窗这些组件在多处都会用到提前抽象成公共组件后面能省很多事。Vue3里自定义组件用defineProps接收参数用defineEmits向外抛事件。具体到健康趋势图父组件只需要传入elderlyId子组件内部自己调用接口拿数据然后用watch监听elderlyId变化重新请求。这种设计让组件变得非常独立换一个老人就刷新一份数据。同样的思路还可以用在“家属绑定老人”这个业务场景里家属端的首页组件接收不同的老人ID展示不同老人的健康概况。5.3 前后端联调与Axios封装Axios请求层一定要统一封装。基础的配置包括baseURL、超时时间、请求拦截器、响应拦截器。请求拦截器里统一加token响应拦截器里统一处理后端返回的Result对象。如果code401说明登录过期直接跳转登录页如果code500用Element Plus的Message组件弹出后端异常信息。跨域问题是前后端分离开发绕不开的坑。开发环境下Vite的dev server可以配置proxy把请求转发给后端比如把/api开头的请求转发到localhost:8080。这样浏览器访问的是前端开发服务器的地址不存在跨域问题。生产环境用Nginx做反向代理把/api路径转发到后端服务。我见过不少同学在开发环境直接改axios的baseURL为后端地址然后被CORS报错折磨一下午其实一个proxy配置就能解决。6. 部署上线与运维经验6.1 本地环境准备开发这个系统本地环境至少要装JDK 8或11、Maven 3.6、MySQL 5.7或8.0、Node.js 16。JDK版本和SpringBoot版本要适配比如SpringBoot 2.7.x一般用JDK 8或11SpringBoot 3.x要求JDK 17。版本不匹配启动直接报错这个问题在初学阶段出现频率极高。MySQL的安装方式有安装版和免安装版两种。免安装版下载压缩包后解压、配置my.ini、执行mysqld --initialize-insecure初始化然后启动服务。这个方案适合希望完全掌握环境细节的同学。能跑起来之后用Navicat或命令行工具执行项目里的sql脚本一次性建好表结构和初始化数据。项目配置文件里的数据库连接串长这样spring: datasource: url: jdbc:mysql://localhost:3306/eldercare?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver这里两个最容易出错的地方一是serverTimezone必须显式指定否则时间字段读写可能偏差8小时二是useSSL建议设为false本地开发环境用不上SSL开了反而可能报警告日志。6.2 打包部署从本地到服务器前端项目打包后是纯静态文件运行npm run build之后生成dist目录。这个目录可以交给Nginx托管同时Nginx配置反向代理把/api路径的请求转发到后端服务的8080端口。后端项目打包则用Maven的package命令打jar包然后java -jar启动。生产环境部署的一个关键点是跨域问题。开发环境前端Vite的dev server可以配置proxy转发请求避免跨域。生产环境更推荐用Nginx统一处理前端静态资源和后端接口通过同域路径区分这样前端代码里axios的baseURL可以留默认值部署更省心。Nginx的关键配置大概是server { listen 80; server_name yourdomain.com; location / { root /opt/eldercare/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这行很关键Vue Router的history模式刷新页面时是请求真实路径如果不配置try_files刷新一个二级路由页面就会404。这个问题在部署Vue3单页应用时几乎必遇。6.3 运维期常见问题系统正式运行后最先遇到的往往是数据库连接数不够。SpringBoot默认的HikariCP连接池最大连接数是10如果前端页面并发请求稍高连接池容易被打满。建议在application.yml里调整最大连接数同时把数据库本身的max_connections也调大一些。另一个高频问题是时区问题。数据库连接串里配置serverTimezoneAsia/Shanghai否则时间字段的读写会出现8小时偏差。这个问题排查起来很隐蔽因为不是所有接口都受影响只有查询某段时间范围的接口才会暴露出来。日志管理方面建议引入Logback的滚动策略按天生成日志文件保留最近30天。日志里一定要把请求URL、操作人ID、耗时打出来后期排查线上问题能不能快速定位基本就靠这些日志。我习惯在Controller的返回值前面加一个AOP切面统一打印接口入参、出参和耗时排查问题的时候效率提升非常明显。7. 常见问题排查速查表现象可能原因解决思路后端启动报DataSource相关错误数据库没启动或连接串配置错误检查MySQL是否启动配置的账号密码权限是否正确前端请求接口返回404Nginx或Vite代理路径配置不对确认/api前缀是否正确是否匹配后端的RequestMapping中文乱码数据库字符集不是utf8mb4建表语句统一CHARSETutf8mb4连接串加characterEncodingutf8token失效提示频繁前端没有把token带到请求头检查Axios请求拦截器是否生效MySQL连接超时连接池配置和数据库wait_timeout不匹配调整连接池的maxLifetime小于数据库wait_timeoutMyBatis SQL报错XML或注解SQL有语法问题打开MyBatis的SQL日志把打印出的SQL复制到数据库客户端执行前端启动报依赖错误Node版本过高或依赖版本冲突统一Node版本删除node_modules和package-lock后重新install这些都是我在实际项目里踩过的坑。比如字符集问题如果建库的时候没有指定utf8mb4初始数据没问题一旦提交带表情符号或中文生僻字的记录直接报错。再比如Nginx代理问题很多人配完发现前端能打开但接口请求全部失败其实就是location路径的斜杠和proxy_pass的路径拼接规则没有搞清楚。多看几遍Nginx的location匹配规则实测一次基本就不会再犯。8. 从源码到二次开发的经验总结拿到这套源码我建议的学习路径是先把数据库脚本跑起来看所有表的结构从表的字段反推业务模块。然后启动后端用Postman逐个调用核心接口理解请求和响应结构。接着启动前端走一遍完整的业务操作流比如给某位老人录入一条健康数据、发起一个服务工单、处理一条预警。最后再回到代码把每个模块的Controller、Service、Mapper串起来读一遍。二次开发时最常见的一类需求是新增健康指标类型。改动点包括字典表新增指标项、健康指标录入页面增加一个Tab、趋势分析页面增加对应的图表配置、后端硬编码的阈值校验条件是否需要补充。只要表结构设计合理这类扩展并不会伤筋动骨。根据我自己的实操经验还有几个细节值得留意。一是MyBatis的批量写操作如果一次要批量插入几十上百条健康指标记录用foreach标签拼接成一个大的INSERT语句比逐条插入快得多但SQL长度和参数数量要控制超过MySQL的max_allowed_packet会报错。二是Vue3的tabs标签页样式Element Plus默认样式偏素实际项目中往往要覆盖样式建议用CSS变量或者深度选择器统一处理不要每个页面写死内联样式。三是接口返回给前端的日期格式建议统一为yyyy-MM-dd HH:mm:ss可以全局配置Jackson的格式化规则否则前端还要额外处理。这套系统的价值在于它把一块真实的业务场景完整落地了而不是停留在增删改查练习层面。把这块源码吃透你对SpringBoot、MyBatis、Vue3这三件套的理解以及前后端分离项目的整体把控能力都会有一个比较明显的提升。后续再去做其他管理类系统你会发现很多套路是相通的只是换了一批表、换了一批页面而已。