尧图网页设计 
1. 为什么养老监护平台选择了SpringBootVue而不是其他方案社区智慧养老监护平台这个项目本质上是一个典型的Java Web管理系统需要管理老人档案、健康监测数据、护工排班、家属通知、设备报警记录还要有后台管理页面供社区工作人员日常操作。项目名称里把SpringBoot、Vue、MySQL、MyBatis都点出来了这其实也代表了目前国内中小型管理系统最主流、最容易招人接手的一套技术组合。我接触过不少类似的管理系统需求最开始也犹豫过到底用什么架构。社区养老平台的特点是并发量不高、业务逻辑复杂、报表和状态流转多、需要频繁与第三方设备对接手环、血压计、呼救按钮还要考虑后续维护的人能不能快速上手。如果上微服务对社区项目来说就是杀鸡用牛刀如果只用JSP加Servlet前后端耦合严重页面维护成本会很高。最后落在SpringBootVue这套组合上是因为它在工程化、开发效率、招人成本和部署难度之间取得了最好的平衡。1.1 这个平台到底要解决社区里的什么问题养老监护不是一个单点功能而是把社区里分散的信息串起来。我实际梳理业务时把核心场景拆成了四类社区工作人员需要知道每一位老人的基本信息、紧急联系人、既往病史、用药情况。家属希望远程看到老人的健康状态比如血压、心率、睡眠时长以及护工是否按时上门。护工需要接到任务提醒比如某位老人今天该测血糖了或者手环上报了异常心率。管理人员需要看到全局数据比如哪个片区报警最多、哪些老人最近体征不稳定方便安排回访。这四类场景决定了系统不是单纯的CRUD而是“档案管理设备数据接入任务流转报警通知”的组合。所以项目标题里强调“监护管理”核心不是展示数据而是处理异常状态和任务闭环。我的开发习惯是先列角色再定权限最后才写接口。这个项目最终拆成了五类角色系统管理员、社区工作人员、护工、家属、老人家属查看端。其中老人本身不登录因为大部分老人不习惯用App但家属端一定要有否则“监护”两个字就没有落到人身上。1.2 技术选型的对比过程选型不能只看技术新不新要看团队和运维能力。我当时列过一个对比表技术组合优点缺点是否适合本项目SpringBoot Thymeleaf前后端一体部署简单页面交互弱难以做复杂状态联动勉强可以SpringBoot Vue前后端分离后期好维护需要处理跨域和双端部署很适合SpringCloud微服务全家桶扩展性强运维成本高社区项目没有必要不适合PHP Native页面上手快长期维护和Java生态差距大不建议SpringBoot的优势在于自动配置和起步依赖几分钟就能把Web项目跑起来MyBatis则适合团队里习惯写SQL的开发者尤其是多表关联查询多、报表SQL复杂的时候直接写XML比JPA的自动SQL更直观。Vue2/Vue3都可以我建议普通管理系统直接用Vue2加Element UI稳定资料多除非你明确要用Vue3的组合式API和vite否则别给自己找麻烦。选型还有一层考虑是源码交付。项目标题带“完整源码”意味着很可能需要交给别人二次开发。SpringBootMavenMySQLMyBatis这套东西任何一个学过Java的都能快速看懂换成别的冷门框架交付之后维护成本就大了。2. 数据库设计从老人档案到报警记录的完整表结构数据库设计是这个项目里最不能省时间的部分。SpringBoot和Vue都是工具数据的准确性和流转逻辑才是系统的命。我设计表时遵循一个原则一个社区可能同时管理几百位老人表不能设计得太散但也不能把所有东西塞进一张大宽表。2.1 核心数据模型拆分我从业务对象入手最终整理出了下面这些核心表elder老人基础档案包括姓名、身份证号、住址、紧急联系人、既往病史、护理等级。device设备信息表包括设备编号、设备类型手环、血压计、呼救按钮、绑定老人ID、状态。health_record健康监测记录包括老人ID、设备ID、心率、血压、血氧、体温、采集时间。alert_record报警记录包括报警类型心率异常、跌倒、呼救、报警级别、处理状态、处理人、处理时间。care_task护理任务包括任务类型上门、测血压、送药、执行护工、计划时间、完成状态。user/role/user_role用户和权限。family_binding家属与老人的绑定关系方便推送通知。operate_log操作日志记录谁在什么时候改了什么。这个模型看起来不复杂但每一张表都有隐藏的坑。比如health_record会随着设备上报涨得很快一定要建索引联合索引(elder_id, collect_time)几乎是必须的。比如报警表的状态字段我建议用0待处理、1已处理、2已忽略不要只有布尔值因为运营人员需要将来回头查历史。我在设计时特别加了一个alert_source字段用来区分报警是设备自动上报、家属手动上报还是工作人员登记。这个字段看似多余但后面做报表统计时非常有用可以分别看设备可靠性、人工漏报率。2.2 关键表结构示例以下是alert_record表的核心建表SQL实际项目还要加上create_time、update_time等通用字段CREATE TABLE alert_record ( id bigint(20) NOT NULL AUTO_INCREMENT, elder_id bigint(20) NOT NULL COMMENT 老人ID, device_id bigint(20) DEFAULT NULL COMMENT 设备ID, alert_type varchar(32) NOT NULL COMMENT 报警类型heart_rate/fall/sos/blood_pressure, alert_level tinyint(4) NOT NULL DEFAULT 1 COMMENT 报警级别1一般2严重3紧急, alert_source varchar(32) NOT NULL DEFAULT device COMMENT device/family/staff, content varchar(500) DEFAULT NULL COMMENT 报警描述, handle_status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待处理 1已处理 2已忽略, handle_user_id bigint(20) DEFAULT NULL COMMENT 处理人ID, handle_time datetime DEFAULT NULL COMMENT 处理时间, handle_remark varchar(500) DEFAULT NULL COMMENT 处理备注, PRIMARY KEY (id), KEY idx_elder_time (elder_id, create_time), KEY idx_status_level (handle_status, alert_level) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT报警记录表;有两点经验说给新手听。第一字符集一定要用utf8mb4因为老人名字里可能会有生僻字普通utf8放到MySQL里会变成乱码甚至报错。第二业务字段尽量加COMMENT这个平台后期要交接别人看表结构时注释比实体类上的注解还管用。数据库设计阶段最容易犯的错是把“护工和老人的关系”做成一对一。实际社区里一个护工会负责多个老人一个老人也可能有多个护工上门所以关系表一定要单独建。我用的是一张care_relation表字段包括护工ID、老人ID、开始日期、结束日期这样排班、统计工作量都方便。3. 后端落地的关键点SpringBoot项目结构、MyBatis动态SQL与报警闭环数据库定了以后后端开发就顺畅很多。项目的后端我采用标准的Controller-Service-Mapper三层结构没有过度设计。这个项目里最考验功底的不是增删改查而是报警处理流程和MyBatis动态查询的写法。3.1 项目目录怎么分才能让源码清晰可读我见过太多培训班式的项目所有Controller堆在一个包下面代码完全没法看。这个平台我用的目录结构如下com.community.eldercare ├── controller │ ├── ElderController.java │ ├── DeviceDataController.java │ ├── AlertController.java │ └── CareTaskController.java ├── service │ ├── AlertService.java │ ├── DeviceDataService.java │ └── ... ├── mapper │ ├── ElderMapper.java │ ├── AlertMapper.java │ └── ... ├── entity │ ├── Elder.java │ ├── AlertRecord.java │ └── ... ├── dto │ ├── AlertQueryDTO.java │ └── ... ├── common │ ├── Result.java │ ├── GlobalExceptionHandler.java │ └── ... └── config └── WebConfig.javaResult统一封装返回结构前端拿到的永远是{code, message, data}这样联调时省掉很多口头约定。GlobalExceptionHandler处理参数校验和业务异常避免每个Controller都写try-catch。这些基础设施看着简单但能把代码质量拉开一大截。3.2 MyBatis动态SQL的核心用法报警查询是这个项目使用频率最高的接口。社区工作人员打开“待处理报警”页面时需要按老人姓名、报警级别、报警类型、时间段组合筛选。用MyBatis的where和if标签写动态SQL比每次拼接字符串不知道好到哪里去。select idqueryAlertList resultTypecom.community.eldercare.entity.AlertRecord SELECT a.*, e.name AS elder_name FROM alert_record a LEFT JOIN elder e ON a.elder_id e.id where if testelderName ! null and elderName ! AND e.name LIKE CONCAT(%, #{elderName}, %) /if if testalertLevel ! null AND a.alert_level #{alertLevel} /if if testalertType ! null and alertType ! AND a.alert_type #{alertType} /if if teststartTime ! null AND a.create_time gt; #{startTime} /if if testendTime ! null AND a.create_time lt; #{endTime} /if /where ORDER BY a.create_time DESC /select这里要特别注意和在XML里要转义成gt;和lt;不然XML解析会直接报错。还有一个经验能用LIKE做模糊查询的时候就要控制范围如果后期数据量大了建议换成分页加全文索引但这套小系统用LIKE足够了。3.3 健康数据上报和报警闭环的实现过程设备数据上报接口是我最先写的因为前端页面能不能看到实时数据完全取决于它。硬件手环通过HTTP POST把数据推给后端JSON结构大致是{ deviceCode: HB00123, heartRate: 92, bloodPressureHigh: 135, bloodPressureLow: 85, oxygen: 97, collectTime: 2025-01-15 08:30:00 }Controller接收后先根据deviceCode查到绑定的老人ID再插入health_record然后判断指标是否超过阈值。阈值我放在系统参数表里没有写死在代码中这样运营人员可以在后台调整不用重新发版。报警闭环是重点我给它设计了四个状态设备上报触发报警→生成待处理记录→工作人员点击处理→填写处理结果。如果一条报警超过30分钟还没处理系统需要自动升级给值班负责人短信提醒。短信接口我用的是第三方平台但代码里做了接口封装方便以后换成别的供应商。我踩过的坑是处理报警的时候工作人员可能同时开着多个页面导致重复处理。解决办法很简单Service层处理前先加一个UPDATE alert_record SET handle_status 1 WHERE id #{id} AND handle_status 0通过受影响行数判断是否被其他人抢先处理。这种“乐观锁”的思路在管理系统里非常实用。3.4 分页查询不能只靠前端分页是每个后台管理系统都躲不开的事情。MyBatis的PageHelper在这类项目里几乎是标配用起来就一行代码PageHelper.startPage(pageNum, pageSize); ListAlertRecord list alertMapper.queryAlertList(queryDTO); PageInfoAlertRecord pageInfo new PageInfo(list);但千万注意PageHelper只能在第一次执行的Mapper查询中生效。如果你在Service层先查了别的表再查目标表分页就可能跑到错误的SQL上。所以我在Service层里只要用了PageHelper就保证紧接着只执行目标查询中间不做其他多余操作。4. 前端Vue部分的实现管理后台怎么设计才能让工作人员用起来顺手前端是整个系统的脸面。社区工作人员年龄普遍不小他们不会关心你用了什么技术只关心页面好不好找、按钮显不显眼、有没有明显的反馈。Vue的角色是负责把这些交互逻辑组织好。4.1 路由、菜单和权限的处理方式Vue项目我采用的是Vue Router加本地路由守卫后端登录成功后返回token和角色标识。前端根据角色动态生成侧边栏菜单。简单说router里配置好所有页面路由但在beforeEach守卫里判断用户是否登录、当前角色是否允许访问某个路径。社区工作人员可能只看到“老人管理、报警处理、护理任务”管理员才能看到“用户管理、报表统计”。菜单的数据来源是一个静态映射表因为角色只有五种动态路由的性能收益不大还容易出权限漏洞。const roleMenus { admin: [/dashboard, /elder, /alert, /task, /device, /user, /report], staff: [/dashboard, /elder, /alert, /task], caregiver: [/task, /elder], family: [/elder, /health] };这种做法比后端下发菜单树简单得多适合中小型项目。如果以后角色多了再改成数据库动态配置也不迟。4.2 数据列表页和表单页的Vue组件设计首页仪表盘的图表我选了ECharts用来展示报警趋势和健康数据波动。ECharts这部分没有特别复杂的逻辑主要是把后端返回的时间序列数组转成图表的series数据。报警处理页是前端最核心的页面。我把它做成一个列表每一行显示老人姓名、报警类型、报警时间、级别标签右侧是处理按钮。点击后弹出一个Dialog填写处理结果。这个页面要注意的点是处理成功后不要只console.log一定要重新请求列表数据否则界面状态和数据不一致用户会以为操作没成功。老人档案表单比较长有基本信息、健康信息、家庭信息、紧急联系人。Element UI里的el-form虽然好用但校验规则写起来很烦。我的建议是拆成多个el-tabs每个Tab放一组信息提交时一起验证这样页面不会太长用户体验也好。4.3 前后端联调时最容易出现的几个坑第一个坑是跨域。开发环境Vue跑在8080SpringBoot跑在8081前端请求直接被浏览器拦截。解决办法是后端写一个CorsFilter或者使用CrossOrigin注解但我更推荐统一在WebMvcConfigurer里配置跨域避免在每个Controller上加注解。第二个坑是时间格式。Java后端返回的LocalDateTime默认是一长串数字Vue显示出来完全看不懂。我在application.yml里配置了全局日期格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8第三个坑是接口返回字段和前端取值对不上。这个没有窍门只能靠前后端约定数据结构后端统一用Result包一层前端所有请求都从response.data.data拿业务数据联调时少吵很多架。Vue项目还有一个实用的经验所有请求接口集中放在src/api目录下按模块拆文件不要散落在页面里。这样以后改接口地址只需要动一个文件。我见过很多项目接口写得到处都是结果后端改接口名前端页面一个文件一个文件找非常痛苦。5. 源码落地全流程环境配置、打包部署、反编译对照与完整源码的使用方法“完整源码”这四个字意味着什么不只是代码能跑而是要别人拿到手之后按照文档一步步把环境搭起来启动后端启动前端看到页面能够二次开发。源码交付容易踩的坑我在这里集中讲一遍。5.1 本地环境的具体版本搭配这个项目我用的版本组合是亲测稳定的一套技术组件版本备注JDK1.8稳定和老系统兼容SpringBoot2.5.x不要选3.x3.x依赖JDK17且部分框架兼容性有差异MySQL5.7或8.08.0需要确认驱动用com.mysql.cj.jdbc.DriverMyBatisspring-boot-starter 2.5.x自带需要手动配置MapperScanNode.js14.x或16.x配合Vue2和npmVue2.6.x配合Element UI 2.15.xMaven3.6.3国内建议配置阿里云镜像仓库新手最容易卡在MySQL安装上。安装MySQL 8.0的时候如果忘了初始化密码后面连接数据库会一直报Access denied。建议安装时先用mysqld --initialize-insecure生成一个空密码账户再手动设置密码避免莫名其妙连不上。数据库初始化文件需要按顺序执行先建库再跑表结构SQL最后跑初始化数据SQL。初始化数据里至少要准备一个管理员账号不然登录入口都没有。5.2 后端和前端各自的打包部署方式后端打包我用的Maven命令mvn clean package -DskipTests打出来的jar包直接用下面命令启动java -jar elcare-platform.jar --spring.profiles.activeprod生产环境的数据库密码不要写在application.yml里最好用环境变量传入。实测下来部署到Windows服务器和Linux服务器的差异不大Linux下记得给jar包执行权限。前端打包前要求先配置好接口地址。Vue里我习惯用环境变量区分// .env.production VUE_APP_BASE_API http://服务器IP:8081/api前端执行npm run build后生成dist目录把里面的文件扔到Nginx的html目录然后配置反向代理让/api开头的请求转发到后端避免前端直接暴露后端端口。server { listen 80; server_name your-domain.com; location / { root /opt/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }我踩过一个真实的坑前端打包后路径用的是/部署到Nginx子路径下页面全是空白。后来在vue.config.js里把publicPath改成./才解决。这一步还牵涉到路由的mode我用的hash模式部署更省心。5.3 如何用反编译工具对照阅读已有源码有读者可能拿到的是别人给的打包好的jar包想参考里面是怎么实现的。SpringBoot的jar包里没有太多神秘的东西逻辑都在BOOT-INF/classes下面。平时我们写好的.class文件需要反编译才能看回Java代码。反编译这个操作在Java圈子里其实很普遍我用过的一般思路是先用解压工具把jar包解开找到BOOT-INF/classes下的业务代码。用反编译工具比如JD-GUI或Luyten把.class文件打开转成可读的Java源码。结合application.yml、static下的前端资源、mybatis的Mapper XML一起看就能还原出大致的项目结构。不过需要提醒一句除非你拿到的是自己项目的备份或者别人明确允许照着学习否则不要拿反编译的代码直接商用。完整的源码交付项目里你直接用作者提供的源码会更省事。反编译这个技能更适合用来学习别人的设计思路比如看看别人的报警流程是怎么写的异常处理是怎么组织的。5.4 完整的SQL脚本和参数初始化列表源码包里一定要包含一个完整的数据库脚本并且要写明初始化账号和密码。这个项目里我准备了db_init.sql建库建表。db_data.sql角色、管理员账号、菜单权限、系统参数。db_sample.sql示例老人数据、示例设备数据、示例报警数据方便前端页面一进来就有数据展示。系统参数表里放了血压阈值、心率阈值、报警升级时间等。默认值如下参数名默认值说明heart_rate_high120心率过高报警阈值heart_rate_low50心率过低报警阈值blood_pressure_high160收缩压过高报警阈值alert_upgrade_minutes30报警超时升级时间quiet_hours_start22:00免打扰时段开始新人第一次看这个项目时我建议先跑通最简单的登录流程再跑通报警处理闭环最后再去看设备上报和ECharts图表。按这个顺序啃源码思路会特别清晰。6. 项目做成之后我最想告诉你的几个真实体会这个平台从需求梳理到第一版能跑通大概花了一个月时间。如果让我重新做一遍有几件事我会在一开始就做而不是中途再补。第一报警通知的优先级一定要看业务场景不能只看技术。社区养老平台里跌倒报警和呼救按钮报警必须走最高优先级心率异常可以稍微放宽。你设计的系统不是给技术看的而是给社区工作人员用的他们每天要处理很多报警如果每个报警都弹窗加短信最后大家会麻木真正的紧急情况反而被忽略。所以我把报警分成三个级别一般级别只在后台列表里展示严重级别才发短信紧急级别才会同时推送给值班负责人和家属。这个逻辑要在一开始就写进需求文档里。第二不要小看操作日志。社区养老平台涉及老人隐私信息谁查看了老人档案、谁修改了护理等级都必须留痕。这个需求用户一开始没提但是真正上线之后管理员一定会来问。后来我在所有涉及隐私的Controller里加了一个注解切面统一记录日志。虽然增加了一些代码量但换来的信任感是值得的。第三页面提示语要写人话不要写技术语言。前端调用后端接口失败时如果直接弹出“网络错误”工作人员会摸不着头脑。我统一封装了错误提示把常见的异常转成“操作失败请稍后重试”“该老人已被其他工作人员处理请刷新页面再试”这些细节看起来不起眼但实际使用体验差别很大。第四测试数据一定要贴近真实。我遇到过一个界面效果很好的项目数据库里老人姓名全是“张三”地址全是“小区1栋”。工作人员测试时就反馈看不出问题等真上线了才发现某些标签过长会挤爆表格。我给源码包准备的示例数据里特地放了一些长者姓名、详细的地址、不同报警级别的记录让第一次打开页面的人就能感受到真实系统的样子也方便检查样式。第五不要在一个项目里堆太多新技术。标题里虽然写了SpringBoot、Vue、MySQL、MyBatis但这套组合本身已经足够。不要为了炫技引入Redis、消息队列、ElasticSearch除非你真有高并发场景。社区养老项目的数据量一天顶多几千条MySQL完全扛得住。技术栈简单后面的人接手时才不会一头雾水。现在我回头再看这个项目最满意的不是用了多新的框架而是整个流程走通了老人档案录入、手环数据上传、阈值判断、报警生成、工作人员处理、家属查看形成了一个完整的业务闭环。系统和硬件之间的对接也预留了接口后续如果想接更多设备只需要在DeviceDataController里加解析方法不需要改动核心业务流程。养老监护这类系统技术只是一个载体真正有价值的是业务逻辑的严谨性和对老年人的关怀。拿这套源码去学习的时候多想想每个功能背后的使用场景比单纯复制代码有价值得多。希望你也能在这个项目里体会到把技术变成实际服务的那份成就感。 SpringBoot+Vue构建社区智慧养老监护平台：架构设计与实践
1. 为什么养老监护平台选择了SpringBootVue而不是其他方案社区智慧养老监护平台这个项目本质上是一个典型的Java Web管理系统需要管理老人档案、健康监测数据、护工排班、家属通知、设备报警记录还要有后台管理页面供社区工作人员日常操作。项目名称里把SpringBoot、Vue、MySQL、MyBatis都点出来了这其实也代表了目前国内中小型管理系统最主流、最容易招人接手的一套技术组合。我接触过不少类似的管理系统需求最开始也犹豫过到底用什么架构。社区养老平台的特点是并发量不高、业务逻辑复杂、报表和状态流转多、需要频繁与第三方设备对接手环、血压计、呼救按钮还要考虑后续维护的人能不能快速上手。如果上微服务对社区项目来说就是杀鸡用牛刀如果只用JSP加Servlet前后端耦合严重页面维护成本会很高。最后落在SpringBootVue这套组合上是因为它在工程化、开发效率、招人成本和部署难度之间取得了最好的平衡。1.1 这个平台到底要解决社区里的什么问题养老监护不是一个单点功能而是把社区里分散的信息串起来。我实际梳理业务时把核心场景拆成了四类社区工作人员需要知道每一位老人的基本信息、紧急联系人、既往病史、用药情况。家属希望远程看到老人的健康状态比如血压、心率、睡眠时长以及护工是否按时上门。护工需要接到任务提醒比如某位老人今天该测血糖了或者手环上报了异常心率。管理人员需要看到全局数据比如哪个片区报警最多、哪些老人最近体征不稳定方便安排回访。这四类场景决定了系统不是单纯的CRUD而是“档案管理设备数据接入任务流转报警通知”的组合。所以项目标题里强调“监护管理”核心不是展示数据而是处理异常状态和任务闭环。我的开发习惯是先列角色再定权限最后才写接口。这个项目最终拆成了五类角色系统管理员、社区工作人员、护工、家属、老人家属查看端。其中老人本身不登录因为大部分老人不习惯用App但家属端一定要有否则“监护”两个字就没有落到人身上。1.2 技术选型的对比过程选型不能只看技术新不新要看团队和运维能力。我当时列过一个对比表技术组合优点缺点是否适合本项目SpringBoot Thymeleaf前后端一体部署简单页面交互弱难以做复杂状态联动勉强可以SpringBoot Vue前后端分离后期好维护需要处理跨域和双端部署很适合SpringCloud微服务全家桶扩展性强运维成本高社区项目没有必要不适合PHP Native页面上手快长期维护和Java生态差距大不建议SpringBoot的优势在于自动配置和起步依赖几分钟就能把Web项目跑起来MyBatis则适合团队里习惯写SQL的开发者尤其是多表关联查询多、报表SQL复杂的时候直接写XML比JPA的自动SQL更直观。Vue2/Vue3都可以我建议普通管理系统直接用Vue2加Element UI稳定资料多除非你明确要用Vue3的组合式API和vite否则别给自己找麻烦。选型还有一层考虑是源码交付。项目标题带“完整源码”意味着很可能需要交给别人二次开发。SpringBootMavenMySQLMyBatis这套东西任何一个学过Java的都能快速看懂换成别的冷门框架交付之后维护成本就大了。2. 数据库设计从老人档案到报警记录的完整表结构数据库设计是这个项目里最不能省时间的部分。SpringBoot和Vue都是工具数据的准确性和流转逻辑才是系统的命。我设计表时遵循一个原则一个社区可能同时管理几百位老人表不能设计得太散但也不能把所有东西塞进一张大宽表。2.1 核心数据模型拆分我从业务对象入手最终整理出了下面这些核心表elder老人基础档案包括姓名、身份证号、住址、紧急联系人、既往病史、护理等级。device设备信息表包括设备编号、设备类型手环、血压计、呼救按钮、绑定老人ID、状态。health_record健康监测记录包括老人ID、设备ID、心率、血压、血氧、体温、采集时间。alert_record报警记录包括报警类型心率异常、跌倒、呼救、报警级别、处理状态、处理人、处理时间。care_task护理任务包括任务类型上门、测血压、送药、执行护工、计划时间、完成状态。user/role/user_role用户和权限。family_binding家属与老人的绑定关系方便推送通知。operate_log操作日志记录谁在什么时候改了什么。这个模型看起来不复杂但每一张表都有隐藏的坑。比如health_record会随着设备上报涨得很快一定要建索引联合索引(elder_id, collect_time)几乎是必须的。比如报警表的状态字段我建议用0待处理、1已处理、2已忽略不要只有布尔值因为运营人员需要将来回头查历史。我在设计时特别加了一个alert_source字段用来区分报警是设备自动上报、家属手动上报还是工作人员登记。这个字段看似多余但后面做报表统计时非常有用可以分别看设备可靠性、人工漏报率。2.2 关键表结构示例以下是alert_record表的核心建表SQL实际项目还要加上create_time、update_time等通用字段CREATE TABLE alert_record ( id bigint(20) NOT NULL AUTO_INCREMENT, elder_id bigint(20) NOT NULL COMMENT 老人ID, device_id bigint(20) DEFAULT NULL COMMENT 设备ID, alert_type varchar(32) NOT NULL COMMENT 报警类型heart_rate/fall/sos/blood_pressure, alert_level tinyint(4) NOT NULL DEFAULT 1 COMMENT 报警级别1一般2严重3紧急, alert_source varchar(32) NOT NULL DEFAULT device COMMENT device/family/staff, content varchar(500) DEFAULT NULL COMMENT 报警描述, handle_status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待处理 1已处理 2已忽略, handle_user_id bigint(20) DEFAULT NULL COMMENT 处理人ID, handle_time datetime DEFAULT NULL COMMENT 处理时间, handle_remark varchar(500) DEFAULT NULL COMMENT 处理备注, PRIMARY KEY (id), KEY idx_elder_time (elder_id, create_time), KEY idx_status_level (handle_status, alert_level) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT报警记录表;有两点经验说给新手听。第一字符集一定要用utf8mb4因为老人名字里可能会有生僻字普通utf8放到MySQL里会变成乱码甚至报错。第二业务字段尽量加COMMENT这个平台后期要交接别人看表结构时注释比实体类上的注解还管用。数据库设计阶段最容易犯的错是把“护工和老人的关系”做成一对一。实际社区里一个护工会负责多个老人一个老人也可能有多个护工上门所以关系表一定要单独建。我用的是一张care_relation表字段包括护工ID、老人ID、开始日期、结束日期这样排班、统计工作量都方便。3. 后端落地的关键点SpringBoot项目结构、MyBatis动态SQL与报警闭环数据库定了以后后端开发就顺畅很多。项目的后端我采用标准的Controller-Service-Mapper三层结构没有过度设计。这个项目里最考验功底的不是增删改查而是报警处理流程和MyBatis动态查询的写法。3.1 项目目录怎么分才能让源码清晰可读我见过太多培训班式的项目所有Controller堆在一个包下面代码完全没法看。这个平台我用的目录结构如下com.community.eldercare ├── controller │ ├── ElderController.java │ ├── DeviceDataController.java │ ├── AlertController.java │ └── CareTaskController.java ├── service │ ├── AlertService.java │ ├── DeviceDataService.java │ └── ... ├── mapper │ ├── ElderMapper.java │ ├── AlertMapper.java │ └── ... ├── entity │ ├── Elder.java │ ├── AlertRecord.java │ └── ... ├── dto │ ├── AlertQueryDTO.java │ └── ... ├── common │ ├── Result.java │ ├── GlobalExceptionHandler.java │ └── ... └── config └── WebConfig.javaResult统一封装返回结构前端拿到的永远是{code, message, data}这样联调时省掉很多口头约定。GlobalExceptionHandler处理参数校验和业务异常避免每个Controller都写try-catch。这些基础设施看着简单但能把代码质量拉开一大截。3.2 MyBatis动态SQL的核心用法报警查询是这个项目使用频率最高的接口。社区工作人员打开“待处理报警”页面时需要按老人姓名、报警级别、报警类型、时间段组合筛选。用MyBatis的where和if标签写动态SQL比每次拼接字符串不知道好到哪里去。select idqueryAlertList resultTypecom.community.eldercare.entity.AlertRecord SELECT a.*, e.name AS elder_name FROM alert_record a LEFT JOIN elder e ON a.elder_id e.id where if testelderName ! null and elderName ! AND e.name LIKE CONCAT(%, #{elderName}, %) /if if testalertLevel ! null AND a.alert_level #{alertLevel} /if if testalertType ! null and alertType ! AND a.alert_type #{alertType} /if if teststartTime ! null AND a.create_time gt; #{startTime} /if if testendTime ! null AND a.create_time lt; #{endTime} /if /where ORDER BY a.create_time DESC /select这里要特别注意和在XML里要转义成gt;和lt;不然XML解析会直接报错。还有一个经验能用LIKE做模糊查询的时候就要控制范围如果后期数据量大了建议换成分页加全文索引但这套小系统用LIKE足够了。3.3 健康数据上报和报警闭环的实现过程设备数据上报接口是我最先写的因为前端页面能不能看到实时数据完全取决于它。硬件手环通过HTTP POST把数据推给后端JSON结构大致是{ deviceCode: HB00123, heartRate: 92, bloodPressureHigh: 135, bloodPressureLow: 85, oxygen: 97, collectTime: 2025-01-15 08:30:00 }Controller接收后先根据deviceCode查到绑定的老人ID再插入health_record然后判断指标是否超过阈值。阈值我放在系统参数表里没有写死在代码中这样运营人员可以在后台调整不用重新发版。报警闭环是重点我给它设计了四个状态设备上报触发报警→生成待处理记录→工作人员点击处理→填写处理结果。如果一条报警超过30分钟还没处理系统需要自动升级给值班负责人短信提醒。短信接口我用的是第三方平台但代码里做了接口封装方便以后换成别的供应商。我踩过的坑是处理报警的时候工作人员可能同时开着多个页面导致重复处理。解决办法很简单Service层处理前先加一个UPDATE alert_record SET handle_status 1 WHERE id #{id} AND handle_status 0通过受影响行数判断是否被其他人抢先处理。这种“乐观锁”的思路在管理系统里非常实用。3.4 分页查询不能只靠前端分页是每个后台管理系统都躲不开的事情。MyBatis的PageHelper在这类项目里几乎是标配用起来就一行代码PageHelper.startPage(pageNum, pageSize); ListAlertRecord list alertMapper.queryAlertList(queryDTO); PageInfoAlertRecord pageInfo new PageInfo(list);但千万注意PageHelper只能在第一次执行的Mapper查询中生效。如果你在Service层先查了别的表再查目标表分页就可能跑到错误的SQL上。所以我在Service层里只要用了PageHelper就保证紧接着只执行目标查询中间不做其他多余操作。4. 前端Vue部分的实现管理后台怎么设计才能让工作人员用起来顺手前端是整个系统的脸面。社区工作人员年龄普遍不小他们不会关心你用了什么技术只关心页面好不好找、按钮显不显眼、有没有明显的反馈。Vue的角色是负责把这些交互逻辑组织好。4.1 路由、菜单和权限的处理方式Vue项目我采用的是Vue Router加本地路由守卫后端登录成功后返回token和角色标识。前端根据角色动态生成侧边栏菜单。简单说router里配置好所有页面路由但在beforeEach守卫里判断用户是否登录、当前角色是否允许访问某个路径。社区工作人员可能只看到“老人管理、报警处理、护理任务”管理员才能看到“用户管理、报表统计”。菜单的数据来源是一个静态映射表因为角色只有五种动态路由的性能收益不大还容易出权限漏洞。const roleMenus { admin: [/dashboard, /elder, /alert, /task, /device, /user, /report], staff: [/dashboard, /elder, /alert, /task], caregiver: [/task, /elder], family: [/elder, /health] };这种做法比后端下发菜单树简单得多适合中小型项目。如果以后角色多了再改成数据库动态配置也不迟。4.2 数据列表页和表单页的Vue组件设计首页仪表盘的图表我选了ECharts用来展示报警趋势和健康数据波动。ECharts这部分没有特别复杂的逻辑主要是把后端返回的时间序列数组转成图表的series数据。报警处理页是前端最核心的页面。我把它做成一个列表每一行显示老人姓名、报警类型、报警时间、级别标签右侧是处理按钮。点击后弹出一个Dialog填写处理结果。这个页面要注意的点是处理成功后不要只console.log一定要重新请求列表数据否则界面状态和数据不一致用户会以为操作没成功。老人档案表单比较长有基本信息、健康信息、家庭信息、紧急联系人。Element UI里的el-form虽然好用但校验规则写起来很烦。我的建议是拆成多个el-tabs每个Tab放一组信息提交时一起验证这样页面不会太长用户体验也好。4.3 前后端联调时最容易出现的几个坑第一个坑是跨域。开发环境Vue跑在8080SpringBoot跑在8081前端请求直接被浏览器拦截。解决办法是后端写一个CorsFilter或者使用CrossOrigin注解但我更推荐统一在WebMvcConfigurer里配置跨域避免在每个Controller上加注解。第二个坑是时间格式。Java后端返回的LocalDateTime默认是一长串数字Vue显示出来完全看不懂。我在application.yml里配置了全局日期格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8第三个坑是接口返回字段和前端取值对不上。这个没有窍门只能靠前后端约定数据结构后端统一用Result包一层前端所有请求都从response.data.data拿业务数据联调时少吵很多架。Vue项目还有一个实用的经验所有请求接口集中放在src/api目录下按模块拆文件不要散落在页面里。这样以后改接口地址只需要动一个文件。我见过很多项目接口写得到处都是结果后端改接口名前端页面一个文件一个文件找非常痛苦。5. 源码落地全流程环境配置、打包部署、反编译对照与完整源码的使用方法“完整源码”这四个字意味着什么不只是代码能跑而是要别人拿到手之后按照文档一步步把环境搭起来启动后端启动前端看到页面能够二次开发。源码交付容易踩的坑我在这里集中讲一遍。5.1 本地环境的具体版本搭配这个项目我用的版本组合是亲测稳定的一套技术组件版本备注JDK1.8稳定和老系统兼容SpringBoot2.5.x不要选3.x3.x依赖JDK17且部分框架兼容性有差异MySQL5.7或8.08.0需要确认驱动用com.mysql.cj.jdbc.DriverMyBatisspring-boot-starter 2.5.x自带需要手动配置MapperScanNode.js14.x或16.x配合Vue2和npmVue2.6.x配合Element UI 2.15.xMaven3.6.3国内建议配置阿里云镜像仓库新手最容易卡在MySQL安装上。安装MySQL 8.0的时候如果忘了初始化密码后面连接数据库会一直报Access denied。建议安装时先用mysqld --initialize-insecure生成一个空密码账户再手动设置密码避免莫名其妙连不上。数据库初始化文件需要按顺序执行先建库再跑表结构SQL最后跑初始化数据SQL。初始化数据里至少要准备一个管理员账号不然登录入口都没有。5.2 后端和前端各自的打包部署方式后端打包我用的Maven命令mvn clean package -DskipTests打出来的jar包直接用下面命令启动java -jar elcare-platform.jar --spring.profiles.activeprod生产环境的数据库密码不要写在application.yml里最好用环境变量传入。实测下来部署到Windows服务器和Linux服务器的差异不大Linux下记得给jar包执行权限。前端打包前要求先配置好接口地址。Vue里我习惯用环境变量区分// .env.production VUE_APP_BASE_API http://服务器IP:8081/api前端执行npm run build后生成dist目录把里面的文件扔到Nginx的html目录然后配置反向代理让/api开头的请求转发到后端避免前端直接暴露后端端口。server { listen 80; server_name your-domain.com; location / { root /opt/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }我踩过一个真实的坑前端打包后路径用的是/部署到Nginx子路径下页面全是空白。后来在vue.config.js里把publicPath改成./才解决。这一步还牵涉到路由的mode我用的hash模式部署更省心。5.3 如何用反编译工具对照阅读已有源码有读者可能拿到的是别人给的打包好的jar包想参考里面是怎么实现的。SpringBoot的jar包里没有太多神秘的东西逻辑都在BOOT-INF/classes下面。平时我们写好的.class文件需要反编译才能看回Java代码。反编译这个操作在Java圈子里其实很普遍我用过的一般思路是先用解压工具把jar包解开找到BOOT-INF/classes下的业务代码。用反编译工具比如JD-GUI或Luyten把.class文件打开转成可读的Java源码。结合application.yml、static下的前端资源、mybatis的Mapper XML一起看就能还原出大致的项目结构。不过需要提醒一句除非你拿到的是自己项目的备份或者别人明确允许照着学习否则不要拿反编译的代码直接商用。完整的源码交付项目里你直接用作者提供的源码会更省事。反编译这个技能更适合用来学习别人的设计思路比如看看别人的报警流程是怎么写的异常处理是怎么组织的。5.4 完整的SQL脚本和参数初始化列表源码包里一定要包含一个完整的数据库脚本并且要写明初始化账号和密码。这个项目里我准备了db_init.sql建库建表。db_data.sql角色、管理员账号、菜单权限、系统参数。db_sample.sql示例老人数据、示例设备数据、示例报警数据方便前端页面一进来就有数据展示。系统参数表里放了血压阈值、心率阈值、报警升级时间等。默认值如下参数名默认值说明heart_rate_high120心率过高报警阈值heart_rate_low50心率过低报警阈值blood_pressure_high160收缩压过高报警阈值alert_upgrade_minutes30报警超时升级时间quiet_hours_start22:00免打扰时段开始新人第一次看这个项目时我建议先跑通最简单的登录流程再跑通报警处理闭环最后再去看设备上报和ECharts图表。按这个顺序啃源码思路会特别清晰。6. 项目做成之后我最想告诉你的几个真实体会这个平台从需求梳理到第一版能跑通大概花了一个月时间。如果让我重新做一遍有几件事我会在一开始就做而不是中途再补。第一报警通知的优先级一定要看业务场景不能只看技术。社区养老平台里跌倒报警和呼救按钮报警必须走最高优先级心率异常可以稍微放宽。你设计的系统不是给技术看的而是给社区工作人员用的他们每天要处理很多报警如果每个报警都弹窗加短信最后大家会麻木真正的紧急情况反而被忽略。所以我把报警分成三个级别一般级别只在后台列表里展示严重级别才发短信紧急级别才会同时推送给值班负责人和家属。这个逻辑要在一开始就写进需求文档里。第二不要小看操作日志。社区养老平台涉及老人隐私信息谁查看了老人档案、谁修改了护理等级都必须留痕。这个需求用户一开始没提但是真正上线之后管理员一定会来问。后来我在所有涉及隐私的Controller里加了一个注解切面统一记录日志。虽然增加了一些代码量但换来的信任感是值得的。第三页面提示语要写人话不要写技术语言。前端调用后端接口失败时如果直接弹出“网络错误”工作人员会摸不着头脑。我统一封装了错误提示把常见的异常转成“操作失败请稍后重试”“该老人已被其他工作人员处理请刷新页面再试”这些细节看起来不起眼但实际使用体验差别很大。第四测试数据一定要贴近真实。我遇到过一个界面效果很好的项目数据库里老人姓名全是“张三”地址全是“小区1栋”。工作人员测试时就反馈看不出问题等真上线了才发现某些标签过长会挤爆表格。我给源码包准备的示例数据里特地放了一些长者姓名、详细的地址、不同报警级别的记录让第一次打开页面的人就能感受到真实系统的样子也方便检查样式。第五不要在一个项目里堆太多新技术。标题里虽然写了SpringBoot、Vue、MySQL、MyBatis但这套组合本身已经足够。不要为了炫技引入Redis、消息队列、ElasticSearch除非你真有高并发场景。社区养老项目的数据量一天顶多几千条MySQL完全扛得住。技术栈简单后面的人接手时才不会一头雾水。现在我回头再看这个项目最满意的不是用了多新的框架而是整个流程走通了老人档案录入、手环数据上传、阈值判断、报警生成、工作人员处理、家属查看形成了一个完整的业务闭环。系统和硬件之间的对接也预留了接口后续如果想接更多设备只需要在DeviceDataController里加解析方法不需要改动核心业务流程。养老监护这类系统技术只是一个载体真正有价值的是业务逻辑的严谨性和对老年人的关怀。拿这套源码去学习的时候多想想每个功能背后的使用场景比单纯复制代码有价值得多。希望你也能在这个项目里体会到把技术变成实际服务的那份成就感。