1. 項目概述與需求拆解1.1 這個項目解決的到底是什么問題先說個現(xiàn)象我接觸過的不少高校里心理咨詢中心其實挺尷尬的。線下預約排隊能排到兩三個星期以后學生有問題不敢去學院辦公室問覺得“被輔導員知道被全院知道”加上咨詢室開放時間固定白天有課的學生基本約不上。另一方面心理咨詢師的時間被大量重復性事務占用——回答“在哪里預約”“你們幾點上班”“怎么取消”這類問題真正做咨詢的時間反而被壓縮。所以這個項目的核心不是“做一個網(wǎng)站”而是把心理咨詢服務從前臺接待、紙質(zhì)登記、電話確認這套流程遷移到線上自助式服務。學生能自己看咨詢師排班、自己約時間、自己填心理評測問卷咨詢師能在線管理日程、查看預約記錄、做簡單的評估記錄管理員能看整體數(shù)據(jù)、管理用戶和內(nèi)容。這就是一個典型的“信息管理在線服務”雙合一的業(yè)務系統(tǒng)。如果你是計算機相關專業(yè)的畢業(yè)生這類選題在答辯時有一個天然優(yōu)勢業(yè)務邊界非常清晰評審老師不需要額外花時間理解項目是干什么的所有功能點都能對應到明確的業(yè)務需求。不像某些徒有其表的“智能推薦系統(tǒng)”你扛不住一句“為什么用這個方法不用那個方法”。1.2 校園場景的特殊性在哪里很多人會把校園心理平臺想成“一個普通的預約網(wǎng)站”這是最大的誤區(qū)。校園場景有幾個非常具體的要求直接決定了系統(tǒng)設計的方向。第一個是權限模型復雜。同樣的預約功能學生看到的是“我要約哪個老師”咨詢師看到的是“我的日程管理”管理員看到的是“所有老師的所有日程”。這三個角色的數(shù)據(jù)范圍、操作邊界、頁面入口完全不同權限設計一旦沒做好后面每個功能都要打補丁。第二個是隱私保護優(yōu)先級極高。學生填寫的心理評測結(jié)果、咨詢記錄屬于敏感數(shù)據(jù)界面展示和數(shù)據(jù)庫存儲都要做隔離。學生本人只能看自己的評測報告咨詢師只能看預約了自己時段的學生信息管理員原則上不直接查看評測明細——只能看統(tǒng)計匯總數(shù)據(jù)。這個規(guī)則在功能設計階段就要想清楚而不是最后快答辯了才補。第三個是互動模式不再是單一的“預約—到場”。線上心理咨詢平臺通常有兩種模式預約線下咨詢或者直接在平臺內(nèi)做文字/語音咨詢。對于一個畢業(yè)設計體量的項目建議做預約留言板在線反饋的組合不建議直接上實時音視頻。理由后面章節(jié)會說這里先記住結(jié)論。1.3 為什么說“畢業(yè)設計”這個屬性影響技術方案“計算機畢業(yè)設計”這六個字意味著這個項目的評價標準不是“功能越復雜越好”而是“邏輯完整、技術合理、工作量飽滿”。評審老師看重的有三個點業(yè)務邏輯能不能閉環(huán)、技術選型能不能說明白理由、工作量能不能體現(xiàn)出來。所以我個人強烈建議不要一上來就堆微服務、分布式、Redis緩存、消息隊列這些東西。SpringBoot單體應用配合MySQL加上合理的模塊劃分足夠支撐一個完整的校園心理平臺。用我常說的一句話畢業(yè)設計的核心是證明你理解了一個系統(tǒng)是怎么從零到一建設起來的而不是證明你背過多少框架名。2. 技術選型思路與核心框架解析2.1 為什么是SpringBoot而不是其他框架現(xiàn)在Java后端就業(yè)市場的主流要求就是SpringBoot這個不用多解釋。但從項目本身的角度看選SpringBoot有三個實實在在的好處。第一起步成本低。SpringBoot的自動配置機制把大量繁瑣的Bean注冊、XML配置變成了約定俗成的默認值一個空的Web項目幾分鐘就能跑起來。對于需要同時兼顧文檔撰寫、數(shù)據(jù)庫設計、前端頁面、功能開發(fā)的大四學生來說省下來的時間很寶貴。第二生態(tài)成熟出問題好搜。這是一個很現(xiàn)實的因素。你做項目過程中遇到的90%的報錯在搜索引擎上都能找到對應的解決方案因為用SpringBoot的人實在太多了。比如后面會提到的Lombok編譯報錯問題、SpringBoot版本過高導致的配置項變更問題都是社區(qū)里反復討論過的話題。第三加分項明確。答辯時老師問“為什么選SpringBoot”你可以回答SpringBoot基于Spring框架通過自動配置和起步依賴簡化了項目搭建內(nèi)置Tomcat可以打成Jar包獨立運行配合Spring MVC提供RESTful接口天然適合前后端分離開發(fā)。這三句話就把選型理由說得明明白白。2.2 版本選擇是第一個坑說一個我在幫別人排查項目時遇到最多的問題SpringBoot版本太高。很多同學直接從官網(wǎng)拉最新穩(wěn)定版Spring Boot 3.x結(jié)果一整合舊教程里的代碼就報錯——因為Spring Boot 3.0以上版本要求JDK 17同時javax.servlet變成了jakarta.servlet一大批第三方工具的兼容性都變了。我做這個項目時用的是SpringBoot 2.7.x系列 JDK 1.8。為什么因為這個組合是當前畢業(yè)設計生態(tài)里最穩(wěn)的市面上絕大多數(shù)教程適配的是這個版本MyBatis-Plus、Hutool、Lombok等常用工具在這個組合下無痛兼容而且JDK 1.8依然是很多學校機房和企業(yè)老項目的標配。注意如果你的項目需求或?qū)熤付烁甙姹灸钦埡雎晕业慕ㄗh。但如果是自己選聽我的2.7.x JDK 8是你做畢設最省心的組合。2.3 輕量級不是功能少而是設計克制標題里“輕量級Java框架”這個詞很多人理解成“功能簡單”這不對。輕量級的本意是“最小依賴實現(xiàn)核心功能不引入不必要的復雜度”。具體到這個項目我的理解是能不引入中間件就不引入。比如用戶登錄狀態(tài)用Spring SessionRedis是常見的生產(chǎn)級方案但畢業(yè)設計場景里單機部署的SpringBoot應用用JWT或者普通的Session機制完全夠用。再比如文件上傳把學生頭像存到本地磁盤比引一個OSS對象存儲更直觀代碼量少部署也簡單。“克制”的另一層意思是你引入的每一個技術組件都要能回答“它解決了什么痛點”。比如你引入Redis就要說清楚“存放驗證碼并設置過期時間”“緩存熱點數(shù)據(jù)降低數(shù)據(jù)庫壓力”。你引入消息隊列就要想清楚“哪個業(yè)務場景真的需要異步削峰”。如果答不上來這個組件就是扣分項而不是加分項。2.4 前后端分離還是服務端渲染這個項目我強烈建議用前后端分離原因不只是技術趨勢更重要的是開發(fā)節(jié)奏上的優(yōu)勢。Vue Element UI是當前學校的主流技術棧前端的頁面組件可以直接套用開源模板快速搭建后端的邏輯通過RESTful API對外暴露前端調(diào)接口拿JSON數(shù)據(jù)渲染頁面兩邊可以并行推進。同時也預留了一個擴展點如果未來要接入移動端或者小程序后端API不用做任何改動新寫一個前端殼子就行。這個話術在答辯“未來展望”環(huán)節(jié)非常好用。前端就選Vue 2版本Element UI組件庫配合Axios請求庫。如果你會Vue 3那也可以用Vue 3 Element Plus但要注意教程和資料最多的還是Vue 2自己權衡。我對大多數(shù)人的建議是選你最有把握的畢業(yè)設計不是新技術試驗場。3. 核心功能模塊設計與數(shù)據(jù)庫建模3.1 角色定位與功能全景圖任何項目的第一步都不是寫代碼而是把角色和功能梳理清楚。這個平臺總共有三類角色外加一個“游客”我把他們的核心訴求整理成了一張表角色核心訴求核心功能學生快速約到咨詢師、保護隱私、查看自己的記錄注冊登錄、瀏覽咨詢師、查看排班、在線預約、填寫評測問卷、查看評測報告、留言反饋咨詢師管理自己的排班、查看預約、快速記錄登錄、維護個人資料、設置可預約時段、查看預約列表、處理預約、填寫咨詢記錄管理員統(tǒng)覽全局、管理基礎數(shù)據(jù)用戶管理、咨詢師審核、文章管理、數(shù)據(jù)統(tǒng)計、系統(tǒng)設置游客了解平臺、獲取幫助瀏覽平臺介紹、查看心理科普文章、查看常見問題這里要特別留意“游客和學生的邊界”。很多畢設會把所有內(nèi)容都鎖在登錄后才可看這其實不符合業(yè)務邏輯——一個學生第一次訪問平臺應該能先看看平臺有什么、咨詢師長什么樣、科普文章能不能讀有了信任感才愿意注冊。所以前端頁面必須有一部分是免登錄開放的。3.2 預約業(yè)務的核心流程預約是這個平臺的核心業(yè)務也是最容易出現(xiàn)邏輯漏洞的地方。一個合理的預約流程至少包含以下環(huán)節(jié)學生查看咨詢師列表進入咨詢師詳情頁查看該咨詢師的可預約時間段由咨詢師提前設置選擇一個時間段提交預約申請系統(tǒng)檢查該時間段是否仍可預約防止兩個人同時搶到預約成功后狀態(tài)為“待確認”學生和咨詢師都能看到咨詢師確認或取消預約學生收到狀態(tài)變更通知咨詢完成后咨詢師填寫本次咨詢記錄注意第4步“防并發(fā)沖突”。兩個學生同時點了同一個時段理論上只允許一個人成功。技術實現(xiàn)上最簡單的方案是在數(shù)據(jù)庫層面做約束判斷當前時間段預約數(shù)是否小于容量通過UPDATE語句帶條件更新影響行數(shù)來判斷是否搶到。這個問題的解決方案在答辯時也是一個非常好的技術亮點能體現(xiàn)你是否考慮過并發(fā)場景。3.3 數(shù)據(jù)庫表設計的關鍵決策數(shù)據(jù)庫表設計不能邊寫邊想必須在開工前把核心表結(jié)構定下來。我按照這個項目實際需要整理了這樣一組核心表用戶相關user用戶表學生/咨詢師/管理員都放這里用role字段區(qū)分consultant_info咨詢師擴展信息表咨詢方向、從業(yè)年限、個人簡介、資質(zhì)證書編號student_info學生擴展信息表學號、學院、年級業(yè)務相關appointment預約表關聯(lián)用戶ID、咨詢師ID、時段、狀態(tài)、備注schedule排班表/可預約時段表咨詢師ID、日期、開始時間、結(jié)束時間、是否已約evaluation_template評測問卷模板表evaluation_question評測問題表evaluation_record評測記錄表學生ID、模板ID、分數(shù)、結(jié)果等級evaluation_answer評測答案表每題的選擇結(jié)果message_board留言表學生留言、咨詢師回復內(nèi)容相關article心理科普文章表banner首頁輪播圖表notice公告表關于user表要不要拆成用戶主表和用戶擴展表很多同學猶豫。我的建議是拆原因?qū)W生和咨詢師的信息字段差異很大比如咨詢師要存“咨詢方向”而學生要存“學號”。如果全塞在user表里要么大量字段為空要么表結(jié)構臃腫難以理解。拆分后user表只存公共字段擴展表用外鍵關聯(lián)user_id思路清晰答辯也好講。3.4 評測問卷模塊設計經(jīng)驗心理評測模塊是這個平臺區(qū)別于“普通預約網(wǎng)站”的重要亮點實現(xiàn)得好能撐起不少工作量。我建議至少設計3套評測模板比如“焦慮自評量表SAS”“抑郁自評量表SDS”“睡眠質(zhì)量評估”。這里重要的不是量表本身的專業(yè)醫(yī)學背景而是它的計分和結(jié)果映射邏輯。拿SAS舉例20道題目每道題按1-4分計分粗分乘以1.25取整數(shù)得到標準分。標準分小于50為正常50-59為輕度焦慮60-69為中度焦慮70及以上為重度焦慮。這個映射規(guī)則在代碼中用一個配置類封裝前端按照后臺返回的分數(shù)區(qū)間展示對應結(jié)果。評測結(jié)果要和預約流程聯(lián)動如果評測結(jié)果異常頁面直接推送一條建議——“系統(tǒng)檢測到您最近情緒壓力偏高建議盡快預約咨詢師進行線下溝通這里為您推薦幾位擅長情緒管理的咨詢師”。這樣就把評測模塊的價值和大預約模塊綁在了一起業(yè)務邏輯閉環(huán)了。4. 核心功能實現(xiàn)與關鍵技術細節(jié)4.1 登錄認證與權限控制的落地SpringBoot JWT做登錄認證是我推薦的一套輕量級方案。核心思路用戶登錄成功后服務器用SecretKey簽發(fā)一個Token返回給前端前端每次請求在請求頭里帶上Authorization: token后端寫一個攔截器統(tǒng)一校驗Token解析出用戶ID和角色放到ThreadLocal或請求上下文里。JWT的好處是無狀態(tài)后端不需要存Session對前后端分離部署非常友好。但要記住兩個細節(jié)Token要設置過期時間建議2小時前端的Axios攔截器在收到401響應時自動跳轉(zhuǎn)登錄頁并提示“登錄已過期”密碼不能用明文存數(shù)據(jù)庫至少要用MD5加鹽或BCrypt加密。Spring Security自帶的BCryptPasswordEncoder是最穩(wěn)妥的選擇權限控制層面我習慣用自定義注解RequireRole(CONSULTANT)加攔截器的方案攔截器先解析Token拿到用戶角色再判斷當前請求的接口是否允許該角色訪問。比Spring Security的PreAuthorize更直觀對還沒系統(tǒng)學過Spring Security的同學來說更容易講清楚原理。4.2 預約模塊的并發(fā)防重實現(xiàn)前面提到預約需要防并發(fā)沖突這里說具體實現(xiàn)。預約表里加一個version字段或者依靠帶條件的UPDATE// 偽代碼更新某個時間段為“已預約” int rows appointmentMapper.updateStatusByIdAndStatus(appointmentId, 0, 1); if (rows 0) { // 更新成功說明該時段之前是未預約狀態(tài)本次操作成功 } else { // 更新失敗說明該時段已被別人預約 throw new BusinessException(該時間段已被預約請選擇其他時間); }核心原理是UPDATE語句影響行數(shù)為0時說明條件不滿足。這里WHERE條件里帶著status0未預約兩個請求同時進來數(shù)據(jù)庫層面的行鎖保證只有一個請求能改成功。4.3 評測模塊的計分實現(xiàn)評測模塊的代碼核心不復雜但要把邏輯捋清楚。前端把學生的答案按[{questionId: 1, optionValue: 2}, ...]的格式提交到后端后端拿到答案列表后// 偽代碼計算SAS量表標準分 int roughScore evaluationService.calculateRoughScore(answers, templateId); int standardScore (int) Math.round(roughScore * 1.25); String resultLevel standardScore 50 ? 正常 : standardScore 60 ? 輕度焦慮 : standardScore 70 ? 中度焦慮 : 重度焦慮;這里有幾個坑要注意有些題目是反向計分的比如“我覺得一切都很好”需要按選項值5 - optionValue處理題目表里要加一個isReverse字段模板的版本管理評測模板以后可能會修改題目所以evaluation_record表必須記錄本次評測用的template_id否則歷史評測記錄對應不上當時用的題目結(jié)果顯示建議用分級顏色正常用綠色、輕度用黃色、中重度用紅色前端判斷resultLevel后渲染對應顏色視覺上更直觀4.4 留言板與咨詢師回復的會話模型留言板的實現(xiàn)有一個容易忽略的點——它實際上是“一對一會話”而非“公開帖”。學生的咨詢內(nèi)容屬于隱私不能像論壇一樣公開所有人可見。所以我設計的是學生可以發(fā)起一個咨詢話題標題內(nèi)容咨詢師登錄后只能看到分配給自己的未回復話題?；貜屯瓿珊髮W生端收到狀態(tài)更新可以繼續(xù)追問。這就涉及數(shù)據(jù)庫表設計feedback_topic留言主題表 - id, student_id, title, content, status, create_time feedback_reply回復表 - id, topic_id, consultant_id, content, create_time默認情況下feedback_topic不直接關聯(lián)咨詢師而是在第一次回復時才綁定。學生發(fā)起話題后管理員或系統(tǒng)自動分配給當前空閑的咨詢師咨詢師回復后該話題即與該咨詢師綁定后續(xù)追問都由同一個人回復。這個邏輯既保護隱私又避免了“多個咨詢師同時回復一個學生”的混亂。4.5 咨詢師排班功能的設計思路排班功能要做成“周模板臨時調(diào)整”的雙層結(jié)構這是我從實際運營場景里總結(jié)出來的。咨詢師每周的可用時間往往是有規(guī)律的比如“周一三五下午2點到5點有空”如果讓咨詢師每天手動添加排班操作負擔太重。所以數(shù)據(jù)庫里加一張schedule_template表記錄咨詢師一周內(nèi)的固定排班規(guī)則然后再有一張schedule_item表記錄具體某一天的可預約時段。咨詢師可以在周模板基礎上做微調(diào)比如某周周三臨時有事刪除當天時段。前端交互上咨詢師端使用一個“周視圖”日歷頁面選了日期可以一鍵“復制上周排班”也可以手動新增/刪除某一天的時段操作體驗自然。5. 項目管理與部署落地經(jīng)驗5.1 開發(fā)順序與里程碑安排給所有做畢設的同學一個時間管理建議這是我自己帶項目時反復強調(diào)的。整個項目建議按下面四個里程碑推進第一階段需求梳理與設計約1周。寫需求文檔畫用例圖、ER圖、原型圖。這個階段不寫代碼但要確定所有表結(jié)構和接口清單。表結(jié)構定好了后面開發(fā)才不會反復改數(shù)據(jù)庫。第二階段核心業(yè)務閉環(huán)約2周。先做后端從注冊登錄開始把用戶管理、咨詢師管理、預約管理、留言板這些核心接口全部跑通。前端同步做基礎的頁面框架和API對接。先跑通“學生注冊—登錄—查看咨詢師—預約—咨詢師確認”這條主鏈路其他功能后續(xù)補。第三階段功能完善約2周。做評測模塊、文章管理、數(shù)據(jù)統(tǒng)計、輪播圖、公告等周邊功能。這里要特別提醒每個功能做完立即自測不要攢到最后統(tǒng)一測試否則出問題根本定位不到是哪一段代碼改壞了。第四階段測試與打磨約1周。完整的全流程測試、邊界情況測試重復預約、密碼錯誤、Token過期、界面細節(jié)調(diào)整、Bug修復。最后留兩三天寫答辯PPT和準備問答題。5.2 SpringBoot項目打包與部署項目開發(fā)完成后要用Maven打成Jar包部署。這里我把關鍵流程和常見問題寫一起mvn clean package -DskipTests打包成功后在target目錄下生成xxx.jar文件直接扔到服務器上java -jar xxx.jar下面是幾個我踩過的坑如果打包報錯“You arent using a compiler supported by lombok”說明Lombok版本和JDK版本不匹配檢查pom.xml里Lombok的版本2.7.x的SpringBoot配套Lombok 1.18.x版本一般沒問題如果有靜態(tài)資源上傳的頭像不要直接存在項目目錄里因為Jar包重新部署會覆蓋文件。我在配置里指定了一個外部路徑file.D:/upload/用于存儲上傳文件生產(chǎn)部署時換成Linux服務器路徑JDK 1.8項目部署到Docker很多教程讓你用openjdk:8-jdk-alpine作為基礎鏡像但如果你用的SpringBoot版本較新可能需要openjdk:8-jre-alpine并注意時區(qū)配置。最簡單的Dockerfile示例FROM openjdk:8-jdk-alpine VOLUME /tmp ADD target/campus-psychology.jar app.jar ENTRYPOINT [java,-Djava.security.egdfile:/dev/./urandom,-jar,/app.jar]構建鏡像并啟動docker build -t campus-psychology . docker run -d -p 8080:8080 --name psychology campus-psychology5.3 單元測試怎么寫得能讓答辯加分SpringBoot單元測試在畢業(yè)設計里容易被忽略但如果你寫了答辯時非常加分。我的建議是不要追求覆蓋率而是重點覆蓋核心業(yè)務邏輯注冊模塊用戶名重復、密碼加密驗證預約模塊同一時段并發(fā)預約、非本人取消預約評測模塊正向計分與反向計分題目的計算邏輯舉例預約并發(fā)測試可以用一個簡單的多線程測試類SpringBootTest public class AppointmentServiceTest { Autowired private AppointmentService appointmentService; Test public void testConcurrentBooking() throws InterruptedException { int threadCount 10; CountDownLatch latch new CountDownLatch(threadCount); final int[] successCount {0}; for (int i 0; i threadCount; i) { new Thread(() - { try { appointmentService.bookAppointment(1L, 1L); synchronized (successCount) { successCount[0]; } } catch (BusinessException e) { // 預約失敗的線程信息 } finally { latch.countDown(); } }).start(); } latch.await(); // 斷言同一個時段只有一個預約成功 Assertions.assertEquals(1, successCount[0]); } }這段代碼即使不完全懂多線程的同學也能照著寫效果卻非常直觀——老師看到你考慮到了并發(fā)場景這個項目檔次就不一樣了。6. 常見問題與排查技巧實錄6.1 數(shù)據(jù)庫連接總是失敗這是排查記錄里出現(xiàn)頻率最高的問題。先檢查application.yml里的配置然后手工用數(shù)據(jù)庫客戶端工具Navicat或DataGrip試連一下。如果客戶端能連上但項目連不上重點檢查pom.xml里數(shù)據(jù)庫驅(qū)動的依賴范圍是不是誤加了scoperuntime/scope之外的限制。另一個隱蔽問題是時區(qū)serverTimezoneAsia/Shanghai不配的話MySQL 8.x版本連接時會報一個時區(qū)警告提示配置讓程序更安全。加上一句話就解決。6.2 前端聯(lián)調(diào)時跨域報錯SpringBoot后端的CORS跨域配置最簡單的方案是寫一個WebMvcConfigurer的配置類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); } }前后端分離開發(fā)時這個配置幾乎是必寫的有些同學忘了寫前端一直報跨域錯誤排查半天發(fā)現(xiàn)是少了這段代碼。6.3 數(shù)據(jù)統(tǒng)計頁面加載慢管理員端的數(shù)據(jù)統(tǒng)計頁要展示預約數(shù)量、用戶數(shù)量、評測完成數(shù)量等聚合數(shù)據(jù)。笨辦法是每個指標實時查一次數(shù)據(jù)庫用戶量大了以后頁面可能要等好幾秒。優(yōu)化的思路是用Scheduled寫一個定時任務每10分鐘統(tǒng)計一次核心指標存入statistics_cache表頁面加載時直接讀緩存表數(shù)據(jù)不需要實時到分鐘級管理員看的是趨勢這個優(yōu)化我強烈建議做代碼量不大但答辯時能講出“數(shù)據(jù)統(tǒng)計性能優(yōu)化”這個點。6.4 SpringBoot啟動報OutOfMemoryError開發(fā)階段遇到過java.lang.OutOfMemoryError: insufficient memory這種問題。多數(shù)情況是IDEA給JVM分配的內(nèi)存不夠或者項目里加載了過多的依賴導致元空間溢出。解決方式Help - Change Memory Settings調(diào)整IDEA最大堆內(nèi)存建議設為1024MB以上在Run Configuration的VM options里加上-Xms256m -Xmx512m如果重啟后還是報錯檢查是否有循環(huán)依賴。SpringBoot 2.6版本以上默認禁止循環(huán)依賴會直接啟動失敗并給出明確的提示信息按照提示重構代碼即可。7. 答辯現(xiàn)場最容易被追問的十個問題這部分是保命內(nèi)容我建議你把下面的問題逐一準備好答案不要等到答辯現(xiàn)場臨場發(fā)揮。問題1為什么選擇SpringBoot而不是Spring回答要點SpringBoot是Spring的增強通過自動配置和起步依賴減少了繁瑣的配置內(nèi)嵌Tomcat容器項目可以獨立運行提供了生產(chǎn)級特性健康檢查、外部化配置本質(zhì)還是基于Spring生態(tài)。我的項目利用SpringBoot快速搭建RESTful API配合Spring MVC處理請求路由。問題2JWT和Session有什么區(qū)別為什么選JWT回答要點Session狀態(tài)保存在服務器內(nèi)存需要依賴同一臺服務器粘性會話在集群環(huán)境下要引入Session共享方案。JWT把狀態(tài)信息編碼在Token中服務器不需要存狀態(tài)天然適合前后端分離和橫向擴展。缺點是無法主動讓Token失效到期前即使注銷登錄Token依然可用所以需要設置較短的有效期。問題3預約功能的并發(fā)問題是怎么解決的回答要點用數(shù)據(jù)庫樂觀鎖方式。UPDATE appointment SET status1 WHERE id? AND status0影響行數(shù)為0說明已被搶約。數(shù)據(jù)庫的行級鎖保證了同一時間只有一個事務能成功更新。問題4如果系統(tǒng)部署到線上你擔心哪些安全隱患回答要點可以提到SQL注入風險我用了MyBatis的預編譯機制規(guī)避、XSS跨站腳本攻擊前端對輸入內(nèi)容做了標簽過濾、密碼安全BCrypt加密存儲、用戶敏感數(shù)據(jù)隔離訪問。問題5你的項目的亮點是什么回答要點不要泛泛說“功能完整”要挑一個具體場景講透。比如“我在評測模塊中設計了反向計分規(guī)則不同模板可配置預約模塊通過條件更新解決了并發(fā)沖突問題評測結(jié)果與預約推薦關聯(lián)形成業(yè)務閉環(huán)”。問題6項目的數(shù)據(jù)量大了之后性能瓶頸可能出現(xiàn)在哪里回答要點查詢量最大的接口是咨詢師列表和預約記錄分頁。解決思路給常用查詢字段加索引用PageHelper分頁插件避免全表查詢熱門數(shù)據(jù)可以做緩存。問題7為什么評測模板要單獨建表回答要點模板和題目分離題目變化不影響歷史記錄管理員可以通過后臺維護模板不需要改代碼為以后新增評測量表做了擴展。問題8異常和統(tǒng)一返回格式是怎么處理的回答要點項目用統(tǒng)一Result對象包裝返回結(jié)果code、message、data后端用RestControllerAdvice全局異常處理器捕獲業(yè)務異常和系統(tǒng)異常轉(zhuǎn)換成統(tǒng)一的JSON結(jié)構。前端根據(jù)code值統(tǒng)一處理提示和跳轉(zhuǎn)。問題9如何保證不同角色看到的菜單和功能不一樣回答要點前端根據(jù)登錄接口返回的role字段動態(tài)生成菜單后端接口通過自定義注解攔截器校驗角色雙重保障。問題10部署遇到的最大挑戰(zhàn)是什么回答要點這個要結(jié)合自己的實際經(jīng)歷。比如你遇到了Docker容器中的時區(qū)問題、上傳文件路徑問題、數(shù)據(jù)庫編碼問題都可以講。重點不是講問題有多難而是講你是怎么一步步排查出來的這比什么都加分。我在實際陪跑畢業(yè)設計的過程中見過太多同學把精力花在堆新技術上反而忽略了業(yè)務閉環(huán)和基礎代碼質(zhì)量。這個校園網(wǎng)絡心理支持平臺如果用SpringBoot老老實實做把預約流程的并發(fā)邏輯、評測模塊的計算邏輯、角色權限的隔離設計講清楚答辯拿優(yōu)秀是完全有把握的。希望這篇拆解能幫你在開始寫代碼之前先把整個項目的骨架和關鍵雷區(qū)都摸透。