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