從需求到落地我如何用Spring Boot搭起一套智慧養(yǎng)老院管理系統(tǒng)去年年初接手了一個養(yǎng)老院管理系統(tǒng)的開發(fā)任務(wù)機構(gòu)那邊的情況比較典型三百多張床位護理人員幾十號人老人的健康檔案還停留在紙質(zhì)登記家屬想了解老人情況只能打電話問前臺護理排班全靠Excel手動排。領(lǐng)導(dǎo)說要上一套“智慧養(yǎng)老”系統(tǒng)我一開始以為是噱頭等真正把需求理完才發(fā)現(xiàn)這塊業(yè)務(wù)遠比想象中復(fù)雜——它既要做傳統(tǒng)的人事、床位、費用管理又要對接健康監(jiān)測設(shè)備和護理任務(wù)流轉(zhuǎn)還牽扯到家屬端的實時溝通。整套系統(tǒng)從立項到上線用了將近五個月最終的架構(gòu)是基于Spring Boot為后端核心搭建的把設(shè)備對接、任務(wù)調(diào)度、權(quán)限控制、消息推送這些能力全部揉進了一個單體應(yīng)用中。這篇文章分享一下整套系統(tǒng)的設(shè)計思路和關(guān)鍵實現(xiàn)細節(jié)。如果你正準備做類似的SpringBoot畢設(shè)項目或者公司打算給養(yǎng)老機構(gòu)做信息化改造應(yīng)該能從中看到一條比較務(wù)實的落地路線——包括數(shù)據(jù)庫建模、定時任務(wù)設(shè)計、多角色權(quán)限控制以及我在實際開發(fā)里踩過的那些坑。1. 項目背景與需求盤點養(yǎng)老院管理系統(tǒng)到底管什么動工之前我花了整整一周蹲在養(yǎng)老院里觀察他們的日常運轉(zhuǎn)。這個過程非常重要因為養(yǎng)老管理系統(tǒng)和普通的業(yè)務(wù)系統(tǒng)有個顯著區(qū)別它的核心數(shù)據(jù)是“人”而且是需要持續(xù)照護的老年人系統(tǒng)一旦出錯直接影響的是線下護理安全。所以需求分析階段不能只坐在辦公室看調(diào)研表必須搞清楚每個角色每天到底在做什么。1.1 傳統(tǒng)養(yǎng)老院管理的三大痛點第一個痛點是老人健康信息碎片化。血壓、血糖、服藥記錄、體檢報告散落在紙質(zhì)檔案和護士的隨身本子上醫(yī)生巡診時要逐頁翻找同一個數(shù)據(jù)可能被重復(fù)登記好幾次。第二個痛點是護理任務(wù)沒有閉環(huán)。排班表排完就完事了護工是否按時執(zhí)行了翻身、喂藥、體征測量這些任務(wù)管理層完全不知道萬一老人出現(xiàn)異常事后連責任追溯都做不了。第三個痛點是家屬溝通成本極高。家屬詢問老人情況工作人員要現(xiàn)去查、現(xiàn)場問回復(fù)不及時不說還容易因為信息不一致產(chǎn)生矛盾。1.2 系統(tǒng)邊界與角色梳理針對這三個痛點我們把系統(tǒng)劃分成六大核心模塊老人檔案管理、健康監(jiān)測與預(yù)警、護理任務(wù)管理、床位與入住管理、費用與物資管理、家屬端消息服務(wù)。角色方面一開始只規(guī)劃了管理員、護士、護工、醫(yī)生四種后來機構(gòu)提出家屬也需要登錄查看老人健康數(shù)據(jù)又追加了家屬角色最終權(quán)限模型變成了五種角色外加系統(tǒng)超級管理員。這里有一個容易被忽視的需求不同角色對數(shù)據(jù)的可見范圍完全不同。比如護工只能看到自己負責樓層的老人列表醫(yī)生能看到全院的健康數(shù)據(jù)但不能操作費用模塊家屬只能看到綁定老人的部分信息。這種數(shù)據(jù)權(quán)限的控制決定了后端的查詢邏輯不能只靠簡單的用戶角色判斷必須設(shè)計一套可配置的數(shù)據(jù)范圍機制這個后面專門講。2. 技術(shù)選型的現(xiàn)實理由為什么還是用Spring Boot打底說實話在2025年這個時間點談技術(shù)選型可選項太多了微服務(wù)、云原生、Serverless……但對這樣一個業(yè)務(wù)復(fù)雜、團隊規(guī)模不大、交付周期緊張的養(yǎng)老管理系統(tǒng)來說Spring Boot仍然是最穩(wěn)妥的打底方案。原因很直接生態(tài)成熟、招人容易、坑都有前人填過而且單體應(yīng)用在數(shù)據(jù)事務(wù)一致性上比微服務(wù)簡單得多。2.1 分層架構(gòu)與目錄結(jié)構(gòu)我采用的是經(jīng)典的四層結(jié)構(gòu)Controller層接收請求、Service層處理業(yè)務(wù)、Mapper層操作數(shù)據(jù)庫、Entity層映射實體。目錄結(jié)構(gòu)上我習慣按業(yè)務(wù)模塊分包而不是按技術(shù)層次分包這樣后期維護時找代碼非?？臁om.eldercare.system ├── controller # 接口層只做參數(shù)接收和結(jié)果封裝 ├── service # 業(yè)務(wù)邏輯層事務(wù)控制都在這一層 ├── mapper # MyBatis接口配合XML文件 ├── entity # 數(shù)據(jù)庫實體對象 ├── dto # 前端交互的數(shù)據(jù)傳輸對象 ├── config # 各類配置類比如MyBatis、Redis、攔截器配置 ├── common # 統(tǒng)一返回結(jié)果、異常處理、工具類 ├── task # 定時任務(wù)類集中放的地方 └── aspect # AOP切面日志記錄和權(quán)限校驗這種分包方式的優(yōu)勢是當你接到一個新需求比如“給家屬端增加健康周報功能”你只需要順著業(yè)務(wù)模塊找到對應(yīng)的controller、service、mapper文件改動的范圍非常明確不會出現(xiàn)改一個功能要翻十幾個目錄的情況。2.2 關(guān)鍵依賴和版本選擇版本選擇上我吃過一次虧這里直接說結(jié)論Spring Boot 2.7.x 配 JDK 8 是最穩(wěn)的組合尤其是對生產(chǎn)環(huán)境已有的老系統(tǒng)而言。如果你是新項目且團隊愿意用 JDK 17那直接上 Spring Boot 3.x 也沒問題但要注意 MyBatis、PageHelper 這些第三方庫是否有對應(yīng)的適配版本。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent依賴清單里我額外加了這幾個MyBatis-Plus做單表CRUD和分頁、Redis做緩存和驗證碼存儲、Spring Security做認證授權(quán)、Hutool工具庫處理日期和字符串、Fastjson2做JSON序列化、WebSocket用于給家屬端推送實時消息。還有一個容易被忽略的依賴是spring-boot-starter-validation參數(shù)校驗如果不引入這個接口層會堆滿手工判斷邏輯代碼會很難看。2.3 初始化配置里被忽略的細節(jié)Spring Boot的自動裝配原理很多人都能背出來但實際配置時有個小細節(jié)容易掉坑多環(huán)境配置文件的拆分。我用的是application.yml加application-dev.yml、application-prod.yml的組合通過啟動參數(shù)--spring.profiles.activeprod切換環(huán)境。同時要注意數(shù)據(jù)庫密碼、第三方密鑰這些絕不能直接寫在配置文件中我這邊是結(jié)合了環(huán)境變量注入和Jasypt加密生產(chǎn)環(huán)境配置文件里看到的是一串密文密鑰本身放在部署服務(wù)器的環(huán)境變量里。spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/eldercare?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: ${DB_USERNAME} password: ${DB_PASSWORD}還有一個小坑提醒一下Spring Boot 2.7.x 之后跨域配置推薦直接實現(xiàn)WebMvcConfigurer的addCorsMappings方法而不是用CrossOrigin注解到處標。前端的Vue項目打包后如果要和Spring Boot放在同一個服務(wù)里跑要注意靜態(tài)資源路徑和接口路徑不能沖突我習慣把接口統(tǒng)一掛/api前綴前端打包產(chǎn)物放到static目錄下。3. 核心表結(jié)構(gòu)設(shè)計與建模思路數(shù)據(jù)庫設(shè)計階段我反復(fù)修改了四版才定稿。核心原因在于養(yǎng)老系統(tǒng)的數(shù)據(jù)關(guān)系比一般的管理系統(tǒng)要復(fù)雜得多——同一個老人既關(guān)聯(lián)著健康檔案、入住記錄、床位信息又關(guān)聯(lián)著護理評估、繳費流水和家屬綁定如果一開始表結(jié)構(gòu)設(shè)計得不夠合理后期寫SQL的時候會非常難受。3.1 老人檔案與健康數(shù)據(jù)的關(guān)系設(shè)計老人基礎(chǔ)檔案我單獨建了一張elder表字段包括姓名、身份證號、家屬聯(lián)系方式、緊急聯(lián)系人、既往病史、過敏藥物、入住日期等。這里有個容易犯的錯誤把健康指標直接作為字段加到elder表里。比如有人會設(shè)計成elder表里加blood_pressure、blood_sugar兩個字段表面上看省事實際上完全違背了業(yè)務(wù)邏輯——血壓血糖是持續(xù)產(chǎn)生的時間序列數(shù)據(jù)每個老人一天可能測量多次正確做法是單獨建一張health_record表每次測量生成一條記錄。CREATE TABLE health_record ( id bigint NOT NULL AUTO_INCREMENT, elder_id bigint NOT NULL COMMENT 老人ID, type varchar(20) NOT NULL COMMENT 指標類型blood_pressure/blood_sugar/heart_rate等, value varchar(50) NOT NULL COMMENT 測量值, unit varchar(20) DEFAULT NULL COMMENT 單位, measured_at datetime NOT NULL COMMENT 測量時間, created_by bigint DEFAULT NULL COMMENT 記錄人設(shè)備采集則為設(shè)備ID, PRIMARY KEY (id), KEY idx_elder_time (elder_id, measured_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;3.2 床位、護理任務(wù)與排班的表關(guān)系床位管理看起來簡單實際上牽扯到入住流程的完整性。我的設(shè)計是bed表記錄床位號和所在房間、樓層check_in_record表記錄每一次入住和退住的周期elder表通過一個current_bed_id字段指向當前床位。這樣設(shè)計的理由是一旦發(fā)生換床或者暫時外出住院current_bed_id可以隨時更新而歷史的入住記錄保留在check_in_record里方便統(tǒng)計入住率和床位周轉(zhuǎn)。護理任務(wù)這塊我建了四張表care_task定義任務(wù)模板比如“每兩小時翻身”“每日早晚測量血壓”care_plan記錄每個老人的個性化計劃care_assignment是具體到某一天某個班次的任務(wù)分配care_execution記錄執(zhí)行結(jié)果。這種設(shè)計把“做什么”“誰來做”“做沒做”三層信息完全拆開當我需要生成月報統(tǒng)計“本月翻身任務(wù)完成率”時只需要關(guān)聯(lián)care_assignment和care_execution兩張表按狀態(tài)字段聚合即可。4. 關(guān)鍵功能模塊的落地與踩坑記錄框架搭好之后真正的工作量在業(yè)務(wù)模塊的細節(jié)實現(xiàn)上。這一節(jié)挑三個最有代表性的功能來拆解每個功能背后都有值得一提的設(shè)計決策和實際問題。4.1 健康監(jiān)測設(shè)備的對接Modbus協(xié)議與WebSocket推送這家養(yǎng)老院采購了一批智能床墊和手腕式血壓計設(shè)備數(shù)據(jù)通過一個本地網(wǎng)關(guān)以Modbus協(xié)議上傳。一開始我打算自己解析Modbus報文后來發(fā)現(xiàn)網(wǎng)關(guān)廠商提供了基于MQTT的數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)于是走了一條更簡單務(wù)實的路——Spring Boot充當MQTT客戶端訂閱設(shè)備數(shù)據(jù)。Configuration public class MqttConfig { Bean public MqttConnectOptions mqttConnectOptions() { MqttConnectOptions options new MqttConnectOptions(); options.setServerURIs(new String[]{tcp://192.168.1.100:1883}); options.setCleanSession(true); options.setConnectionTimeout(10); options.setKeepAliveInterval(30); return options; } }訂閱到數(shù)據(jù)后在消息處理方法里做單位轉(zhuǎn)換和數(shù)據(jù)格式化然后寫入health_record表。同時觸發(fā)異常閾值判斷——比如高壓超過180或者心率低于50立即調(diào)用預(yù)警服務(wù)推送站內(nèi)消息給值班護士、短信通知護士長、并且通過WebSocket實時推送到大屏監(jiān)控端。這里要重點提醒設(shè)備數(shù)據(jù)的并發(fā)寫入量雖然不大但很密集每臺床墊每30秒一條數(shù)據(jù)五十臺設(shè)備同時上報就是每秒近兩條寫入。雖然MySQL完全扛得住但如果是項目初期建議先加上Redis緩存最近一次測量值讀操作優(yōu)先從緩存取減少數(shù)據(jù)庫壓力。4.2 護理任務(wù)排班的定時任務(wù)實現(xiàn)護理排班是整個系統(tǒng)里邏輯最繞的模塊。需求是這樣的系統(tǒng)根據(jù)護理等級自動生成每日任務(wù)比如一級護理的老人每天需要6次血壓測量、4次翻身、3次喂藥提醒二級護理則減少頻次。同時要支持護士長手動調(diào)整某個老人的任務(wù)計劃。實現(xiàn)這個功能我用的是Spring Boot內(nèi)置的Scheduled定時任務(wù)每天早上5點執(zhí)行一次任務(wù)生成邏輯為當天排班的每個護工生成任務(wù)清單。Scheduled(cron 0 0 5 * * ?) public void generateDailyCareTasks() { ListCarePlan plans carePlanService.listValidPlans(); for (CarePlan plan : plans) { ListCareAssignment assignments buildAssignments(plan); careAssignmentService.saveBatch(assignments); } log.info(Daily care tasks generated, total: {}, plans.size()); }實際運營過程中發(fā)現(xiàn)純定時生成滿足不了需求有臨時入住的老人、有臨時取消的任務(wù)護工在APP端點了“確認執(zhí)行”后如果超時未完成系統(tǒng)要自動升級提醒。這些都需要在任務(wù)任務(wù)調(diào)度之外增加觸發(fā)機制。我最終的做法是定時任務(wù)負責生成“計劃內(nèi)任務(wù)”而所有“臨時任務(wù)”通過消息隊列Async異步寫入保證高峰期不會因為線程阻塞影響主流程。另外Spring Boot的Scheduled默認是單線程執(zhí)行的如果你的系統(tǒng)里有多個定時任務(wù)務(wù)必在啟動類上加EnableScheduling的同時配置線程池否則多個任務(wù)會互相排隊等待。4.3 家屬端查看與消息通知家屬端我采用的是Spring Boot Vue分離開發(fā)后端只提供RESTful API。這里重點說消息通知的設(shè)計。需求要求老人的健康數(shù)據(jù)出現(xiàn)異常、每月賬單生成、護理計劃變更時家屬都能收到通知。我最初用的是短信但短信費太高一條一毛多一個月幾千條下來成本不低。后來接入了微信公眾號模板消息家屬關(guān)注公眾號并綁定老人之后后端通過調(diào)用微信接口推送模板消息成本為零。public void sendWechatTemplate(String openId, String templateId, MapString, String data) { String accessToken wechatService.getAccessToken(); JSONObject body new JSONObject(); body.put(touser, openId); body.put(template_id, templateId); body.put(data, data); // 通過RestTemplate調(diào)用微信推送接口 }如果只是做畢設(shè)項目沒有真正的微信公眾號資質(zhì)也可以退一步用spring-boot-starter-mail的JavaMail發(fā)送郵件通知或者直接做站內(nèi)信加WebSocket實時提示效果一樣能演示完整。5. 多角色權(quán)限體系的安全落地權(quán)限體系是我花了最多時間調(diào)試的部分不是因為技術(shù)復(fù)雜而是因為養(yǎng)老機構(gòu)的角色權(quán)限維度和常規(guī)企業(yè)系統(tǒng)不一樣——一個護士長可能既要跨科室查看數(shù)據(jù)又要被限制不能修改某些關(guān)鍵字段醫(yī)生可以看到生命體征趨勢但不能操作繳費護工只能看到自己負責的老人。這種“看得見但動不了”的邊界細分必須用RBAC再加數(shù)據(jù)權(quán)限過濾才能實現(xiàn)。5.1 基于RBAC的菜單與數(shù)據(jù)權(quán)限設(shè)計用戶表、角色表、菜單表、用戶角色關(guān)聯(lián)表、角色菜單關(guān)聯(lián)表這里不展開說明。關(guān)鍵在于數(shù)據(jù)權(quán)限的過濾方案MyBatis-Plus提供了DataPermissionInterceptor數(shù)據(jù)權(quán)限插件可以在SQL執(zhí)行前自動拼接數(shù)據(jù)范圍條件。例如護工登錄后查詢?nèi)蝿?wù)列表時攔截器自動追加WHERE care_assignment.nurse_id 當前用戶ID而護士長登錄時追加的就是WHERE care_assignment.floor_id IN (護士長管轄樓層)。這種方案的好處是業(yè)務(wù)代碼里完全不用寫權(quán)限判斷邏輯Service層只寫正常的業(yè)務(wù)查詢權(quán)限規(guī)則集中在攔截器里配置。要是你沒有用MyBatis-Plus也可以在Service層手動拼接查詢條件但代碼會冗余很多。另外一個很實用的技巧所有需要做數(shù)據(jù)權(quán)限的Mapper方法第一參數(shù)都傳一個DataScope對象作為過濾條件載體這樣既保持兼容又能手動覆蓋默認規(guī)則。5.2 登錄認證、接口鑒權(quán)與操作日志認證這塊我選的是JWT Redis的組合。登錄成功后生成JWT返回前端同時把token存在Redis中設(shè)置過期時間12小時。每次請求通過攔截器校驗token是否有效同時校驗該用戶是否還有操作權(quán)限。這里有個細節(jié)JWT本身是無狀態(tài)的一旦簽發(fā)沒法主動失效所以必須依賴Redis里的狀態(tài)做二次校驗。我踩過的坑是最開始只校驗JWT簽名導(dǎo)致修改密碼后舊token依然能訪問接口后來加上Redis校驗才解決。操作日志用AOP切面實現(xiàn)是最省力的。定義一個Log注解標注在需要記錄的方法上切面里獲取方法參數(shù)、執(zhí)行結(jié)果、當前用戶ID、IP地址、操作耗時異步寫入日志表。對養(yǎng)老系統(tǒng)來說操作日志不只是審計需要還承擔著責任追溯的作用——假如老人出現(xiàn)跌倒事件家屬質(zhì)疑護理不到位系統(tǒng)里能夠查清楚誰在什么時間給老人做了哪些護理操作。Aspect Component public class LogAspect { Around(annotation(operLog)) public Object around(ProceedingJoinPoint point, OperLog operLog) throws Throwable { long start System.currentTimeMillis(); Object result point.proceed(); long cost System.currentTimeMillis() - start; // 異步保存日志 loggerService.asyncSave(buildLog(point, operLog, result, cost)); return result; } }6. 部署與性能優(yōu)化的實戰(zhàn)清單系統(tǒng)開發(fā)完成之后部署和性能優(yōu)化階段又耗了兩周。這里分享幾個我實際遇到并解決的問題如果你想快速把項目跑起來這些經(jīng)驗?zāi)軒湍闵僮卟簧購澛贰?.1 查詢性能優(yōu)化分頁、索引、慢SQL最核心的高頻查詢是“老人列表頁”需要關(guān)聯(lián)床位信息、護理等級、當前狀態(tài)還要支持按姓名、樓層、狀態(tài)篩選。數(shù)據(jù)量幾百條的時候沒感覺等業(yè)務(wù)跑了兩個月、健康記錄表到了幾十萬行之后列表查詢明顯變慢。排查下來發(fā)現(xiàn)慢的主要原因有兩個一是多表關(guān)聯(lián)時沒有走索引二是health_record表的數(shù)據(jù)量增長導(dǎo)致聯(lián)表掃描時間變長。解決方案很簡單給elder表的name、current_bed_id字段加了索引給health_record表的elder_id和measured_at建了聯(lián)合索引。同時把所有列表查詢改成了分頁查詢統(tǒng)一使用MyBatis-Plus的Page對象避免一次查出全表數(shù)據(jù)。這里建議從項目初期就養(yǎng)成習慣任何列表接口一律分頁不要圖省事返回全量數(shù)據(jù)。慢SQL日志一定要在開發(fā)階段就開啟MyBatis的mybatis.configuration.log-impl設(shè)為StdOutImpl可以在控制臺打印完整SQL配合druid連接池的監(jiān)控頁面基本能定位90%的慢查詢問題。6.2 打包部署時的常見坑打包部署我經(jīng)歷了兩個坑值得一提。第一個是前端Vue項目打包后放進Spring Boot的static目錄刷新頁面就直接404。原因是Vue的路由是history模式一旦直接訪問/elder/list這個前端路由后端的DispatcherServlet會嘗試尋找對應(yīng)的Controller找不到就返回404。解決辦法是在Spring Boot里加一個ErrorPageRegistrar把前端路由的404請求統(tǒng)一轉(zhuǎn)發(fā)到index.html。第二個坑是打包產(chǎn)物太大jar包超過150MB每次上傳服務(wù)器都特別慢。分析后發(fā)現(xiàn)一半的體積來自靜態(tài)資源和第三方依賴。我在pom.xml里配置了Spring Boot Maven Plugin的excludes把前端靜態(tài)資源單獨放在服務(wù)器上用Nginx托管后端jar包瘦身到60MB左右。實際上生產(chǎn)環(huán)境建議前后端完全分離部署Spring Boot進程不處理靜態(tài)資源讓Nginx統(tǒng)一抗并發(fā)這是最省事的架構(gòu)。6.3 容器化部署的額外建議如果你想把系統(tǒng)用Docker部署Dockerfile建議用多階段構(gòu)建第一個階段用maven:3.8-jdk-8執(zhí)行打包第二個階段用openjdk:8-jre-alpine作為運行環(huán)境只復(fù)制jar包進去。這樣構(gòu)建出來的鏡像體積可以從1GB以上降到200MB以內(nèi)。FROM maven:3.8-jdk-8 AS build WORKDIR /app COPY pom.xml . COPY src ./src RUN mvn package -DskipTests FROM openjdk:8-jre-alpine WORKDIR /app COPY --frombuild /app/target/eldercare-system.jar . EXPOSE 8080 ENTRYPOINT [java, -jar, eldercare-system.jar, --spring.profiles.activeprod]數(shù)據(jù)庫如果用Docker跑MySQL一定要把數(shù)據(jù)目錄掛載到宿主機否則容器一刪數(shù)據(jù)全丟。我在測試環(huán)境犯過這個錯誤重新導(dǎo)入數(shù)據(jù)浪費了半天。生產(chǎn)環(huán)境的數(shù)據(jù)庫建議直接部署在宿主機上不跑容器運維起來更省心。實際開發(fā)中還有一個和功能無關(guān)但很影響體驗的事日志規(guī)范。這套系統(tǒng)我統(tǒng)一用logback作為日志框架輸出格式里包含時間、線程名、級別、Logger名稱、消息體。同時在application.yml里配置了按天滾動的日志策略保留最近三十天日志歸檔文件壓縮后存到專門目錄。當線上出現(xiàn)問題需要排查時直接grep關(guān)鍵詞定位錯誤效率比翻控制臺高得多?；剡^頭來看這個項目技術(shù)上并沒有用到什么炫酷的新框架核心能力全部建立在Spring Boot這個穩(wěn)定基座之上。但真正的價值在于對業(yè)務(wù)的理解——怎么把老人的健康數(shù)據(jù)流、護理任務(wù)流、家屬溝通流串起來讓系統(tǒng)不再只是一個記錄工具而能真正減少一線護理人員的工作負擔、降低管理風險。如果你也在做類似的系統(tǒng)開發(fā)建議多花時間在業(yè)務(wù)調(diào)研和表結(jié)構(gòu)設(shè)計上這兩個環(huán)節(jié)做扎實了后面的代碼開發(fā)反而是一路順暢的。