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