接手过不少管理系统的项目但养老智慧服务平台这套东西和我之前做的普通后台管理系统还是有很大区别的。最大的感受是它不是把线下表格搬到线上而是把线下服务流程真正跑通。这篇文章我就基于 SpringBoot Vue3 MyBatis MySQL 这套前后端分离架构聊聊从项目拆解到落地的完整思路包括架构怎么搭、表怎么建、权限怎么设计、哪些地方容易踩坑以及背后的逻辑是什么。1. 养老行业的数字化缺口这个平台到底在解决什么问题1.1 养老服务场景的痛点梳理在真正动手写代码之前我习惯先花一段时间去了解业务场景。养老服务平台不是单纯的信息管理系统它要覆盖的对象是老人、家属、护理员、管理人员有时候还有政府监管方或第三方服务商。你会发现这里面的核心矛盾是信息传递靠人响应速度靠喊。举几个我在实际项目交流里听到的高频痛点老人档案散落在纸质表格和 Excel 里护理员交接班要翻半天记录。家属想了解老人今天吃了什么、血压多少得打电话问护理员护理员还要回忆。发生突发情况比如老人跌倒或异常离床消息靠口头通知从发现到处置的时间不可控。管理人员无法及时统计每个护理员完成了多少项照护任务服务质量靠抽查。这些痛点的本质是缺一个统一的数据中枢和任务流转机制。养老智慧服务平台要做的就是用一套系统把档案—健康—照护—工单—家属互动串起来让每一步操作留痕、每一份数据可查、每一个任务有闭环。1.2 从需求到功能核心业务流程如何映射为系统模块基于上面的痛点我在规划功能模块时没有一上来就列菜单而是先画了一条业务主线老人入院建档 → 评估分级 → 制定照护计划 → 生成照护工单 → 护理员执行并反馈 → 家属查看与评价。这条主线映射到系统里就变成了几个核心功能模块业务环节系统功能关键实体入院建档老人档案管理老人基本信息、家属信息、入住记录评估分级能力评估管理评估量表、评分结果、护理等级照护计划照护计划管理计划模板、项目明细、执行频率任务执行工单/任务管理工单、任务项、执行记录、异常标记健康监测健康数据管理血压、血糖、心率、体温记录对外沟通家属端/消息中心通知公告、健康推送、家属留言运营管理护理员管理、排班管理护理员、班次、考勤很多新手容易犯的错是拿着通用后台管理系统的模板往上套——有用户管理、角色管理、菜单管理就以为完事了。但养老项目不是这样它的核心是数据关联和服务闭环比如老人档案必须关联评估结果评估结果必须决定照护计划照护计划必须生成可执行的工单工单完成后必须反馈记录。少了任何一环系统都只是一个空壳。1.3 目标用户与角色权限模型设计权限模型也是这个系统的重头戏。养老平台的用户类型比普通企业 OA 复杂我参考了角色的实际使用场景超级管理员系统全部权限负责配置基础数据、管理所有账户。机构管理员管理本机构内部的护理员、老人档案、工单分配。护理员查看被分配的任务、执行并提交记录、接收预警信息。护士/医生查看健康数据、处理异常、更新照护计划。家属只查看与自己绑定老人的相关信息不能看其他老人数据。这里的权限重点不是菜单权限而是数据权限。比如说机构管理员只能看本机构的数据护理员只能看自己被分配的工单家属只能绑定特定老人。用 SpringBoot 做权限我一般基于 JWT 拦截器实现接口级鉴权再通过 ThreadLocal 存储当前登录用户上下文在 Service 层做数据隔离过滤。这种方案比引入重型框架轻也够灵活。2. 技术选型背后的现实逻辑为什么偏偏是这四件套2.1 SpringBoot作为后端骨架的理由这套系统选择 SpringBoot可以说是Java技术栈下的稳妥解。SpringBoot 的价值不只是简化配置它更重要的是把生态整合起来——Spring Security、MyBatis、Redis、定时任务、消息推送这些组件都能在统一框架下协作。我在项目里用到的 SpringBoot 关键特性自动装配大大减少了 XML 和繁琐配置起步快。Starter 机制引入spring-boot-starter-web、spring-boot-starter-validation等按需引入。配置文件多环境支持通过application-dev.yml、application-prod.yml区分环境部署时只改一个参数。内置容器默认内嵌 Tomcat打包成 jar 即可运行适合前后端分离部署。不过也要提醒一句SpringBoot 版本迭代快不同大版本之间可能有行为差异。热词里有人提到springboot版本太高这在引入第三方依赖时确实会影响兼容性。所以我在选型时定了一个原则不用最新用稳定版本一般选当前生态里主流的生产版本比如 2.7.x 或 3.x 中社区大量使用的那一档。2.2 前端为什么选Vue3而不是其他框架前端的核心诉求是管理系统页面密集、交互频繁、表单复杂、数据实时性要求高。Vue3 在组合式APIComposition API上的改进恰好对上了这类需求。我用 Vue3 的主要理由组合式 API 让代码复用更容易比如把获取老人列表搜索分页抽成一个自定义 hook多个页面直接复用。响应式系统性能好proxy替代了 Vue2 的defineProperty数据量大时渲染性能更稳定。生态成熟Element Plus、Vite、Pinia 这些配套工具链完整开发体验顺滑。TypeScript 支持友好接口定义、类型提示对复杂业务字段的约束很有帮助。热词里反复出现vue3 composition api和option api的对比我个人在项目里的建议是逻辑简单的页面用 Options API 反而直观逻辑复用多或数据流复杂的模块用 Composition API 更顺手。不要为了炫技强制全部用组合式合适才是关键。2.3 MyBatis与MySQL的组合考量MyBatis 在这套架构里的定位是灵活的手写 SQL。养老业务里报表汇总、复杂统计查询很多比如统计某机构本月各护理等级的老人数量查询某护理员的工单完成率这些查询往往涉及多表关联和条件拼接。MyBatis 的动态SQL在这种场景下非常舒服可以按需拼条件不需要在代码里做一堆 if 判断。MySQL 用得就更是常规了。成本低、社区活跃、运维资料多支撑中小型养老机构的业务量完全没问题。关键是把表结构设计好、索引建对、慢查询理清楚。2.4 这套选型的取舍边界坦白说这套组合也有它的局限性。比如如果要做复杂的实时双向通信像老人呼叫的语音视频前端可以考虑再引入 WebSocketVue3 和后端都能支持但需要额外处理。如果要做全国性多节点的高并发平台MySQL 单库可能会成为瓶颈需要引入分库分表或分布式数据库方案。但对单机构或区域级平台来说这套架构已经足够。如果要做智能硬件设备的实时数据流接入需要加消息队列如 RabbitMQ 或 Kafka来削峰我后面会提到怎么扩展。技术选型不是越复杂越好而是匹配业务规模和团队能力。SpringBoot Vue3 MyBatis MySQL 这套组合最大的优势是生态成熟、招聘容易、坑有现成答案适合绝大多数中小型智慧养老项目。3. 前后端分离架构设计与数据库建模3.1 系统分层从Controller到Service到Mapper这套系统的后端结构我采用的是经典三层架构再加一层 DTO/VO 做数据转换com.ylzh.platform ├── controller // 接收请求参数校验返回统一结果 ├── service // 业务逻辑事务管理 ├── mapper // MyBatis 数据访问接口 ├── entity // 数据库实体 ├── dto // 入参对象 ├── vo // 出参对象 ├── config // 配置类跨域、拦截器、定时任务等 ├── utils // 工具类JWT、日期处理、结果封装等 └── common // 全局异常、统一返回、常量一个典型的请求链路是这样的前端调用/api/elder/page→ Controller 接收参数 → Service 处理分页逻辑、调用 Mapper → Mapper 执行 SQL 返回结果 → Service 组装成 VO → Controller 返回统一结构{ code, message, data }。这套分层的价值在于每一层职责清晰改一处不影响另一处。比如换了前端框架后端接口不用动调整了查询逻辑只改 Service 和 Mapper不碰 Controller。3.2 核心数据表设计与业务约束数据库设计是这套系统的地基。我直接给出核心表的规划思路老人档案表elderCREATE TABLE elder ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_no VARCHAR(32) NOT NULL COMMENT 老人编号, name VARCHAR(64) NOT NULL COMMENT 姓名, gender TINYINT COMMENT 性别, birth_date DATE COMMENT 出生日期, id_card VARCHAR(18) COMMENT 身份证号, phone VARCHAR(20) COMMENT 联系电话, room_no VARCHAR(32) COMMENT 房间号, bed_no VARCHAR(32) COMMENT 床位号, care_level TINYINT COMMENT 护理等级:1自理2半失能3失能, entry_date DATE COMMENT 入住日期, status TINYINT DEFAULT 1 COMMENT 状态:0离院1在院, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT老人档案表;照护工单表care_orderCREATE TABLE care_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 工单编号, elder_id BIGINT NOT NULL COMMENT 老人ID, caregiver_id BIGINT COMMENT 护理员ID, plan_date DATE COMMENT 计划日期, start_time DATETIME COMMENT 开始时间, finish_time DATETIME COMMENT 完成时间, status TINYINT COMMENT 状态:0待派单1进行中2已完成3异常, remark VARCHAR(500) COMMENT 备注 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT照护工单表;健康数据表health_recordCREATE TABLE health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL COMMENT 老人ID, type TINYINT COMMENT 类型:1血压2血糖3心率4体温5血氧, value VARCHAR(32) COMMENT 测量值, unit VARCHAR(16) COMMENT 单位, measure_time DATETIME COMMENT 测量时间, recorder_id BIGINT COMMENT 记录人ID, abnormal_flag TINYINT DEFAULT 0 COMMENT 是否异常:0正常1异常 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT健康数据表;表设计时的几个关键约束点elder_id 字段贯穿所有业务表是数据关联的主线。状态字段用数字字典维护代码里定义常量避免魔法数散落各处。金额、时间字段类型要准确金额用DECIMAL(10,2)时间用DATETIME不要用字符串存时间。所有表加 create_time 和 update_time排查问题时会非常有用。3.3 登录认证与JWTSession还是Token前后端分离架构下Session 模式天然存在跨域和状态共享的问题。所以我用的是JWTJSON Web Token方案。流程是用户登录 → 后端校验用户名密码 → 生成 JWT包含用户ID、角色、过期时间。前端拿到 token 存在本地localStorage 或 Pinia每次请求在Authorization头里带上。后端拦截器解析 token校验合法性并解析出当前用户信息存入 ThreadLocal。接口通过RequiresPermission(elder:add)之类的注解或自定义拦截判断权限。JWT 的优势是无状态、后端不需要维护 Session方便水平扩展。但也要注意JWT 无法主动失效。如果用户被禁用或改了密码旧的 token 在过期前仍然有效。所以我一般会加一个小表记录 token 的黑名单或版本号或者把 token 有效期设短一点配合前端的 401 拦截重新登录。3.4 前端路由与后端接口的对应关系Vue3 前端采用 Vite Vue Router Pinia 的组合。路由设计按模块划分/login - 登录页 /layout - 主布局框架 /dashboard - 首页看板 /elder/list - 老人档案列表 /elder/detail/:id - 老人详情与健康记录 /care/plan - 照护计划管理 /care/order - 工单管理 /health/record - 健康数据录入与查询 /member/notice - 家属通知管理 /system/user - 用户管理 /system/role - 角色权限后端接口按模块划分统一前缀/api例如模块接口示例老人档案/api/elder/page,/api/elder/detail/{id},/api/elder/add,/api/elder/update登录认证/api/auth/login,/api/auth/logout,/api/auth/info工单管理/api/care/order/page,/api/care/order/assign,/api/care/order/complete健康记录/api/health/list,/api/health/add,/api/health/alerts前端通过 Axios 封装统一请求拦截器里做三件事附加 token、处理 401 跳转登录、解包统一返回结构。4. 核心业务模块的落地实现细节4.1 老人档案管理信息关联与状态流转老人档案是系统的核心主数据不能只是增删改查。我把它做成了带状态流转的模块入院登记录入基本信息生成唯一编号elder_no默认状态在院。能力评估调用评估页面选择量表后端计算总分自动映射护理等级。照护计划按护理等级加载对应的照护项目模板生成周期性的任务计划。状态变更离院、转院、换房、调整护理等级每一步都要有操作记录。这里的重点是档案状态变化要留痕。我增加了一张elder_status_log表记录操作人、操作类型、变更前后值、操作时间。这么做一是为了可追溯二是为了后续做统计报表时能回溯历史数据。很多项目一开始不在乎这个等要做月度报表的时候才发现查不出这个人当月5号之前是什么护理等级。到时候再补数据基本补不回来。4.2 健康监测与预警服务定时任务与消息推送健康数据模块既要支持手动录入护理员早晚测量后录入也要预留硬件设备接入的接口。我设计的是一个通用数据入口手动录入护理员在移动端或 PC 端录入血压、血糖、心率、体温、血氧。异常判断后端根据阈值规则自动标记异常。比如收缩压高于 160 或低于 90 就标记为异常。预警推送当连续两条记录异常或单条记录严重异常时触发预警生成告警记录并通过 WebSocket 或消息推送通知值班人员。阈值规则我写在配置表里这样管理人员可以调不用改代码。这个设计思路很通用把业务规则参数化而不是写死。预警模块的核心代码逻辑Service public class HealthAlertService { Autowired private HealthRecordMapper healthRecordMapper; Autowired private AlertRecordMapper alertRecordMapper; public void checkHealthAlert(Long elderId, HealthRecord record) { // 阈值配置从缓存获取 HealthThreshold threshold thresholdCache.get(record.getType()); if (threshold null) return; boolean isAbnormal judgeAbnormal(record.getValue(), threshold); if (isAbnormal) { // 查询近半小时是否已有同一类型的连续异常 int recentCount healthRecordMapper.countRecentAbnormal( elderId, record.getType(), LocalDateTime.now().minusMinutes(30)); if (recentCount 1) { createAlertRecord(elderId, record, 连续异常); } } } }这里有个细节判断连续异常的时间窗口要有。否则一位老人血压本来就高每次测量都异常预警消息会把值班人员淹没。我设的是同一类型 30 分钟内出现第 2 次异常才触发。4.3 照护工单闭环从派单到完成的状态机设计照护工单是系统里最体现服务闭环的模块。我采用状态机设计状态流转是待派单(0) - 已派单(1) - 进行中(2) - 已完成(3) - 异常(4) - 重新派单每个状态的转换条件都校验只有待派单状态才能派单。只有已派单状态护理员接单后才能变成进行中。进行中可以提交完成或报告异常。异常工单必须填写异常原因并可重新派单。状态流转的代码我用了一个简单的状态机校验而不是 if 堆砌private static final MapInteger, ListInteger TRANSITIONS new HashMap(); static { TRANSITIONS.put(0, Arrays.asList(1)); TRANSITIONS.put(1, Arrays.asList(2, 4)); TRANSITIONS.put(2, Arrays.asList(3, 4)); TRANSITIONS.put(4, Arrays.asList(1)); } public void changeStatus(CareOrder order, int targetStatus) { ListInteger allowed TRANSITIONS.get(order.getStatus()); if (allowed null || !allowed.contains(targetStatus)) { throw new BusinessException(非法状态流转: order.getStatus() - targetStatus); } order.setStatus(targetStatus); }这个设计的好处是规则集中在明确的位置后续添加新状态只需要改一张表。而且避免了到处散落的 if status 1 then status 2 这种难以维护的写法。4.4 家属端可视化数据如何汇总展示家属端界面展示的是摘要信息它的数据来源于多个模块的聚合。我专门设计了一个接口一次性返回家属关联老人的概览数据GetMapping(/api/family/overview) public ResultFamilyOverviewVO getFamilyOverview() { Long userId SecurityUtils.getCurrentUserId(); // 1. 查询当前家属绑定的老人ID列表 ListLong elderIds familyBindService.getBoundElderIds(userId); // 2. 聚合各模块数据 FamilyOverviewVO vo new FamilyOverviewVO(); vo.setElderBasicInfo(elderService.listByIds(elderIds)); vo.setHealthRecords(healthRecordService.getLatestByElderIds(elderIds)); vo.setCareOrders(careOrderService.getTodayByElderIds(elderIds)); vo.setNotices(noticeService.latestByElderIds(elderIds)); return Result.success(vo); }这里比较重要的问题是接口聚合时机与性能。一次性返回多个模块的数据必然涉及多表查询。我通过两个手段控制开销数据量不大时直接多表查没问题数据量大时对当日工单和最新健康记录这两类高频数据做 Redis 缓存缓存失效时间控制在 30 秒到 1 分钟。家属端对数据实时性要求没那么苛刻30 秒内的延迟完全可接受。5. 联调、部署与性能优化经验5.1 本地开发环境规划与MySQL初始化开发环境我推荐直接用 Docker 起 MySQL省去本地安装的麻烦。但要注意热词里提到docker安装mysql失败的情况这里总结一下我常用的稳定方案# 1. 拉取镜像 docker pull mysql:5.7.44 # 2. 启动容器 docker run -d \ --name mysql-yanglao \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDroot123 \ -e MYSQL_DATABASEyanglao_db \ -v /data/mysql-data:/var/lib/mysql \ mysql:5.7.44两个关键点时区问题MySQL 连接串一定要加serverTimezoneAsia/Shanghai否则时间错 8 小时。编码问题连接串加characterEncodingutf8mb4否则 emoji 或生僻字存不进去比如老人姓名里有喆。连接串示例datasource: url: jdbc:mysql://localhost:3306/yanglao_db?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: root123如果不用 DockerWindows 或 Linux 直接装 MySQL 也可以初始化脚本建议按模块拆分文件01_schema.sql、02_data.sql、03_index.sql方便重复执行和版本管理。5.2 跨域问题与统一返回体设计前后端分离开发时跨域是必然遇到的问题。我在后端写了一个全局跨域配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有个细节allowCredentials(true)时allowedOrigins不能写成*要用allowedOriginPatterns(*)否则浏览器会拦截带凭证的请求。这种问题不遇到一次根本不会注意。统一返回体是前后端协作的契约我会定义成{ code: 200, message: success, data: {} }对应 Java 端定义一个泛型类Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.code 200; r.message success; r.data data; return r; } public static T ResultT error(Integer code, String message) { ResultT r new Result(); r.code code; r.message message; return r; } }这样做的好处是前端 Axios 拦截器只需要统一处理这一个结构体不用关心每个接口不同的返回格式。5.3 前端构建与SpringBoot静态资源整合开发环境下前后端分离让 Vite 跑localhost:5173后端跑localhost:8080跨域交给上面的 CORS 配置解决。但部署阶段有两种常见方式我实际都试过方式一前端构建后丢进 SpringBoot 静态目录npm run build # 将 dist 目录内的文件复制到 SpringBoot 的 src/main/resources/static/然后修改后端的接口前缀让前端请求的地址从同源出发。这种方式比较简单适合单体部署一台服务器。但要特别注意前端路由是 history 模式时刷新页面会出现 404。解决办法是后端加一个路径降级转发把前端路由对应的路径转发到index.htmlController public class PageForwardController { RequestMapping(value {/elder/**, /care/**, /health/**, /system/**}) public String forward() { return forward:/index.html; } }方式二Nginx 反向代理分离部署前端静态文件交给 Nginx后端接口反向代理到 SpringBoot这种方式更灵活升级前端不用重新打包后端。我的生产环境推荐用方式二但本地快速演示用方式一更方便。5.4 SQL性能调优与慢查询排查养老系统的数据量短期内不会特别大但报表查询、多表 join 用得不合理时依然会拖慢系统。几个我实际用到的优化手段索引设计核心查询条件的字段必须建索引。elder_id type measure_time是健康记录表常用的组合索引status plan_date是工单表的常用组合索引。避免大字段查询列表页只查需要的列不要 SELECT *更不要把文本大字段带到列表接口。分页优化深分页时用LIMIT 10000, 20这种写法很蠢改用WHERE id ? LIMIT 20或基于索引的分页逻辑。慢查询日志MySQL 开启慢查询日志定位执行时间超过 1 秒的 SQL。一个我在项目里遇到的经典慢查询案例查询某护理员本月完成工单数量时SQL 中对care_order表的caregiver_id字段没建索引全表扫描数据量到 10 万条后一次查询耗时 2.8 秒。加上idx_caregiver_id_status组合索引后耗时降到 40 毫秒。6. 踩坑实录与个人经验总结6.1 MyBatis缓存导致的数据不一致热词里有人专门搜过mybatis缓存mybatis二级缓存实现说明这个话题关注度很高。我在项目里试过开启 MyBatis 二级缓存后来发现做业务系统时这个默认行为反而容易挖坑。举个例子一个护理员修改了某老人的照护计划但另一个接口读取的却是二级缓存里的旧数据导致前端显示的计划跟数据库不一致。MyBatis 二级缓存是按 namespace 维度的多表关联查询时很容易出现缓存脏数据——你更新了 A 表但缓存的是 A join B 的结果B 变了缓存却不知道。结论是业务系统里MyBatis 二级缓存默认关着就好非要缓存的话用 Redis 做应用层缓存可控性高得多。6.2 Vue3开发中那些不容易注意的坑Vue3 本身很稳定但生态搭配时有一些坑Pinia 和 Vuex 混用有些项目从 Vue2 迁移过来一边用 Vuex 一边用 Pinia最后状态分散排查问题很痛苦。我建议新项目只选一种直接用 Pinia。响应式丢失从接口拿到的数据如果直接赋值给 reactive 对象的某个属性有时候会丢失响应式。用 ref 或 shallowRef 处理列表数据更稳。组件卸载后的异步操作异步请求发出后组件销毁了数据回来后还在 setState控制台会报警告。解决办法是在 hook 里用一个mounted标志位判断或者用 AbortController 取消请求。Element Plus 表单校验自定义校验规则时如果写法有问题表单提交永远卡在校验不过。调试时可以在 rules 里加trigger: blur逐个排查。6.3 SpringBoot版本差异导致的兼容性问题热词里提到springboot版本太高这个我确实遇到过。比如 SpringBoot 3.x 基于 Jakarta EE包名从javax.servlet改成了jakarta.servlet很多旧版第三方 SDK 直接不兼容。我建议的稳定组合是SpringBoot 2.7.x MyBatis Spring Boot Starter 2.3.xSpringBoot 3.x MyBatis Spring Boot Starter 3.0.xJDK 版本与 SpringBoot 大版本匹配2.7 用 JDK 8 或 113.x 用 JDK 17如果选型时不确定就直接在项目初期把整个技术栈跑一个最小 Demo把登录、查列表、增删改查全流程走通确认版本之间没有兼容问题再开始写业务。6.4 关于这套系统的一些实用建议做养老服务平台这类项目我有几点个人体会比较深第一业务流程的理解先于写代码。哪怕你不懂养老行业也要花时间跟使用方聊清楚照护流程。很多项目做到一半推倒重来不是因为技术问题而是需求理解错了。第二权限和数据隔离一开始就设计好。等系统上线了再补数据权限改动量会是原来的三倍以上。家属、护理员、机构管理员之间数据的隔离边界必须在表设计阶段就清楚。第三健康预警的阈值要可配置。老人身体状况差异很大有人血压 150 没问题有人 130 就头晕。写死的预警规则只能应付演示真实的平台必须要让管理人员按个体定制阈值。第四工单闭环比界面美观重要。很多管理员后台看起来精美但没有解决任务真正被执行的问题。工单的状态流转、异常处理、完成度统计才是这个系统最核心的价值所在。这套 SpringBoot Vue3 MyBatis MySQL 的架构用来搭建养老智慧服务平台从功能完整性和可扩展性来说都足够扎实。实际开发中我最大的体会是技术框架只是骨架业务闭环才是灵魂。把档案、评估、照护、健康、工单、家属互动这些链路串起来以后你会发现这套系统比普通的增删改查后台有生命得多。项目做到最后最让我有成就感的不是写了几千行代码而是这套系统真的能帮护理员少翻几次纸质记录帮家属少打几通询问电话帮管理人员看清楚服务质量的真实情况。从这个角度看技术选型反而成了最简单的那部分。