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