1. 项目概述与架构设计思路养老行业这几年一直是被技术圈低估的赛道直到智慧养老的概念真正落地大家才发现这里面藏着大量可做的业务闭环。我当初接下这个企业级养老智慧服务平台的时候客户的需求其实很朴素他们旗下有多家养老机构老人信息散落在Excel表格和纸质档案里护理员排班靠微信群喊家属想知道老人今天的血压和活动情况只能打电话问护士。整个管理链条又碎又慢还容易出责任事故。所以这个系统的核心目标非常明确——把老人档案、健康数据、护理任务、费用结算、家属沟通全部拉到一条线上让机构管理者、护理员、家属三方都能通过一个平台完成各自的操作。选择SpringBootVueMyBatisMySQL这套组合不是因为它新而是因为它稳。企业级项目最怕的不是技术不够炫而是团队接手成本高、招不到人、出问题没人能维护。SpringBoot的自动配置和生态成熟度摆在那里Vue在国内前端圈的普及率极高MyBatis对复杂SQL的掌控力比JPA强得多MySQL则是绝大多数中小型企业的标配数据库。这套技术栈招人容易、资料多、排错快是典型的“性价比最优解”。我在前期的技术选型评审会上也考虑过Spring Cloud Alibaba微服务方案但最终放弃了——项目初期单体应用完全够用强行拆微服务只会增加部署和运维的复杂度等业务量真的上去再拆分也不迟。整个系统的角色权限分三层超级管理员管全局机构管理员管单个院区护理员和家属各看各的数据。模块划分上我拆出了老人档案管理、健康监测与评估、护理工单派发、床位管理、费用管理、家属端小程序接口、数据可视化大屏这七个子系统后面几个章节我会逐个拆解核心实现。1.1 技术选型背后的取舍逻辑后端我用的是SpringBoot 2.7.x版本JDK 1.8因为客户现场环境比较保守Java 8在云服务器上跑得最稳而且不需要额外处理模块化相关的问题。如果你用的是更高版本主要麻烦在于依赖兼容性比如MyBatis-Spring-Boot-Starter某个小版本对JDK升级后的字节码处理会出问题排查起来既费时间又容易让人怀疑是不是自己的代码写错了。所以除非有特殊需求我建议直接锁定Java 8。MyBatis我是用XML方式写SQL的没有用注解。这里有个很实际的原因养老平台里查询条件多且杂老人列表可能按姓名、身份证号、入住状态、院区ID、护工ID、时间段等多条件组合过滤这种动态SQL用XML的if和where标签写最清晰注解方式拼接起来会非常痛苦可读性差且容易漏条件。再者后续调优SQL的时候DBA只需要看XML文件就能直接改不需要动Java代码。持久层的选择永远是“能底控到什么程度”优先。前端选了Vue 2.7 Element UI。可能有人会说Vue 3都出来这么久了为什么还在用Vue 2原因有三一是Element UI对Vue 2的组件生态最成熟养老管理后台需要的表格、表单、树形控件、日期选择器这些开箱即用二是客户方后续可能有外包团队接手Vue 2的市场存量代码量大找人接盘容易三是这套系统的页面交互复杂度不算顶尖Vue 2完全扛得住没必要为了“升级”而升级。如果你是新项目且团队没历史包袱直接上Vue 3 Element Plus也没问题但如果是接手我这类老项目保持版本一致会更省心。1.2 系统整体模块拆分与数据流走向系统的数据流是典型的“录入-流转-闭环”模式。以护理工单为例护士在后台录入老人的每日护理计划系统根据计划自动生成工单护理员在移动端接单并执行执行完成后回填实际执行情况系统同步记录到老人的护理档案里最后费用模块根据护理等级和工单数量自动计算费用。整条链路的数据都围绕“老人ID”这个主键流转所有业务表都通过老人ID关联避免数据孤岛。这种拆分方式的好处在于每个模块都有独立的Service层和Mapper层业务边界清晰。比如健康监测模块只管血压、血糖、心率、体温这些指标数据的录入和趋势分析跟护理工单模块互不干扰。后面接智能手环、智能床垫等IoT设备时只需要新增一个数据采集接口把设备数据落到健康监测表里上游业务不需要改动。这也算给客户预留了未来的扩展空间企业级项目这东西不能只看眼前。2. 数据库设计与企业级表结构实践数据库是一套管理系统的地基地基没打好后面写业务代码就是给自己挖坑。这套系统的核心表我设计了15张左右包括用户表、角色表、权限表、老人档案表、家属关系表、床位表、护理等级表、护理工单表、健康监测表、费用流水表、操作日志表等。老人档案表和用户表做了逻辑分离因为老人本身不一定是登录用户而他的子女家属才是用户。如果用一套用户表硬扛所有角色后续扩展角色维度的时候肯定要返工。2.1 核心表结构设计与字段规范先聊聊老人档案表。这张表是全系统的数据枢纽字段设计上除了基本的人口学信息姓名、性别、身份证号、出生日期、紧急联系人等还保留了一个非常重要的逻辑删除字段deleted配合create_time和update_time使用。企业级项目一律禁止物理删除这是铁律。为什么老人档案一旦物理删除关联的护理记录、健康数据、费用流水就全断掉了轻则查不到历史数据重则面临审计合规风险。用逻辑删除只是在查询条件里加一个where deleted 0成本极低收益很高。床位表的设计需要特别提一下因为这里藏着一个容易踩坑的点床位状态必须是“空闲/已入住/维修中/预留”四态而不是简单的“空闲/占用”两态。养老院的实际场景中经常出现床位维修、家属预留的情况如果只有两态就得用备注字段硬凑查询统计时就会乱。每个床位还关联了房间号、楼层、区域自理区/失能区/失智区这些字段是后面做可视化大屏统计的重要维度。健康监测表我用了“一行一指标一记录”的设计也就是每条记录只存一个指标的数据。比如同一天给老人测量了血压和血糖那就会生成两条记录通过老人ID和监测类型字段区分。看起来数据行数会膨胀得很快但实际查询效率反而更高因为按时间范围和指标类型查数据时只需要单表索引扫描。如果按传统思维“一行存所有指标”用JSON或者多个可空字段不仅索引效率低而且不同设备上报的数据维度还不一样字段根本没法一次性设计完。这种设计叫作“纵表”在IoT数据场景里非常常见。2.2 MySQL关键配置与索引优化实战MySQL版本我建议用5.7或者8.0都行客户环境用的是5.7.44。安装之后第一件事就是把字符集改成utf8mb4而不是utf8因为utf8在MySQL里是utf8mb3的别名存不了emoji表情家属端反馈留言里万一有人发个表情就报错了。改法是在my.cnf里加[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_unicode_ci数据库连接串上也要带上编码参数jdbc:mysql://localhost:3306/eldercare?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai这个serverTimezone建议显式指定否则SpringBoot 2.x连接MySQL 8.0时会报时区错误。这些都是基础中的基础但我在项目现场发现很多同行真的会漏掉。索引优化这块核心规则就一条高频查询条件建联合索引排序字段进索引。老人列表页常规查询是按院区ID、入住状态、入住时间倒序排列所以建联合索引(deleted, campus_id, status, checkin_time)注意deleted字段一定放第一位因为所有查询都带这个条件索引最左前缀原则下它能直接过滤掉大部分逻辑删除数据。费用流水表按老人ID和时间段查建(elder_id, create_time)联合索引。我实测过数据量到50万级的时候联合索引比单列索引的查询性能提升在3倍以上。MyBatis的Mapper映射里所有的表名、字段名我建议用驼峰还是下划线直接用下划线保留原样开启驼峰自动映射map-underscore-to-camel-case: true让Java实体类用驼峰命名两者自动对应写SQL的时候不会因为大小写问题出错。这些配置在application.yml里一行搞定mybatis: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpllog-impl我建议开发环境开成StdOut方便实时看到SQL执行情况生产环境删掉或者换成SLF4J否则日志量太大容易把磁盘写满。3. 后端核心功能实现与SpringBoot集成细节后端开发不是把接口写出来就完事的关键要看代码怎么组织、事务边界怎么划分、权限怎么拦截、SQL怎么写不出慢查询。我按Controller-Service-Mapper三层结构组织代码Controller层只做参数接收和简单校验Service层放业务逻辑和事务Mapper层纯数据访问。这样组织的好处非常直接接口出问题先从Controller找参数业务逻辑出问题去Service层排查SQL性能问题只看Mapper的XML就行。排查链路清晰了维护成本自然就降下来了。3.1 统一返回体与异常处理机制企业级项目的接口不能今天返回一个Map明天返回一个JSONObject前后端对接会变得非常痛苦。我写了一个统一返回体Result结构包含code、message、data三个字段配合一个全局异常处理器。异常处理器的原理是通过RestControllerAdvice捕获所有未处理的异常让系统异常也返回固定结构的响应体而不是满屏的堆栈信息裸奔到前端。这是一个非常基础但极其容易被忽视的环节。我看到太多项目在联调阶段前端跑来问“这个接口为什么返回的是这样一段HTML错误页”多半就是没做全局异常处理。实际开发中我还单独定义了一个BusinessException携带错误码和错误信息。比如护理员试图操作用户ID不存在的数据业务层就抛BusinessException全局异常处理器捕获后返回给前端“老人信息不存在请刷新后重试”用户体验和代码可读性都提升很多。3.2 关键业务模块的SQL写法与事务控制把最核心的健康监测趋势图和护理工单派发这两块单独拎出来讲讲。健康监测趋势图的SQL是一个典型的动态条件查询加时间分组逻辑select idselectHealthTrend resultTypejava.util.HashMap SELECT DATE_FORMAT(record_time, %Y-%m-%d) AS date, ROUND(AVG(record_value), 1) AS avg_value FROM health_record where if testelderId ! null elder_id #{elderId} /if if testmetricType ! null and metricType ! AND metric_type #{metricType} /if if teststartTime ! null AND record_time #{startTime} /if if testendTime ! null AND record_time lt; #{endTime} /if /where GROUP BY date ORDER BY date /select这里要注意一个细节endTime判断里的要在XML里写成lt;否则XML解析会直接报错。还有GROUP BY之前最好先确认索引覆盖了record_time字段否则数据量大之后这条聚合查询会很慢。我在现场遇到过类似的情况最后给(metric_type, record_time)加了个联合索引秒回。护理工单的创建逻辑涉及多表操作生成工单、更新护理计划状态、记录操作日志这三步必须在一个事务里完成不能出现工单生成了但日志没记录的情况。实现上就是在Service方法上直接加Transactional注解默认回滚策略是碰到RuntimeException和Error就回滚碰到检查性异常不会回滚。所以我代码里自定义异常都继承RuntimeException这样能保证事务在业务任何环节出错时都能安全回滚。这个注解的原理几句话能讲清楚Spring在运行时通过AOP给方法生成代理对象只有从外面调用这个代理对象的方法时事务才会生效。如果你在同一个类里内部调用加事务的方法注解是不生效的因为走的是this而不是代理。这个坑我踩过这里专门提醒一句。3.3 JWT登录认证与接口权限控制登录认证这块我用的方案是Spring SecurityJWT但我把默认的登录认证流程给屏蔽掉了自定义了一个Token过滤器。核心逻辑前端调用登录接口验证用户名密码成功后后端签发JWT后续每个请求在Header里带上Token过滤器拦截请求后解析并校验Token把用户信息塞进SecurityContext里。这个方案的成熟度和安全性都很高。代码结构大致是这样OncePerRequestFilter的子类里使用SecurityContextHolder在上下文中存放认证对象然后放行到Controller层。权限控制通过PreAuthorize(hasAuthority(admin:elder:add))这类注解实现权限点做到按钮级别。比如家属端的接口只有绑定了老人关系的账号才能访问在Service层里除了JWT的用户角色校验外还要再做一层业务数据校验查这个用户和老人的关联关系不匹配就抛异常。只用权限注解是防不住水平越权的真正要做的是数据级别的校验这个容易被新手忽略。4. 前端Vue实现与部署集成方案前端这块我用的是Vue全家桶路由用vue-router状态管理用VuexUI组件库是Element UI。整个前端工程用vue-cli 4搭建配置了开发环境的代理转发把/login、/api开头的请求全部转发到后端的8080端口这样开发的时候前端和后端各跑各的也不会遇到跨域问题。开发环境的代理配置在vue.config.js里module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } };生产环境这套架构就不对了因为前端dist和SpringBoot的Jar包是部署在同一个服务上的不需要跨域。我的方案是把前端打包后的dist目录复制到SpringBoot项目的resources/static目录下再设置一个规则静态资源请求让SpringBoot直接返回文件不是静态资源的请求全部转发到index.html上交给前端路由接管。这样一来整个系统就是一个独立的SpringBoot应用无论放哪个服务器都能跑部署成本几乎为零。4.1 核心页面与用户交互实现思路先说说管理后台最常用的老人管理页。这个页面包含了左侧的院区树形结构、右上方的搜索栏、中间的表格、底部的分页数据交互频率非常高。这个页面的数据量如果超过几万条一次性加载全部数据体验会很差我用的是分页查询加懒加载的方式每次只请求当前页的数据翻页时再拉取下一页。表格里的状态字段是用标签组件展示的状态不同背景色也不同比如血压偏高显示红色、正常显示绿色。这种直接用前端判断显示的方案比后端把样式字段都传回来要合理得多后端只回传数据前端根据自己的业务语义做渲染。健康数据可视化这块用的是ECharts。按老人ID和时间范围拉取数据之后前端把从后端拿到的每一天的聚合值转成ECharts要求的数组结构然后调用setOption渲染折线图。这里有个细节ECharts实例一定要在组件beforeDestroy生命周期里调用dispose销毁否则页面反复切换路由时会出现内存泄漏页面越来越卡。这个坑我前期没注意运营反馈“系统用了三天之后会变得很卡”排查半天才发现是图表实例没销毁。另外一个重要的交互是护理工单的派发和接单流程。护理员端我单独做了一套简化版页面只显示和自己相关的工单列表点进去能看到老人信息和护理项明细做完勾选完成并填写备注。这里前端用到了vue-router的守卫机制在路由meta里配置角色权限比如护理员角色只能访问移动工作台相关的路由其他路由直接跳转到404页面或禁止访问页。前端路由守卫只是一种体验上的过滤真正挡不住恶意请求所以后端接口的鉴权仍然是必须的这点一定要跟团队的同事讲清楚。4.2 前端打包与SpringBoot整合部署实录部署环节是整个项目最容易出幺蛾子的地方我给出一份可以被直接照抄的组合流程。前端打包命令npm install npm run buildbuild完成之后dist目录下会生成静态文件。然后把这几个文件直接复制到SpringBoot项目的src/main/resources/static目录下。直接在IDE里操作是拖拽复制命令行操作就是cp -rf dist/* /path/to/springboot/src/main/resources/static/然后在SpringBoot项目里加一个Controller作用是处理history模式下的前端路由回退。我记得VueRouter默认用的是hash模式地址栏里会带个#号虽然能用但不太美观。你要是想用history模式就必须加这个Controller否则用户按F5刷新某个非根路径时会直接404Controller public class ViewController { RequestMapping(value {/, /{path:[^\\.]*}, /{path:^(?!api$).*}/**/{path:[^\\.]*}}) public String forward() { return forward:/index.html; } }这段代码的意思是所有不带文件后缀的请求路径比如 /home、/elder/list都交给index.html去处理让vue-router自行解析。而带文件后缀的请求比如 .js、.css、.png走静态资源映射直接在static目录里找文件。这样配置完之后一个Jar包就能直接启动整个系统包括前后端。我曾经用这种方式发给客户一个演示包对方在Windows服务器上双击起Jar包就能用了省去了配置Nginx和申请域名的麻烦。5. 系统部署、运维与常见问题排查方案部署方案我这里分两个环境来讲。开发环境用IDE直接启动SpringBoot数据库连接本地MySQL。测试和生产环境打包成Jar包用systemd或者Windows服务的方式做守护启动。服务器配置建议是2核4G起步因为一个Jar包加上一个MySQL进程内存占用到2.5G左右属于正常水平再小会很勉强。如果访问量真的大起来前端用Nginx扛静态资源来做动静分离后端再用云数据库扩容路径是现成的。5.1 常见问题排查与解决方案速查表我把这一年来在项目里实际踩过的坑和对应的排查方法整理成了一张表给同行做个参考问题现象根本原因排查方法与解决方案前端登录后刷新页面就404vue-router的history模式缺少后端路由回退增加ViewController做无后缀路径转发到index.html中文乱码短信验证码里的汉字变问号数据库字符集没有设置为utf8mb4修改my.cnf并重启MySQL已有表用ALTER TABLE语句转字符集线上接口报错但控制台没有SQL日志log-impl配置被移除了临时开启StdOutImpl看执行日志或接SkyWalking这类APM工具分页查询出现重复数据MySQL分页时没有ORDER BY唯一性字段查询SQL必须加排序字段最好用主键id兜底PageHelper分页不生效查出来的是全表数据数据库方言配置或PageHelper版本不兼容检查pagehelper依赖版本和helper-dialect配置数据库连接池满了系统卡死连接泄漏通常是事务方法里捕获了异常但没回滚用HikariCP的监控指标排查泄漏检查事务注解是否能按预期生效前端页面打包后图片资源404vue-cli的publicPath配置不对把publicPath从相对路径改成绝对路径或 ./ 并确保路径层级匹配多条件组合查询越来越慢没有给高频查询建联合索引用EXPLAIN分析执行计划按最左前缀原则添加联合索引5.2 性能优化与上线前自检清单性能优化这件事实操上比想象中简单大部分瓶颈都在数据库层面。前端打包后的静态文件用Gzip压缩通常js文件能压缩60%以上首屏加载速度体感翻倍。后端层面的优化主要在查询效率核心列表查询禁止使用select *只查需要的列减少IO和网络传输大字段比如老人健康备注单独拆到明细表主表查询不加载。这些都是写代码阶段就要立的规矩。上线前自检清单也顺带分享一下第一修改默认密码这条虽然是常识但出问题最多的就是它第二确认MySQL开启了binlog保证数据库能恢复到任意时间点第三全局搜索代码里有没有System.out.println全部替换成log第四用压测工具Jmeter跑一遍核心接口看吞吐量和错误率是否符合预期第五备份数据库到异地存储。这五条如果都能落实项目上线之后的半夜电话能少接一大半。5.3 项目扩展方向与二次开发建议这套平台做完上线之后客户一定会提出新需求这是企业级项目的常事。最常见的扩展方向是IoT设备接入。有些智能手环有对外开放的HTTP接口只需开发一个数据同步模块定时拉取设备数据写入健康监测表即可。如果需要对接的厂商没有开放接口就用ModBus协议做一体机对接这块和SpringBoot没有直接关系单独起一个采集服务即可。还有一类常见的扩展是大屏可视化把整个养老院的床位利用率、护理员工作量、老人健康预警数量全部集中到一块LED大屏上。这时候前端部分可以用DataV来做图形渲染后端直接复用现有的统计接口不需要改任何业务逻辑。二次开发最核心的建议是业务逻辑一定要写在Service层并且通过接口暴露不要在前端页面里做大量的逻辑处理。这样第三方的数据接入和页面扩展都能在不破坏现有功能的前提下进行。我见过太多项目在赶工期的时候把判断逻辑直接写在Vue的方法里导致后期一个数据来源变了要改十来个页面。千万不要这么干。6. 安全管理与日志监控体系建设安全管理在企业级项目里永远是优先级最高的事情。养老平台涉及大量老人隐私信息包括身份证号、联系方式、病史数据、床位信息一旦泄露就是大事故。我从一开始就把安全体系横切到所有模块里去。密码存储用的BCrypt加密算法不存明文。哪怕数据库被人拖走了拿到的也是无法还原的密文BCrypt每次加盐同一密码两次生成的密文都不一样防止撞库攻击。登录接口做了验证码用图形验证码防止羊毛党脚本暴力破解。JWT的过期时间我设置在2小时前端在Token即将过期时主动调用刷新接口避免用户用着用着突然被踢下线的不良体验。接口层的防SQL注入更不用说MyBatis里全部参数用#{}占位符而不是${}拼接。${}会直接把参数值拼进SQL语句一旦有人把条件参数恶意改成了一段SQL片段就是灾难性的。如果真有必须动态传表名或者排序字段的场景那也只能做白名单校验不允许用户直接传字段名进去。这个区分我反复跟团队强调过这是底线问题。日志监控这块我用的是SLF4J加Logback。核心业务操作比如老人入住的创建、费用调整操作都打了info日志并记录操作人ID和时间系统登录失败、权限拒绝、异常堆栈自动打到单独的错误日志文件里。配合日志检索工具对接到已有的ELK或者简单点直接ssh进服务器tail -f日志文件就能看。对于没有专职运维的团队能做到这一步已经很专业了。调试的时候开StdOut日志可以实时看到完整SQL这是和DBA配合调优的利器。7. 项目交付与落地实施经验项目做完了不代表就可以撒手了企业级项目的交付往往比开发本身更考验人。我在这个养老平台的项目中总结出一套给别人配合的落地策略在这里一并分享。第一阶段是先做试点院区的数据初始化。把老人们的纸质档案按Excel模板整理好批量导入系统。这一步要特别小心身份证号、入住日期、护理等级这些关键字段的准确性因为它们是后续所有业务流转的基础。我写了一个Excel导入工具通过Apache POI读取模板逐行校验后用MyBatis批量插入一次导入几千条也不成问题。第二阶段是给护理员做培训。这比写代码要难得多因为很多护理员年纪偏大对系统天然有排斥心理。我当时的做法是先选两三个接受度高的护理员做种子用户让他们尝到甜头比如手机上报工单比手写纸质单快得多再让他们去影响其他同事。系统设计上也做了妥协比如移动端页面全部用大按钮大字表单单选框代替手动输入让操作尽可能简化。第三阶段就是全面上线和验收了。上线初期我安排了全员陪跑的现场支持随叫随到收集了大量真实使用反馈比如“这个表格能不能默认按入院时间排序”“这个按钮颜色看不清楚”。这些反馈大部分是合理的后面在一个月内迭代了三个小版本把体验打磨到让使用者舒服为止。系统的终极目标不是技术多先进而是能让那些跟电脑打了半辈子交道的人少花五分钟办完事多花五分钟陪老人说说话。看到护理员叔叔阿姨们熟练地掏出手机点来点去的时候我会觉得这段时间的熬夜加班全都值了。最后再分享一个小技巧去现场维护的时候随身带一个装了全套环境的移动硬盘包括JDK、MySQL安装包、Redis、项目部署包和一份部署文档。客户现场的网络和环境你永远预料不到有了这套东西基本能在半小时内把新环境拉起来。这个习惯帮我救了好几次急配合了不知道多少遍无论对方是云服务器还是内网机房都能快速交付。