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