簡介這是一套面向計算機專業(yè)本科生的Java畢業(yè)設計實戰(zhàn)資源聚焦智慧養(yǎng)老場景基于Spring Boot快速構建Web應用系統(tǒng)解決老齡化社會中老人健康管理、家屬協(xié)同監(jiān)護與機構服務數(shù)字化等實際問題。資源包共954個文件涵蓋195個Java后端邏輯類、164個JavaScript交互腳本、69個HTML頁面、65個Vue組件及53個CSS樣式文件輔以SQL建庫腳本、演示視頻mp4、PPT答辯材料與完整畢業(yè)論文docx整體壓縮后50.79MB結構清晰、模塊完整便于理解MVC分層設計與前后端分離實現(xiàn)。已有300人學習下載內(nèi)容覆蓋用戶管理、個人中心、登錄鑒權等核心流程分析以及管理員與老人雙角色功能模塊的詳細設計與系統(tǒng)測試方案附帶3個bat一鍵部署腳本和Navicat兼容數(shù)據(jù)庫設計支持二次開發(fā)與定制化改造。 最近好幾個粉絲私信問Java畢業(yè)設計怎么選我想了想還是把“基于Spring Boot的智慧養(yǎng)老平臺”這個項目拿出來聊聊。這題目看著普通但后端的技術點基本全覆蓋Spring Boot框架、Web接口開發(fā)、權限控制、數(shù)據(jù)庫設計、定時任務、報表統(tǒng)計一套下來該學的框架知識都碰了一遍。而且養(yǎng)老領域方向很明確不像“網(wǎng)上商城”那樣爛大街也不像AI算法那樣難落地對Java方向的本科生來說是最穩(wěn)的選擇之一。我當初做這個課題前后花了三個月左右。很多人以為畢設就是敲代碼但其實代碼只是其中一部分后面論文、PPT、答辯一樣都不能省。這篇我就從項目拆解、技術選型、核心實現(xiàn)、論文寫作再到最后的答辯演示一條線講清楚照著做基本不用走彎路。無論你是準備做畢設還是想在面試里拿這個項目當談資這篇都會比課程的“Hello World”有用得多。1. 項目定位與需求梳理1.1 為什么選智慧養(yǎng)老這個方向做畢設第一步不是寫代碼而是搞清楚“做什么”。智慧養(yǎng)老平臺表面上是管理系統(tǒng)實質(zhì)上是一個面向養(yǎng)老場景的信息化服務平臺。目標用戶很明確老人、家屬、護理人員、平臺管理員。它跟普通管理系統(tǒng)的最大區(qū)別是業(yè)務鏈條長、角色多、場景貼近現(xiàn)實。大部分類似的畢設題目比如“圖書管理系統(tǒng)”“網(wǎng)上商城”聚焦單一業(yè)務而智慧養(yǎng)老平臺有健康檔案、服務工單、緊急求助、親情關注等不同業(yè)務線不同業(yè)務線之間還需要聯(lián)動。比如老人在App上報了心率異常系統(tǒng)要生成預警記錄同時通知家屬和護工護工處理后還要回填處理結果。這是一條完整的業(yè)務閉環(huán)寫論文的時候“系統(tǒng)分析”和“功能設計”章節(jié)內(nèi)容會很充實答辯時有東西可講。從答辯角度來說評委通常關心三點一是你為什么選這個題目社會背景加現(xiàn)實需求二是系統(tǒng)解決了什么問題三是你在系統(tǒng)里做了哪些有深度的技術點。智慧養(yǎng)老這個方向三個問題都好答這是它穩(wěn)的地方。1.2 需求梳理先把用戶角色和業(yè)務流程畫清楚需求分析階段我會建議先畫三個東西角色用例圖、核心業(yè)務流程圖、功能結構圖。不用畫得多專業(yè)但一定要畫清楚。在這個項目里我定義了四種角色老人或家屬查看健康檔案、預約服務、發(fā)起緊急求助、查看服務進度護工接收工單、上報服務結果、維護服務記錄管理員管理用戶、審核工單、統(tǒng)計報表、發(fā)布公告系統(tǒng)后臺自動任務健康數(shù)據(jù)異常預警、定時統(tǒng)計數(shù)據(jù)這里有個容易被忽視的點家屬賬號和老人賬號要分開設計。很多同學把家屬和老人共用一張用戶表導致數(shù)據(jù)權限分不清楚。我在設計時是用戶表加角色表加家庭成員綁定表老人和家屬之間通過綁定關系關聯(lián)這樣既能支持一個老人綁定多個家屬也方便后續(xù)做親屬通知功能。核心業(yè)務流程我列了三條服務預約流程家屬或老人提交預約 → 管理員審核派單 → 護工上門服務 → 護工回填結果 → 家屬確認完成健康預警流程設備或手動錄入健康數(shù)據(jù) → 系統(tǒng)判斷異常 → 生成預警記錄 → 通知家屬與護工 → 處理記錄回執(zhí)緊急求助流程老人一鍵求助 → 系統(tǒng)獲取基本信息 → 通知家屬與值班人員 → 生成工單跟進這三條流程是系統(tǒng)的骨架也是后面數(shù)據(jù)庫設計和接口設計的基本依據(jù)。你把這些流程在論文里寫清楚老師會覺得你的需求分析是真實用了心的。1.3 功能模塊劃分做減法而不是做加法接下來是功能模塊劃分。我的建議是“緊扣核心業(yè)務、別貪多”把功能劃分為前臺和后臺兩大塊前臺老人與家屬協(xié)同端登錄注冊、家庭成員綁定健康檔案查看、健康數(shù)據(jù)錄入與查看服務預約與進度追蹤緊急求助入口通知消息列表后臺管理員與護工管理端用戶管理老人、家屬、護工的基礎信息維護健康檔案管理查看老人的歷史數(shù)據(jù)與異常記錄服務工單管理審核、派單、狀態(tài)跟蹤緊急求助管理查看、處理、歸檔公告資訊管理數(shù)據(jù)統(tǒng)計看板用柱狀圖、折線圖展示老人數(shù)量、服務量、異常趨勢等這個功能列表不一定是最全的但每一個模塊都能跟前面的業(yè)務流程閉環(huán)。不要一上來就把“語音識別”“人臉識別”這種大而空的功能寫進去除非你有確切的實現(xiàn)方案否則到后期會把自己坑死。我給所有人的建議就一條畢業(yè)設計的功能寧可少而完整也不要多而半成品。2. 技術選型與架構設計2.1 為什么用Spring Boot版本怎么選這個題目最大的標簽就是Spring Boot。理解Spring Boot的核心價值其實就是降低SSM時代繁瑣配置的成本。傳統(tǒng)的SSM框架要寫大量的XML配置Spring Boot通過自動配置和starter機制把這一層幾乎全包了讓我們把精力集中在業(yè)務代碼上。版本選擇上我強烈建議Java加Spring Boot的經(jīng)典組合JDK 8加Spring Boot 2.7.x。很多同學看到網(wǎng)上有Spring Boot 3.x就想用最新的。這里提醒一下Spring Boot 3.x要求JDK 17以上而且很多依賴包、教程都是基于2.x寫的加上原本的javax命名空間變更為jakarta接手成本對新手并不友好。畢業(yè)設計追求的是穩(wěn)定、不折騰直接用2.7.x省下的時間夠你多寫兩章論文。關于Spring Boot版本配置可以參考這些常用依賴spring-boot-starter-webWeb核心spring-boot-starter-security或簡單攔截器方案做登錄鑒權spring-boot-starter-validation參數(shù)校驗mybatis-plus-boot-starter數(shù)據(jù)持久層mysql-connector-java數(shù)據(jù)庫驅動lombok減少實體類代碼hutool工具類庫生成驗證碼、時間格式化非常方便2.2 分層架構與包結構代碼要能經(jīng)得起答辯分層結構如果你做得清晰論文里的系統(tǒng)設計章節(jié)甚至可以直接復用。我用的是經(jīng)典三層架構Controller層負責接收請求、參數(shù)校驗、返回統(tǒng)一結果Service層業(yè)務邏輯處理事務邊界Mapper層數(shù)據(jù)訪問在這個基礎上再加兩個輔助包config配置類、common統(tǒng)一返回結果與異常處理。實際項目中我建議的包結構是這樣的src/main/java/com/example/smartcare/ ├── controller/ # 接口層 ├── service/ # 業(yè)務層 ├── mapper/ # 數(shù)據(jù)持久層 ├── entity/ # 實體類 ├── dto/ # 請求和響應對象 ├── vo/ # 視圖對象比如統(tǒng)計結果 ├── config/ # 配置類跨域、攔截器、MyBatis-Plus分頁 ├── common/ # 統(tǒng)一返回、異常處理、工具類 ├── task/ # 定時任務 └── SmartCareApplication.java這里說一個很多新手會犯的錯誤直接用實體類接收前端請求參數(shù)。雖然能跑但答辯時如果老師問“DTO和實體為什么要分開”會答不上來。實體類對應數(shù)據(jù)庫表結構DTO對應前端請求參數(shù)這樣拆開的好處是避免把數(shù)據(jù)庫字段暴露給前端、更容易做參數(shù)校驗、需求變更時影響面更小。這也是面試時經(jīng)常被問到的點。2.3 前端方案選你最有把握的智慧養(yǎng)老平臺的前端我見過幾種做法前后端分離Vue加Element UI后端只出接口。這個方案是目前的主流適合對前端有一定基礎的同學但要注意跨域問題。服務端渲染Thymeleaf加Bootstrap或Layui后臺模板。優(yōu)點是部署簡單、不存在跨域缺點是頁面交互體驗一般。半分離后端用Thymeleaf模板渲染頁面局部交互用jQuery或Ajax。我當時用的是Vue加Element UI加Axios前端打包后放到Spring Boot的static目錄下這樣仍然是一個可執(zhí)行jar包避免同時部署兩個服務。現(xiàn)在回想這是一個很實用的決定一個jar包搞定整個項目、不用配置Nginx、演示的時候不容易翻車。如果前端經(jīng)驗不夠我建議用Bootstrap或Layui這類傳統(tǒng)模板畢業(yè)后如果做管理系統(tǒng)會經(jīng)常遇到這些方案如果想沖前端崗位的面試Vue的優(yōu)先級更高。但無論選哪種核心是你已經(jīng)實際用過它做了完整的功能而不是用別人寫好的模板來應付。3. 數(shù)據(jù)庫設計與關鍵表結構3.1 不搞“一張大表”按業(yè)務邊界拆表數(shù)據(jù)庫設計是整個項目里最值得花時間的地方。很多同學的數(shù)據(jù)庫喜歡把字段一股腦塞進一張表里比如把老人信息和家屬信息寫在同一張表看著簡單實際上后續(xù)做權限控制、統(tǒng)計分析時基本沒法寫SQL。我的表結構劃分思路是用戶表sys_user賬號、密碼、真實姓名、電話、角色、頭像、狀態(tài)角色表sys_role角色編碼、角色名用戶角色綁定表sys_user_role用戶ID、角色ID家庭成員綁定表family_bind老人ID、家屬ID、關系、綁定時間健康檔案表health_record老人ID、血壓、血糖、心率、體溫、記錄時間服務類型表service_type服務名稱、描述、價格服務工單表service_order老人ID、服務類型ID、護工ID、狀態(tài)、預約時間、完成時間緊急求助表emergency_alert老人ID、求助時間、狀態(tài)、處理人、處理說明公告表notice標題、內(nèi)容、發(fā)布時間、發(fā)布人系統(tǒng)通知表sys_message接收人ID、內(nèi)容、類型、是否已讀以健康檔案表為例字段設計大概這樣CREATE TABLE health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL COMMENT 老人用戶ID, blood_pressure VARCHAR(20) COMMENT 血壓收縮壓/舒張壓, blood_sugar DECIMAL(5,2) COMMENT 血糖值, heart_rate INT COMMENT 心率, temperature DECIMAL(4,1) COMMENT 體溫, record_date DATE NOT NULL COMMENT 記錄日期, remark VARCHAR(255) COMMENT 備注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );這里要注意查詢老人最近一條健康記錄需要按record_date和create_time排序后取第一條所以索引要覆蓋到(elder_id, record_date, create_time)。第一次我漏了這個索引數(shù)據(jù)量上去之后查詢變慢加上索引就解決問題了。這也是論文系統(tǒng)測試章節(jié)里可以寫的一個優(yōu)化點。3.2 工單狀態(tài)機設計服務工單是智慧養(yǎng)老平臺里最復雜的業(yè)務實體它不能只存一個“狀態(tài)”字段就沒下文了。我在工單表里設計了這幾個核心字段order_no工單編號用時間戳加隨機數(shù)生成方便追溯elder_id老人IDservice_type_id服務類型caregiver_id護工ID派單后賦值status狀態(tài)0待審核、1待服務、2服務中、3待確認、4已完成、5已取消appoint_time預約時間create_time創(chuàng)建時間finish_time完成時間evaluate家屬評價為什么要把狀態(tài)設計成6個而不是3個因為每一步都有明確的操作人和操作時機論文和答辯時可以畫“工單狀態(tài)機圖”這是很多同學沒想到的加分點。比如工單流轉順序是提交預約 → 管理員審核 → 系統(tǒng)派單 → 護工服務 → 家屬確認 → 完成。每一狀態(tài)變更都記錄日志后續(xù)出問題能追蹤這在實際項目中是非常核心的設計思路。另外還要提一下緊急求助表和服務工單表的關系緊急求助可能生成工單也可能只生成告警記錄。我通過一個source_type字段區(qū)分工單來源1普通預約、2緊急求助生成這樣既能追蹤普通服務也能把緊急處理的記錄串起來。3.3 統(tǒng)一返回對象與全局異常處理寫后端接口時如果每個接口都手動返回JSON格式的Map后期維護會極其痛苦。我在項目里定義了一個統(tǒng)一返回體Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }然后用RestControllerAdvice做全局異常處理把業(yè)務異常和系統(tǒng)異常分開。這樣Controller代碼會非常干凈前端也不用每一個請求都做額外的判斷邏輯。記得在全局異常處理器里處理參數(shù)校驗異常MethodArgumentNotValidException和兜底異常Exception否則前端頁面會直接看到一大段英文堆棧信息演示的時候很尷尬。4. 核心功能實現(xiàn)與實操要點4.1 登錄鑒權JWT方案與權限控制智慧養(yǎng)老平臺涉及老人、家屬、護工、管理員多類角色登錄鑒權不能不做。我沒有選擇傳統(tǒng)的Session方案而是用了JWT方案理由有兩點一是無狀態(tài)前后端分離場景下更友好二是畢設論文中“系統(tǒng)安全設計”章節(jié)有內(nèi)容可寫。JWT的核心邏輯是用戶登錄成功后后端驗證用戶名密碼生成一個token返回給前端前端將token存在localStorage里之后每個請求都在Authorization頭帶上token后端通過攔截器或Spring Security解析token判斷用戶身份和角色。如果你不想引入Spring Security它的過濾器鏈學習成本相對高可以直接用攔截器加JWT實現(xiàn)Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); } Claims claims JwtUtil.parseToken(token); if (claims null) { response.setStatus(401); response.getWriter().write(未登錄或token已過期); return false; } request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } }然后注冊攔截器時注意排除登錄接口、靜態(tài)資源以及一些公開接口。如果你對過濾器和攔截器的區(qū)別不清楚建議把兩者區(qū)別弄明白這是Java面試被問頻率極高的問題。這里分享一個我踩過的坑JWT的密鑰和過期時間不要寫死在代碼里放到application.yml配置文件中方便修改。過期時間我當時設的是24小時實際使用時如果用戶一直在操作到期后會突然被踢出因此可以在此基礎上做一個簡單的續(xù)期策略比如token存在7天但如果用戶3天沒活躍就失效。不需要做得太復雜答辯能說清楚即可。4.2 健康數(shù)據(jù)上報與預警通知健康模塊是這個項目的靈魂也是區(qū)別于普通管理系統(tǒng)最大的亮點。實現(xiàn)思路如下前端或模擬設備端通過接口上報老人的血壓、血糖、心率、體溫等數(shù)據(jù)后端校驗后寫入health_record表。然后在Service層做一次規(guī)則判斷收縮壓大于140或舒張壓大于90判為血壓偏高血糖大于7.0判為血糖偏高心率大于100或小于60判為心率異常體溫大于37.5判為發(fā)熱如果判斷結果異常就往emergency_alert表和sys_message表各插入一條記錄并發(fā)送一份通知。我在這個環(huán)節(jié)用了Spring Boot的Async注解把通知發(fā)送做成異步避免阻塞主流程。Async public void sendHealthAlert(Long elderId, String content) { ListLong familyIds familyBindMapper.selectFamilyIdsByElderId(elderId); // 批量插入系統(tǒng)通知 // 如果有短信或微信推送接口可在這里接入 }這是能顯著提升項目完成度的設計。論文里可以寫“基于事件驅動的通知模塊”面試時可以把異步、線程池、消息隊列的演進關系講一遍。別忘了在啟動類上加上EnableAsync注解否則Async不會生效。這個坑我見過好幾個同學踩。4.3 服務工單閉環(huán)與并發(fā)安全工單模塊的核心邏輯在處理狀態(tài)變更時一定要加上事務。比如護工點擊“開始服務”會涉及更新工單狀態(tài)、修改服務記錄等多個操作如果只更新一個表還好說多個表必須用Transactional包住。派單邏輯如果涉及“將任務分配給在線護工”你需要確定護工是否有正在進行的工單、是否超出最大接單數(shù)。我當時的處理是查詢該護工今日狀態(tài)為“待服務”和“服務中”的工單數(shù)量小于5單才能派單。這個規(guī)則不復雜但對數(shù)據(jù)的一致性和并發(fā)有要求如果兩個請求同時給同一個護工派單會有問題。可以在SQL里加條件更新UPDATE service_order SET caregiver_id #{caregiverId}, status 2 WHERE id #{orderId} AND status 1用條件更新的方式來判斷狀態(tài)是否還是“待服務”避免并發(fā)情況下重復派單。在論文的系統(tǒng)設計章節(jié)可以把這個細節(jié)寫進去這是一個非常好的加分點說明你考慮了并發(fā)場景。4.4 數(shù)據(jù)統(tǒng)計看板SQL聚合與ECharts展示后臺管理端的統(tǒng)計看板其實是讓整個系統(tǒng)看起來“高一個檔次”的功能。我在首頁放了三個統(tǒng)計維度用戶總數(shù)與角色分布、工單狀態(tài)對比、近7天健康異常趨勢。實現(xiàn)時用SQL分組統(tǒng)計和日期函數(shù)SELECT DATE(create_time) AS day, COUNT(*) AS cnt FROM emergency_alert WHERE create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(create_time) ORDER BY day;前端用ECharts折線圖展示。這里提醒一下ECharts的data數(shù)據(jù)格式要和后端返回的JSON字段一一對應。我第一次聯(lián)調(diào)時后端返回的是day和cnt前端卻取了date和count導致圖表空白排查了很久。所以前后端聯(lián)調(diào)時最好先定好接口文檔把每個字段名對齊能省非常多時間。5. 論文、PPT與答辯準備5.1 畢業(yè)論文結構怎么組織很多人代碼做完了論文卻拖到最后兩周才動筆結果非常痛苦。我的建議是論文和開發(fā)同步推進代碼完成一部分論文就寫一部分。畢業(yè)設計的論文一般按照軟件工程的標準流程來寫摘要一段話講清楚背景、系統(tǒng)功能、技術棧、實現(xiàn)結果緒論項目背景、國內(nèi)外現(xiàn)狀、研究意義、論文結構需求分析用戶角色分析、功能需求、非功能需求、用例圖、業(yè)務流程圖系統(tǒng)設計總體架構、技術架構、功能模塊設計、數(shù)據(jù)庫設計E-R圖和主要表結構系統(tǒng)實現(xiàn)核心功能模塊的代碼實現(xiàn)說明帶核心代碼片段和運行截圖系統(tǒng)測試功能測試用例表、測試結果分析總結與展望做了什么、不足與改進方向這里特別提醒論文里的截圖一定要自己實際運行后截圖不要盜用網(wǎng)上的圖查重和答辯都能查出來。另外系統(tǒng)測試不要只寫“測試通過”要有具體的測試用例表格編號、功能描述、操作步驟、預期結果、實際結果、是否通過。評委很看重這個細節(jié)。5.2 PPT設計原則與答辯話術PPT不需要花哨但邏輯要清楚。我的PPT結構大致按照論文目錄來但每頁只放核心內(nèi)容不要貼大段代碼。三個原則頁面文字少、多用架構圖和截圖、每頁只有一個核心觀點。答辯時是10到15分鐘我的經(jīng)驗是準備兩套講法如果評委不懂技術細節(jié)重點講項目背景、解決了什么問題、系統(tǒng)演示效果如果評委懂技術重點講技術方案、難點和解決方案、對并發(fā)和數(shù)據(jù)庫設計做了哪些優(yōu)化建議提前準備這些問題為什么選Spring Boot它的核心特性是什么數(shù)據(jù)庫有哪些表為什么這么設計角色權限是怎么實現(xiàn)的健康異常預警是怎么觸發(fā)的你的系統(tǒng)在并發(fā)場景下做了哪些優(yōu)化如果讓這個系統(tǒng)上線你還有什么改進計劃以上問題想清楚答辯基本穩(wěn)了。我當時在答辯現(xiàn)場被問到最多的問題就是“你說的智能體現(xiàn)在哪里”所以你要準備好把“規(guī)則預警、自動通知、工單閉環(huán)、數(shù)據(jù)看板”這些點串成一個完整的故事講出來。6. 常見問題與調(diào)試實錄6.1 環(huán)境與啟動類問題Spring Boot啟動失敗報“Port 8080 was already in use”是最常見的問題。Windows下用netstat -ano | findstr 8080找到PID然后在任務管理器結束進程。或者直接在application.yml里換一個端口比如8081。如果是長時間用電腦開發(fā)建議直接改一個不常用的端口省心。數(shù)據(jù)庫連接報“Access denied for user”檢查MySQL賬號密碼、數(shù)據(jù)庫是否存在、url中數(shù)據(jù)庫名拼寫是否正確。這里有個容易被忽略的點MySQL 8.0的驅動類名是com.mysql.cj.jdbc.Driverurl中還要加上serverTimezoneAsia/Shanghai否則時區(qū)報錯。Maven依賴下載慢或依賴沖突建議配置阿里云鏡像倉庫不要直接用默認中央倉庫。依賴沖突時用mvn dependency:tree排查比如Druid和MyBatis-Plus之間的日志依賴沖突可以直接排除沖突的傳遞依賴。6.2 代碼層面的典型坑MyBatis-Plus分頁查詢不生效。很多人寫了Page對象但查出來依舊全量數(shù)據(jù)原因是沒有配置分頁插件。需要在config里加上Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }Lombok編譯找不到方法。新裝的IDEA默認沒有開啟Annotation Processing或者沒裝Lombok插件。在Settings里搜Annotation Processors勾選Enable annotation processing然后重啟IDEA。如果還不行檢查pom里Lombok的依賴是否在有效scope內(nèi)。前端請求跨域瀏覽器報CORS錯誤。前后端分離時我直接在后端寫了一個全局跨域配置類Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }allowedOriginPatterns()和allowCredentials(true)同時使用時注意不要用allowedOrigins()否則會有安全限制。6.3 演示與部署注意事項無論你用的是自己電腦演示還是服務器部署最后一定要準備一個“干凈演示環(huán)境”關閉代碼編輯器里無關的窗口避免答辯時誤觸數(shù)據(jù)庫先用腳本導入一份完整的測試數(shù)據(jù)不要演示時現(xiàn)場造數(shù)據(jù)整理一條演示的完整路徑登錄 → 查看統(tǒng)計看板 → 查看老人健康檔案 → 模擬一次健康數(shù)據(jù)上報 → 展示預警通知 → 展示工單流轉 → 現(xiàn)場答疑檢查打包命令確保能正常執(zhí)行mvn clean package -DskipTests如果你用的是前后端分離結構演示前提前把前端打包到Spring Boot的static目錄確保一個jar包跑起來就能看到完整頁面。演示前一定要在答辯教室的電腦上實際跑一遍再上臺哪怕只是用虛擬機跑也要確保網(wǎng)絡環(huán)境、MySQL版本、JDK版本一致。我見過太多同學答辯當天打不開項目原因只有一個環(huán)境沒提前驗證。7. 從畢設到面試項目延伸價值7.1 面試官最常追問的方向整理很多同學做完畢設就扔了其實很可惜。畢設項目是Java后端求職面試時最有說服力的項目經(jīng)歷前提是你得能講清楚。圍繞智慧養(yǎng)老平臺面試官常問的問題大概會從下面幾個方向展開Spring Boot層面自動配置原理是什么為什么引入一個starter就能用如何自定義一個starterWeb安全層面JWT和session有什么區(qū)別token過期怎么處理SQL注入怎么防止MyBatis的#{}和${}區(qū)別是什么數(shù)據(jù)庫層面索引為什么能提升查詢性能建索引的原則是什么如何分析慢SQL并發(fā)層面你項目里哪里用到了異步和線程池如果不加鎖并發(fā)派單會有什么問題工程化層面Maven生命周期、打包流程、日志怎么配置、Lombok原理是什么建議你把每個問題寫成一頁筆記用自己的項目例子回答。比如面試官問“你們項目里怎么處理健康預警的”你可以這樣回答“老人健康數(shù)據(jù)錄入后服務層做規(guī)則判斷一旦指標異常就寫入預警表同時觸發(fā)異步通知給綁定的家屬和護工推送消息。對于并發(fā)問題比如同時多個設備上報時我用樂觀鎖和唯一索引去重避免重復預警記錄?！边@一段回答既講了業(yè)務又帶了并發(fā)處理還體現(xiàn)數(shù)據(jù)庫設計意識比干巴巴說“我用了Spring Boot”強太多。7.2 項目的擴展方向你也可以把這個項目繼續(xù)往深了擴展比如接一個心率模擬器來模擬設備實時上報或者用WebSocket推送給家屬端實時預警又或者加入簡單的數(shù)據(jù)分析模型做健康趨勢預測這些擴展方向都可以寫進論文的展望部分也可以作為面試時“為什么想做、怎么做”的加分素材。我現(xiàn)在回顧自己做這個畢設的過程最深的感受是一個畢業(yè)設計做得好的標準不是代碼量多大、功能多炫而是你能不能在做完后把每一個決策都講出理由。技術選型為什么這么選、表為什么這么建、接口為什么這么設計、異常為什么這么處理這些“理由”才是畢業(yè)設計真正的收獲。最后再給一個非常實用的建議不管你是從零開始做還是用已有的源代碼做二次開發(fā)都建議自己把核心模塊的代碼重新敲一遍尤其是登錄鑒權、健康數(shù)據(jù)預警、工單流轉這三個模塊。一來是為了真正理解原理二來是答辯前的時間安排才不會被突發(fā)情況打亂。這個項目看著不大但能把它做完并講透你的Java后端基本功和工程項目思維就已經(jīng)超過絕大多數(shù)應屆生了。本文還有配套的精品資源點擊獲取