做畢設(shè)選課題的時候十個里有七八個都會盯著“XX管理系統(tǒng)”這個方向而“教師工作量管理系統(tǒng)”算是里面比較有代表性的一個。它要處理的數(shù)據(jù)不復(fù)雜但業(yè)務(wù)規(guī)則很細(xì)又天然適合用 Java 后端加 Web 前端的組合來實現(xiàn)。很多人一開始沖著 SpringBoot Vue MySQL MyBatis 這套完整技術(shù)棧去選它結(jié)果動手后發(fā)現(xiàn)真正的難點根本不在框架本身工作量怎么折算、審核狀態(tài)怎么流轉(zhuǎn)、統(tǒng)計報表怎么聚合這些業(yè)務(wù)設(shè)計才是最磨人的。這篇分享我就以自己實際做完一版“基于 SpringBoot Vue 的教師工作量管理系統(tǒng)”的經(jīng)歷為主線把從需求拆解、數(shù)據(jù)庫設(shè)計、后端接口實現(xiàn)到前端頁面聯(lián)調(diào)的完整思路和關(guān)鍵代碼細(xì)節(jié)都過一遍。無論你是準(zhǔn)備拿它當(dāng)畢業(yè)設(shè)計、課程設(shè)計還是單純想練手一套前后端分離的項目這篇文章都能幫你少走不少彎路。我不打算講太多虛的框架原理重點放在“哪些地方容易卡住”“哪個設(shè)計決策會影響后面開發(fā)”—這些才是在網(wǎng)上文案里最不好找的東西。1. 項目概述與需求拆解1.1 教師工作量管理系統(tǒng)到底在管什么很多人在設(shè)計這個系統(tǒng)之前容易把它想成“一個普通的增刪改查后臺”這是最大的誤區(qū)。教師工作量管理核心對象不是教師信息本身而是“工作量記錄”。這個記錄要牽扯到教師、學(xué)期、課程類型、授課班級、課時數(shù)、審核狀態(tài)、最終折算分值等一堆字段。比如某老師這學(xué)期給三個班上了《數(shù)據(jù)結(jié)構(gòu)》其中兩個班是理論課一個班是實驗課。系統(tǒng)要做的不只是把這六條記錄存進(jìn)去還要能按照“理論課 1 課時折 1 個工作量、實驗課 1 課時折 0.8 個工作量”這種規(guī)則自動算出這個老師這學(xué)期的總工作量。這還不算完工作量數(shù)據(jù)從提交到生效中間要過審核。普通教師填完提交之后教務(wù)秘書要能看見待審核的記錄審核通過之后數(shù)據(jù)才能進(jìn)入統(tǒng)計。如果審核不通過還要能駁回并填上駁回理由。有些高校甚至要求按教研室、學(xué)院、全校三級匯總還要支持按學(xué)期導(dǎo)出明細(xì)表。所以這個系統(tǒng)看著是管理系統(tǒng)實際上帶有很明顯的工作流和報表屬性。認(rèn)清這一點后面的技術(shù)設(shè)計思路才會正確數(shù)據(jù)庫表不能只設(shè)計教師表和課程表必須有一個能承載審核狀態(tài)和系數(shù)折算明細(xì)的核心表后端接口也不能只做 CRUD還要有狀態(tài)流轉(zhuǎn)校驗和聚合統(tǒng)計邏輯。1.2 技術(shù)棧為什么是 SpringBoot Vue MySQL MyBatis這套組合在高校項目中出現(xiàn)頻率極高不是沒有原因的。我分別說說每塊的不可替代性。后端用 SpringBoot核心價值是“低配置起步”。傳統(tǒng)的 SSM 項目要寫一大堆 XML 配置和 web.xml光是搭環(huán)境就可能消耗兩三天。SpringBoot 內(nèi)置了 Tomcat、自動裝配了常用組件寫一個 Controller 接口幾乎不需要額外配置。更重要的是SpringBoot 的生態(tài)里很容易集成 JWT 登錄、攔截器、全局異常處理、MyBatis 分頁插件這些都是管理系統(tǒng)最需要的基建設(shè)施。前端用 Vue核心價值是前后端分離帶來的開發(fā)效率。教師工作量管理系統(tǒng)涉及的頁面不少登錄頁、個人工作量填報頁、審核列表頁、統(tǒng)計報表頁、基礎(chǔ)數(shù)據(jù)管理頁用 Vue 組件化開發(fā)可以把每一塊拆成獨立組件頁面間通過路由跳轉(zhuǎn)數(shù)據(jù)狀態(tài)用統(tǒng)一的管理方式。相比傳統(tǒng)的 JSP 服務(wù)端渲染Vue 的響應(yīng)式綁定在處理“審核列表勾選多條批量通過”這種交互時要舒服太多。數(shù)據(jù)庫選 MySQL 是最穩(wěn)妥的選擇。工作量系統(tǒng)的核心操作是查詢和統(tǒng)計MySQL 的 SQL 聚合能力足夠而且網(wǎng)上資料最多出了問題容易搜到解決方案。如果你所在環(huán)境要求用 SQL Server或者想試試更現(xiàn)代的 PostgreSQL也不是不行但沒必要在畢設(shè)階段給自己增加切換數(shù)據(jù)庫的額外負(fù)擔(dān)。MyBatis 同樣是經(jīng)典選擇。我見過有人糾結(jié)要不要用 MyBatis-Plus 或者 Spring Data JPA。我的看法是MyBatis 原生寫 SQL 的方式最適合這種管理系統(tǒng)中“按動態(tài)條件拼裝查詢”“按學(xué)期分組聚合統(tǒng)計”的場景。動態(tài) SQL 和手寫 Mapper XML 的掌控力是 JPA 給不了的而 MyBatis-Plus 雖然自帶通用方法很方便但在自定義統(tǒng)計查詢上最終還是得回到 XML 里寫 SQL。所以“SpringBoot MyBatis”是穩(wěn)扎穩(wěn)打的組合沒有任何短板。2. 系統(tǒng)設(shè)計模塊劃分、角色權(quán)限與核心流程2.1 功能模塊全景整個系統(tǒng)我拆成了四個方面基礎(chǔ)數(shù)據(jù)管理、工作量業(yè)務(wù)、統(tǒng)計報表、系統(tǒng)管理?；A(chǔ)數(shù)據(jù)管理包含教師信息、課程信息、班級信息、學(xué)期信息的維護(hù)。教師信息一般跟用戶登錄賬號分開管理用戶表管賬號密碼教師表管姓名、教職工號、所屬教研室和職稱。課程信息則要維護(hù)課程名稱、課程類型、默認(rèn)課時系數(shù)。工作量業(yè)務(wù)模塊是核心包含三個子模塊工作量填報、工作量審核、工作量查詢。填報支持教師自己在線提交也支持管理員代錄審核支持單條通過、批量通過、駁回并填寫意見查詢支持按教師名、課程名、學(xué)期、狀態(tài)等多個條件組合篩選。統(tǒng)計報表模塊主要實現(xiàn)兩個功能按學(xué)期統(tǒng)計每個教師的工作量總分及明細(xì)占比按課程類型統(tǒng)計教學(xué)工作量的分布情況以表格加 ECharts 圖表方式展示并支持導(dǎo)出 Excel。系統(tǒng)管理模塊則是用戶管理、角色分配、密碼重置這些通用功能。這些模塊之間的邏輯關(guān)系是基礎(chǔ)數(shù)據(jù)服務(wù)于工作量填報工作量服務(wù)于統(tǒng)計報表系統(tǒng)管理貫穿全局。設(shè)計時一定要先做通這個邏輯否則很容易出現(xiàn)“數(shù)據(jù)查出來了但不知道屬于哪個學(xué)期哪種課程類型”的尷尬。2.2 三角色權(quán)限模型這個系統(tǒng)我設(shè)計了三個角色系統(tǒng)管理員、教務(wù)審核員、普通教師。普通教師登錄后只能看到自己的工作量記錄可以新增填報、修改未提交狀態(tài)下的記錄、查看已審核通過的數(shù)據(jù)。教務(wù)審核員能查看所轄范圍內(nèi)的所有工作量記錄能做審核操作但原則上不應(yīng)該去修改教師填報的具體學(xué)時。系統(tǒng)管理員擁有全部操作權(quán)限主要負(fù)責(zé)維護(hù)用戶賬號、教師信息、課程數(shù)據(jù)和學(xué)期配置。權(quán)限控制的實現(xiàn)分成兩層。后端每個接口在做業(yè)務(wù)處理之前要校驗當(dāng)前登錄用戶的角色我通過攔截器解析 JWT 之后把用戶信息放到上下文中接口里判斷角色是否符合權(quán)限要求。前端做的是界面級控制比如普通教師登錄后菜單里根本不顯示“工作量審核”入口。數(shù)據(jù)權(quán)限也要注意。比如普通教師查列表時SQL 強(qiáng)制帶上當(dāng)前登錄用戶的教師編號而不是把查詢條件全部交給前端傳遞。否則別人改一下請求參數(shù)就能看全院數(shù)據(jù)這在課程設(shè)計和畢設(shè)答辯中是非常嚴(yán)重的邏輯漏洞。2.3 核心業(yè)務(wù)流程與狀態(tài)設(shè)計工作量填報審核流程我用狀態(tài)機(jī)來理解設(shè)計了四個狀態(tài)草稿、待審核、已通過、已駁回。教師新增一條工作量記錄時默認(rèn)進(jìn)入“草稿”狀態(tài)可以隨時修改或刪除。確認(rèn)無誤后點擊“提交審核”狀態(tài)變?yōu)椤按龑徍恕辈⑶掖藭r記錄不允許再被教師本人編輯。教務(wù)審核員看到待審核記錄后可以點擊“通過”讓它進(jìn)入“已通過”或點擊“駁回”使其進(jìn)入“已駁回”狀態(tài)并附帶駁回理由。被駁回的記錄教師可以修改后再次提交狀態(tài)重新變回“待審核”。這個狀態(tài)流轉(zhuǎn)帶來一個必須注意的點統(tǒng)計報表只能統(tǒng)計“已通過”狀態(tài)的數(shù)據(jù)。我在設(shè)計時犯過一個錯誤剛開始把狀態(tài)流轉(zhuǎn)寫得太隨意導(dǎo)致報表統(tǒng)計里混入了“待審核”記錄數(shù)據(jù)對不上號才發(fā)現(xiàn)了這個坑。后面在 Service 層加了嚴(yán)格的狀態(tài)校驗邏輯只允許合法的狀態(tài)遷移比如“已通過”狀態(tài)不能直接改回“草稿”必須走“退回”操作。流程設(shè)計最好把它畫在文檔里用文字方式把幾個核心流轉(zhuǎn)路徑列清楚哪怕只是自己看也能避免邊寫代碼邊改邏輯導(dǎo)致返工。3. 數(shù)據(jù)庫設(shè)計實戰(zhàn)3.1 表結(jié)構(gòu)全景我把系統(tǒng)的數(shù)據(jù)表分成基礎(chǔ)表和業(yè)務(wù)表兩個部分。基礎(chǔ)表包括用戶表、教師信息表、課程表、學(xué)期表、學(xué)院或系部表。用戶表負(fù)責(zé)登錄認(rèn)證字段有 id、用戶名、密碼、角色、狀態(tài)。教師信息表以教職工號為主鍵字段包括姓名、性別、職稱、所屬系部、聯(lián)系電話、入職時間同時用 user_id 與用戶表關(guān)聯(lián)實現(xiàn)賬號與業(yè)務(wù)數(shù)據(jù)的分離。業(yè)務(wù)表包括工作量明細(xì)表和審核記錄表。工作量明細(xì)表是核心業(yè)務(wù)表一個字段都不能少。審核記錄表則記錄每一次審核行為包括審核人、審核時間、審核意見、操作類型。這六類表是硬需求。如果還要做課程班級關(guān)聯(lián)可能需要額外的關(guān)聯(lián)表但對教師工作量管理系統(tǒng)來說工作量明細(xì)表里直接存班級名稱字符串就可以解決問題不需要為了“規(guī)范”而無謂增加復(fù)雜度。這是畢業(yè)設(shè)計和真實生產(chǎn)系統(tǒng)的差別前者更注重功能完整和可演示。3.2 工作量明細(xì)表設(shè)計細(xì)節(jié)這是全系統(tǒng)最關(guān)鍵的一張表字段設(shè)計直接決定了后面統(tǒng)計 SQL 好不好寫。我的建表字段大致如下id 主鍵自增teacher_id 關(guān)聯(lián)教師course_id 關(guān)聯(lián)課程semester_id 關(guān)聯(lián)學(xué)期class_name 存班級名稱total_hours 存課時數(shù)course_type 存課程類型0 理論1 實驗2 實踐convert_hours 存折算后的工作量status 存審核狀態(tài)0 草稿1 待審核2 已通過3 已駁回submit_time 存提交時間audit_time 存審核時間audit_user 存審核人audit_comment 存駁回意見creator_id 存創(chuàng)建人create_time 存創(chuàng)建時間。課程類型不要直接用中文字符串存到數(shù)據(jù)庫比如直接存“理論課”“實驗課”這樣后續(xù)如果想改類型名稱會非常麻煩。我用 int 枚舉通過 MyBatis 的 typeHandler 或者在前端映射成對應(yīng)文本顯示。折算字段 convert_hours 我是預(yù)先把計算好的結(jié)果存進(jìn)去的。有些設(shè)計方案里只在查詢時按系數(shù)乘總課時那會導(dǎo)致統(tǒng)計邏輯分散在各個報表 SQL 里。每次要調(diào)整系數(shù)就得改多個地方非常容易漏。我選擇在業(yè)務(wù)提交時一次性算好并存進(jìn)字段統(tǒng)計時直接拿 convert_hours 做 SUM既統(tǒng)一又高效。3.3 索引與數(shù)據(jù)完整性考量我為工作量明細(xì)表加了一個聯(lián)合唯一索引teacher_id, semester_id, course_id, class_name目的是防止同一個老師在同一學(xué)期給同一個班級上同一門課產(chǎn)生兩條重復(fù)記錄。有實際的業(yè)務(wù)場景可以利用唯一索引來兜底就算前端沒有做防重復(fù)校驗數(shù)據(jù)庫層面也能攔住。外鍵方面我明確建議畢設(shè)項目盡量用邏輯外鍵而不是物理外鍵。也就是說在表設(shè)計時不聲明 FOREIGN KEY 約束只在 Java 實體里建立關(guān)聯(lián)關(guān)系。原因是物理外鍵在刪除教師或課程數(shù)據(jù)時容易觸發(fā)約束報錯平時調(diào)試時還得手動查級聯(lián)關(guān)系邏輯外鍵可以在代碼層面控制刪除邏輯靈活性更強(qiáng)。數(shù)據(jù)庫層面的外鍵是給嚴(yán)格要求數(shù)據(jù)強(qiáng)一致性的生產(chǎn)系統(tǒng)準(zhǔn)備的不適用于頻繁造數(shù)據(jù)和演示的項目。MySQL 8 環(huán)境下要注意驅(qū)動版本。用 com.mysql.cj.jdbc.Driverurl 里一般要帶上 serverTimezoneAsia/Shanghai否則數(shù)據(jù)庫連接會因時區(qū)差異報錯這一點網(wǎng)上資源描述得比較少實際遇到的人卻非常多。4. 后端實現(xiàn)中的重難點4.1 后端工程結(jié)構(gòu)與統(tǒng)一響應(yīng)我的后端工程采用標(biāo)準(zhǔn)分層結(jié)構(gòu)controller 負(fù)責(zé)接收參數(shù)service 處理業(yè)務(wù)邏輯mapper 負(fù)責(zé)數(shù)據(jù)庫交互。包名上分為 config、controller、service、mapper、pojo、common 這幾層。pojo 里放 entity、dto、vocommon 里放統(tǒng)一結(jié)果類、異常類、工具類。統(tǒng)一結(jié)果類是必做的。所有接口無論成功失敗都返回同一個格式code、message、data。前端 axios 封裝就可以根據(jù) code 做統(tǒng)一的錯誤提示比如用戶登錄過期時返回 401前端直接跳轉(zhuǎn)登錄頁。剛開始開發(fā)時我也圖省事直接返回 Map 或?qū)嶓w對象后來發(fā)現(xiàn)前端每次都要判斷數(shù)據(jù)類型寫起來非常折磨。統(tǒng)一響應(yīng)類之后接口就變成“無腦返回 Result.success(data)”的模式維護(hù)成本大幅下降。全局異常處理也建議寫。用 RestControllerAdvice 捕獲 RuntimeException、參數(shù)校驗異常和自定義業(yè)務(wù)異常在異常處理器里轉(zhuǎn)成統(tǒng)一格式返回。這樣 Service 層就不用到處 try-catch只管拋出業(yè)務(wù)異常即可代碼干凈很多。4.2 登錄鑒權(quán)與密碼安全登錄鑒權(quán)我用 JWT 實現(xiàn)。登錄成功時服務(wù)端生成一個 token里面包含用戶 id、用戶名、角色信息并設(shè)置大約 2 小時的過期時間。前端把 token 存儲到 localStorage 或 sessionStorage之后每次請求在請求頭里帶上 Authorization 字段。后端配置一個攔截器對所有需要登錄的接口做 token 校驗。解析成功后把用戶信息放入 ThreadLocal方便 Service 層直接獲取當(dāng)前登錄者。校驗失敗時返回 401前端 axios 攔截器收到 401 后統(tǒng)一跳轉(zhuǎn)到登錄頁。密碼存儲一定不能用明文。最基礎(chǔ)也要做 MD5 加鹽更推薦用 BCrypt 加密。Spring Security 自帶 BCryptPasswordEncoder但為了精簡依賴我只引入了單獨的 jbcrypt 工具類幾行代碼就能完成哈希和校驗。這個點如果做得好答辯時是很加分的因為很多管理系統(tǒng)項目在密碼安全上非常隨意。接口層面的權(quán)限控制我用了自定義注解加攔截器判斷的方式。在需要管理員權(quán)限的接口方法上標(biāo)注 RequireAdmin攔截器里檢查角色字段不符合就返回?zé)o權(quán)限信息。比起在每個 Controller 里手動 if 判斷這種方式更集中也更優(yōu)雅。4.3 工作量折算與統(tǒng)計邏輯工作量折算的業(yè)務(wù)規(guī)則要放到 Service 層不要寫死在 Controller 里更不能散落在前端。我設(shè)計了一個 WorkloadCalculateService核心邏輯是按課程類型讀取對應(yīng)的系數(shù)然后用總課時乘以系數(shù)算出折算值用 BigDecimal 計算避免浮點精度問題。比如默認(rèn)規(guī)則理論課系數(shù) 1.0實驗課系數(shù) 0.8實踐課系數(shù) 1.2。課時數(shù)字段用 int 存系數(shù)存在數(shù)據(jù)庫參數(shù)表中方便后續(xù)管理員修改。為什么不把系數(shù)寫死因為需求很可能從“1.0/0.8/1.2”變成“1.0/0.9/1.5”寫死就要改源碼重新部署。把系數(shù)做成一張配置表用 Key-Value 的方式存儲后臺管理頁面加一個參數(shù)維護(hù)入口就徹底規(guī)避了這個擴(kuò)展問題。統(tǒng)計邏輯我用一條聚合 SQL 完成。按教師和學(xué)期分組SUM 各課程類型折算工時。如果還要按課程類型做二次分組就在 GROUP BY 里多加一個字段。報表數(shù)據(jù)量大時可以通過 Map 或 VO 接收查詢結(jié)果不要試圖用一個多表 JOIN 塞進(jìn)實體類。MyBatis 的 resultType 直接指定 Map 類型的做法在統(tǒng)計查詢里非常實用。4.4 MyBatis 動態(tài) SQL 與分頁工作量列表頁通常有多個篩選條件教師姓名、學(xué)期、課程類型、審核狀態(tài)。這些條件不是必填的所以 Mapper XML 里要寫動態(tài) SQL。我用 MyBatis 的if標(biāo)簽來拼接 WHERE 子句。這里有一個非常容易踩的坑判斷條件時不能直接用status ! 因為當(dāng) status 為 0 時MyBatis 里0 ! 在 OGNL 表達(dá)式里其實是不相等的導(dǎo)致條件不生效。正確寫法是分開判斷status ! null and status ! 只能處理字符串為空數(shù)字類型必須單獨用status ! null。數(shù)字 0 的情況尤其要小心我在寫課程類型查詢時吃過一次虧前端傳 courseType0 理論課結(jié)果條件被拼漏了返回了全部課程類型的數(shù)據(jù)。分頁我使用了 PageHelper 插件用法是查詢前調(diào)用 PageHelper.startPage(pageNum, pageSize)緊接著的下一條查詢會被自動攔截并生成分頁 SQL返回的 PageInfo 里有 total、pages、list 等字段直接給前端用。但這里有個注意點PageHelper 只對緊隨其后的第一條 SQL 生效如果中間有別的查詢分頁效果就會失效或錯亂所以在 Service 設(shè)計時最好在獨立方法里完成分頁查詢。還有一個動態(tài) SQL 技巧如果查詢條件空值特別多建議先拼一個“始終成立”的 WHERE 11再逐個追加if條件。雖然語法上不那么優(yōu)雅但確實是最直觀不容易錯的寫法。5. 前端 Vue 實現(xiàn)與前后端聯(lián)調(diào)5.1 前端工程結(jié)構(gòu)與組件劃分前端我采用的是 Vue 和 Element UI 組件庫的組合方案。如果完全新建項目用 Vue 3 加 Element Plus 當(dāng)然更現(xiàn)代但如果參考資源大多是 Vue 2 的項目沿用 Vue 2 方案更容易快速落地。關(guān)鍵是前后端分離這種架構(gòu)思路本質(zhì)上不依賴具體版本。目錄結(jié)構(gòu)上我把 api 模塊單獨抽出來按業(yè)務(wù)域拆分文件比如 workload.js、user.js、course.js每個文件內(nèi)導(dǎo)出對應(yīng)接口的 axios 請求函數(shù)。這樣頁面組件里不會出現(xiàn)直接的 axios 調(diào)用接口變更時只需要改對應(yīng) api 文件不用動頁面。views 目錄按角色分文件夾teacher 下的工作量填報頁、workload 查詢頁admin 下的審核頁、統(tǒng)計頁、基礎(chǔ)數(shù)據(jù)管理頁。公共組件放到 components 目錄比如審核狀態(tài)標(biāo)簽組件、分頁組件、教師選擇組件。路由設(shè)計上采用嵌套路由配合側(cè)邊欄菜單動態(tài)生成路由菜單是加分項但會增加復(fù)雜度。如果工期緊張靜態(tài)路由配置加權(quán)限判斷完全夠用邏輯更清晰排錯更方便。5.2 關(guān)鍵頁面設(shè)計與交互邏輯登錄頁是最重要的門面。表單校驗賬號密碼非空提交后接收 token 和用戶角色根據(jù)角色跳轉(zhuǎn)到不同首頁。我的做法是管理員進(jìn)全局統(tǒng)計頁教師進(jìn)個人工作量列表頁。工作量填報頁面核心是動態(tài)表單。課程下拉框的數(shù)據(jù)來自課程管理接口班級輸入框支持手動輸入字符串總課時是數(shù)字輸入框課程類型是單選組。教師在填寫時頁面可以實時展示折算規(guī)則提示選了實驗課輸入課時后自動算出預(yù)計工作量展示給用戶。這個反饋體驗對答辯演示很有幫助。審核頁面做成待辦事項列表風(fēng)格。列表展示申請人的教師名、課程、班級、總課時、折算數(shù)、提交時間。操作按鈕根據(jù)狀態(tài)差異性展示待審核記錄顯示“通過”“駁回”按鈕已通過記錄按鈕隱藏或置灰。批量操作建議只在待審核狀態(tài)下開放通過時一次勾選多條提交后端處理。統(tǒng)計報表頁面我用 ECharts 做柱狀圖和餅圖。柱狀圖展示某個教師在不同學(xué)期的工作量對比餅圖展示某個學(xué)院理論課、實驗課、實踐課占比。這些圖表的數(shù)據(jù)都是調(diào)用統(tǒng)計接口動態(tài)渲染的而不是寫死配置。寫死配置這種靜態(tài)數(shù)據(jù)在演示時容易被追問很影響答辯印象。5.3 Axios 封裝與跨域聯(lián)調(diào)經(jīng)驗Axios 一定要封裝。我用攔截器統(tǒng)一做三件事請求攔截時把 token 從存儲空間取出放進(jìn)請求頭響應(yīng)攔截時統(tǒng)一判斷 codecode 為 200 時直接返回 datacode 為 401 時清除本地登錄態(tài)并跳轉(zhuǎn)登錄頁其他業(yè)務(wù)錯誤彈出 Element UI 的 Message 通知。跨域問題基本每個做前后端分離的人都會遇到。解決辦法是后端寫一個 CorsFilter配置允許跨域的路徑、允許的請求頭和請求方法前端的請求就能正常訪問。這里有個細(xì)節(jié)預(yù)檢請求 OPTIONS 要直接放行返回 200否則前端會報 CORS 錯誤尤其在使用自定義請求頭時這個坑非常常見。接口字段命名保持一致也很重要。前端傳后端統(tǒng)一用 camelCase駝峰后端實體也用駝峰數(shù)據(jù)庫字段是下劃線風(fēng)格靠 MyBatis 的 mapUnderscoreToCamelCase 配置自動轉(zhuǎn)換。這個配置要在 application.yml 里顯式開啟不開啟會導(dǎo)致實體屬性映射不上頁面顯示不出來數(shù)據(jù)。時間字段的處理容易忽略。數(shù)據(jù)庫的 datetime 類型返回給前端是一個帶 T 的字符串直接展示不美觀。我的方案是前端封裝一個日期格式化工具函數(shù)展示時按需求格式化成“2025-03-18 14:30”這種樣式提交時間控件時再轉(zhuǎn)成后端能接受的標(biāo)準(zhǔn)格式。6. 常見問題與排查技巧6.1 高頻問題速查表把這一路下來遇到的問題整理成了一張表放在這里方便以后排查也省得每次都要重新翻控制臺?，F(xiàn)象常見原因解決辦法登錄頁請求報 401token 沒傳或已過期檢查 axios 請求攔截器是否帶了請求頭重新登錄獲取新 token查詢條件帶數(shù)字 0 不生效MyBatis 動態(tài) SQL 判斷漏掉! null數(shù)字類型條件單獨寫if testcourseType ! null再拼接 SQL實體屬性值全部為 null未開啟下劃線轉(zhuǎn)駝峰在 application.yml 設(shè)置 map-underscore-to-camel-case: true前端請求跨域失敗后端未配置 CorsFilter或 OPTIONS 沒放行配置全局跨域過濾器直接放行 OPTIONS 請求PageHelper 分頁不起作用startPage 與查詢中間插了其他 SQL或插件版本不兼容把 startPage 放在查詢方法內(nèi)緊鄰查詢語句之前檢查插件版本適配數(shù)據(jù)庫連接報時區(qū)錯誤驅(qū)動版本或 url 參數(shù)不對MySQL 8 使用 com.mysql.cj.jdbc.Driver 且 url 上加 serverTimezoneAsia/Shanghai圖片或靜態(tài)資源 404前后端分離部署時路徑配置錯誤檢查 publicPath 和打包后的靜態(tài)資源路徑教師提交后還能隨意修改狀態(tài)流轉(zhuǎn)校驗缺失Service 層增加狀態(tài)檢查非草稿狀態(tài)禁止編輯操作6.2 實際開發(fā)中踩過的幾個坑第一個坑是審核狀態(tài)統(tǒng)計混亂。最初我寫統(tǒng)計報表時沒有過濾狀態(tài)草稿數(shù)據(jù)也被放進(jìn) SUM 里。發(fā)現(xiàn)后一方面在統(tǒng)計 SQL 里明確加 status 2另一方面在數(shù)據(jù)層面教育自己業(yè)務(wù)數(shù)據(jù)的有效性和狀態(tài)強(qiáng)相關(guān)所有統(tǒng)計都先想清楚“我要統(tǒng)計的是哪個狀態(tài)之下的數(shù)據(jù)”。第二個坑是刪除講師信息時被業(yè)務(wù)數(shù)據(jù)阻塞。刪一個不再授課的教師時發(fā)現(xiàn)工作量表里還掛著這個教師的歷史記錄物理外鍵報錯。我后來把刪除邏輯改成“邏輯刪除”給用戶和教師表加 is_deleted 字段列表查詢永遠(yuǎn)只顯示未刪除的數(shù)據(jù)歷史業(yè)務(wù)數(shù)據(jù)保留這樣既不影響統(tǒng)計也能正?！皠h除”用戶。第三個坑是前端參數(shù)名不統(tǒng)一。有些接口用 userId有些用 teacherId明明指的是同一個字段聯(lián)調(diào)時經(jīng)常因為參數(shù)命名不一致導(dǎo)致查詢數(shù)據(jù)始終為空。后來我定了一個規(guī)范所有涉及當(dāng)前登錄用戶的一律由后端從 token 里解析不從前端傳遞跨角色的查詢參數(shù)統(tǒng)一用查詢對象的字段名。這樣一改聯(lián)調(diào)難度下降非常多。第四個坑是課程類型文字與數(shù)字混淆。數(shù)據(jù)庫存了 int前端展示做了字典映射但導(dǎo)出 Excel 時忘記做反向映射導(dǎo)出的表里課程類型那一列全是 0 和 1。后面統(tǒng)一封裝了一個轉(zhuǎn)換工具類凡是展示層的轉(zhuǎn)換都走同一個方法就不會漏。還有一個開發(fā)效率上的建議準(zhǔn)備一套完整的演示數(shù)據(jù)。包括至少 3 個教師賬號、1 個審核員賬號、1 個管理員賬號對應(yīng) 2 個學(xué)期、5 門課程、幾十條工作量記錄覆蓋每一種狀態(tài)。演示答辯時直接輸入賬號就能展示不需要現(xiàn)場錄數(shù)據(jù)?，F(xiàn)場造數(shù)據(jù)不僅浪費(fèi)時間還容易暴露邊界問題。僅圍繞代碼層面的東西還有一個容易忽略的點SpringBoot 項目的啟動類不要放在有中文路徑的目錄下尤其是從網(wǎng)盤下載的源碼解壓后路徑里帶中文或者非常深的多層目錄很容易引發(fā)莫名其妙的加載失敗。先確認(rèn)當(dāng)前項目在純英文路徑下再排查別的錯誤。最后分享一個很小但很實用的經(jīng)驗開發(fā)者提交代碼或打包給老師看的時候把數(shù)據(jù)庫導(dǎo)出 SQL 腳本一并準(zhǔn)備好并保證腳本里包含全部表結(jié)構(gòu)和演示數(shù)據(jù)。對方拿到項目導(dǎo)入 SQL、改一下數(shù)據(jù)庫名和賬號密碼、啟動后端、啟動前端就能跑起來。這種“開箱即用”的體驗比任何詳細(xì)文檔都更能說明你的工程能力。做完這個系統(tǒng)我個人最大的體會是一個業(yè)務(wù)系統(tǒng)真正難的不是技術(shù)框架本身而是把業(yè)務(wù)規(guī)則理清楚并穩(wěn)定地落地。教師工作量管理系統(tǒng)就是很好的訓(xùn)練場它有真實的管理場景、有狀態(tài)流轉(zhuǎn)、有權(quán)限體系、有統(tǒng)計報表但整體復(fù)雜度又不至于失控。如果你正在糾結(jié)選題或者卡在某個實現(xiàn)環(huán)節(jié)照著這套思路往下拆把數(shù)據(jù)表和狀態(tài)流轉(zhuǎn)先設(shè)計好后面寫代碼會順暢得多。