每年到了畢業(yè)季做畢設管理系統的需求就特別多。有的是老師要處理幾十個學生的選題、開題、中期檢查、答辯評分用Excel來回傳文件簡直能讓人崩潰有的則是學生要做畢設想找一個結構完整、能出成果的技術項目作為參考。我去年幫某高校信息學院的老師搭過一套完整的畢業(yè)設計管理系統從選題申報到成績歸檔全流程覆蓋技術棧就是標題里的這套組合——SpringBoot Vue MyBatis MySQL。當時踩了不少坑也沉淀了不少實戰(zhàn)經驗這篇就把完整的設計思路、核心實現和排坑過程捋一遍給正打算做類似系統的朋友參考。這套東西非常適合用來做畢業(yè)設計題目同時也具備企業(yè)級項目的基本雛形一共梳理了六大塊整體架構設計、數據庫建模、后端核心實現、前端對接落地、常見問題排查以及生產部署和二次開發(fā)的方向。1. 系統整體設計與技術選型思路1.1 業(yè)務模塊拆解從選題到答辯的全流程覆蓋先理清楚一個畢業(yè)設計管理系統到底要管哪些事。我按照實際業(yè)務流拆成了五個核心模塊基礎信息管理、選題管理、過程文檔管理、答辯與評分管理、系統管理?；A信息模塊管學生、教師、專業(yè)、班級這些主數據選題管理是核心中的核心涵蓋教師申報課題、學生選題、雙選確認、選題調整過程文檔管理負責開題報告、中期檢查表、結題報告的上傳和審批答辯與評分則涉及答辯分組、評委打分、成績匯總和等級評定系統管理包含用戶權限、角色分配、字典維護和操作日志。技術方案上我選擇了完全前后端分離的架構。后端用SpringBoot作為應用框架負責業(yè)務邏輯、鑒權、數據持久化前端用Vue全家桶構建單頁應用配合Element UI組件庫快速搭建管理界面持久層用MyBatis手寫SQL配合動態(tài)SQL處理復雜的分頁和聯表查詢數據庫用MySQL 5.7存儲全部業(yè)務數據。選這套組合的核心理由有三個。第一SpringBoot的應用生態(tài)足夠成熟資料多、案例多遇到問題容易找到解決方案第二Vue的組件化開發(fā)模式非常適合管理后臺這類頁面密集型的項目而且Element UI幾乎為后臺管理系統量身定制第三MyBatis在復雜報表查詢和存儲過程支持方面比JPA靈活得多這在成績統計和權限查詢這種需要大量定制SQL的場景下特別占優(yōu)勢。如果換成Spring Data JPA遇到多表聯查和復雜動態(tài)條件會非常痛苦。這套技術組合能覆蓋“學分制管理系統”這類相似業(yè)務的全部場景換皮即可遷移到在線考試、教學管理等領域。1.2 權限模型設計基于RBAC的三角色體系權限設計我直接用了經典的RBACRole-Based Access Control基于角色的訪問控制模型。系統里定義了三類基礎角色管理員、教師、學生。管理員擁有全部權限可以配置系統參數、管理所有用戶、監(jiān)控流程節(jié)點教師可以申報課題、審核學生選題、評定過程文檔、錄入成績學生可以瀏覽課題、提交選題申請、上傳文檔、查看成績和評語。表面上看只有三個角色但在實際表結構上我還是把權限粒度細化到了操作級別。用五張表來實現用戶表、角色表、用戶-角色關聯表、菜單權限表、角色-菜單關聯表。前端通過路由守衛(wèi)控制頁面訪問后端通過攔截器校驗每個接口的權限碼雙端校驗避免只在前端隱藏頁面就以為安全的誤區(qū)。很多畢設項目只在前端用v-if控制按鈕顯隱后端接口完全不設防這種設計在答辯的時候很容易被問倒一定要前后端都做權限控制。這里補一句經驗RBAC權限表初始化時一定要寫數據庫腳本而不是在代碼里手動添加。把五張表的建表語句和基礎數據都整理成init.sql統一執(zhí)行重復搭建環(huán)境的時候直接批量導入效率高很多。角色和菜單的關聯數據也要在腳本里固化否則每開一個新環(huán)境都要手點一遍授權故障率極高。2. 數據庫設計與MyBatis持久層實踐2.1 核心數據表結構字段設計的取舍數據庫是整個系統的承重墻表結構設計得好不好直接決定了后期開發(fā)順不順。我總共設計了18張表這里挑最關鍵的幾張來說。用戶表(user)我用了邏輯刪除加唯一索引的經典組合學號或工號作為用戶名密碼存BCrypt加密后的密文字段包括user_id、username、password、real_name、user_type、department_id、phone、email、status。課題表(topic)是核心業(yè)務表字段設計上格外注意狀態(tài)機的表達。用topic_status字段存數字狀態(tài)碼0表示草稿、1表示待審核、2表示選題開放中、3表示已滿員、4表示已關閉。用整數表達狀態(tài)便于后期審核流程的SQL檢索和統計不要用字符串拼接否則做報表統計時很難聚合。課題類型、來源、年份也要單獨冗余字段存字典值不會頻繁變化但查詢頻繁的數據可以做冗余免得每次都要關聯字典表。選題關系表(topic_application)記錄了學生和課題之間的申請、確認、駁回、撤銷操作。這張表同時冗余了學生姓名、學號、教師姓名、課題標題等冗余字段這個設計是刻意的。因為在列表頁展示申請記錄時前端要做聯表查詢和學生表、課題表關聯三次才能拿到所有展示字段很損耗性能。用空間換時間直接冗余進來查詢效率大幅提升。實際上MyBatis聯合查詢的性能在數據量過萬之后會有明顯下降冗余讓主查詢維持在單表級別是這個系統能保持流暢的關鍵。過程文檔表(thesis_document)統一存儲開題報告、中期檢查、結題報告的元數據。文檔本體存在本地磁盤或對象存儲表里只存文件名、文件路徑、文件大小、提交時間、審核狀態(tài)和審核評語。上傳附件一律先用UUID重命名避免中文名和非法字符帶來的存儲和URL訪問問題。狀態(tài)字段區(qū)分待審核、已通過、已駁回三種。每個階段學生只能上傳一個文檔后上傳的覆蓋前一個用版本號字段記錄操作次數實現了簡單的版本追蹤。答辯分組表(defense_group)存儲答辯時間、地點、評委ID列表答辯成績表(defense_score)則存每個評委給出的分數和評語。這里多說一句成績表的每條記錄必須同時存學生ID、課題ID、評委ID方便后期做多維度統計。我之前見過有人在成績表里只存學生ID和分數結果想做“某位評委的給分分布”分析時做不出來只能重新加字段補數據非常被動。2.2 MyBatis動態(tài)SQL與分頁查詢的實踐MyBatis在這套系統里扮演的角色主要是三類場景基礎的單表CRUD、動態(tài)多條件分頁查詢、復雜報表統計?；ACRUD用MyBatis Generator生成減少大量重復的實體類和Mapper XML代碼。核心的復雜查詢我手寫SQL比如課題列表頁支持按課題名稱、課題類型、指導教師、狀態(tài)、年份進行組合篩選這就必須用動態(tài)SQL。分頁方案我選擇了PageHelper插件理由很簡單穩(wěn)定、接入成本低、和MyBatis整合成熟。只需要在依賴里加上pagehelper-spring-boot-starter然后在Controller層調用PageHelper.startPage(pageNum, pageSize)緊接著的查詢就會自動帶上LIMIT分頁。返回結果用PageInfo包裝一下前端就能拿到總記錄數、總頁數、當前頁數據。這里有個細節(jié)值得分享PageHelper的ThreadLocal機制要求startPage和查詢必須在同一個方法內連續(xù)執(zhí)行中間不能有任何其他的數據庫操作否則分頁條件會被別的不相關的查詢消費掉導致莫名奇妙的SQL異常。我最初開發(fā)時在startPage后面寫了一個日志入庫操作結果日志語句反倒被分頁了排查了大半天才發(fā)現是線程上下文的坑。針對報表統計這類SQL我直接用Select注解寫在Mapper接口上不走XML文件。比如統計各專業(yè)選題數量分布、統計各教師指導學生的數量、統計成績分段人數這類查詢相對固定寫在注解里直觀簡潔。XML文件主要放那些業(yè)務復雜、需要復用SQL片段的長SQL比如篩選列表和聯表查詢。這種分配方式讓Mapper代碼看起來干凈整齊也方便維護。還有一個關鍵點是防止SQL注入。MyBatis中#{}是預處理占位符會生成PreparedStatement參數綁定絕對安全${}是字符串拼接雖然靈活但很容易注入。我的原則是所有用戶輸入的條件都必須用#{}${}只用在極少數需要動態(tài)傳表名或排序字段的地方并且配合白名單校驗只有指定的值才允許通過。2.3 事務管理與MySQL隔離級別的選擇畢業(yè)設計系統的業(yè)務中選題申請、成績錄入這類操作涉及多條表更新的原子性問題。比如學生申請選題時既要往topic_application表插入一條申請記錄又要更新topic表的當前選課人數。兩步操作必須保證同時成功或同時失敗否則就會出現申請記錄存在但課題人數沒加的臟數據。SpringBoot中使用Transactional注解管理事務非常方便直接在Service方法上標注即可。默認情況下RuntimeException和Error觸發(fā)回滾受檢異常不會回滾。所以我在業(yè)務代碼里統一使用自定義業(yè)務異常繼承RuntimeException并且配合全局異常處理器統一返回JSON。事務的傳播機制用默認的REQUIRED就足夠了正常情況下不存在嵌套事務的復雜場景。MySQL默認的RRRepeatable Read可重復讀隔離級別在這套系統中是夠用的。雖然互聯網大廠高并發(fā)場景普遍推薦RCRead Committed讀已提交以獲得更好的并發(fā)性能但畢設系統的并發(fā)量級在幾百人以內RR的間隙鎖問題不會成為瓶頸。用RR反而有個額外好處事務內多次讀取結果一致邏輯不容易出錯。我在開發(fā)階段沒有改動隔離級別保持默認。3. SpringBoot后端核心實現與業(yè)務閉環(huán)3.1 基于JWT的身份認證與接口鑒權前后端分離架構下Session不再是首選方案我選擇用JWTJSON Web Token做無狀態(tài)認證。用戶登錄成功后后端用密鑰生成一個包含用戶ID、用戶名、角色的令牌返回給前端前端存儲到localStorage并在每次請求時加到Authorization頭。后端通過攔截器解析令牌識別當前用戶身份。第一步是引入jjwt依賴配置一個工具類負責令牌的生成和解析。生成時設置過期時間為24小時開發(fā)環(huán)境可以調長一些。解析失敗或過期時拋出異常由全局異常處理器轉成401響應。密碼存儲用BCrypt加密同一密碼每次加密結果不同防彩虹表攻擊。第二步是自定義攔截器實現接口鑒權。我這里沒有引入Spring Security因為它對很多人來說配置復雜、概念抽象反而增加了畢設項目的理解成本。我用HandlerInterceptor實現一個簡單的AuthInterceptor在preHandle方法中校驗JWT是否有效同時判斷當前用戶是否擁有該接口要求的權限碼。權限碼通過自定義注解RequirePermission標注在Controller方法上攔截器讀取注解進行比對。這種輕量級的鑒權方案麻雀雖小五臟俱全理解起來非常清晰答辯時也能講明白整個認證鏈路。用Spring Security當然更專業(yè)但如果對它的過濾器鏈理解不透徹很容易配出漏洞到時候講不清原理反倒扣分。對畢設系統和中小型企業(yè)后臺來說自研JWT攔截器在開發(fā)效率和可解釋性上是更優(yōu)的選擇。3.2 核心業(yè)務閉環(huán)選題雙選機制的實現選題功能是整個系統最有業(yè)務價值的部分也是開發(fā)中最費心思的模塊。流程上是教師申報課題并提交審核管理員審核通過后進入選題池學生在選題開放時間段內瀏覽課題并提交申請教師看到申請后選擇通過或駁回雙方確認后選題關系正式建立同時候選人數限制生效。我在實現時用一個狀態(tài)流轉控制類來管理所有操作。整個選題狀態(tài)機共有8個狀態(tài)學生申請、教師已退回、學生重新申請、教師已接受、學生已確認、管理員已歸檔、學生已撤銷、課題已關閉。每個狀態(tài)轉移到下一個狀態(tài)是嚴格受控的不滿足前置條件的操作一律拋出業(yè)務異常。用枚舉定義狀態(tài)碼和允許的轉移關系在Service層做合法性校驗保證狀態(tài)不會亂跳。關于并發(fā)控制這里有一個經典的超選問題。假設一個課題限選3人第3個和第4個學生同時提交申請時如果兩個事務同時讀到當前人數為2就會都通過校驗導致課題人數變成4超額。解決方案有兩種一是給topic表加一個selection_count字段并在更新的時候用UPDATE topic SET selection_count selection_count 1 WHERE topic_id #{id} AND selection_count max_student這種樂觀并發(fā)控制語句用數據庫的行鎖保證原子性二是直接用SELECT ... FOR UPDATE對課題行加鎖。我選擇了前者因為它不需要額外的事務加鎖步驟一個SQL就完成了校驗和扣減實際壓測下來沒有出現超選情況。選題關閉后進入過程管理階段。學生按節(jié)點上傳開題報告、中期檢查表、結題報告教師在線查看并審批。審批通過后文檔狀態(tài)變?yōu)橐淹ㄟ^駁回時學生可以重新上傳。這里用了SpringBoot的文件上傳接口處理MultipartFile限制單文件最大50MB存儲路徑用日期分目錄避免一個目錄下文件過多導致檢索緩慢。3.3 答辯評分與成績匯總的實現方案答辯評分模塊要考慮靈活性和統計便捷性。老師創(chuàng)建答辯組時需要指定答辯時間、地點、評委然后把學生分配到組里。評委登錄系統后進入評分頁面看到本組學生名單給每個學生打分并填寫評語。成績計算邏輯我設計成了可配置方案平時成績占20%過程文檔提交情況和質量、指導教師評分占30%、答辯成績占50%。答辯成績取所有評委給分的平均值。三項加總得到最終成績再根據分數映射成優(yōu)秀、良好、中等、及格、不及格五個等級。規(guī)則配置在系統參數表里管理員可以調整權重不需要改代碼。成績發(fā)布后學生端可以查看自己的分數和等級同時教師端可以導出本組學生的成績Excel表。導出功能用Apache POI實現生成真正的xlsx文件而不是把Excel當成CSV寫這樣能保證中文不亂碼、格式正確。導出接口加了異步處理防止大組數據導出時阻塞主線程。4. Vue前端從工程搭建到功能落地4.1 工程初始化與路由權限控制前端我用的Vue 2.7配合Vue Router 3和Vuex 3這套組合技術成熟且在畢設項目中資料最全。腳手架直接使用Vue CLI創(chuàng)建我用的是webpack模式。創(chuàng)建完成后安裝Element UI、axios、vuex-persistedstate等依賴。整體目錄結構按照views、components、router、store、api、utils來劃分api目錄下按業(yè)務模塊拆分文件比如user.js、topic.js、document.js每個文件里封裝對應的接口請求函數。路由設計分成靜態(tài)路由和動態(tài)路由兩部分。靜態(tài)路由只有登錄頁和404頁面其余業(yè)務頁面全部走動態(tài)路由。用戶登錄成功后前端拿到該用戶的可訪問菜單和按鈕權限碼用router.addRoutes動態(tài)添加路由表。這樣學生登錄后地址欄手動敲教師端的URL也進不去因為前端根本沒有注冊那個路由匹配不到組件就自動跳到404。路由守衛(wèi)主要做兩件事一是未登錄攔截所有需要登錄的頁面訪問時校驗token是否存在不存在則跳轉登錄頁并攜帶redirect參數登錄后自動回到原頁面二是權限校驗在beforeEach鉤子里讀取當前用戶的路由權限表判斷目標路由是否有權限訪問。配合后端鑒權形成了雙保險。登錄頁的設計雖然常規(guī)但也有細節(jié)。表單校驗用了Element UI的rules對學號/工號、密碼做必填和長度校驗。登錄成功后調用獲取用戶信息接口拉取基本資料和菜單權限存到Vuex中?？紤]到刷新頁面會丟失Vuex內存狀態(tài)我引入了vuex-persistedstate插件把關鍵狀態(tài)同步到localStorage這樣刷新不會白屏跳登錄。4.2 通用組件的封裝表格、彈窗、上傳前端開發(fā)中最大的工作量其實在重復的表格頁面和彈窗表單上。每個模塊幾乎都是“搜索條件表格展示新增/編輯彈窗刪除確認”的模式。為了減少重復代碼我封裝了一個基于Element UI的ProTable組件它接收四個關鍵參數搜索表單項配置、表格列配置、接口請求函數、操作按鈕配置。組件內部自動處理搜索、重置、分頁、加載狀態(tài)業(yè)務頁面只需要傳入配置項就能渲染出完整的CRUD界面。封裝的第二個重要組件是文件上傳組件。畢業(yè)設計系統里學生要上傳Word或PDF格式的文檔教師和管理員要上傳Excel成績表、教學計劃等材料每個上傳場景都需要文件類型限制、大小限制、進度顯示和回顯邏輯。封裝時可配置accept屬性限制文件類型size限制大小action指定上傳接口返回后回填文件路徑到表單隱藏字段。之所以下這么大功夫封裝組件是因為前端代碼的復用度直接決定了項目的可維護性。我見過很多半途而廢的項目問題不在邏輯復雜而在于重復代碼太多開發(fā)后期改一個需求要同時改十幾個長得差不多的頁面耐心被消磨殆盡項目也就爛尾了。組件化維護好后面加一個“通知公告”模塊只花了一個下午。表格數據展示方面實踐中有個容易被忽略的點性別、狀態(tài)、類型這類字段后端返回的往往是數字編碼前端不能直接展示數字需要一個通用的字典翻譯機制。我在utils目錄里寫了dict.js維護一份字典映射表提供翻譯函數在表格列中調用用戶看到的是“男/女”“已通過/待審核”這類可讀文字。同時支持字典項的顏色映射比如通過的標綠色、駁回的標紅色狀態(tài)一目了然。4.3 跨域聯調與接口對接的實操記錄前后端分離開發(fā)中跨域問題是聯調第一關。前端運行在localhost:8080后端運行在localhost:8080兩個端口不同瀏覽器的同源策略會攔截接口請求。解決跨域我用了兩層方案。第一層是后端配置CORS過濾器允許指定的前端地址跨域訪問設置allowedOriginPatterns為*allowedMethods為GET、POST、PUT、DELETE、OPTIONS并允許攜帶認證信息。第二層是在開發(fā)環(huán)境用Vue CLI的proxyTable把/api前綴的請求代理到后端地址讓瀏覽器認為請求是同源的。聯調過程中最常踩的坑是數據格式不一致。后端返回的統一響應體設計為{ code: 200, message: success, data: { ... } }但不同開發(fā)者在寫代碼時容易漏掉部分接口的包裝導致前端拿到的是裸數據。解決方法是后端統一用一個ResponseResult類包裝所有響應全局異常處理器也要確保最終返回格式一致。前端axios響應攔截器中統一做兩層處理第一層判斷HTTP狀態(tài)碼是否為200第二層判斷業(yè)務code是否為200出現非200統一彈錯誤提示。Mock數據在前端先行開發(fā)的階段是利器。沒有后端接口時用Mock.js攔截axios請求返回模擬數據前端可以獨立開發(fā)頁面和交互邏輯后端接口聯調時只需在配置中心把mock開關關掉請求就會走到真實后端。這樣前后端可以并行開發(fā)顯著壓縮了項目工期。我習慣把Mock統一放在mock目錄為每個模塊建一個mock文件接口路徑和真實后端保持一致方便切換。5. 常見問題與排查實錄速查表5.1 跨域、上傳失敗、分頁異常等高頻問題聯調和測試階段遇到最多的問題是跨域配置不生效、文件上傳超時、分頁數據錯亂和Session失效跳轉異常。我把典型問題和排查方式整理成了一個表格這里列出來供參考問題現象排查思路解決方案CORS跨域瀏覽器報No Access-Control-Allow-Origin確認過濾器是否生效、請求是否帶credentials檢查允許源配置和方法確保放行OPTIONS預檢請求上傳大文件超時axios報timeout異常后端MultipartFile大小限制、前端超時時間設置后端配置max-file-size和max-request-size前端axios設置timeout30000分頁錯亂或丟失多表聯查時分頁總數錯誤檢查是否PageHelper上下文被消費SQL中是否存在多余查詢保證startPage與查詢在同一個Mapper方法調用中連續(xù)執(zhí)行中文亂碼JSON返回中文顯示為問號數據庫連接串未指定characterEncodingJDBC URL增加characterEncodingutf8前端響應攔截器統一設置UTF-8前端路由刷新404刷新后跳到404頁面靜態(tài)資源托管路徑和history模式沖突使用hash模式或配置nginx try_files回退到index.html導出Excel打不開文件亂碼或格式損壞POI生成xlsx時用錯擴展名響應頭設置錯誤正確設置Content-Type和Content-Dispositionfilename用URLEncoder編碼排查問題時我的經驗是先看瀏覽器Network面板的請求狀態(tài)和響應體再決定是前端問題還是后端問題。一半以上的聯調問題都能在Network面板直接定位不要一上來就猜原因。其次在后端日志中開啟SQL打印MyBatis會把執(zhí)行的SQL和參數值打出來肉眼就能看到是不是參數傳遞出錯。這個習慣幫我節(jié)省了大量時間。5.2 性能優(yōu)化清單從慢查詢到首屏提速系統開發(fā)完成后壓測發(fā)現幾個性能瓶頸點逐一解決后接口響應時間從平均600ms降到了150ms左右。這里記錄一下優(yōu)化清單給遇到類似問題的朋友做參考。第一項是數據庫層的索引優(yōu)化。最頻繁的幾個查詢條件是按學生ID查申請記錄、按教師ID查課題列表、按狀態(tài)篩選申報單。對應的三張表分別建立了聯合索引(student_id, topic_status)、(teacher_id, topic_year)、(topic_status, topic_type)。建索引前用EXPLAIN查看執(zhí)行計劃發(fā)現不少全表掃描加上索引后直接走索引查詢。建索引并非越多越好每個索引都會拖慢寫入速度只對高頻查詢條件的字段建索引其他的不動。第二項是接口層的字段裁剪。有些列表接口把實體類的所有字段全返回給前端包括description這種大字段。一個課題列表20條數據每個都帶幾百字的描述和冗余字段傳輸量自然大。優(yōu)化方案是新建查詢用的VO類只包含列表展示需要的字段查詢SQL也只SELECT需要的列避免SELECT *。這樣接口響應體從單次幾十KB降到幾KB速度提升非常明顯。第三項是前端路由懶加載。原來一個路由文件把所有組件同步引入首屏要加載整個JS包白屏時間很長。改成路由懶加載后訪問哪個頁面才加載對應的組件JS首屏資源體積只剩原來的四成。配合CDN加載Vue、Vue Router、Element UI這些公共庫利用瀏覽器緩存機制第二次訪問的加載速度又能提升一截。第四項是open-in-new-tab這類靜態(tài)資源的緩存策略。上傳的頭像、附件在FastDFS或本地存儲路徑上設置Cache-Control頭存一天的緩存減少重復請求。這一項優(yōu)化起來成本極低收益卻很直觀。對于畢設管理系統這種用戶量不大、但表單密集的系統優(yōu)化核心還是數據庫和傳輸體積真沒必要去碰Redis或者加消息隊列。5.3 安全加固防SQL注入、XSS、越權與爆破畢設系統上生產環(huán)境之前安全加固不能省。我這個項目做了四層防護每一層都有明確的實操方案。防SQL注入的核心是杜絕字符串拼接SQL。前面已經提過所有參數都必須走#{}占位符MyBatis的${}僅在極少數白名單場景下使用。在此基礎上攔截器層還能統一檢查請求參數里是否包含常見注入關鍵字不過這不作為主要防線只是一種縱深防御。防XSS攻擊主要針對存儲型XSS。用戶在富文本編輯器里可以提交帶有script標簽的內容如果不處理別人瀏覽時就會執(zhí)行惡意腳本。我的處理方式是后端設置了一個全局的HTML過濾器對請求參數中的script、onerror等敏感標簽做轉義或剔除。同時前端在渲染富文本時也要做過濾雙端配合。Element UI的table組件默認也不會解析HTML這減少了一部分風險但不能因此省掉后端的過濾措施。防越權訪問主要通過數據權限控制。學生只能操作自己的課題申請記錄教師只能審核自己名下的課題。即便學生手動改接口傳參把申請ID換成別人的后端也要校驗當前登錄用戶是否是記錄的屬主。這個邏輯我在Service層統一做了校驗抽取了一個checkOwnership方法所有涉及按主鍵操作的業(yè)務方法都先調用它。防暴力破解在登錄接口加了簡單的嘗試次數限制。同一個賬號連續(xù)5次密碼錯誤就鎖定15分鐘同時在前端登錄頁加一個圖形驗證碼。驗證碼用后端生成圖片返回給前端存session或Redis。這里要特別提醒JWT無狀態(tài)模式下如果用Redis存了驗證碼或登錄計數那這個Key的過期時間一定要設置合理避免長期占用Redis內存。6. 打包部署與二次開發(fā)的擴展空間6.1 前后端打包與環(huán)境配置管理項目開發(fā)完成進入部署階段前后端各自要處理一些“最后一公里”的問題。后端SpringBoot項目打包成可執(zhí)行的JAR包關鍵是把配置文件里的數據庫地址、Redis地址等環(huán)境相關變量抽成外部配置項使用SpringBoot的Profile機制區(qū)分dev和prod環(huán)境。生產環(huán)境用java -jar xxx.jar --spring.profiles.activeprod啟動時指定Profile數據庫密碼等重要信息通過環(huán)境變量注入。前端打包使用npm run build生成dist靜態(tài)目錄部署到Nginx。Nginx配置要解決兩個關鍵點一是將/api路徑的請求反向代理到后端服務二是不管用戶訪問哪個前端路由都回退到index.html入口防止history模式下的404問題。配置大概長這樣server { listen 80; server_name your-domain.com; location / { root /opt/graduation-frontend/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /files/ { alias /data/upload/; } }這里有個細節(jié)try_files $uri $uri/ /index.html;是SPA應用部署的核心不加這個配置用戶在非根路徑刷新頁面就會404。上傳文件的別名映射也很有必要否則每次部署都要重新上傳一遍默認的文檔模板和頭像圖片。SQL腳本的管理同樣值得重視。我的做法是建立sql目錄按版本編號組織腳本v1.0-init.sql放全量的建表和初始數據v1.1-add-column.sql放后續(xù)迭代的增量變更。每發(fā)布一次新版本運維只需要按序號執(zhí)行對應的增量腳本不需要動不動就重跑全量初始化。這個習慣從小項目做起以后接手大型項目不會發(fā)懵。6.2 后續(xù)可擴展方向消息通知、移動端與智能評分基礎版的畢設管理系統已經能覆蓋核心業(yè)務但架構上保留了充足的橫向擴展空間這里列幾個我調研過的方向供二次開發(fā)參考。消息通知模塊是目前最值得擴展的功能。當前系統內產生新申請、審批通過、文檔被駁回等事件時都是靠用戶主動刷新頁面才能感知。擴展方案是接入WebSocket后端在業(yè)務狀態(tài)流轉時推送消息。具體可用SpringBoot的WebSocket集成一個簡單的消息推送服務前端維護一個全局消息中心收到新通知時在導航欄角標上出現紅點提醒。更進一步還能支持郵件通知在學生提交選題時自動發(fā)送一封確認郵件。這塊工作量和收益比非常高能為系統增加明顯的“在線感”。移動端適配是另一個實用方向。目前前端是桌面端優(yōu)先的設計在手機上瀏覽表格會撐出很長的橫向滾動條體驗不好?？尚械淖龇ㄓ袃煞N一是用Vue的響應式設計改造現有頁面在大屏和小屏之間切換布局二是開發(fā)一個專門的移動端H5頁面或者小程序只包含學生最常用的三個功能——查看課題、提交申請、查看成績。第二個方案在工期緊張時更可控不觸碰原有復雜度極高的桌面端代碼。智能化方向也值得一提。比如根據學生的專業(yè)方向和歷史成績推薦匹配課題這個可以用一個簡單的基于關鍵詞的推薦算法實現把課題標簽和學生興趣標簽做余弦相似度計算推薦TopN課題在個人首頁展示。答辯評分可以做多維度的統計數據儀表盤展示成績分布、選題熱度、指導教師工作量等視圖這些數據都已經在數據庫里只需新增幾個查詢接口和一個大屏頁面就能落地。這些方向都能讓這套系統從“作業(yè)級”進一步走向“產品級”也能在答辯時展現出獨立思考和技術深度。6.3 團隊協作規(guī)范從單體倉庫到自動化構建最后單獨講講團隊協作層面。畢設系統如果是一個人在寫以上各節(jié)基本夠用如果是兩三個人一起開發(fā)規(guī)范和自動化就變得重要了。代碼管理上我用GitFlow的簡化版main分支為穩(wěn)定主干develop分支為開發(fā)集成分支feature分支從develop切出。每個功能模塊一個分支開發(fā)完合并到develop最后再上main。每次提交信息按“type: description”格式寫feat表示新功能fix表示修bugstyle表示格式調整。分支規(guī)范的作用不只是把代碼存檔而是讓協作者能通過Git history快速理解項目演進脈絡。這一點在項目后期回溯問題時價值極高。數據庫變更管理方面我在團隊里強制要求每張表結構變更都跟著增量SQL腳本代碼合并的同時腳本也要合并。如果兩個開發(fā)者同時改了同一張表直接在SQL腳本層面通過Git的沖突檢測發(fā)現和解決而不是等到聯調時才發(fā)現字段對不上。這個習慣用了一種非常樸素的方法解決了團隊協作中“最不想發(fā)生”的數據庫結構沖突。CI/CD方面我給項目配置了一套簡易的自動化構建流程。后端代碼提交到develop分支時云上構建平臺自動拉代碼、跑測試、打包JAR包前端代碼提交時自動執(zhí)行npm install和npm run build產物上傳到指定目錄。這些自動化流水線跑起來之后部署環(huán)節(jié)不再依賴某一個開發(fā)者的筆記本電腦發(fā)布流程變得穩(wěn)定可復現。關于這套系統的實戰(zhàn)復盤個人體驗最深的還是那句老話技術棧是骨架業(yè)務理解是靈魂。SpringBoot、Vue、MyBatis、MySQL這套組合確實成熟穩(wěn)重但真正把系統做出價值靠的是對畢業(yè)設計管理業(yè)務中那些狀態(tài)流轉、權限劃分、數據閉環(huán)的深入理解。開發(fā)過程中踩過的每一個坑——PageHelper的上下文污染、動態(tài)SQL的潛在注入、前端路由刷新404、跨域配置遺漏——都會成為未來技術生涯中的寶貴經驗。如果讀者打算用這個主題作為畢業(yè)設計建議在基礎功能之上挑一個擴展方向深挖比如消息通知或智能推薦做出差異化答辯時也更有話可說。