課程設(shè)計(jì)選題這件事經(jīng)歷過的人都知道有多費(fèi)勁。每次一到學(xué)期中段辦公室里全是學(xué)生發(fā)來的老師XX題目還有名額嗎的消息微信群消息滾動(dòng)堪比秒殺現(xiàn)場Excel表格傳來傳去改得亂七八糟。我見過不止一個(gè)老師用先到先得手工登記結(jié)果總有學(xué)生說我明明先發(fā)的消息你怎么沒看到。學(xué)生選題全靠搶、教師審核全靠催、管理員統(tǒng)計(jì)全靠手動(dòng)匯總這就是傳統(tǒng)流程的真實(shí)寫照。所以才有了這套基于SpringBoot后端Vue前端MySQL的課程設(shè)計(jì)選題管理信息管理系統(tǒng)把選題、審核、統(tǒng)計(jì)整個(gè)過程線上化誰選了哪個(gè)題、狀態(tài)是否通過打開頁面一目了然。這篇文章從需求分析、后端設(shè)計(jì)、前端協(xié)作、數(shù)據(jù)庫建模到實(shí)際運(yùn)行踩坑完整復(fù)盤這套系統(tǒng)的方方面面適合正在做課程設(shè)計(jì)、想?yún)⒖汲墒霿eb項(xiàng)目源碼、或者準(zhǔn)備自己動(dòng)手寫一個(gè)選題系統(tǒng)的同學(xué)。1. 先聊聊課程設(shè)計(jì)選題這件事痛點(diǎn)比你想的深課程設(shè)計(jì)是高校教學(xué)里幾乎每學(xué)期都有的環(huán)節(jié)但選題環(huán)節(jié)長期處于一種原始社會(huì)的狀態(tài)。別小看這個(gè)看似簡單的管理需求真正做起來才發(fā)現(xiàn)里面的規(guī)則細(xì)節(jié)遠(yuǎn)比想象多。1.1 手工選題的混亂現(xiàn)場我最早接觸這個(gè)需求是因?yàn)榭吹侥澄焕蠋熡肊xcel登記學(xué)生選題。表格里有課題名稱、學(xué)生姓名、學(xué)號(hào)、聯(lián)系方式幾個(gè)字段開放給全班同學(xué)自己填。聽起來沒問題實(shí)際上操作起來全是坑一個(gè)課題被多個(gè)學(xué)生同時(shí)填上到底算誰的老師只能按填表時(shí)間先后判斷但Excel沒有時(shí)間戳學(xué)生各說各話。更麻煩的是老師改一次表格就要重新發(fā)一次文件每個(gè)學(xué)生手里的版本都不一樣最后匯總時(shí)數(shù)據(jù)對(duì)不上得從頭核對(duì)聊天記錄。微信群的搶答式選題就更亂了。老師在群里發(fā)題目清單學(xué)生在下面回復(fù)我要3號(hào)題。高峰期消息刷得飛快老師翻記錄翻到眼花。而且這種模式下信息公開程度完全取決于學(xué)生是否在群里、是否刷到了消息晚來的學(xué)生根本不知道哪些題目還有名額只能挨個(gè)私聊老師碰運(yùn)氣。原本應(yīng)該是學(xué)生根據(jù)自己的興趣和能力選擇合適的課題硬生生變成了拼手速、拼網(wǎng)速、拼人脈。還有一類問題是選題之后的變更。學(xué)生選完題過兩周想換題或者老師發(fā)現(xiàn)某個(gè)課題方向不適合某位學(xué)生需要撤銷重選。手工模式下這種變更幾乎沒有留痕誰改過、什么時(shí)候改的、改成什么了全靠記憶出了問題說不清楚。1.2 系統(tǒng)要解決的三個(gè)核心問題手動(dòng)流程混亂的本質(zhì)其實(shí)可以歸納成三件事名額歸屬不明確、狀態(tài)信息不透明、操作記錄不完整。這套選題管理系統(tǒng)就是圍繞這三件事設(shè)計(jì)的。名額歸屬問題說白了就是一個(gè)課題能被多少人選、被誰選。系統(tǒng)里每個(gè)課題都可以設(shè)置可選人數(shù)上限學(xué)生提交選題后進(jìn)入待審核狀態(tài)教師審核通過才算真正占用名額。如果審核不通過名額自動(dòng)釋放其他學(xué)生可以繼續(xù)選。這樣就避免了誰先搶到算誰的這種規(guī)則不透明的情況。狀態(tài)信息不透明指的是選題做到哪一步了。學(xué)生視角需要知道我選的題目老師審核了沒有要不要重新選教師視角需要知道我的課題被哪些學(xué)生選了哪些還沒人選哪些審核通過了管理員視角需要知道全局還有多少學(xué)生沒選上題、哪些課題沒人選、每個(gè)老師的指導(dǎo)學(xué)生數(shù)是多少。這些狀態(tài)在系統(tǒng)里通過可選、待審核、已通過、已駁回等幾個(gè)明確狀態(tài)表達(dá)誰看都不會(huì)產(chǎn)生歧義。操作記錄不完整對(duì)應(yīng)的是系統(tǒng)的日志能力。誰在什么時(shí)間選了哪個(gè)題、誰在什么時(shí)間審核了什么操作都能在后臺(tái)查到。這個(gè)特性平時(shí)不起眼但一旦出現(xiàn)學(xué)生說我沒選過這個(gè)題老師說我沒審核過這個(gè)學(xué)生之類的爭議記錄就是最有力的依據(jù)。我在設(shè)計(jì)的時(shí)候特意把關(guān)鍵操作都寫入了操作日志表實(shí)測(cè)下來非常有必要。2. 功能拆解三種角色、兩條主流程、一組狀態(tài)機(jī)做管理系統(tǒng)最忌諱一上來就寫代碼。角色—流程—狀態(tài)這套骨架不梳理清楚寫出來的功能大概率是亂的。這套選題系統(tǒng)在動(dòng)手前我先把業(yè)務(wù)規(guī)則理了一遍。2.1 管理員、教師、學(xué)生的權(quán)限邊界整個(gè)系統(tǒng)只有三種角色權(quán)限邊界劃分得非常清晰。管理員是超級(jí)管理者負(fù)責(zé)基礎(chǔ)數(shù)據(jù)的維護(hù)。學(xué)生的批量導(dǎo)入、教師的賬號(hào)創(chuàng)建、課程的學(xué)期設(shè)置、系統(tǒng)的運(yùn)行參數(shù)都?xì)w管理員管。管理員一般不直接參與選題業(yè)務(wù)但擁有查看所有數(shù)據(jù)的權(quán)限便于統(tǒng)計(jì)和排查問題。教師是課題的提供者和審核者。教師登錄后可以發(fā)布新課題、修改課題描述、設(shè)置課題可選人數(shù)、查看自己課題的被選情況也可以對(duì)學(xué)生提交的選題申請(qǐng)進(jìn)行通過或駁回操作。教師的權(quán)限范圍限定在自己的課題上看不到其他老師的課題詳情但系統(tǒng)提供了按老師維度匯總的統(tǒng)計(jì)頁面方便系里掌握整體情況。學(xué)生是選題的主體。學(xué)生登錄后可以瀏覽當(dāng)前學(xué)期所有可選課題列表按課題名稱、教師姓名、關(guān)鍵詞進(jìn)行搜索查看課題的剩余名額和當(dāng)前狀態(tài)然后提交選題申請(qǐng)。每個(gè)學(xué)生同時(shí)只能有一個(gè)有效的選題記錄——所謂有效是指待審核或已通過狀態(tài)。被駁回后可以重新選擇其他課題但一旦審核通過就不能再改了除非教師手動(dòng)撤銷。這個(gè)一人一題的約束是整個(gè)系統(tǒng)的核心業(yè)務(wù)規(guī)則后面會(huì)在數(shù)據(jù)庫層面和代碼層面雙重實(shí)現(xiàn)防止繞過前端直接調(diào)接口的情況。2.2 選題與審核的狀態(tài)流轉(zhuǎn)整個(gè)系統(tǒng)的主流程其實(shí)只有兩條一條是學(xué)生的選題流程一條是教師的審核流程。兩條流程通過選題記錄的狀態(tài)字段串在一起。學(xué)生提交選題申請(qǐng)后系統(tǒng)生成一條選題記錄狀態(tài)為待審核。此時(shí)課題的已選人數(shù)不增加防止審核不通過后還需要額外操作釋放名額。教師看到待審核記錄后可以選擇通過或駁回。通過后狀態(tài)變?yōu)橐淹ㄟ^課題已選人數(shù)加一駁回后狀態(tài)變?yōu)橐疡g回學(xué)生可以重新選擇其他課題。這里有個(gè)細(xì)節(jié)值得展開說為什么不在學(xué)生提交時(shí)就直接占用名額而是等教師審核我最初設(shè)計(jì)的版本確實(shí)是提交即占用但實(shí)際使用中發(fā)現(xiàn)一個(gè)問題——有學(xué)生一股腦把熱門題都選一遍占著名額等審核導(dǎo)致真正想選的學(xué)生選不了最后審核不通過才釋放浪費(fèi)了時(shí)間窗口。改成提交待審核、通過才占額之后雖然教師的審核壓力變大了但名額分配更公平。這也算是一次真實(shí)業(yè)務(wù)反饋倒逼設(shè)計(jì)的調(diào)整。除此之外系統(tǒng)還有一條撤銷邏輯教師可以在審核通過之后因故撤銷某位學(xué)生的選題資格將課題名額釋放學(xué)生重新變?yōu)槲催x題狀態(tài)。這個(gè)操作用于處理中途換題、學(xué)生退課等特殊情況同時(shí)在日志中記錄原因。2.3 核心流程的邊界條件設(shè)計(jì)梳理流程時(shí)最容易漏掉的就是邊界條件我做了一個(gè)完整的清單逐一處理學(xué)生提交選題時(shí)如果已經(jīng)有一條待審核或已通過的記錄系統(tǒng)直接攔截提示當(dāng)前已有在審或通過的選題。課題可選人數(shù)為1時(shí)只要有學(xué)生審核通過課題自動(dòng)變?yōu)橐褲M員狀態(tài)不再出現(xiàn)在可選列表中。學(xué)生只能看到當(dāng)前學(xué)期、狀態(tài)為可選或已滿員的課題歷史課題和未開放課題一律不可見。教師只能審核自己名下的課題選題記錄接口層面做了歸屬校驗(yàn)防止越權(quán)。學(xué)期切換時(shí)上一學(xué)期的所有選題記錄自動(dòng)歸檔學(xué)生在新學(xué)期重新選題。這些邊界條件看似瑣碎但正是它們決定了系統(tǒng)是否可用。我見過不少功能完好的演示系統(tǒng)一到真實(shí)使用場景就崩絕大多數(shù)都是栽在邊界條件上。所以這一部分花費(fèi)的時(shí)間比重絕不小于寫業(yè)務(wù)代碼。3. SpringBoot后端的關(guān)鍵實(shí)現(xiàn)狀態(tài)管理、并發(fā)控制與登錄鑒權(quán)后端是整個(gè)系統(tǒng)的數(shù)據(jù)中樞。我選擇SpringBoot是因?yàn)樗谡n程設(shè)計(jì)類項(xiàng)目里生態(tài)最成熟Spring MVC處理請(qǐng)求、Spring Data JPA或MyBatis操作數(shù)據(jù)庫、Spring Security管理安全一套組合拳下來幾乎不需要額外造輪子。當(dāng)然不同版本的選型有講究后面細(xì)說。3.1 分層結(jié)構(gòu)與請(qǐng)求處理鏈路這個(gè)項(xiàng)目的后端采用經(jīng)典的四層結(jié)構(gòu)Controller層接收HTTP請(qǐng)求并做參數(shù)校驗(yàn)Service層實(shí)現(xiàn)業(yè)務(wù)邏輯Mapper/Repository層訪問數(shù)據(jù)庫實(shí)體類負(fù)責(zé)數(shù)據(jù)映射。層與層之間嚴(yán)格單向依賴Controller不直接操作數(shù)據(jù)庫Service不直接處理HTTP細(xì)節(jié)這樣后續(xù)排查問題時(shí)可以快速定位是接口問題還是邏輯問題還是數(shù)據(jù)問題。舉個(gè)例子學(xué)生提交選題的接口請(qǐng)求路徑大概長這樣POST /api/selection請(qǐng)求體里包含課題ID。Controller層拿到課題ID后先做基礎(chǔ)校驗(yàn)——課題是否存在、當(dāng)前學(xué)期是否開放——然后交給Service層。Service層首先查詢學(xué)生當(dāng)前的選題記錄判斷是否已有待審核或已通過狀態(tài)接著查詢課題信息判斷是否還有剩余名額全部通過后開啟事務(wù)插入一條選題記錄狀態(tài)設(shè)為待審核。如果中途任何一步校驗(yàn)失敗直接拋出業(yè)務(wù)異常由全局異常處理器統(tǒng)一轉(zhuǎn)換為JSON錯(cuò)誤信息返回給前端。這套鏈路的優(yōu)點(diǎn)是職責(zé)單一、便于測(cè)試。我習(xí)慣在每個(gè)Service方法里先寫注釋標(biāo)明業(yè)務(wù)規(guī)則再寫代碼這樣過兩周回來看還能快速想起當(dāng)初的意圖。3.2 并發(fā)選題防超搶的落地方案選題系統(tǒng)有一個(gè)繞不開的技術(shù)問題并發(fā)。幾十個(gè)學(xué)生同一時(shí)間都點(diǎn)提交選題如果恰好都是同一個(gè)熱門課題怎么保證名額不超前端按鈕禁用、提示正在提交這類手段只能防君子擋不住惡意請(qǐng)求和網(wǎng)絡(luò)重放。我的做法是在數(shù)據(jù)庫層面加雙保險(xiǎn)。第一道保險(xiǎn)是選題記錄表的唯一索引UNIQUE KEY uk_student_current (student_id, status_valid_flag)。但這里有個(gè)技術(shù)細(xì)節(jié)——MySQL的唯一索引不允許同一字段出現(xiàn)多個(gè)NULL值不對(duì)MySQL的InnoDB引擎中唯一索引允許多個(gè)NULL值所以不能用status字段直接做唯一索引因?yàn)橐粋€(gè)學(xué)生會(huì)有多條歷史記錄。實(shí)際方案有兩種一是加一個(gè)當(dāng)前有效標(biāo)記字段有效為1歷史為0對(duì)(student_id, valid_flag)建唯一索引二是單獨(dú)維護(hù)一張學(xué)生當(dāng)前選題表每個(gè)學(xué)生最多一條記錄天然強(qiáng)制唯一。這兩種方案我都實(shí)現(xiàn)過第二種更干凈也更容易理解。第二道保險(xiǎn)是事務(wù)內(nèi)的行鎖。提交選題時(shí)無論先查課題表還是先插記錄都要保證判斷名額和增加計(jì)數(shù)在同一個(gè)事務(wù)里原子執(zhí)行。關(guān)鍵操作是對(duì)課題表記錄加行鎖SELECT ... FOR UPDATE鎖住課題行之后再判斷當(dāng)前已選人數(shù)是否小于上限滿足則更新人數(shù)、插入選題記錄。這樣兩個(gè)并發(fā)事務(wù)同時(shí)進(jìn)來時(shí)第二個(gè)事務(wù)會(huì)被阻塞等第一個(gè)提交后再讀取最新人數(shù)自然也就不會(huì)超賣。實(shí)測(cè)下來這兩種機(jī)制疊加之后即使用腳本同時(shí)發(fā)幾十個(gè)請(qǐng)求搶同一個(gè)課題最終也只有設(shè)定數(shù)量的學(xué)生能成功其余全部收到課題名額不足的提示。這也算是一道經(jīng)典的秒殺練習(xí)放到選題場景里同樣適用。3.3 基于JWT的角色鑒權(quán)與攔截器系統(tǒng)雖然不算復(fù)雜但三種角色的權(quán)限差異很明顯安全設(shè)計(jì)不能只是擺設(shè)。我采用的是JWTJSON Web Token無狀態(tài)鑒權(quán)方案用戶登錄成功后后端簽發(fā)一個(gè)包含用戶ID、用戶名、角色信息的Token前端每次請(qǐng)求在請(qǐng)求頭里攜帶后端通過攔截器解析校驗(yàn)。實(shí)際實(shí)現(xiàn)時(shí)我在SpringBoot里寫了一個(gè)AuthInterceptor注冊(cè)到WebMvcConfigurer中。攔截器負(fù)責(zé)兩件事一是解析請(qǐng)求頭中的Token驗(yàn)簽并判斷是否過期二是根據(jù)Token中的角色信息校驗(yàn)當(dāng)前請(qǐng)求URL是否有訪問權(quán)限。對(duì)于不需要登錄就能訪問的接口比如登錄接口本身用白名單方式排除。這里有個(gè)容易被忽略的細(xì)節(jié)Token中不要放敏感信息。有些同學(xué)直接把用戶密碼放進(jìn)Token里這等于把密碼明文寫在了每次請(qǐng)求頭上一旦Token被截獲密碼就泄露了。我的做法是Token里只放用戶ID、用戶名和角色密碼等敏感字段任何時(shí)候都從數(shù)據(jù)庫查詢。另外前端存Token也有講究。放在localStorage里最簡單但有XSS風(fēng)險(xiǎn)放HttpOnly Cookie里更安全但要注意跨域時(shí)Cookie的SameSite設(shè)置可能影響攜帶。這個(gè)項(xiàng)目里我采用localStorage存儲(chǔ)配合前端路由守衛(wèi)判斷登錄態(tài)對(duì)于課程設(shè)計(jì)場景來說夠用但如果你做生產(chǎn)級(jí)系統(tǒng)建議升級(jí)為Cookie方案。4. Vue前端怎么搭頁面組織、API封裝與角色區(qū)分的實(shí)操記錄前端部分我選的是Vue搭配Element UI組件庫。這套組合在課程設(shè)計(jì)項(xiàng)目中非常流行組件齊全、文檔完善、社區(qū)案例多遇到問題搜一下基本都有答案。整個(gè)前端工程結(jié)構(gòu)按照頁面—組件—API—路由四層組織。4.1 路由與菜單如何按角色區(qū)分前端先按登錄狀態(tài)做了第一層分流未登錄用戶訪問任何頁面都會(huì)被路由守衛(wèi)重定向到登錄頁。登錄成功后根據(jù)用戶角色動(dòng)態(tài)生成菜單和路由。管理員看數(shù)據(jù)統(tǒng)計(jì)和用戶管理頁教師看課題管理和審核頁學(xué)生看選題頁和我的選題頁。具體做法是登錄接口返回用戶信息和角色后前端根據(jù)角色從路由配置里篩選出可訪問的路由表動(dòng)態(tài)添加到Vue Router中同時(shí)渲染對(duì)應(yīng)的側(cè)邊欄菜單。這里有個(gè)實(shí)操經(jīng)驗(yàn)路由表一定要區(qū)分靜態(tài)路由和動(dòng)態(tài)路由。登錄頁、404頁屬于靜態(tài)路由業(yè)務(wù)頁面全部屬于動(dòng)態(tài)路由刷新頁面時(shí)要重新加載動(dòng)態(tài)路由否則一刷新就白屏。我最初沒處理刷新問題結(jié)果每次刷新都跳回登錄頁一度以為是登錄態(tài)丟失排查了半天才發(fā)現(xiàn)是動(dòng)態(tài)路由沒恢復(fù)。后來在全局前置守衛(wèi)里加了一步如果本地有Token但路由表中沒有業(yè)務(wù)路由就先調(diào)用一次獲取用戶信息接口重新生成路由表再放行。這樣刷新問題就徹底解決了。4.2 axios封裝與接口對(duì)接約定前端所有HTTP請(qǐng)求統(tǒng)一走一個(gè)封裝好的axios實(shí)例。封裝的核心有三塊請(qǐng)求攔截器在每次請(qǐng)求前把Token加到請(qǐng)求頭響應(yīng)攔截器統(tǒng)一處理業(yè)務(wù)錯(cuò)誤碼和HTTP錯(cuò)誤以及集中處理401未授權(quán)跳轉(zhuǎn)登錄頁。接口地址統(tǒng)一以/api開頭后端Controller用RequestMapping(/api/...)對(duì)應(yīng)。前后端接口字段名約定使用小駝峰后端返回的數(shù)據(jù)結(jié)構(gòu)統(tǒng)一為{ code, message, data }。這套約定一旦定下來前后端聯(lián)調(diào)時(shí)就不需要反復(fù)對(duì)字段。我也見過一些項(xiàng)目前后端各寫各的字段名一個(gè)用student_name一個(gè)用studentName聯(lián)調(diào)時(shí)天天對(duì)著文檔發(fā)愁純粹是自找麻煩。封裝好之后頁面里調(diào)用接口就非常清爽。比如學(xué)生提交選題只需在Vue組件里調(diào)用this.$api.selection.submit(topicId)剩下的Token注入、錯(cuò)誤提示、Loading狀態(tài)都由封裝層處理。代碼可讀性高維護(hù)成本也低。4.3 聯(lián)調(diào)過程中最容易出問題的地方前后端聯(lián)調(diào)時(shí)踩得最多的坑有三個(gè)我挨個(gè)說。第一個(gè)是跨域。前端開發(fā)服務(wù)器默認(rèn)跑在8081端口后端是8080瀏覽器會(huì)攔截跨域請(qǐng)求。我的解決方案是在Vue的vue.config.js里配置devServer代理將/api開頭的請(qǐng)求轉(zhuǎn)發(fā)到http://localhost:8080這樣前端看起來就是同源請(qǐng)求不需要后端額外開啟CORS。如果你選擇在后端用CrossOrigin注解開啟跨域也可以但注意要把a(bǔ)llowCredentials配置對(duì)否則攜帶Token的請(qǐng)求會(huì)出問題。第二個(gè)是日期格式。后端返回的時(shí)間字段如果序列化成時(shí)間戳前端需要自己轉(zhuǎn)換如果返回的是帶T的ISO格式字符串JSON解析后也容易跟預(yù)期不一致。我的做法是在后端統(tǒng)一配置Jackson的日期格式為yyyy-MM-dd HH:mm:ss前端直接展示即可省掉一批轉(zhuǎn)換工具函數(shù)。第三個(gè)是參數(shù)校驗(yàn)的一致性。前端做了必填校驗(yàn)后端也必須做絕對(duì)不能依賴前端校驗(yàn)。惡意用戶可以繞過前端直接構(gòu)造請(qǐng)求后端如果不在Controller或Service層校驗(yàn)參數(shù)非法數(shù)據(jù)就會(huì)寫進(jìn)數(shù)據(jù)庫。這個(gè)項(xiàng)目里后端用javax.validation注解對(duì)請(qǐng)求實(shí)體做了非空、長度等校驗(yàn)校驗(yàn)失敗會(huì)返回明確的錯(cuò)誤信息。5. MySQL表結(jié)構(gòu)與數(shù)據(jù)關(guān)系幾張表撐起整個(gè)業(yè)務(wù)數(shù)據(jù)庫設(shè)計(jì)是選題系統(tǒng)的地基。這套系統(tǒng)雖然功能面不少但核心表其實(shí)就那么幾張把表之間的關(guān)系理清楚業(yè)務(wù)邏輯也就通了一半。5.1 用戶、課題、選題記錄三張核心表第一張是用戶表。包含用戶ID、用戶名、密碼BCrypt加密存儲(chǔ)、真實(shí)姓名、角色管理員/教師/學(xué)生、所屬班級(jí)學(xué)生、所屬院系教師、創(chuàng)建時(shí)間等字段。用戶表和角色是簡單的一對(duì)一關(guān)系沒有單獨(dú)拆角色表因?yàn)檫@套系統(tǒng)角色固定且不會(huì)擴(kuò)展拆表反而增加聯(lián)查成本。第二張是課題表。字段包括課題ID、課題名稱、課題描述、所屬教師ID、所屬課程/學(xué)期、可選人數(shù)上限、已選人數(shù)、狀態(tài)開放/關(guān)閉/滿員、創(chuàng)建時(shí)間、更新時(shí)間。課題表通過教師ID關(guān)聯(lián)用戶表體現(xiàn)每個(gè)課題歸屬一個(gè)教師的關(guān)系。已選人數(shù)這個(gè)字段是冗余字段可以由選題記錄統(tǒng)計(jì)得到但保留它可以在列表頁快速顯示剩余名額避免每次都匯總計(jì)算。這個(gè)冗余是經(jīng)過權(quán)衡的數(shù)據(jù)一致性靠事務(wù)保證。第三張是選題記錄表。這條表是整個(gè)業(yè)務(wù)的核心字段包括記錄ID、學(xué)生ID、課題ID、狀態(tài)待審核/已通過/已駁回/已撤銷、提交時(shí)間、審核時(shí)間、審核意見、審核教師ID。每條記錄代表某位學(xué)生某一次選題申請(qǐng)同一個(gè)學(xué)生對(duì)同一個(gè)課題可以有歷史記錄比如被駁回后再選但同一時(shí)刻只能存在一條有效記錄。除了這三張主表還有一張操作日志表記錄關(guān)鍵操作的行為人、時(shí)間、操作類型和操作詳情。它不是業(yè)務(wù)必需但一旦出現(xiàn)糾紛就是鐵證強(qiáng)烈建議保留。5.2 唯一索引與事務(wù)的配合使用表結(jié)構(gòu)設(shè)計(jì)里最關(guān)鍵的約束不在字段類型而在索引和事務(wù)。學(xué)生一人一題的約束我采用前面提到的學(xué)生當(dāng)前選題表方案這張表只有兩個(gè)核心字段學(xué)生ID主鍵、當(dāng)前選題記錄ID外鍵關(guān)聯(lián)選題記錄表。每個(gè)學(xué)生最多一行從數(shù)據(jù)結(jié)構(gòu)上就杜絕了一個(gè)學(xué)生同時(shí)擁有兩個(gè)有效選題的可能。課程表的名額控制則依賴事務(wù)和行鎖。我曾在一開始只用先查詢?cè)俑碌倪壿媽?shí)現(xiàn)名額扣減結(jié)果在高并發(fā)下超賣了三次。后來改成在事務(wù)里先SELECT ... FOR UPDATE鎖定課題行再更新已選人數(shù)問題才徹底解決。這里還想談一個(gè)設(shè)計(jì)取舍是否使用外鍵約束。這個(gè)項(xiàng)目里我保留了邏輯外鍵但沒有在表上建物理外鍵原因有二物理外鍵會(huì)增加刪除數(shù)據(jù)的成本調(diào)試數(shù)據(jù)時(shí)很麻煩很多團(tuán)隊(duì)在數(shù)據(jù)量上來后會(huì)改用分庫分表物理外鍵會(huì)變成阻礙。用邏輯外鍵配合Service層校驗(yàn)既保證業(yè)務(wù)正確性又給后期留了靈活度。對(duì)于學(xué)習(xí)項(xiàng)目你甚至可以建上物理外鍵看到數(shù)據(jù)庫自動(dòng)拒絕非法關(guān)聯(lián)理解會(huì)更直觀。5.3 演示數(shù)據(jù)與真實(shí)數(shù)據(jù)的處理源碼包里通常附帶topic_manage.sql初始化腳本里面除了建表語句還包含一批演示數(shù)據(jù)一個(gè)管理員賬號(hào)、三五個(gè)教師賬號(hào)、二十個(gè)學(xué)生賬號(hào)、每個(gè)教師幾個(gè)到十幾個(gè)課題。這些數(shù)據(jù)的用途是讓你跑起來就能看到效果不用從零開始造數(shù)。但要注意演示數(shù)據(jù)千萬別直接用在真實(shí)環(huán)境。我在實(shí)際部署時(shí)遇到過有人忘了改初始密碼被學(xué)生猜中管理員密碼的尷尬情況。所以拿到源碼后第一件事應(yīng)該是登錄管理員賬號(hào)修改默認(rèn)密碼或者直接刪除演示賬號(hào)通過管理員的批量導(dǎo)入功能重新錄入真實(shí)師生數(shù)據(jù)。批量導(dǎo)入功能我實(shí)現(xiàn)的是Excel模板上傳后端用EasyExcel解析逐行校驗(yàn)后插入錯(cuò)誤行會(huì)返回具體報(bào)錯(cuò)原因比如學(xué)號(hào)重復(fù)手機(jī)號(hào)格式錯(cuò)誤。6. 拿到源碼后的一小時(shí)本地運(yùn)行全流程實(shí)操記錄標(biāo)題說可直接運(yùn)行這句話不能白說。我把從零開始跑通這套系統(tǒng)的最短路徑完整記錄一下按照這個(gè)順序操作預(yù)計(jì)一個(gè)小時(shí)以內(nèi)可以讓前后端同時(shí)運(yùn)行起來。6.1 環(huán)境準(zhǔn)備JDK、Node、MySQL版本搭配后端要求JDK 1.8及以上推薦JDK 1.8或JDK 11不要直接上JDK 21某些舊版本的依賴可能不兼容。Maven建議3.6以上。前端要求Node.js 16或更高版本建議用LTS版本。MySQL推薦5.7或8.0源碼的初始化腳本兼容這兩個(gè)版本但連接配置略有差異后面說。先把本機(jī)已有環(huán)境檢查一遍。命令行里分別執(zhí)行java -version、mvn -v、node -v、npm -v、mysql --version確認(rèn)都存在且版本達(dá)標(biāo)。環(huán)境不齊的話按對(duì)應(yīng)官網(wǎng)下載安裝即可這個(gè)環(huán)節(jié)最花時(shí)間的是下載安裝本身很快。數(shù)據(jù)庫方面啟動(dòng)MySQL服務(wù)后用客戶端工具Navicat、DataGrip、命令行都行執(zhí)行初始化腳本。腳本文件名一般是topic_manage.sql里面自動(dòng)包含建庫語句CREATE DATABASE IF NOT EXISTS topic_manage你只需要選擇執(zhí)行腳本或直接source導(dǎo)入庫和表都會(huì)自動(dòng)創(chuàng)建好。導(dǎo)入完成后驗(yàn)證一下USE topic_manage; SHOW TABLES;看到用戶表、課題表、選題記錄表等就說明成功了。6.2 導(dǎo)入數(shù)據(jù)庫與修改后端配置數(shù)據(jù)庫導(dǎo)入成功后打開后端源碼目錄找到src/main/resources/application.yml。這里面需要修改的核心配置有三個(gè)數(shù)據(jù)庫地址、用戶名、密碼。默認(rèn)為jdbc:mysql://localhost:3306/topic_manage、用戶root、密碼123456。如果你的MySQL密碼不是這個(gè)必須修改否則啟動(dòng)時(shí)會(huì)在連接數(shù)據(jù)庫環(huán)節(jié)直接報(bào)錯(cuò)。這里有一個(gè)MySQL 8.0專屬的坑。8.0默認(rèn)的認(rèn)證插件是caching_sha2_password老版本的驅(qū)動(dòng)連不上報(bào)錯(cuò)信息看起來像Public Key Retrieval is not allowed。解決方法是在JDBC連接串上追加參數(shù)allowPublicKeyRetrievaltrueuseSSLfalseserverTimezoneAsia/Shanghai。另外5.7版本不需要allowPublicKeyRetrieval這個(gè)參數(shù)所以初始化腳本和配置文件最好和你的MySQL版本對(duì)應(yīng)。如果啟動(dòng)時(shí)報(bào)時(shí)區(qū)相關(guān)的錯(cuò)誤十有八九是serverTimezone沒配或配錯(cuò)了。修改完成后在源碼根目錄執(zhí)行mvn spring-boot:run或者用IDE打開項(xiàng)目直接運(yùn)行主類?？吹絊pring Boot的啟動(dòng)日志刷完最后一行是Started ... in xx seconds說明后端啟動(dòng)成功默認(rèn)端口8080。這時(shí)可以先用瀏覽器訪問http://localhost:8080/api/health之類的健康檢查接口或者直接開始啟動(dòng)前端。6.3 前端啟動(dòng)與前后端聯(lián)調(diào)驗(yàn)證進(jìn)入前端源碼目錄這個(gè)目錄下應(yīng)該有一個(gè)package.json文件。執(zhí)行npm install安裝依賴這一步在網(wǎng)速一般的情況下可能需要幾分鐘到十幾分鐘。安裝完成后執(zhí)行npm run serve開發(fā)服務(wù)器啟動(dòng)默認(rèn)端口通常為8081。控制臺(tái)會(huì)打印訪問地址瀏覽器打開即可看到登錄頁面。為什么開發(fā)服務(wù)器的默認(rèn)端口不是8080因?yàn)楹蠖苏剂?080。Vue CLI的默認(rèn)端口是8080但項(xiàng)目配置里改成了8081并且設(shè)置了代理所有/api請(qǐng)求轉(zhuǎn)發(fā)到http://localhost:8080。如果你發(fā)現(xiàn)后端端口改了這里也要對(duì)應(yīng)修改代理目標(biāo)否則前端請(qǐng)求會(huì)全部失敗表現(xiàn)為接口報(bào)錯(cuò)、頁面沒有數(shù)據(jù)。啟動(dòng)完成后用初始化腳本里的演示賬號(hào)登錄。管理員賬號(hào)登錄后應(yīng)該能看到用戶管理和數(shù)據(jù)統(tǒng)計(jì)頁面教師賬號(hào)能看到課題管理頁面學(xué)生賬號(hào)能看到課題列表。分別測(cè)試一遍完整的流程管理員導(dǎo)入學(xué)生、教師發(fā)布課題、學(xué)生選題、教師審核通過這樣整個(gè)系統(tǒng)就跑通了。實(shí)測(cè)下來最順暢的驗(yàn)證順序是先以管理員身份創(chuàng)建兩個(gè)學(xué)生再用教師身份發(fā)布一個(gè)課題并設(shè)置人數(shù)上限為1然后兩個(gè)學(xué)生分別登錄嘗試選同一個(gè)課題第二個(gè)學(xué)生應(yīng)當(dāng)收到名額不足的提示。這樣一測(cè)核心業(yè)務(wù)邏輯是否正常就一目了然了。7. 運(yùn)行期常見故障與排查思路我踩過的那些坑最后這部分跟大家分享一些實(shí)際運(yùn)行中大概率會(huì)遇到的故障和排查方法。這些問題我在開發(fā)調(diào)試階段幾乎都踩過一遍整理成清單能幫你少走不少彎路。7.1 跨域問題的完整排查鏈路前端啟動(dòng)后頁面能打開但列表數(shù)據(jù)加載不出來打開瀏覽器開發(fā)者工具Console里報(bào)錯(cuò)類似CORS policy: No Access-Control-Allow-Origin header或者Network里看到請(qǐng)求狀態(tài)是(failed)net::ERR_FAILED。這基本就是跨域問題。排查思路分三步。第一步確認(rèn)前端代理是否生效?？磛ue.config.js里的devServer.proxy配置確認(rèn)/api前綴和代理目標(biāo)地址正確。如果你修改過后端端口這里的target也要同步修改。第二步確認(rèn)代理是否把請(qǐng)求真的轉(zhuǎn)發(fā)到了后端?？春蠖丝刂婆_(tái)有沒有打印出對(duì)應(yīng)的請(qǐng)求日志如果后端完全沒反應(yīng)說明代理沒配上或者前端請(qǐng)求路徑本身就錯(cuò)了。第三步如果你繞開代理直接走后端CORS那么檢查后端是否配置了CorsFilter或CrossOrigin并且allowedOrigins里是否包含前端地址。我看過很多初學(xué)同學(xué)在跨域上卡了一兩天其實(shí)大多數(shù)時(shí)候都是代理配置里少寫了一個(gè)changeOrigin: true或者后端CORS配置里allowedOrigins寫成了*導(dǎo)致和攜帶Token沖突。這兩個(gè)點(diǎn)優(yōu)先檢查。7.2 數(shù)據(jù)庫連接中的編碼與時(shí)區(qū)坑數(shù)據(jù)庫問題往往比業(yè)務(wù)代碼問題更隱蔽。最常見的兩個(gè)癥狀第一個(gè)是中文亂碼。頁面或后臺(tái)能看到中文課題名稱變成???. 原因多半是數(shù)據(jù)庫或表的字符集不是utf8mb4。在MySQL 8.0里建庫時(shí)可以顯式指定CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci初始化腳本里其實(shí)已經(jīng)帶上了但如果你手動(dòng)建庫很容易用默認(rèn)的latin1。檢查方法很簡單SHOW CREATE DATABASE topic_manage;看字符集是不是utf8mb4。如果不是改庫字符集或重建。第二個(gè)是時(shí)區(qū)導(dǎo)致的日期錯(cuò)亂。日期字段會(huì)比本地時(shí)間晚8小時(shí)或者直接插入失敗。根源在于JDBC連接串里缺了serverTimezoneAsia/Shanghai。有些同學(xué)會(huì)用serverTimezoneGMT%2B8這也可以但推薦直接用數(shù)據(jù)庫名時(shí)區(qū)直觀且不容易錯(cuò)。7.3 修改配置后最常見的連鎖反應(yīng)我最后聊一個(gè)更隱蔽的坑你以為只改了一個(gè)配置結(jié)果引發(fā)了另一個(gè)地方的問題。典型場景是前端端口被占用你把前端開發(fā)服務(wù)器端口從8081改成了8082結(jié)果頁面能打開了接口卻全部報(bào)錯(cuò)。為什么因?yàn)関ue.config.js里的代理配置寫死了target: http://localhost:8080這沒問題但你忘了代理配置中有一行pathRewrite或其他設(shè)置或者你把后端端口也一起改了導(dǎo)致代理目標(biāo)失效。修改任何端口、地址類配置前先全局搜索一下有沒有其他地方引用了舊值這個(gè)習(xí)慣可以省掉大量排查時(shí)間。還有一個(gè)場景是MySQL從電腦A遷移到電腦B數(shù)據(jù)文件直接拷貝過去但B機(jī)器的MySQL版本和A不一致導(dǎo)致驅(qū)動(dòng)認(rèn)證方式不匹配。如果啟動(dòng)時(shí)報(bào)Unable to load authentication plugin caching_sha2_password優(yōu)先檢查MySQL版本是否8.0再檢查驅(qū)動(dòng)版本是否8.x驅(qū)動(dòng)和數(shù)據(jù)庫版本對(duì)不上是這類問題最常見的根因。最后一個(gè)建議每一次修改配置后后端要重啟前端如果配置了熱更新可能會(huì)有延遲必要時(shí)手動(dòng)重啟前端開發(fā)服務(wù)器。很多改了沒生效的案例實(shí)際上只是進(jìn)程沒重啟并不是配置寫錯(cuò)了。這套系統(tǒng)從業(yè)務(wù)梳理到技術(shù)實(shí)現(xiàn)再到調(diào)試上線我前前后后跑了三輪迭代。最深的體會(huì)是課程設(shè)計(jì)選題管理這種看似小的系統(tǒng)恰恰是鍛煉完整Web開發(fā)流程的好項(xiàng)目——有明確的多角色權(quán)限、有狀態(tài)流轉(zhuǎn)、有并發(fā)沖突、有前后端協(xié)作麻雀雖小五臟俱全。如果你拿到源碼準(zhǔn)備自己改造二次開發(fā)建議優(yōu)先在選題沖突處理和數(shù)據(jù)統(tǒng)計(jì)報(bào)表兩個(gè)方向上做增強(qiáng)前者是業(yè)務(wù)核心后者是真實(shí)使用中最高頻的需求。我個(gè)人建議的擴(kuò)展點(diǎn)是在現(xiàn)有選題記錄表基礎(chǔ)上增加一個(gè)選題志愿機(jī)制允許學(xué)生按優(yōu)先級(jí)提交多個(gè)志愿由系統(tǒng)按志愿順序自動(dòng)分配——這塊做深了就是選課系統(tǒng)的雛形了。