選課這事兒每年開學(xué)都是教務(wù)老師最頭疼的一周。直到今天仍然有大量高校在用“先到先得 人工補退選”的方式處理學(xué)生選課服務(wù)器一開機就被沖垮后臺導(dǎo)出名單能卡半小時。所以每年畢業(yè)設(shè)計季“Spring Boot 學(xué)生選課管理系統(tǒng)”都會出現(xiàn)在計算機專業(yè)的題目清單里。這篇東西不是給你抄代碼的而是把這類項目的設(shè)計邏輯、開發(fā)順序、答辯時會問到的坑全部拆開講清楚。如果你正準備拿這個題目做畢設(shè)或者在工作中要接手類似的教務(wù)系統(tǒng)可以先花半小時把這篇讀完。它講的是如何把一個看起來“只是增刪改查”的選課系統(tǒng)做成一個能應(yīng)付并發(fā)搶課、權(quán)限隔離、事務(wù)一致性追問的完整項目同時回答“為什么用 Spring Boot”“為什么這么設(shè)計表”“為什么這里要加緩存”這些老師最愛問的問題。1. 選課系統(tǒng)這類畢設(shè)題目的真實現(xiàn)狀每年都有大量學(xué)生選“學(xué)生選課管理系統(tǒng)”這個題目但很多人做到一半才發(fā)現(xiàn)自己只是把教材里的用戶表、課程表、選課表搬出來做了三個 CRUD 頁面。等到寫論文的時候都不知道“創(chuàng)新點”三個字該怎么下筆。事實上選課系統(tǒng)的復(fù)雜度被嚴重低估了它不是“簡單管理系統(tǒng)”而是一個典型的、帶有并發(fā)寫操作和復(fù)雜業(yè)務(wù)規(guī)則的中小型系統(tǒng)。1.1 為什么“選課”比“圖書管理”更適合做畢設(shè)同樣是管理系統(tǒng)圖書管理只需要關(guān)心“書的庫存”核心操作是借書、還書業(yè)務(wù)規(guī)則少系統(tǒng)設(shè)計上沒有太多可以深挖的地方。選課系統(tǒng)則完全不同它天然自帶幾個值得研究的技術(shù)點并發(fā)選課熱門課程同一秒可能被幾百人同時搶數(shù)據(jù)庫層面會競爭同一行記錄。業(yè)務(wù)約束學(xué)生選課不能超學(xué)分上限不能跨年級選課不能和已選課程時間沖突。狀態(tài)流轉(zhuǎn)選課要經(jīng)歷“預(yù)選、抽簽/搶課、退課、補選、課程關(guān)閉”多個狀態(tài)數(shù)據(jù)不只是插入和刪除。權(quán)限角色學(xué)生、教師、教務(wù)管理員各有一套操作流程需要做RBAC權(quán)限控制。這些點恰好對應(yīng) Spring Boot 項目里最常被考察的幾個方向Spring Data JPA/MyBatis 的數(shù)據(jù)訪問、Spring Security/自研攔截器的權(quán)限控制、Redis 緩存減輕數(shù)據(jù)庫壓力、事務(wù)管理保證選課數(shù)據(jù)不產(chǎn)生超選。1.2 大多數(shù)人做這個題目時會踩的坑第一坑數(shù)據(jù)庫表設(shè)計照搬“用戶-角色-菜單”三張表。有些同學(xué)一開始就堆了七八張表角色表、權(quán)限表、菜單表一應(yīng)俱全結(jié)果做出來發(fā)現(xiàn)登錄以后根本沒有細粒度權(quán)限控制的需求反而把登錄邏輯搞得特別復(fù)雜。更合理的做法是先用“學(xué)生表、教師表、課程表、選課表”四張核心表跑通主流程再進行權(quán)限設(shè)計權(quán)限表是逐步演進來的。第二坑選課邏輯寫在 Service 里但是沒有加事務(wù)。一個學(xué)生選兩門課第一門插入成功第二門因為時間沖突拋異常結(jié)果第一門課也寫入進去了。這就是典型的“缺少事務(wù)控制”。第三坑只做了“選課”和“退課”忽略了“課程容量不足”這個最現(xiàn)實的問題。熱門課剩余容量為 0 時前端還允許提交請求后端也沒做校驗最后庫里出現(xiàn)容量為負數(shù)的臟數(shù)據(jù)。2. 解構(gòu)標題里的三個關(guān)鍵詞系統(tǒng)、框架、設(shè)計與實現(xiàn)標題里反復(fù)出現(xiàn)“Spring Boot”“學(xué)生選課管理系統(tǒng)”“設(shè)計與實現(xiàn)”這三個詞其實對應(yīng)著論文和系統(tǒng)里三個不同的關(guān)注層次。把它們拆開理解你會發(fā)現(xiàn)整個項目的脈絡(luò)一下子就清楚了。2.1 “系統(tǒng)”不是一個頁面集合而是一組流程閉環(huán)如果你在開題報告里寫“本系統(tǒng)包括登錄、選課、退課、課程管理、成績錄入等模塊”那只是功能列表不是系統(tǒng)設(shè)計。真正的系統(tǒng)設(shè)計要畫業(yè)務(wù)流程學(xué)生登錄后——查看培養(yǎng)方案開放的可選課程——提交選課請求——判斷學(xué)分是否超限——判斷是否沖突——扣減課程容量——生成選課記錄——教師端查看選課名單——教務(wù)端處理退課審核。每一步都要有對應(yīng)的數(shù)據(jù)變動和異常處理。我見過不少同學(xué)的論文里數(shù)據(jù)流圖畫的是一條直線“學(xué)生選課直接寫入選課表”這顯然是沒在真實系統(tǒng)里跑通過流程。選課中間至少還要經(jīng)過“容量校驗”和“沖突檢測”兩個環(huán)節(jié)否則系統(tǒng)做出來也會被老師一句話問倒“你選課的時候如果兩門課時間沖突了怎么辦”2.2 “Spring Boot”的選擇為什么在這個題目里幾乎是標配Spring Boot 在這個題目里勝出不是因為它的技術(shù)棧“顯得高級”而是三個非常務(wù)實的原因。第一啟動和配置成本極低。傳統(tǒng) Spring 項目要寫一堆 XML 配置Spring Boot 用自動配置把開發(fā)者的注意力集中在業(yè)務(wù)代碼上。對畢設(shè)來說時間有限這一點最實際能讓你把精力留給真正的業(yè)務(wù)邏輯而不是配置調(diào)試。第二生態(tài)成熟。Spring Data JPA 或 MyBatis 都能和它無縫集成Spring Security 可以用于權(quán)限控制Redis 的 starter 包可以讓緩存落地非常平滑。答辯老師聽到你用到了 Spring Security 做權(quán)限至少會認可你了解企業(yè)級開發(fā)的常見套路。第三內(nèi)置 Tomcat。打包成一個 jar 直接運行寫論文的時候部署章節(jié)很好交代演示系統(tǒng)也不需要在評委電腦上裝一堆中間件。這里也順便回答一個常見疑問到底用 JPA 還是 MyBatis我的建議是如果你對 SQL 比較熟選 MyBatis配置 mapper 文件或注解 SQL 都很直觀也方便在論文里展示復(fù)雜查詢語句。如果你希望少寫點代碼選 Spring Data JPA簡單 CRUD 可以省不少時間但是多表關(guān)聯(lián)查詢會相對需要花時間學(xué)一學(xué)。我這邊更推薦 MyBatis因為在“選課沖突檢測”這類場景里你往往需要寫比較復(fù)雜的 SQL 或使用數(shù)據(jù)庫鎖MyBatis 的 SQL 控制力更直接。2.3 “設(shè)計與實現(xiàn)”在論文里要回答什么先說“設(shè)計”。設(shè)計不等于“我用了三層架構(gòu)”。三層架構(gòu)只是代碼組織方式你要設(shè)計的是數(shù)據(jù)結(jié)構(gòu)、業(yè)務(wù)流程、接口規(guī)范和異常處理策略。課程表的唯一約束怎么設(shè)計選課表的聯(lián)合唯一索引是什么退課操作是物理刪除還是狀態(tài)變更這些都是設(shè)計內(nèi)容。再說“實現(xiàn)”。實現(xiàn)也不等于貼代碼。你要能夠說清楚每個核心接口的請求參數(shù)、響應(yīng)結(jié)果、異常情況以及關(guān)鍵代碼的時序邏輯。比如選課接口Spring Boot 代碼執(zhí)行順序是接收 POST 請求解析 studentId 和 courseId查學(xué)生當(dāng)前已選學(xué)分校驗是否超限查課程信息校驗是否可選、是否已選過、容量是否足夠進入事務(wù)更新課程剩余容量插入選課記錄返回成功或拋出業(yè)務(wù)異常。把這些按步驟寫清楚論文的“詳細設(shè)計”一章就有了真正的骨架。3. 系統(tǒng)模塊到底怎么劃先理清角色再談功能很多初學(xué)者習(xí)慣把“功能模塊圖”畫成一個巨大的方框里面塞下十幾個小方框這看起來內(nèi)容多實際毫無重點。選課系統(tǒng)的模塊劃分最好的切入點是角色權(quán)限因為不同角色對系統(tǒng)的訴求完全不同。3.1 三個角色的核心訴求學(xué)生角色的核心操作是瀏覽課程、選課、退課、查看個人課表。這個視角的系統(tǒng)要解決的問題是“怎么快速找到我能選、我想選的課”所以課程列表頁一定要支持按課程名稱、學(xué)分、上課時間篩選而不是把所有課程一次性全查出來。教師角色的核心操作是查看自己開設(shè)課程的學(xué)生名單有時還要錄入成績。這個視角的重點在于“開課管理”和“成績管理”教師不需要也不應(yīng)該看到其他教師的課程數(shù)據(jù)。教務(wù)管理員的核心操作是基礎(chǔ)數(shù)據(jù)維護維護學(xué)生信息、維護教師信息、維護課程信息、設(shè)置選課時間段、處理個別學(xué)生的補退選申請。3.2 權(quán)限控制的最小落地方式權(quán)限這塊不用一上來就上 Spring Security JWT那樣學(xué)習(xí)成本太高而且畢設(shè)系統(tǒng)一般是單體應(yīng)用前后端不分離或者簡單的模板渲染都能滿足需求。我建議的做法是數(shù)據(jù)庫加一個 role 字段值可以是 STUDENT、TEACHER、ADMIN登錄接口校驗用戶名密碼后把用戶 ID、角色存入 Session寫一個攔截器HandlerInterceptor攔截所有 /api/** 請求校驗 Session 中是否有登錄用戶再通過注解或路徑規(guī)則判斷角色是否匹配對于選課、退課等敏感操作Service 層再做一次數(shù)據(jù)歸屬校驗比如學(xué)生只能操作自己的選課記錄。這樣既控制了權(quán)限又能在答辯時解釋 RBAC 的簡化模型還能在小論文里對比“基于 Session 和基于 JWT 的兩種方案差異”。如果你非要上 Spring Security也可以但一定要能講清楚 Spring Security 的過濾器鏈原理否則老師一句“你這個 Spring Security 配置的過濾器順序會不會有問題”就容易卡殼。3.3 核心表結(jié)構(gòu)設(shè)計與字段說明選課系統(tǒng)最少需要五張核心數(shù)據(jù)表這也是最穩(wěn)妥的起步方案。下面把每張表的用途和關(guān)鍵字段列出來建表的時候可以直接參考表名關(guān)鍵字段設(shè)計說明studentid, student_no, name, password, major, grade, max_credit學(xué)生基礎(chǔ)信息max_credit 表示每學(xué)期學(xué)分上限默認20teacherid, teacher_no, name, password, department教師基礎(chǔ)信息courseid, course_code, name, credit, teacher_id, capacity, selected_count, class_time, statusstatus 控制是否開放選課selected_count 表示當(dāng)前已選人數(shù)selectionid, student_id, course_id, select_time, status聯(lián)合唯一索引 (student_id, course_id)防止重復(fù)選課semesterid, name, is_current用學(xué)期表隔離不同學(xué)期的選課數(shù)據(jù)不要把所有學(xué)期課程混在一張表里課程表里的 selected_count 和課程容量 capacity 是關(guān)鍵設(shè)計點。每次選課成功時需要既插入一條 selection 記錄又把 course.selected_count 加 1。這兩個動作必須放在同一個事務(wù)里。更嚴格的做法是在選課 SQL 里加“容量樂觀鎖”比如UPDATE course SET selected_count selected_count 1 WHERE id #{courseId} AND selected_count capacity;這行 SQL 返回的影響行數(shù)如果為 0說明課程已滿選課失敗。這個寫法比“先查容量再更新”安全得多也是答辯時一個很好的加分項因為它直接在數(shù)據(jù)庫層面解決了超選問題。4. 從空工程到可演示系統(tǒng)我建議的落地順序很多同學(xué)拿到題目喜歡從登錄注冊開始寫寫完登錄寫權(quán)限寫完權(quán)限再寫課程管理結(jié)果是課程管理還沒寫完開題時吹的“選課系統(tǒng)”影子都沒見到老師催中期進度時非常被動。我自己做項目比較習(xí)慣“縱向切片”的開發(fā)方式也就是先打通一條完整的主流程再橫向擴展其他功能。4.1 第一階段先打通“登錄-看課-選課-查課表”全鏈路先用 Spring Initializr 創(chuàng)建一個最簡單的 Spring Boot 工程引入 Spring Web、MyBatis、MySQL Driver。這個階段不需要做多角色權(quán)限直接用一個 student 表完成登錄。建好數(shù)據(jù)庫和五張核心表插入幾條測試數(shù)據(jù)登錄接口根據(jù)用戶名和密碼查詢 student 表密碼用 MD5 加密存儲實際項目要加鹽畢設(shè)用加密過的 MD5 加一個固定鹽值勉強夠解釋課程列表接口查詢所有可選課程返回 JSON 列表選課接口先做最基本的插入 selection 記錄然后再逐步加事務(wù)、容量校驗課表查詢接口按學(xué)生 ID 查詢選課記錄并關(guān)聯(lián)課程信息。等這一條鏈路跑通了項目就有了“骨架”后續(xù)加功能都是往骨架上添肉。這種開發(fā)方式最大的好處是任何時候停下來系統(tǒng)都有得演示不會出現(xiàn)“功能做了三個沒有一個能跑通”的尷尬局面。4.2 第二階段加入教師端和教務(wù)端主流程跑通之后再拆角色。教師端主要做兩件事查看自己課程下的學(xué)生選課名單、錄入成績。這時候需要在 teacher 表和 course 表之間建立關(guān)聯(lián)查詢時用 teacher_id 做條件確保教師只能看到自己的課程。教務(wù)端要做的第一件事是課程維護包括新增課程、修改容量、開放選課狀態(tài)切換。這個階段最需要注意的是“菜單與權(quán)限不同步”的問題。有些同學(xué)前端做了一個菜單欄把所有端的功能都渲染出來了學(xué)生登錄后點教師菜單后端雖然攔截了但前端體驗很差。正確做法是登錄接口把角色返回給前端前端根據(jù)角色動態(tài)渲染菜單。4.3 第三階段在打磨細節(jié)中提升答辯質(zhì)量到了這個階段系統(tǒng)已經(jīng)能用但這個時候恰恰是拉開差距的時候。很多普通項目只能演示正常流程你的系統(tǒng)可以演示以下這些細節(jié)重復(fù)選課提示同一學(xué)生重復(fù)提交同一門課返回明確錯誤信息“你已選過該課程”學(xué)分超限校驗選擇課程后已選學(xué)分總和超過上限給出提示并阻止課程時間沖突檢測課程表里有 class_time 字段選課時循環(huán)比較已選課程發(fā)現(xiàn)時間重疊就報錯容量不足提示熱門課程剩余 0 時前端按鈕置灰后端再次校驗。每個細節(jié)都對應(yīng)論文里的一小段“異常情況處理與分析”加起來內(nèi)容量就足夠撐起核心章節(jié)了。5. 并發(fā)搶課、緩存穿透與事務(wù)一致性被追問最多的技術(shù)點選課系統(tǒng)的“技術(shù)含金量”很大程度上體現(xiàn)在高并發(fā)場景。答辯老師只要聽說“選課”大概率會問一句“如果幾百人同時搶一門只有 50 個名額的課你的系統(tǒng)會不會超賣”這個問題回答得好項目檔次能明顯不一樣。5.1 為什么不能只靠“先查再更新”最簡單的選課邏輯是Course course courseMapper.selectById(courseId); if (course.getSelectedCount() course.getCapacity()) { courseMapper.increaseSelectedCount(courseId); selectionMapper.insert(selection); return 選課成功; }這段代碼看起來沒問題實際上在并發(fā)環(huán)境下問題很大。兩個請求同時查出selectedCount49都滿足小于容量 50 的條件然后兩個請求都執(zhí)行了increaseSelectedCount最終 selectedCount 變成 51容量被突破。這就是經(jīng)典的并發(fā)超賣問題。解決辦法就是我前面提到的那條“帶條件的 UPDATE”UPDATE course SET selected_count selected_count 1 WHERE id #{courseId} AND selected_count capacity;同時選課記錄插入要在同一個事務(wù)里并且啟用適當(dāng)?shù)臄?shù)據(jù)庫隔離級別。如果你用了 Redis也可以把課程剩余容量緩存到 Redis 里選課前用 Lua 腳本做扣減再同步到數(shù)據(jù)庫但這對畢設(shè)來說有點重了。這里更推薦把“數(shù)據(jù)庫樂觀更新”作為主方案把 Redis 方案作為論文里的“優(yōu)化與展望”來寫。5.2 緩存穿透課程列表接口的隱形瓶頸選課高峰期課程列表頁會被反復(fù)請求。如果不加緩存每次刷新都打到數(shù)據(jù)庫課程表數(shù)據(jù)量一大數(shù)據(jù)庫 IO 就會成為瓶頸。最常見的做法是使用 Redis 緩存熱門課程列表String cacheKey course:list:hot; ListCourse hotCourses redisTemplate.opsForValue().get(cacheKey); if (hotCourses null) { // 去數(shù)據(jù)庫查然后寫入緩存設(shè)置過期時間 }這里容易忽略的是緩存穿透問題如果某個課程 ID 根本不存在請求仍然會每次都穿過緩存去查數(shù)據(jù)庫數(shù)據(jù)庫壓力依然很大。解決方式也很簡單——空結(jié)果也緩存幾分鐘或者用布隆過濾器攔截不存在的 ID。畢設(shè)系統(tǒng)里用“空值緩存”就夠了布隆過濾器可以作為論文里的進階點提一句。5.3 事務(wù)回滾與異常處理的配合選課失敗有很多種原因但 Service 層代碼如果不加事務(wù)可能會留下臟數(shù)據(jù)。正確做法是在選課 Service 方法上標注Transactional然后在業(yè)務(wù)校驗失敗時拋出RuntimeException或自定義業(yè)務(wù)異常讓事務(wù)回滾。有一個細節(jié)容易被忽略如果在事務(wù)方法內(nèi)部 try-catch 吞掉了異常事務(wù)是不會回滾的。比如Transactional public Result selectCourse(Long studentId, Long courseId) { try { // 校驗 更新 插入 } catch (Exception e) { return Result.error(選課失敗); } }這種寫法看似友好實際事務(wù)邊界已經(jīng)失效數(shù)據(jù)可能出現(xiàn)不一致。正確寫法是把 try-catch 放在 Controller 層做全局異常處理Service 層只負責(zé)往外拋異常。Spring Boot 里可以用RestControllerAdvice統(tǒng)一捕獲業(yè)務(wù)異常返回 JSON 提示這樣代碼既干凈事務(wù)也安全。如果答辯的時候能自己主動講出這個點老師基本不會再追問“事務(wù)失效為什么沒處理”。6. 真實答辯中必定被追問的四個問題系統(tǒng)做完進入答辯環(huán)節(jié)很多同學(xué)最擔(dān)心老師問“框架源碼”“算法”之類的深問題。實際上對于選課系統(tǒng)這種題目老師更在意的還是“你自己有沒有真正理解系統(tǒng)”下面四個問題出現(xiàn)的頻率非常高提前準備好比臨時背書強得多。6.1 你選課的時候怎么處理“超選”情況這個問題千萬不要只說“用事務(wù)”要把事務(wù)和并發(fā)控制結(jié)合起來說。可以參考這條回答思路“選課的核心操作是一句帶條件的更新 SQLUPDATE course SET selected_count selected_count 1 WHERE id ? AND selected_count capacity這條 SQL 的原子性由數(shù)據(jù)庫行鎖保證。當(dāng)多個請求同時到達時只有一個請求能成功執(zhí)行更新語句影響行數(shù)是 1其余請求影響行數(shù)為 0判定為容量已滿。同時選課記錄的插入和課程容量的更新放在同一個事務(wù)里如果插入失敗整個事務(wù)回滾容量不會被錯誤占用。”這條回答涵蓋了并發(fā)控制、事務(wù)邊界、數(shù)據(jù)庫鎖三個知識點已經(jīng)超過多數(shù)畢設(shè)項目的深度。6.2 課程表容量字段和選課記錄數(shù)會不會不一致老師說這句話是在暗示你可能只改了其中一個表?；卮鹚悸肥敲看芜x課成功先更新 course 表容量再插入 selection 記錄兩者在同一個事務(wù)里。如果要進一步保證一致性可以在 selection 表上建觸發(fā)器或者定期跑一個對賬定時任務(wù)將課程表的 selected_count 與 selection 表的實際記錄數(shù)比對。定時任務(wù)可以用 Spring 自帶的Scheduled注解實現(xiàn)這也是一個小加分項。6.3 學(xué)生退課后學(xué)分和容量怎么釋放退課是選課的逆操作仍然要放在事務(wù)里刪除或標記 selection 記錄把 course 表的 selected_count 減 1。這里有個業(yè)務(wù)選擇問題——退課是物理刪除還是邏輯刪除。我的建議是使用邏輯刪除加一個 status 字段標記“已退課”這樣學(xué)生和老師都能看到歷史操作記錄教務(wù)端也可以做審計論文里不用花太多篇幅解釋“為什么刪不掉數(shù)據(jù)”。6.4 密碼你是怎么存儲的這問題幾乎是畢設(shè)必問千萬不要回答“明文存數(shù)據(jù)庫”。最低限度也要用 MD5 加固定鹽。稍微進階一點可以用 Spring Security 自帶的 BCryptPasswordEncoder這個做法既能保證安全又能在論文的技術(shù)選型里寫一句“使用 BCrypt 哈希算法對用戶密碼進行加密存儲”比空談“重視安全”有說服力得多。我在幫某高校的學(xué)弟排查選課人數(shù)統(tǒng)計不準的問題時發(fā)現(xiàn)他代碼里兩個 Service 方法各開了一個事務(wù)第一個方法更新課程容量提交后第二個方法插入選課記錄時才報錯導(dǎo)致容量被扣了但選課記錄沒生成。當(dāng)時我讓他把所有數(shù)據(jù)庫操作合并到一個事務(wù)方法里再把業(yè)務(wù)校驗全部前移問題立刻解決。很多時候不是代碼不會寫而是事務(wù)邊界沒劃清這類問題自己在測試階段又很難暴露因為單用戶操作根本看不出并發(fā)問題。如果你也在做類似項目建議測試階段至少開兩個瀏覽器窗口同時登錄兩個學(xué)生賬號用同一門課做容量臨界值測試能復(fù)現(xiàn)不少隱藏問題。