又是一個(gè)“基于SpringBoot的XX管理系統(tǒng)”的畢設(shè)選題而且這次是智慧養(yǎng)老中心方向。每年這個(gè)時(shí)候都會(huì)有人拿著類(lèi)似的題目來(lái)找我聊問(wèn)這個(gè)題好不好做、和網(wǎng)上那些圖書(shū)管理系統(tǒng)、商城系統(tǒng)有什么區(qū)別、技術(shù)棧到底怎么選。如果你正準(zhǔn)備做或者正在做這套“智慧養(yǎng)老中心管理系統(tǒng)”這篇內(nèi)容可以幫你把這些思路理順。這套系統(tǒng)的本質(zhì)并不復(fù)雜它是一套標(biāo)準(zhǔn)的企業(yè)級(jí)業(yè)務(wù)管理系統(tǒng)再加上“智慧”兩個(gè)字帶來(lái)的場(chǎng)景差異化比如老人檔案管理、健康數(shù)據(jù)記錄、照護(hù)任務(wù)流轉(zhuǎn)、床位費(fèi)用結(jié)算、家屬端信息同步等。它不是做人工智能算法也不會(huì)真的去對(duì)接硬件采集生命體征核心考察點(diǎn)是你能否用 SpringBoot 把一套業(yè)務(wù)流程完整地做成線上管理系統(tǒng)并保證權(quán)限、狀態(tài)、數(shù)據(jù)關(guān)系都不亂。所以這個(gè)題目做得好不好往往不在于你有沒(méi)有“黑科技”而在于需求理得清不清楚、表設(shè)計(jì)規(guī)不規(guī)范、流程能不能自洽。下面的內(nèi)容我會(huì)按照自己做項(xiàng)目時(shí)的習(xí)慣從需求拆解講起一直講到后端實(shí)現(xiàn)、坑點(diǎn)規(guī)避和最后的畢設(shè)答辯展示把整個(gè)過(guò)程掰開(kāi)來(lái)講。不管你現(xiàn)在是剛打開(kāi) IDEA 還不知道建什么包還是已經(jīng)把登錄做完了開(kāi)始迷茫下一步這篇都能給你一個(gè)相對(duì)完整的參考。1. 需求拆解與整體設(shè)計(jì)思路1.1 為什么智慧養(yǎng)老中心適合做 SpringBoot 畢設(shè)先說(shuō)個(gè)很現(xiàn)實(shí)的問(wèn)題每年畢設(shè)選題里管理系統(tǒng)占了一大半比如圖書(shū)管理、宿舍管理、校園失物招領(lǐng)。這些題并不是不好只是做的人太多了老師一眼就能看出你的系統(tǒng)是照著哪個(gè)模板改的。而“養(yǎng)老中心管理系統(tǒng)”在業(yè)務(wù)上有一個(gè)天然優(yōu)勢(shì)它有大量真實(shí)存在的信息化痛點(diǎn)比如老人入住、健康檔案更新、護(hù)理任務(wù)派單、家屬溝通記錄、費(fèi)用結(jié)算等這些模塊之間有很強(qiáng)的業(yè)務(wù)關(guān)聯(lián)不是單純一張 CRUD 表就能糊弄過(guò)去的。其次這個(gè)題目自帶“智慧”的包裝空間。你不一定非要做什么物聯(lián)網(wǎng)設(shè)備對(duì)接、人臉識(shí)別門(mén)禁哪怕是在健康數(shù)據(jù)里做一個(gè)異常指標(biāo)提醒在報(bào)表里做一個(gè)可視化統(tǒng)計(jì)都能在答辯時(shí)有一個(gè)“智慧化”的落地點(diǎn)。說(shuō)白了這個(gè)題目的上限很高但下限也很清晰只要能把傳統(tǒng)養(yǎng)老中心的線下紙質(zhì)臺(tái)賬、Excel 管理流程搬到線上就已經(jīng)達(dá)到畢設(shè)的基本要求。1.2 先理清“誰(shuí)在用、用來(lái)干什么”動(dòng)手寫(xiě)代碼之前我最建議你先做一件不寫(xiě)代碼的事把用戶角色和核心場(chǎng)景寫(xiě)清楚。很多畢設(shè)做亂不是因?yàn)楣δ軐?xiě)不出來(lái)而是因?yàn)橐婚_(kāi)始就沒(méi)想明白哪些人會(huì)用系統(tǒng)、每個(gè)角色關(guān)心的數(shù)據(jù)到底是什么。養(yǎng)老中心管理系統(tǒng)底層角色一般分這幾類(lèi)系統(tǒng)管理員維護(hù)所有基礎(chǔ)數(shù)據(jù)包括員工賬號(hào)、房間床位信息、服務(wù)項(xiàng)目?jī)r(jià)格、系統(tǒng)字典項(xiàng)等。前臺(tái)/接待人員負(fù)責(zé)老人入住登記、家屬來(lái)訪記錄、參觀預(yù)約、退住辦理。護(hù)理員負(fù)責(zé)執(zhí)行每日照護(hù)任務(wù)填寫(xiě)照護(hù)記錄上報(bào)老人異常情況。護(hù)士/健康管理人員維護(hù)老人健康檔案錄入體檢指標(biāo)關(guān)注異常數(shù)據(jù)并生成健康提醒。財(cái)務(wù)/收費(fèi)人員生成月度賬單記錄繳費(fèi)情況處理退費(fèi)。養(yǎng)老中心負(fù)責(zé)人/院長(zhǎng)查看入住率、工單完成率、收費(fèi)統(tǒng)計(jì)等總覽數(shù)據(jù)。家屬擴(kuò)展角色查看老人的照護(hù)記錄、健康數(shù)據(jù)、費(fèi)用賬單申請(qǐng)預(yù)約探視。上面這些角色根據(jù)你畢設(shè)的工作量可以合并比如把財(cái)務(wù)和系統(tǒng)管理員并成一個(gè)“管理員”角色把護(hù)士和護(hù)理員合并成“護(hù)理人員”至少保留三種角色管理員、護(hù)理人員、前臺(tái)接待。如果做了移動(dòng)端或家屬端可以再加一個(gè)家屬查看用戶的擴(kuò)展點(diǎn)。不要小看這個(gè)步驟你后面畫(huà) ER 圖、寫(xiě)接口文檔、分 module 開(kāi)發(fā)甚至答辯時(shí)被老師問(wèn)“你系統(tǒng)的用戶權(quán)限設(shè)計(jì)是什么”全部都要基于這張角色列表來(lái)回答。1.3 模塊邊界與數(shù)據(jù)流轉(zhuǎn)設(shè)計(jì)把角色理清之后你會(huì)很自然地得到以下功能模塊它們也是你畫(huà)系統(tǒng)功能架構(gòu)圖的素材老人檔案管理基本信息、家屬聯(lián)系人、入住記錄、住址、緊急聯(lián)系人。床位與房間管理樓棟、樓層、房型、床位狀態(tài)空置/占用/維修支持入住分配床位、退住釋放床位。健康檔案管理體檢記錄、慢病標(biāo)簽、用藥提醒、異常指標(biāo)記錄。照護(hù)工單管理根據(jù)老人護(hù)理等級(jí)生成每日任務(wù)護(hù)理員逐項(xiàng)執(zhí)行和上報(bào)異常情況進(jìn)入待處理列表。服務(wù)項(xiàng)目與費(fèi)用管理定義服務(wù)項(xiàng)目?jī)r(jià)格按入住天數(shù)或按服務(wù)次數(shù)計(jì)費(fèi)生成月度費(fèi)用賬單。接待與訪客管理參觀登記、預(yù)約記錄、訪客來(lái)訪信息。系統(tǒng)管理員工賬號(hào)、角色權(quán)限、操作日志、數(shù)據(jù)字典。模塊之間是存在狀態(tài)關(guān)聯(lián)的。舉個(gè)例子老人入住后系統(tǒng)才允許給他生成健康檔案和照護(hù)計(jì)劃老人退住后他的床位狀態(tài)變成“空置”但檔案并不刪除而是變成“已退住”狀態(tài)方便后續(xù)統(tǒng)計(jì)和歷史查詢。這種業(yè)務(wù)規(guī)則比你在表白墻管理系統(tǒng)里寫(xiě)十個(gè) CRUD 更值得在答辯的時(shí)候說(shuō)。2. 技術(shù)選型與項(xiàng)目骨架搭建2.1 技術(shù)選型的黃金組合SpringBoot Vue MySQL智慧養(yǎng)老中心管理系統(tǒng)技術(shù)棧選擇上我只說(shuō)一句話主流的、自己熟悉的、文檔多的方案就是好方案。如果你沒(méi)有特殊理由請(qǐng)優(yōu)先考慮這套組合后端SpringBoot 2.7.x MyBatis-Plus MySQL 8.0前端Vue 2 Element UI或者 Vue 3 Element Plus取決于你的熟練度權(quán)限認(rèn)證Spring Security / 攔截器 JWT接口文檔Knife4jSwagger 增強(qiáng)版構(gòu)建工具M(jìn)avenSpringBoot 2.7.x 是當(dāng)前最穩(wěn)妥的版本選擇。為什么不用 3.x因?yàn)樵跓衢T(mén)搜索里我也看到很多人反饋“SpringBoot版本太高”導(dǎo)致各種依賴不兼容的情況SpringBoot 3 基于 Jakarta EE很多老教程里的 javax 包要改 jakarta對(duì)新手來(lái)說(shuō)這種問(wèn)題非常消耗時(shí)間。如果你的 JDK 是 1.8那就更沒(méi)必要糾結(jié)直接用 2.7.x它能和 JDK 8 完美配合網(wǎng)上的資料也最多遇到問(wèn)題時(shí)最容易檢索到解決方案。ORM 層能用 MyBatis-Plus 就不要手寫(xiě)純 MyBatis。不是否定 MyBatis而是在畢設(shè)周期內(nèi)MyBatis-Plus 自帶的 BaseMapper 能幫你省去大量重復(fù)的單表 CRUD而且它支持邏輯刪除、自動(dòng)填充時(shí)間字段、樂(lè)觀鎖插件這些都可以作為你“考慮到了開(kāi)發(fā)效率和數(shù)據(jù)安全”的加分點(diǎn)直接寫(xiě)進(jìn)設(shè)計(jì)文檔。前端如果你不會(huì) Vue也可以考慮后端模板引擎方案即 SpringBoot Thymeleaf Bootstrap。雖然看起來(lái)不那么“企業(yè)級(jí)”但安全性更高至少你不需要解決跨域和前后端聯(lián)調(diào)的問(wèn)題。不過(guò)考慮到這個(gè)題目在網(wǎng)絡(luò)上的主流方案都是前后端分離我也建議你按前后端分離來(lái)做畢竟答辯時(shí)直接展示一個(gè)獨(dú)立前端頁(yè)面會(huì)比純后端接口更有說(shuō)服力。2.2 后端工程結(jié)構(gòu)怎么分包才像“企業(yè)級(jí)”很多同學(xué)拿到題之后第一步是新建 Spring Initializr 項(xiàng)目然后默認(rèn)生成一個(gè) SpringbootApplication 類(lèi)接著就開(kāi)始在 controller 里面寫(xiě)業(yè)務(wù)代碼。我見(jiàn)過(guò)太多三個(gè) Controller 撐起整個(gè)項(xiàng)目的畢設(shè)代碼了最后答辯的時(shí)候老師一看源碼就問(wèn)你項(xiàng)目為什么要分這幾層三個(gè)學(xué)生有八個(gè)叫法直接把答辯變成了災(zāi)難。正確做法是嚴(yán)格遵循分層架構(gòu)你的后端包結(jié)構(gòu)可以這樣設(shè)計(jì)com.example.eldercare ├── common // 通用模塊統(tǒng)一返回結(jié)果、異常處理、工具類(lèi) │ ├── result │ ├── exception │ └── utils ├── config // 配置類(lèi)跨域、MyBatis-Plus、Knife4j、靜態(tài)資源映射 ├── controller // 控制層接收參數(shù)返回統(tǒng)一 Result ├── service // 服務(wù)層業(yè)務(wù)邏輯都放在這里 │ └── impl ├── mapper // 數(shù)據(jù)訪問(wèn)層繼承 BaseMapper ├── entity // 數(shù)據(jù)庫(kù)實(shí)體類(lèi) ├── dto // 前端入?yún)?duì)象 ├── vo // 視圖對(duì)象 └── security // JWT 攔截器、權(quán)限注解相關(guān)處理這里面有個(gè)值得你注意的地方實(shí)體類(lèi) entity 直接對(duì)應(yīng)數(shù)據(jù)庫(kù)字段而 dto 和 vo 是為了避免把數(shù)據(jù)庫(kù)結(jié)構(gòu)直接暴露給前端而存在的。比如新增老人入住時(shí)前端傳過(guò)來(lái)的對(duì)象可能包含入住時(shí)間、床位ID、家屬清單甚至還有附件但如果直接寫(xiě)成接收 Elder 實(shí)體屬性對(duì)不上會(huì)非常難受。正確做法是建一個(gè) ElderCheckInDTO把這些字段聚合起來(lái)再由 Service 層拆分成老人表、家屬表、床位表的三次操作而這個(gè)拆分動(dòng)作就是你在答辯時(shí)可以重點(diǎn)講的“業(yè)務(wù)層事務(wù)設(shè)計(jì)”。2.3 中間件Redis、MQ 到底要不要引每次做畢設(shè)都會(huì)有同學(xué)問(wèn)我老師要求用 Redis / 消息隊(duì)列 / Elasticsearch我該怎么集成我給的答案一般是分情況討論。如果畢設(shè)要求里沒(méi)有硬性規(guī)定我的建議是不引或者少引。因?yàn)槟阋胍粋€(gè)中間件就要在論文里解釋為什么要用、部署環(huán)境是否支持、數(shù)據(jù)一致性如何保證這反而會(huì)成為答辯時(shí)一個(gè)容易被追問(wèn)的點(diǎn)。SpringBoot 系統(tǒng)本身的緩存抽象Cacheable就能滿足“老人列表熱點(diǎn)數(shù)據(jù)緩存”的基本演示需求。如果你就是想展示 Redis 能力可以把它用在兩個(gè)相對(duì)合理的點(diǎn)一個(gè)是登錄驗(yàn)證碼存儲(chǔ)另一個(gè)是在 Redis 里維護(hù)護(hù)理員今日待辦任務(wù)的緩存因?yàn)楣螤顟B(tài)頻繁查詢用緩存能明顯降低數(shù)據(jù)庫(kù)壓力。這兩個(gè)點(diǎn)業(yè)務(wù)上都說(shuō)得通也不難實(shí)現(xiàn)。消息隊(duì)列也是同樣道理。如果系統(tǒng)需要在“護(hù)理員上報(bào)異常情況”后立即通知管理員這類(lèi)演示場(chǎng)景用 WebSocket 或者全局異常事件監(jiān)聽(tīng)就夠了沒(méi)有必要為了用 RableMQ 而硬引入。如果擔(dān)心擴(kuò)展性被人質(zhì)疑可以在文檔中寫(xiě)一句“基于可擴(kuò)展的設(shè)計(jì)原則本系統(tǒng)的通知模塊可平滑替換為消息隊(duì)列方案”既展示了你了解 MQ又不用承擔(dān)實(shí)操后的復(fù)雜度。3. 核心業(yè)務(wù)實(shí)現(xiàn)與關(guān)鍵代碼設(shè)計(jì)3.1 數(shù)據(jù)庫(kù)表設(shè)計(jì)從“老人-床位-工單”看關(guān)聯(lián)關(guān)系數(shù)據(jù)庫(kù)表設(shè)計(jì)是這套系統(tǒng)的靈魂我建議你先想清楚核心主鏈路再補(bǔ)全輔助表。核心主鏈路是這樣一條線老人入住時(shí)關(guān)聯(lián)一個(gè)床位系統(tǒng)根據(jù)老人的護(hù)理等級(jí)自動(dòng)生成每日照護(hù)任務(wù)護(hù)理員完成這些任務(wù)后產(chǎn)生照護(hù)記錄同時(shí)月度費(fèi)用表通過(guò)服務(wù)項(xiàng)目和入住時(shí)長(zhǎng)生成賬單。可以看兩張最核心的表設(shè)計(jì)思路。第一張是老人信息表elder_info核心字段包括id主鍵name老人姓名gender性別birthday出生日期id_card身份證號(hào)phone本人電話可能為空health_level護(hù)理等級(jí)自理/半自理/全護(hù)理status狀態(tài)待入住/在住/已退住room_id當(dāng)前床位ID可空emergency_contact緊急聯(lián)系人姓名emergency_phone緊急聯(lián)系人電話create_timeupdate_time這里有兩個(gè)設(shè)計(jì)細(xì)節(jié)身份證號(hào)建議加唯一索引因?yàn)橐粋€(gè)老人只能有一條主檔案status 字段非常關(guān)鍵不能通過(guò) room_id 是否為空來(lái)判斷老人狀態(tài)因?yàn)橐粋€(gè)老人可能只是登記了還沒(méi)入住也可能退住后房間還沒(méi)釋放狀態(tài)字段要顯式維護(hù)。第二張是照護(hù)任務(wù)表care_task核心字段如下id主鍵elder_id老人 IDcare_date照護(hù)日期task_type任務(wù)類(lèi)型如晨間護(hù)理、血壓測(cè)量、送餐、康復(fù)訓(xùn)練executor_id護(hù)理員 IDstatus待執(zhí)行/執(zhí)行中/已完成/已取消execute_time實(shí)際執(zhí)行時(shí)間remark備注在設(shè)計(jì)任務(wù)表時(shí)我最想強(qiáng)調(diào)的是業(yè)務(wù)狀態(tài)的一致性。比如老人已經(jīng)退住了、或者床位換到另一個(gè)區(qū)域原來(lái)生成的 future 任務(wù)應(yīng)該被批量取消。如果不處理這些狀態(tài)就會(huì)在“待辦任務(wù)”里看到已退住老人的任務(wù)還在列表里滾這種細(xì)節(jié)是非常常見(jiàn)的畢設(shè) bug但同時(shí)也是答辯時(shí)展示你考慮周全的好素材。3.2 老人入住與退住的 Service 層事務(wù)處理后端邏輯中最有含金量的不是單表 CRUD而是多表聯(lián)動(dòng)的入住、退住操作。我寫(xiě)一個(gè)入住接口的大致邏輯你感受一下。假如老人已經(jīng)創(chuàng)建了檔案現(xiàn)在前臺(tái)為他辦理入住選擇一個(gè)床位。整個(gè)入住流程如下校驗(yàn)老人狀態(tài)必須是“待入住”不是“在住”或者“已退住”。校驗(yàn)所選床位狀態(tài)必須為“空置”。修改床位狀態(tài)為“占用”綁定房間號(hào)和樓棟信息。修改老人狀態(tài)為“在住”寫(xiě)入入住時(shí)間。創(chuàng)建一條入住記錄比如入住登記時(shí)間、操作人。根據(jù)老人的護(hù)理等級(jí)自動(dòng)生成未來(lái)一段時(shí)間的照護(hù)任務(wù)。這六步必須在一個(gè)事務(wù)里完成。如果第二步成功后第三步失敗數(shù)據(jù)庫(kù)回滾不會(huì)出現(xiàn)床位已經(jīng)占用但老人還是“待入住”的臟數(shù)據(jù)。對(duì)應(yīng)的 Service 層核心代碼可以寫(xiě)成下面這樣Transactional(rollbackFor Exception.class) public ResultVoid checkIn(ElderCheckInDTO dto) { // 1. 校驗(yàn)老人狀態(tài) Elder elder elderMapper.selectById(dto.getElderId()); if (elder null || !待入住.equals(elder.getStatus())) { throw new BusinessException(當(dāng)前老人狀態(tài)不允許辦理入住); } // 2. 校驗(yàn)床位狀態(tài) RoomBed bed bedMapper.selectById(dto.getBedId()); if (bed null || !空置.equals(bed.getStatus())) { throw new BusinessException(當(dāng)前床位已被占用或不存在); } // 3. 更新床位 bed.setStatus(占用); bedMapper.updateById(bed); // 4. 更新老人信息 elder.setStatus(在住); elder.setRoomId(dto.getBedId()); elder.setCheckInTime(LocalDateTime.now()); elderMapper.updateById(elder); // 5. 創(chuàng)建入住記錄 CheckInLog log new CheckInLog(); log.setElderId(elder.getId()); log.setBedId(bed.getId()); log.setOperatorId(getCurrentUserId()); checkInLogMapper.insert(log); // 6. 生成未來(lái) N 天照護(hù)任務(wù) generateCareTask(elder.getId(), dto.getDays(), elder.getHealthLevel()); return Result.success(); }這一段代碼外行看上去只是幾個(gè) update但你能在答辯時(shí)說(shuō)清楚的點(diǎn)非常多為什么用Transactional(rollbackFor Exception.class)而不是默認(rèn)配置、為什么先校驗(yàn)后更新、為什么任務(wù)生成放在入住接口內(nèi)部而不是前端調(diào)用兩個(gè)接口。這些就是“業(yè)務(wù)閉環(huán)”和“低水平 CRUD”的本質(zhì)區(qū)別。3.3 照護(hù)任務(wù)的查詢與工單接單處理對(duì)于護(hù)理員端來(lái)說(shuō)他登錄后最關(guān)心的是“今天我要做哪些任務(wù)”。所以后端要給護(hù)理員提供一個(gè)查詢今日待辦事項(xiàng)的接口。如果只是簡(jiǎn)單select * from care_task where executor_id 也能跑但更好的做法是支持按日期、按狀態(tài)、按老人名模糊篩選并且分頁(yè)返回。用 MyBatis-Plus 的 LambdaQueryWrapper 是最快的寫(xiě)法public PageResultCareTaskVO getMyTask(Long executorId, String date, Integer status, int page, int size) { PageCareTask pageParam new Page(page, size); LambdaQueryWrapperCareTask wrapper new LambdaQueryWrapper(); wrapper.eq(CareTask::getExecutorId, executorId) .eq(StringUtils.isNotBlank(date), CareTask::getCareDate, date) .eq(status ! null, CareTask::getStatus, status) .orderByAsc(CareTask::getStatus) .orderByAsc(CareTask::getCareDate); PageCareTask result careTaskMapper.selectPage(pageParam, wrapper); // 轉(zhuǎn)為 VO補(bǔ)充老人姓名、房間號(hào)等冗余展示字段 PageResultCareTaskVO voPage new PageResult(); // 這里做數(shù)據(jù)組裝... return voPage; }這里有一個(gè)容易被忽視的小坑如果要展示老人姓名、房間號(hào)不要直接在 Mapper 層寫(xiě) join 查所有字段也不要每查詢一條任務(wù)就調(diào)一次 ElderMapper.selectById這會(huì)產(chǎn)生 N1 問(wèn)題。低級(jí)做法是遍歷 task 集合逐個(gè)查老人稍好一點(diǎn)是在 Mapper 里一次性 join 查詢老人姓名和床位信息再好一點(diǎn)是查詢?nèi)蝿?wù)列表后批量查出所有 elderId 對(duì)應(yīng)的老人信息放到 Map 里然后內(nèi)存中組裝。在數(shù)據(jù)量不大的畢設(shè)里 N1 問(wèn)題不明顯但我建議你在代碼注釋里寫(xiě)明“這里避免 N1 問(wèn)題所以采用內(nèi)存組裝”這也是答辯加分項(xiàng)。工單流轉(zhuǎn)的狀態(tài)機(jī)設(shè)計(jì)同樣值得思考。一張照護(hù)任務(wù)工單的狀態(tài)變化大致是待執(zhí)行 → 執(zhí)行中 → 已完成或者 待執(zhí)行 → 取消。如果狀態(tài)比較多建議用狀態(tài)機(jī)模式或者枚舉維護(hù)狀態(tài)轉(zhuǎn)換合法性而不是在 controller 里隨手setStatus(已完成)?？梢宰鲆粋€(gè)簡(jiǎn)單枚舉public enum CareTaskStatus { PENDING(待執(zhí)行), DOING(執(zhí)行中), DONE(已完成), CANCELED(已取消); private final String desc; public boolean canTransferTo(CareTaskStatus target) { if (this PENDING (target DOING || target CANCELED)) return true; if (this DOING target DONE) return true; return false; } }這樣做的好處是非法狀態(tài)流轉(zhuǎn)比如從“待執(zhí)行”直接跳到“已完成”在代碼層面就能攔截而不是等臟數(shù)據(jù)出現(xiàn)在頁(yè)面上才暴露問(wèn)題。3.4 健康數(shù)據(jù)上報(bào)與異常提醒的實(shí)現(xiàn)方案智慧感最強(qiáng)、差異化最大的模塊就在這里。老人健康檔案不僅僅是一張?bào)w檢表還要有定期錄入的體征數(shù)據(jù)比如血壓、血糖、心率、體溫每次錄入的時(shí)候系統(tǒng)自動(dòng)判斷新增數(shù)據(jù)是否超出正常范圍。如果超出則生成一條異常健康提醒推送給管理員或者護(hù)理員。這類(lèi)邏輯我們可以寫(xiě)一個(gè)獨(dú)立的HealthAlertService。健康記錄表為elder_health_record包含以下字段elder_id老人 IDrecord_type指標(biāo)類(lèi)型比如血壓、血糖、心率record_value指標(biāo)值unit單位如 mmHg、mmol/Lrecord_time測(cè)量時(shí)間is_abnormal是否異常advice建議或備注每次保存一條健康記錄時(shí)用一個(gè)規(guī)則判斷超不超標(biāo)。比如血壓的正常范圍是收縮壓 90-140mmHg舒張壓是 60-90mmHg具體閾值可以配置到系統(tǒng)字典表中方便管理人員調(diào)整而不用改代碼。代碼邏輯如下public ResultVoid recordHealth(HealthRecordDTO dto) { HealthRecord record new HealthRecord(); BeanUtils.copyProperties(dto, record); boolean abnormal judgeAbnormal(dto.getRecordType(), dto.getRecordValue()); record.setIsAbnormal(abnormal ? 1 : 0); healthRecordMapper.insert(record); if (abnormal) { HealthAlert alert new HealthAlert(); alert.setElderId(dto.getElderId()); alert.setRecordId(record.getId()); alert.setAlertLevel(普通); // 可以根據(jù)具體偏離幅度設(shè)置 alert.setStatus(待處理); healthAlertMapper.insert(alert); } return Result.success(); }這樣做的好處是業(yè)務(wù)閉環(huán)清晰健康錄入接口只負(fù)責(zé)錄入和規(guī)則判斷異常提醒生成之后管理員可以在“待處理提醒”列表里看到點(diǎn)擊后填寫(xiě)處理措施更新提醒狀態(tài)。如果你還想再加一層“智慧”成分可以寫(xiě)一個(gè)定時(shí)任務(wù)每天統(tǒng)計(jì)過(guò)去 24 小時(shí)的異常健康提醒數(shù)量生成日?qǐng)?bào)發(fā)送到負(fù)責(zé)人的系統(tǒng)通知里用 SpringBoot 的 Scheduled 注解就能實(shí)現(xiàn)不復(fù)雜也不容易翻車(chē)。3.5 文件上傳與靜態(tài)資源映射的大坑智慧養(yǎng)老系統(tǒng)里會(huì)涉及老人照片、體檢報(bào)告 PDF、入住協(xié)議等文件上傳。很多同學(xué)做文件上傳的時(shí)候在本地跑還好好的一打包部署就發(fā)現(xiàn)圖片加載不出來(lái)原因多半是路徑問(wèn)題。SpringBoot 默認(rèn)的靜態(tài)資源目錄是classpath:/static/但這個(gè)目錄存在于 jar 包內(nèi)部運(yùn)行期往 jar 里寫(xiě)文件是非常糟糕的設(shè)計(jì)通常不行也極不建議。正確的標(biāo)準(zhǔn)做法是使用本地磁盤(pán)存放上傳文件然后通過(guò)配置類(lèi)把磁盤(pán)目錄映射成 URL 訪問(wèn)路徑。步驟如下在配置文件中指定上傳目錄與映射前綴。file: upload-dir: /data/eldercare/upload/ access-path: /upload/**創(chuàng)建 WebMvc 配置類(lèi)做資源映射。Configuration public class WebMvcConfig implements WebMvcConfigurer { Resource private FileProperties fileProperties; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(fileProperties.getAccessPath()) .addResourceLocations(file: fileProperties.getUploadDir()); } }Controller 中接收文件并轉(zhuǎn)存到目標(biāo)目錄。PostMapping(/file/upload) public ResultString upload(RequestParam(file) MultipartFile file) { String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); String newFileName UUID.randomUUID() suffix; File dest new File(fileProperties.getUploadDir() newFileName); File parent dest.getParentFile(); if (!parent.exists()) { parent.mkdirs(); } file.transferTo(dest); return Result.success(/upload/ newFileName); }這里有幾個(gè)很重要的細(xì)節(jié)。第一不要在 URL 中返回本地磁盤(pán)絕對(duì)路徑而是返回/upload/xxx.jpg這種虛擬路徑否則前端拿到形如d:\upload\xxx.jpg的地址根本無(wú)法訪問(wèn)。第二生成新文件名盡量用 UUID避免用戶上傳兩個(gè)同名文件相互覆蓋也避免文件名里的中文和非法字符引發(fā)問(wèn)題。第三如果系統(tǒng)被部署到 Docker 容器里需要把宿主機(jī)的一個(gè)目錄掛載到容器內(nèi)的/data/eldercare/upload/否則容器重建后文件就全消失了。這個(gè)點(diǎn)也許你現(xiàn)在用不上但如果你用 Docker 部署它是一個(gè)非常值得提前留意的坑。3.6 權(quán)限設(shè)計(jì)與 Swagger 放行權(quán)限設(shè)計(jì)部分最簡(jiǎn)單的實(shí)現(xiàn)方案是使用 JWT 攔截器。這也是最流行、最好講清楚的方案。用戶在登錄接口驗(yàn)證賬號(hào)密碼成功后后端根據(jù)用戶 ID、用戶名、角色生成一個(gè) JWT Token 返回給前端。前端后續(xù)請(qǐng)求都在請(qǐng)求頭帶上Authorization: Bearer token后端寫(xiě)一個(gè)攔截器統(tǒng)一解析 Token并把用戶信息放到 ThreadLocal 中供 Controller 使用。攔截器默認(rèn)攔截所有接口但一定要在配置中放行登錄接口和 Swagger 接口。不然后端寫(xiě)好接口文檔后前端在 Knife4j 頁(yè)面上測(cè)試每一個(gè)接口都會(huì)提示“未登錄或Token失效”。登錄接口路徑你根據(jù)自己定義Swagger 放行路徑一般有兩種區(qū)分版本的方式如果你用的是 SpringBoot 2.7.x springfox放行路徑通常是/swagger-resources/**、/swagger-ui/**、/v3/api-docs/**。如果你用的是 Knife4j通常額外需要放行/doc.html。這部分可以在 WebMvc 配置類(lèi)的addInterceptors方法中指定Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JwtInterceptor()) .addPathPatterns(/**) .excludePathPatterns( /api/auth/login, /doc.html, /webjars/**, /swagger-resources/**, /v2/api-docs/**, /favicon.ico, /upload/** ); }有一個(gè)也很容易被忽略的點(diǎn)是靜態(tài)文件路徑需要放行比如/upload/**。不然用戶頭像、體檢報(bào)告上傳后前端img標(biāo)簽直接訪問(wèn)圖片 URL 也會(huì)被攔截器攔下來(lái)導(dǎo)致圖片顯示異常。在 Controller 層做角色權(quán)限時(shí)我建議先用最簡(jiǎn)單合理的方法自定義一個(gè)RequireRole(管理員)注解在攔截器中判斷當(dāng)前用戶角色。實(shí)現(xiàn)也不復(fù)雜只需要在 HandlerMethod 上讀取注解。如果沒(méi)有時(shí)間做 Spring Security用這種方式也足夠支撐你答辯里“實(shí)現(xiàn)了基于 RBAC 的權(quán)限控制”這句話。但如果你的開(kāi)題報(bào)告里明確寫(xiě)了 Spring Security那你就要用 Spring Security 做完整的過(guò)濾鏈配置不要中途想當(dāng)然地切換到自定義攔截器避免答辯時(shí)文檔和代碼不一致。3.7 費(fèi)用結(jié)算模塊要注意的時(shí)間維度費(fèi)用模塊很多畢設(shè)會(huì)做成一個(gè)普通的增刪改查但實(shí)際上養(yǎng)老中心的費(fèi)用結(jié)算是一個(gè)比較講究場(chǎng)景的地方。老人在住期間每天都會(huì)產(chǎn)生照護(hù)服務(wù)費(fèi)按月匯總后生成賬單。這個(gè)邏輯如果全部靠人工點(diǎn)擊生成很容易漏算。你可以在月底用定時(shí)任務(wù)自動(dòng)生成賬單草稿再由財(cái)務(wù)人員確認(rèn)后發(fā)送給家屬。設(shè)計(jì)費(fèi)用模塊時(shí)可以考慮這三張表service_item服務(wù)項(xiàng)目定義表比如床位費(fèi)、護(hù)理費(fèi)、餐飲費(fèi)、康復(fù)理療項(xiàng)目。elder_service_consume老人服務(wù)消費(fèi)記錄表。每次服務(wù)項(xiàng)目產(chǎn)生一次消費(fèi)時(shí)插入一條記錄比如入住時(shí)按月產(chǎn)生一筆床位費(fèi)每次康復(fù)訓(xùn)練后產(chǎn)生一筆項(xiàng)目費(fèi)。elder_bill月度賬單表。賬單匯總一個(gè)結(jié)算周期內(nèi)的所有消費(fèi)明細(xì)并將狀態(tài)設(shè)置為“待支付”。定時(shí)生成賬單草稿的偽代碼可以這樣設(shè)計(jì)Scheduled(cron 0 0 3 1 * ?) // 每月1日凌晨3點(diǎn)執(zhí)行 public void generateMonthlyBill() { // 1. 查詢當(dāng)前所有在住老人 // 2. 對(duì)每一位老人按周期統(tǒng)計(jì)該月產(chǎn)生的消費(fèi)明細(xì) // 3. 匯總生成一條待確認(rèn)賬單 // 4. 插入 bill 明細(xì)列表 }這里的難點(diǎn)在于周期邊界和重復(fù)性。比如一位老人 1 月 15 日入住2 月 1 日生成賬單時(shí)他這個(gè)月的消費(fèi)明細(xì)應(yīng)該是 1 月 15 日到 1 月 31 日的服務(wù)費(fèi)。如果某天定時(shí)任務(wù)失敗了重新執(zhí)行會(huì)不會(huì)產(chǎn)生重復(fù)賬單所以賬單模塊還要加“冪等性”處理對(duì)同一個(gè)老人同一個(gè)賬單周期如果已經(jīng)存在“待確認(rèn)”狀態(tài)的賬單就跳過(guò)生成直接做提示。這類(lèi)與業(yè)務(wù)強(qiáng)相關(guān)的小細(xì)節(jié)比任何花哨的技術(shù)更容易打動(dòng)答辯評(píng)委。4. 高發(fā)問(wèn)題排查與畢設(shè)級(jí)避坑清單4.1 SpringBoot 自動(dòng)裝配原理與面試前必背的點(diǎn)做 SpringBoot 項(xiàng)目的人幾乎都會(huì)被問(wèn)到自動(dòng)裝配原理尤其現(xiàn)在就業(yè)環(huán)境卷很多同學(xué)實(shí)習(xí)面試也會(huì)遇到這個(gè)問(wèn)題。即使你現(xiàn)在只是做畢設(shè)我也建議你把背后原理弄明白因?yàn)榇疝q時(shí)老師非常愛(ài)問(wèn)。SpringBoot 的自動(dòng)裝配核心在于啟動(dòng)類(lèi)上的SpringBootApplication注解它由三個(gè)注解組成SpringBootConfiguration、EnableAutoConfiguration、ComponentScan。自動(dòng)配置的關(guān)鍵在EnableAutoConfiguration它的內(nèi)部通過(guò)Import(AutoConfigurationImportSelector.class)導(dǎo)入了一批候選配置。AutoConfigurationImportSelector會(huì)讀取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.importsSpringBoot 早期版本是META-INF/spring.factories文件里面列出了所有自動(dòng)配置類(lèi)比如DataSourceAutoConfiguration、RedisAutoConfiguration。但是并不是所有候選配置都會(huì)生效SpringBoot 會(huì)使用ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty等條件注解來(lái)判斷類(lèi)路徑存在對(duì)應(yīng)依賴時(shí)才裝配對(duì)應(yīng) Bean。用數(shù)據(jù)源舉例當(dāng)你的 pom.xml 里引入了spring-boot-starter-data-jpa或 MyBatis 相關(guān)依賴并且配置了spring.datasource.urlSpringBoot 才會(huì)自動(dòng)幫你創(chuàng)建 Druid/HikariCP 數(shù)據(jù)源。這就是為什么刪掉某個(gè)依賴后運(yùn)行報(bào)找不到數(shù)據(jù)源的錯(cuò)誤因?yàn)殛P(guān)聯(lián)的自動(dòng)配置不見(jiàn)生效了。如果你在答辯時(shí)能把“SpringBoot幫我們做了什么、它是怎么知道要做什么的、如果我想自定義配置該怎么覆蓋默認(rèn)配置”這三句話講通比背 20 個(gè)注解都更有說(shuō)服力。4.2 數(shù)據(jù)庫(kù)配置與 MyBatis-Plus 的常見(jiàn)滑鐵盧我見(jiàn)過(guò)很多 SpringBoot 項(xiàng)目掛在數(shù)據(jù)庫(kù)連接上最常見(jiàn)的坑是 MySQL 時(shí)區(qū)不對(duì)導(dǎo)致連接失敗。如果你的 JDBC URL 寫(xiě)成這樣url: jdbc:mysql://localhost:3306/eldercare在 MySQL 8.x 下啟動(dòng)時(shí)大概率會(huì)報(bào)The server time zone value ...的錯(cuò)誤。解決方法是顯式加上serverTimezoneAsia/Shanghai和useUnicodetruecharacterEncodingutf8useSSLfalseurl: jdbc:mysql://localhost:3306/eldercare?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue另一個(gè)高頻問(wèn)題是 MyBatis-Plus 的駝峰映射。數(shù)據(jù)庫(kù)字段建議使用下劃線命名比如create_time、health_level實(shí)體類(lèi)用駝峰命名createTime、healthLevel。MyBatis-Plus 默認(rèn)開(kāi)啟了map-underscore-to-camel-case: true所以正常情況下沒(méi)問(wèn)題。如果你手寫(xiě)了 XML 自定義 SQL返回字段映射也可能因?yàn)槿鄙賠esultMap而無(wú)法正確映射到實(shí)體字段不要掉以輕心。還有時(shí)間字段的自動(dòng)填充。如果你在實(shí)體類(lèi)上加了TableField(fill FieldFill.INSERT)同時(shí)寫(xiě)了一個(gè) MetaObjectHandler 實(shí)現(xiàn)插入時(shí)自動(dòng)填充創(chuàng)建時(shí)間那在插入接口里就不要手動(dòng)setCreateTime否則自動(dòng)填充和手動(dòng)賦值可能互相覆蓋產(chǎn)生一些莫名其妙的毫秒差異。兩個(gè)機(jī)制用其中一個(gè)就夠了。4.3 事務(wù)失效和循環(huán)依賴這些“背鍋俠”怎么破事務(wù)失效是另一類(lèi)高頻踩坑問(wèn)題。在 SpringBoot 項(xiàng)目里最經(jīng)典的幾個(gè)場(chǎng)景包括方法final修飾導(dǎo)致動(dòng)態(tài)代理失效Transactional不生效。同類(lèi)內(nèi)部方法調(diào)用 this.method()事務(wù)注解不生效因?yàn)槭聞?wù)是通過(guò) AOP 代理完成的內(nèi)部調(diào)用不會(huì)經(jīng)過(guò)代理。異常被 try-catch 吞掉事務(wù)不會(huì)回滾。Transactional只對(duì) RuntimeException 回滾如果 catch 了 Exception 或者拋的是 checked exception默認(rèn)不回滾需要在注解里聲明rollbackFor Exception.class。其中同類(lèi)調(diào)用是最隱蔽的。很多同學(xué)把事務(wù)方法寫(xiě)在 serviceImpl 內(nèi)部然后在同一個(gè)類(lèi)里另一個(gè)非事務(wù)方法調(diào)它結(jié)果發(fā)現(xiàn)數(shù)據(jù)沒(méi)有回滾就特別困惑。解決方式是把內(nèi)部事務(wù)調(diào)用拆到另一個(gè) Service 類(lèi)里或者自己注入自己使用代理對(duì)象調(diào)用方法。循環(huán)依賴這一塊最常見(jiàn)的場(chǎng)景是 Service A 依賴 Service BService B 又依賴 Service A。SpringBoot 2.6 版本開(kāi)始默認(rèn)不允許循環(huán)依賴。建議可以從根本上避免這種設(shè)計(jì)通過(guò)把公共邏輯抽到獨(dú)立的 Service C 或者 mapper 層來(lái)完成。4.4 Redis 中的緩存與登錄狀態(tài)不一致的坑如果使用了 Redis 保存登錄態(tài)而不是 JWT 直接解析開(kāi)發(fā)過(guò)程中很容易出現(xiàn)“明明登錄了卻提示未登錄”“登錄后要重啟項(xiàng)目才生效”的問(wèn)題。排查思路一般是這樣檢查 Redis 的 key 是否加了服務(wù)前綴不同環(huán)境可能互相干擾。檢查 Redis 序列化器默認(rèn)的 JDK 序列化會(huì)把對(duì)象序列化成一長(zhǎng)串不可讀內(nèi)容如果 key 和 value 的序列化方式不一致可能導(dǎo)致查詢不到。檢查存 key 的后綴比如有些同學(xué)把 Token 存成了 Token 用戶 ID但攔截器解析時(shí)只用了 Token 字符串去找自然取不到。檢查配置項(xiàng)spring.redis.timeout是否設(shè)置過(guò)短如果只有 1000ms在高并發(fā)接口連續(xù)訪問(wèn)時(shí)可能出現(xiàn)連接池短暫超時(shí)誤以為是 Token 失效。我個(gè)人認(rèn)為針對(duì)畢設(shè)級(jí)別的系統(tǒng)登錄態(tài)直接用 JWT 就夠了Redis 可以放在驗(yàn)證碼和緩存層這樣遇到問(wèn)題排查起來(lái)也更簡(jiǎn)單。4.5 前端聯(lián)調(diào)跨域、請(qǐng)求頭與時(shí)間格式三連坑前后端分離以后前端在 8080 端口訪問(wèn)后端在 8081 端口必然要處理跨域問(wèn)題。處理方式我推薦在后端寫(xiě)一個(gè)配置類(lèi)統(tǒng)一放行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); } }但如果你同時(shí)加了 Spring Security那么光配置 CORS 還不夠因?yàn)檎?qǐng)求會(huì)先經(jīng)過(guò)安全過(guò)濾器鏈你的 Security 配置里也需要放開(kāi) OPTIONS 請(qǐng)求否則瀏覽器預(yù)檢查請(qǐng)求直接 403。做了 jwt 攔截器的同學(xué)也要注意不要攔截 OPTIONS 請(qǐng)求可以在攔截器里判斷if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; }還有一個(gè)很磨人的時(shí)間格式問(wèn)題。實(shí)體類(lèi)里的 LocalDateTime 字段返回給前端默認(rèn)是yyyy-MM-ddTHH:mm:ss這種 ISO 格式但前端一般希望展示成yyyy-MM-dd HH:mm:ss。如果不想每個(gè) JsonFormat 注解都加可以做一個(gè)全局 Jackson 配置統(tǒng)一設(shè)置時(shí)間格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8這句話對(duì) Java 的 java.util.Date 有用但對(duì) LocalDateTime 不一定生效。如果使用 LocalDateTime 還是統(tǒng)一加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)或者自行注冊(cè)一個(gè) jackson JavaTimeModule配置類(lèi)的實(shí)現(xiàn)比加注解更省事Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - { builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); builder.deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }; }不想額外解析也有個(gè)最簡(jiǎn)單的辦法在 VO 層把 LocalDateTime 字段直接轉(zhuǎn)成 String 再返回前端。雖然聽(tīng)起來(lái)不那么優(yōu)雅但卻是畢設(shè)階段非常高效的手段避免各種序列化問(wèn)題。5. 答辯與演示讓畢設(shè)不再只是“功能堆疊”5.1 在文檔里畫(huà)出核心業(yè)務(wù)流程圖和數(shù)據(jù)流圖答辯評(píng)委會(huì)看材料的最核心依據(jù)是你的畢業(yè)設(shè)計(jì)說(shuō)明書(shū)而不是代碼。我強(qiáng)烈建議你至少把三張圖畫(huà)清楚系統(tǒng)功能架構(gòu)圖、業(yè)務(wù)流程圖、數(shù)據(jù)庫(kù) ER 圖。如果你以前沒(méi)有畫(huà)流程圖的習(xí)慣可以把字面勾勒出來(lái)的業(yè)務(wù)順序轉(zhuǎn)成圖形來(lái)說(shuō)明這樣老師一眼就能看懂你實(shí)現(xiàn)的是什么。盡量畫(huà)出“老人從入院到出院”的全流程。比如前臺(tái)登記老人信息。系統(tǒng)判斷老人護(hù)理等級(jí)。分配評(píng)估通過(guò)的床位。入住后自動(dòng)生成照護(hù)任務(wù)。護(hù)理員執(zhí)行任務(wù)并記錄。周期性生成費(fèi)用賬單。老人退住審核釋放床位。這一條線串起來(lái)以后你的系統(tǒng)就不再是功能模塊的拼圖而是一套有邏輯的完整業(yè)務(wù)閉環(huán)。5.2 演示視頻怎么做才不拉胯畢設(shè)答辯通常有兩種形式現(xiàn)場(chǎng)演示和提交演示視頻。無(wú)論哪種你至少準(zhǔn)備一套“有流量”的賬號(hào)體系里面預(yù)置好可以完整演示的數(shù)據(jù)不要臨時(shí)在系統(tǒng)里新建數(shù)據(jù)那樣一旦輸入卡頓就會(huì)大幅影響觀感。演示腳本建議按下面流程走先用“管理員”登錄展示系統(tǒng)首頁(yè)的統(tǒng)計(jì)面板包括老人總數(shù)、入住率、今日工單完成率、本月收費(fèi)金額這個(gè)環(huán)節(jié)能一眼讓老師知道你做了哪些模塊。進(jìn)入“老人檔案”頁(yè)查詢一位預(yù)置老人點(diǎn)進(jìn)詳情頁(yè)查看他的健康記錄和入住歷史。切到“照護(hù)工單”頁(yè)面以護(hù)理員身份領(lǐng)取一個(gè)今日任務(wù)模擬“待執(zhí)行”到“已完成”狀態(tài)變化。填寫(xiě)一條健康記錄故意錄一個(gè)偏高血壓值展示系統(tǒng)自動(dòng)生成異常提醒。到費(fèi)用列表查看該老人的月度賬單并執(zhí)行繳納動(dòng)作。如果做了家屬端就切換賬號(hào)模擬家屬查看照護(hù)記錄。整個(gè)演示盡量控制在 8 到 10 分鐘畫(huà)面清晰、功能順暢比模塊多更重要。5.3 展示系統(tǒng)里的“人味”細(xì)節(jié)比炫技更重要在最后打磨階段我建議你花一點(diǎn)時(shí)間去優(yōu)化幾個(gè)看得見(jiàn)的細(xì)節(jié)而不是繼續(xù)堆功能系統(tǒng)登錄頁(yè)可以定制一個(gè)養(yǎng)老中心的名稱和標(biāo)語(yǔ)在 banner 生成器里做一個(gè)帶品牌感的啟動(dòng)圖形這些小細(xì)節(jié)雖小但能在演示一開(kāi)始就給人留下不錯(cuò)的印象。首頁(yè)的統(tǒng)計(jì)看板盡量采用圖表庫(kù)做幾個(gè)可視化卡片比如近七天工單量折線圖、房間入住率環(huán)形圖、老人護(hù)理等級(jí)餅圖。表格空數(shù)據(jù)狀態(tài)給一個(gè)友好提示比如“今日暫無(wú)待辦任務(wù)休息一下吧”后臺(tái)管理系統(tǒng)貴在“有人情味”。操作按鈕加二次確認(rèn)例如退住操作提示“確認(rèn)辦理退住嗎該操作會(huì)釋放床位并生成退住記錄”避免誤點(diǎn)。這些視覺(jué)和交互上的細(xì)節(jié)實(shí)際上反映了你能否從用戶視角思考問(wèn)題。答辯老師翻代碼的時(shí)間非常有限但看頁(yè)面演示的時(shí)間是最長(zhǎng)的一個(gè)頁(yè)面流暢、狀態(tài)清晰、細(xì)節(jié)到位的系統(tǒng)通常已經(jīng)離高分不遠(yuǎn)了。就我自己指導(dǎo)過(guò)的經(jīng)驗(yàn)來(lái)看做這套智慧養(yǎng)老中心管理系統(tǒng)畢設(shè)最怕的不是技術(shù)難而是把精力全部耗在 CRUD 上而不去思考業(yè)務(wù)背后的狀態(tài)流轉(zhuǎn)和權(quán)限邊界。如果你能把這條主線理清后端的每個(gè)接口怎么設(shè)計(jì)、數(shù)據(jù)庫(kù)的每張表該有哪些約束自然就通透了。最后再提醒一點(diǎn)寫(xiě)的代碼可以不夠驚艷但你要能清楚說(shuō)明白每一張表為什么存在、每一個(gè)關(guān)鍵操作為什么在一個(gè)事務(wù)里、每一個(gè)狀態(tài)為什么會(huì)這樣流轉(zhuǎn)。做到這個(gè)程度答辯基本就穩(wěn)了。