成績(jī)分析系統(tǒng)的開發(fā)并不復(fù)雜真正難的是把“分析結(jié)果”轉(zhuǎn)化成可執(zhí)行的學(xué)習(xí)建議。SpringBoot Vue MyBatis 這套組合幾乎是國(guó)內(nèi)中小型管理系統(tǒng)的標(biāo)配但很多人做出來的東西要么停留在“增刪改查”層面要么圖表堆了一堆卻不知道數(shù)據(jù)背后的意義。這次拆解一個(gè)完整的學(xué)生成績(jī)分析與弱項(xiàng)輔助系統(tǒng)從數(shù)據(jù)庫(kù)設(shè)計(jì)到算法邏輯再到前端可視化把關(guān)鍵環(huán)節(jié)講透。既然標(biāo)題里帶了“完整源碼”我就按模塊逐個(gè)說明核心實(shí)現(xiàn)。本文涉及的技術(shù)棧為 SpringBoot 2.7 MyBatis MySQL 8.0 Vue 2 Element UI這套組合的穩(wěn)定性和社區(qū)活躍度目前都還挺穩(wěn)的。如果你是準(zhǔn)備做畢業(yè)設(shè)計(jì)或者是剛接觸全棧想找個(gè)完整項(xiàng)目練手這份拆解應(yīng)該能省掉你不少搜代碼的時(shí)間。1. 整體設(shè)計(jì)思路與核心需求拆解1.1 項(xiàng)目定位與功能邊界學(xué)生成績(jī)分析系統(tǒng)的本質(zhì)是把考試產(chǎn)生的原始分?jǐn)?shù)轉(zhuǎn)換成有價(jià)值的信息。教師錄入成績(jī)后系統(tǒng)要能回答幾個(gè)核心問題班級(jí)整體水平怎么樣哪些學(xué)生成績(jī)波動(dòng)大某個(gè)學(xué)生的薄弱科目到底弱在哪里針對(duì)薄弱點(diǎn)能給出什么樣的學(xué)習(xí)建議系統(tǒng)的核心功能模塊我拆成了五個(gè)用戶管理管理員、教師、學(xué)生三種角色、成績(jī)錄入與維護(hù)、成績(jī)分析與統(tǒng)計(jì)、弱項(xiàng)識(shí)別與建議、數(shù)據(jù)可視化看板。實(shí)際開發(fā)時(shí)五個(gè)模塊的優(yōu)先級(jí)是不同的。成績(jī)分析和弱項(xiàng)識(shí)別是核心業(yè)務(wù)邏輯也是拉開代碼質(zhì)量差距的地方用戶管理和成績(jī)錄入屬于基礎(chǔ)功能照常規(guī)辦法揮就能打通可視化看板則是錦上添花但做好了非常加分。技術(shù)選型上SpringBoot負(fù)責(zé)提供RESTful APIMyBatis負(fù)責(zé)數(shù)據(jù)庫(kù)交互Vue Element UI負(fù)責(zé)頁面呈現(xiàn)MySQL存儲(chǔ)數(shù)據(jù)。需要特別說明的是為什么選 MyBatis 而不是時(shí)下熱門的 MyBatis-Plus我的考慮是兩點(diǎn)第一成績(jī)分析涉及大量相對(duì)復(fù)雜的統(tǒng)計(jì)SQLMyBatis 原生支持自定義SQL更直觀第二如果你想拿這個(gè)項(xiàng)目去面試MyBatis 的手寫SQL能力反而是加分項(xiàng)因?yàn)楹芏嗝嬖嚬贂?huì)追問 MyBatis 的執(zhí)行流程和動(dòng)態(tài)SQL這些知識(shí)點(diǎn)在面試八股文里出現(xiàn)頻率很高。1.2 為什么選這三層架構(gòu)而不是更花哨的方案我說一個(gè)很真實(shí)的現(xiàn)狀很多學(xué)生做這類系統(tǒng)一上來就追求微服務(wù)、Redis緩存、消息隊(duì)列結(jié)果一個(gè)單體系統(tǒng)被撐得四不像。成績(jī)分析系統(tǒng)的并發(fā)量最多也就是一個(gè)年級(jí)同時(shí)在線查看成績(jī)幾十個(gè)請(qǐng)求并發(fā)已經(jīng)頂天了。分布式那套架構(gòu)在這里完全是用不上的。SpringBoot MyBatis MySQL Vue 這套組合能形成事實(shí)標(biāo)準(zhǔn)核心原因是“杠桿率”高——每一層都有明確的分工而且每層都有大量成熟的解決方案可以借鑒。前端Vue負(fù)責(zé)交互和圖表渲染后端SpringBoot負(fù)責(zé)業(yè)務(wù)邏輯和接口設(shè)計(jì)MyBatis負(fù)責(zé)SQL與對(duì)象映射。你只需要關(guān)注成績(jī)分析這個(gè)核心業(yè)務(wù)怎么寫其它基礎(chǔ)設(shè)施基本不怎么需要操心。這里有一個(gè)容易被忽略的設(shè)計(jì)點(diǎn)RESTful API 的粒度。成績(jī)系統(tǒng)里有個(gè)很典型的場(chǎng)景教師在前端頁面上勾選多門課程點(diǎn)擊“生成分析報(bào)告”前端到底應(yīng)該發(fā)幾個(gè)請(qǐng)求很多人的第一反應(yīng)是后端提供一個(gè)“批量分析”接口接收課程ID列表一次返回所有分析結(jié)果。我在實(shí)際設(shè)計(jì)時(shí)故意拆分成了“單科分析”和“匯總對(duì)比”兩個(gè)接口單科分析負(fù)責(zé)生成某一門課的詳細(xì)報(bào)告匯總對(duì)比負(fù)責(zé)羅列各科核心指標(biāo)。這樣前端可以按需請(qǐng)求單個(gè)接口的響應(yīng)時(shí)間也能控制在200毫秒以內(nèi)用戶交互體驗(yàn)明顯更順暢。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與成績(jī)分析核心邏輯2.1 數(shù)據(jù)庫(kù)表結(jié)構(gòu)設(shè)計(jì)一個(gè)成績(jī)系統(tǒng)的表結(jié)構(gòu)看似簡(jiǎn)單實(shí)際上有非常容易踩坑的地方。最典型的坑把成績(jī)直接設(shè)計(jì)成“一個(gè)學(xué)生一行每門課一列”的橫向表結(jié)構(gòu)。這種設(shè)計(jì)在錄入的時(shí)候確實(shí)直觀排考場(chǎng)發(fā)成績(jī)單也符合直覺。但一旦要對(duì)多門科目做統(tǒng)計(jì)分析橫向表幾乎是一場(chǎng)災(zāi)難因?yàn)槟阋獙?duì)幾十個(gè)字段做聚合運(yùn)算SQL寫出來不僅冗長(zhǎng)而且性能很差。我的表結(jié)構(gòu)設(shè)計(jì)遵循了縱向存儲(chǔ)原則。學(xué)生表保存學(xué)號(hào)和姓名等基本資料課程表保存課程信息成績(jī)表的每行記錄只承載一個(gè)學(xué)生的一門課成績(jī)外加考試類型字段比如期中、期末、月考。這樣做的好處非常明顯分?jǐn)?shù)聚合的SQL寫起來極其自然比如“統(tǒng)計(jì)某一科全班的最高分”就是一句普通的MAX(score)帶條件查詢?nèi)蹴?xiàng)分析要跨科目對(duì)比的時(shí)候也不需要在多個(gè)字段之間做條件判斷了。具體到成績(jī)表的設(shè)計(jì)我用了這個(gè)字段組合id、student_id、course_id、exam_type、score、class_id。其中student_id、course_id、exam_type建一個(gè)唯一索引防止同一次考試?yán)锿粋€(gè)學(xué)生同一門課被重復(fù)錄入。這里有個(gè)細(xì)節(jié)值得記住創(chuàng)建索引不是為了查詢快首先是為了防重復(fù)。業(yè)務(wù)層面再怎么校驗(yàn)都不如數(shù)據(jù)庫(kù)約束來的可靠。2.2 成績(jī)統(tǒng)計(jì)中的SQL優(yōu)化細(xì)節(jié)成績(jī)分析最基礎(chǔ)的三個(gè)指標(biāo)是平均分、最高分、最低分。這句話聽起來簡(jiǎn)單但在 MyBatis 里寫統(tǒng)計(jì)SQL的時(shí)候有個(gè)很容易導(dǎo)致性能問題的操作——在 Java 代碼里循環(huán)調(diào)用單條查詢。比如一次性分析10門課就在循環(huán)里跑10次“查某科平均分”的SQL每查詢一次就建立一次數(shù)據(jù)庫(kù)會(huì)話。這個(gè)方案雖然也能跑但是數(shù)據(jù)量一大響應(yīng)時(shí)間就上去了。正確的做法是用一條GROUP BY語句搞定整個(gè)分析需求SELECT course_id, ROUND(AVG(score), 2) AS avg_score, MAX(score) AS max_score, MIN(score) AS min_score FROM score WHERE exam_type #{examType} GROUP BY course_id;這樣一條SQL返回的就是所有課程的分析結(jié)果。MyBatis的Select注解或XML里的select標(biāo)簽直接映射成一個(gè)包含多個(gè)對(duì)象的ListScoreStatisticVO一次數(shù)據(jù)庫(kù)交互完成全部計(jì)算。及格率、優(yōu)秀率、分?jǐn)?shù)段分布這些指標(biāo)如果要單獨(dú)寫SQL也是可以實(shí)現(xiàn)的但這里有個(gè)進(jìn)階技巧合并字段計(jì)算。一次查詢把所有指標(biāo)算完。SELECT course_id, COUNT(*) AS total_count, SUM(CASE WHEN score 60 THEN 1 ELSE 0 END) AS pass_count, SUM(CASE WHEN score 85 THEN 1 ELSE 0 END) AS excellent_count, ROUND(AVG(score), 2) AS avg_score FROM score WHERE exam_type #{examType} GROUP BY course_id;這套用CASE WHEN配合SUM的技巧我愿稱之為統(tǒng)計(jì)分析里最實(shí)用的SQL套路。它把多趟查詢合并成了單趟掃描性能提升是實(shí)打?qū)嵉摹Ｄ阍诿嬖嚨臅r(shí)候把這套寫出來面試官對(duì)你的SQL功底會(huì)有一個(gè)正向判斷。2.3 弱項(xiàng)識(shí)別的判定邏輯“弱項(xiàng)”不能靠感覺要有一個(gè)可被解釋的規(guī)則。我設(shè)計(jì)的弱項(xiàng)識(shí)別邏輯分兩步。第一步是絕對(duì)水平判斷。把學(xué)生的單科成績(jī)與班級(jí)平均分做差如果低于班級(jí)平均分的某個(gè)閾值默認(rèn)設(shè)置為5分就標(biāo)記為“偏弱科目”。這個(gè)閾值可以在管理員設(shè)置里配置不同學(xué)校、不同考試難度可以靈活調(diào)整。第二步是相對(duì)趨勢(shì)判斷。比“這次考得不好”更值得關(guān)注的是“連續(xù)下滑”。我在代碼里取了該學(xué)生近三次同科目成績(jī)用一次線性回歸計(jì)算斜率。斜率為負(fù)數(shù)且絕對(duì)值超過預(yù)設(shè)值時(shí)將這門課標(biāo)記為“下滑趨勢(shì)科目”。這個(gè)判定條件比簡(jiǎn)單的“這次的分?jǐn)?shù)比上次低”嚴(yán)謹(jǐn)?shù)枚嘁驗(yàn)橐淮尾▌?dòng)有可能是試卷難度造成的連續(xù)下滑才更能說明問題。這兩步判斷在代碼里組合成一個(gè)弱項(xiàng)識(shí)別接口。識(shí)別完成后系統(tǒng)會(huì)根據(jù)預(yù)設(shè)的“弱項(xiàng)代碼—建議內(nèi)容”映射表自動(dòng)生成輔助學(xué)習(xí)建議。比如“低于班級(jí)平均分5分以上”對(duì)應(yīng)建議是“建議回歸課本梳理基礎(chǔ)知識(shí)點(diǎn)漏洞”“連續(xù)三次成績(jī)下滑”對(duì)應(yīng)建議是“建議與任課教師溝通排查近期學(xué)習(xí)方法是否存在問題”。這種把分析結(jié)果落到具體建議的做法讓整個(gè)系統(tǒng)從“報(bào)表工具”升維成了真正意義上的“輔助系統(tǒng)”。3. 后端核心模塊實(shí)現(xiàn)與API設(shè)計(jì)3.1 SpringBoot項(xiàng)目結(jié)構(gòu)與分層規(guī)范后端項(xiàng)目采用標(biāo)準(zhǔn)的Controller-Service-DAO三層模式。Controller層只負(fù)責(zé)接收請(qǐng)求、參數(shù)校驗(yàn)、返回結(jié)果Service層承載具體業(yè)務(wù)邏輯DAO層通過MyBatis與數(shù)據(jù)庫(kù)交互。我用一個(gè)實(shí)際的弱項(xiàng)分析功能來展示分層后的代碼走向。先看 Controller 層RestController RequestMapping(/api/analysis) public class AnalysisController { Autowired private AnalysisService analysisService; GetMapping(/weakness/{studentId}) public Result getWeaknessAnalysis(PathVariable Integer studentId) { WeaknessAnalysisVO vo analysisService.analyzeWeakness(studentId); return Result.success(vo); } }Controller層非常薄沒有任何業(yè)務(wù)邏輯。參數(shù)就是學(xué)生ID返回值統(tǒng)一封裝在Result對(duì)象里。Result是我自定義的統(tǒng)一響應(yīng)體包含code、message、data三個(gè)字段前端拿到后能統(tǒng)一處理成功和失敗的情況不用每個(gè)接口單獨(dú)判斷。再看 Service 層這里是弱項(xiàng)分析的核心Service public class AnalysisServiceImpl implements AnalysisService { Autowired private ScoreMapper scoreMapper; Override public WeaknessAnalysisVO analyzeWeakness(Integer studentId) { WeaknessAnalysisVO vo new WeaknessAnalysisVO(); // 獲取該學(xué)生的所有成績(jī)信息 ListScoreDO scores scoreMapper.selectScoresByStudentId(studentId); // 按課程分組計(jì)算各科平均值與班級(jí)平均值的差值 MapInteger, ListScoreDO courseGroup scores.stream() .collect(Collectors.groupingBy(ScoreDO::getCourseId)); ListWeakCourseItem weakCourses new ArrayList(); courseGroup.forEach((courseId, courseScores) - { double studentAvg courseScores.stream() .mapToDouble(ScoreDO::getScore) .average() .orElse(0.0); double classAvg scoreMapper.selectCourseAvg(courseId); if (classAvg - studentAvg 5.0) { WeakCourseItem item new WeakCourseItem(); item.setCourseId(courseId); item.setStudentAvg(studentAvg); item.setClassAvg(classAvg); item.setGap(Math.round((classAvg - studentAvg) * 100) / 100.0); weakCourses.add(item); } }); vo.setWeakCourses(weakCourses); return vo; } }這里有一個(gè)面試官經(jīng)常追問的點(diǎn)把“所有成績(jī)”加載到內(nèi)存再分組 vs 直接在SQL里GROUP BY分組哪個(gè)更好我的回答是如果數(shù)據(jù)量在幾千條以內(nèi)一個(gè)學(xué)生的歷史成績(jī)最多也就幾十條內(nèi)存分組完全沒問題代碼還更好讀如果要做全年級(jí)的總分析那一定走SQL聚合。選擇的關(guān)鍵是明確數(shù)據(jù)規(guī)模而不是一味追捧某一種寫法。3.2 MyBatis動(dòng)態(tài)SQL的實(shí)際應(yīng)用MyBatis 一個(gè)核心能力是動(dòng)態(tài)SQL。成績(jī)查詢頁面通常會(huì)有按學(xué)號(hào)、按姓名、按課程、按考試類型、按分?jǐn)?shù)區(qū)間等篩選條件而且這些條件可以自由組合。用戶可能只填課程也可能同時(shí)填課程 分?jǐn)?shù)區(qū)間 考試類型如果為每一種組合寫一條SQL那會(huì)產(chǎn)生大量的重復(fù)代碼。動(dòng)態(tài)SQL就是專門解決組合查詢這個(gè)問題的。select idselectScoresByCondition resultTypeScoreDO SELECT * FROM score where if teststudentId ! null AND student_id #{studentId} /if if testcourseId ! null AND course_id #{courseId} /if if testexamType ! null and examType ! AND exam_type #{examType} /if if testminScore ! null AND score gt; #{minScore} /if if testmaxScore ! null AND score lt; #{maxScore} /if /where ORDER BY create_time DESC /selectwhere標(biāo)簽會(huì)自動(dòng)處理掉第一個(gè)條件前面的AND這樣無論用戶組合了哪些篩選條件SQL都能正確執(zhí)行。這個(gè)細(xì)節(jié)你要是在面試中被問到可以直接展開聊聊 MyBatis 的動(dòng)態(tài)SQL底層拼接邏輯以及$和#在防止SQL注入方面的區(qū)別。另外給個(gè)務(wù)實(shí)建議手寫分頁用LIMIT offset, size就行不要為了分頁引入一套 PageHelper。成績(jī)分析系統(tǒng)的數(shù)據(jù)量級(jí)根本用不上分頁插件多一個(gè)依賴就多一個(gè)配置陷阱少一點(diǎn)是一點(diǎn)。3.3 登錄認(rèn)證與權(quán)限控制的落地方案成績(jī)系統(tǒng)有三種角色管理員、教師、學(xué)生。學(xué)生登錄后只能看自己的成績(jī)和分析報(bào)告教師登錄后可以看所帶班級(jí)的成績(jī)并錄入分?jǐn)?shù)管理員擁有全部權(quán)限。權(quán)限控制如果做不好學(xué)生只需要改一下網(wǎng)址里的ID就能查到別人的成績(jī)這是絕對(duì)不能接受的安全漏洞。我采用的方案是 JWT 攔截器沒有引入 Spring Security。這么說有點(diǎn)反主流但我的考慮是系統(tǒng)的權(quán)限模型只有三種角色、四五個(gè)接口需要做角色校驗(yàn)Spring Security 那套過濾鏈和配置在這個(gè)場(chǎng)景下不僅沒有幫到忙反而增加了學(xué)習(xí)成本。如果你是做畢業(yè)設(shè)計(jì)答辯時(shí)老師問你“為什么不用Spring Security”你完全可以說在職責(zé)邊界清晰的場(chǎng)景下更輕量的實(shí)現(xiàn)能減少維護(hù)成本而且JWT的簽發(fā)與校驗(yàn)邏輯我完全清楚不存在黑盒。JWT 的實(shí)現(xiàn)要點(diǎn)登錄成功后后端把用戶ID、角色、過期時(shí)間這些信息放進(jìn) token然后返回給前端。前端把 token 存在 localStorage 里每次請(qǐng)求在請(qǐng)求頭里帶上Authorization: Bearer ${token}。后端寫一個(gè)攔截器在 Controller 方法執(zhí)行之前校驗(yàn) token 的有效性和角色權(quán)限。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); try { Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; } }角色相關(guān)的校驗(yàn)我在方法上加了自定義注解RequireRole(teacher)然后寫第二個(gè)攔截器專門檢查當(dāng)前請(qǐng)求用戶的角色是否符合注解里的要求。這套方案清晰且易擴(kuò)展后續(xù)如果加了一個(gè)“年級(jí)組長(zhǎng)”角色改一個(gè)注解值就行。4. Vue前端核心頁面與可視化實(shí)現(xiàn)4.1 Vue項(xiàng)目結(jié)構(gòu)與路由設(shè)計(jì)前端用的是 Vue 2 Element UI。項(xiàng)目結(jié)構(gòu)大致分成src/api封裝axios請(qǐng)求、src/router路由配置、src/views頁面組件、src/components通用組件。我在這里想重點(diǎn)聊聊路由守衛(wèi)。系統(tǒng)中學(xué)生和教師看到的菜單完全不同不能靠頁面里寫v-ifrole teacher來藏起來因?yàn)橛脩艨梢允謩?dòng)在地址欄輸入路由地址繞過頁面限制。所以我在路由配置里給需要權(quán)限的頁面加了meta: { requiresAuth: true, roles: [admin, teacher] }這樣的元信息然后在全局前置守衛(wèi)里做驗(yàn)證router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth) { if (!token) { next(/login); return; } const roles to.meta.roles; const userRole localStorage.getItem(role); if (roles !roles.includes(userRole)) { next(/403); return; } } next(); });這套邏輯不復(fù)雜但卻是很多半成品項(xiàng)目容易忽略的一環(huán)。帶權(quán)限控制的前端路由可以讓項(xiàng)目在評(píng)價(jià)維度上明顯高一個(gè)檔次。4.2 ECharts可視化圖表的接入與動(dòng)態(tài)渲染成績(jī)分析結(jié)果如果不用圖表展示就少了一半的競(jìng)爭(zhēng)力。我用 ECharts 做了四個(gè)核心圖表成績(jī)趨勢(shì)折線圖單個(gè)學(xué)生單科歷次成績(jī)變化、班級(jí)成績(jī)分布柱狀圖分?jǐn)?shù)段人數(shù)分布、各科平均分雷達(dá)圖班級(jí)整體學(xué)科結(jié)構(gòu)、成績(jī)對(duì)比條形圖學(xué)生個(gè)人與班級(jí)平均對(duì)比。圖表接入流程上有一個(gè)關(guān)鍵點(diǎn)ECharts 的圖表實(shí)例需要依賴于 DOM 容器的ref或id而 Vue 的組件掛載是有時(shí)序的。如果直接寫在created()里頁面還沒渲染完圖表容器獲取不到就會(huì)報(bào) undefined 錯(cuò)誤。一定要在mounted()生命周期里初始化圖表。另一個(gè)常見問題是異步數(shù)據(jù)到達(dá)后圖表不更新。正確姿勢(shì)是在拿到后端返回的數(shù)據(jù)后調(diào)用myChart.setOption(option)而不是重新初始化。如果你在一個(gè)大屏或看板頁面頻繁切換數(shù)據(jù)還要注意在組件銷毀前調(diào)用myChart.dispose()釋放實(shí)例否則會(huì)造成瀏覽器內(nèi)存泄漏。核心繪圖邏輯參考// 在 mounted 里初始化圖表 const chartDom this.$refs.scoreTrend; this.trendChart echarts.init(chartDom); this.loadTrendData(); // 拿到后端數(shù)據(jù)后 setOption loadTrendData() { api.getScoreTrend(this.studentId).then(res { this.trendChart.setOption({ title: { text: 歷次成績(jī)趨勢(shì) }, tooltip: { trigger: axis }, xAxis: { type: category, data: res.data.examTypes }, yAxis: { type: value, min: 0, max: 100 }, series: [{ name: 成績(jī), type: line, data: res.data.scores, smooth: true, areaStyle: { opacity: 0.2 } }] }); }); }4.3 成績(jī)錄入頁面的交互設(shè)計(jì)細(xì)節(jié)成績(jī)錄入是一個(gè)高頻操作交互設(shè)計(jì)直接影響教師的使用體驗(yàn)。我給成績(jī)錄入頁面做了幾個(gè)細(xì)節(jié)優(yōu)化這些功能不復(fù)雜但體驗(yàn)提升明顯。第一個(gè)是表格內(nèi)的行內(nèi)編輯。教師直接在表格的輸入框里敲成績(jī)不用每改一個(gè)就彈一次對(duì)話框。頁面底部放一個(gè)“保存全部”按鈕。修改過的單元格用高亮底色標(biāo)記教師一眼能看到自己改過哪些地方。第二個(gè)是分?jǐn)?shù)合法性校驗(yàn)。前端輸入框里限制只能輸入 0100 的整數(shù)后端 Service 層再做一次兜底校驗(yàn)超過范圍的返回明確錯(cuò)誤信息。if (score 0 || score 100) { throw new BusinessException(成績(jī)必須在0到100之間); }第三個(gè)設(shè)計(jì)是“按學(xué)號(hào)自動(dòng)補(bǔ)全學(xué)生姓名”。教師錄入時(shí)通常拿到的是學(xué)生名單需要快速定位學(xué)生。我在輸入框里做了一個(gè)聯(lián)動(dòng)輸入學(xué)號(hào)并失焦后自動(dòng)從后臺(tái)拉取該學(xué)生姓名填充到這一行的相鄰單元格減少了查找時(shí)間。這個(gè)功能初期覺得錦上添花實(shí)際上線后教師普遍反饋很實(shí)用。5. 常見問題與排查技巧實(shí)錄5.1 前后端聯(lián)調(diào)時(shí)的跨域問題本地開發(fā)時(shí)前端運(yùn)行在http://localhost:8080后端運(yùn)行在http://localhost:9090端口不同就必然會(huì)觸發(fā)瀏覽器的跨域攔截。新手最常見的坑是前端報(bào)錯(cuò)后拼命調(diào)前端代碼怎么調(diào)都不通其實(shí)問題在后端沒有允許跨域。我的方案是在后端寫一個(gè)全局的 CORS 配置類Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }這里有個(gè)非常容易忽略的細(xì)節(jié)如果使用了 JWT前端請(qǐng)求會(huì)帶Authorization頭并且使用了withCredentials模式允許攜帶 Cookie那么allowedOrigins(*)這種配置在后端會(huì)拋異常。Spring 不允許“允許所有來源”和“允許攜帶憑證”同時(shí)開啟。解決辦法就是用allowedOriginPatterns(*)它能和allowCredentials(true)共存。5.2 MyBatis查詢結(jié)果為空的排查套路很多人在使用 MyBatis 時(shí)遇到過這種問題直接在 MySQL 客戶端里執(zhí)行 SQL 能查出數(shù)據(jù)但通過接口查詢卻返回空列表。這個(gè)問題的排查順序極為固定按順序檢查基本五分鐘內(nèi)能找到問題。第一步先看 MyBatis 的 SQL 日志。在application.yml里加mybatis.configuration.log-impl: org.apache.ibatis.logging.stdout.StdOutImpl然后查看控制臺(tái)打印的 SQL 是不是你預(yù)期的那條。很多時(shí)候 SQL 的條件參數(shù)沒傳進(jìn)去比如#{courseId}對(duì)應(yīng)的參數(shù)名為courseId但前端傳的是course_id導(dǎo)致參數(shù)綁定失敗最終 SQL 查詢結(jié)果條件不匹配。第二步檢查 resultType 和實(shí)體類的字段映射。MySQL 的字段create_time在 Java 實(shí)體里是createTime開啟 MyBatis 的map-underscore-to-camel-case: true配置能自動(dòng)完成駝峰轉(zhuǎn)換。不開啟的狀態(tài)下查詢結(jié)果里createTime就是 null。第三步判斷是否用了if test動(dòng)態(tài)條件把必要參數(shù)過濾掉了。這種情況很隱蔽我踩過某個(gè)條件判斷里寫的是courseId ! null但前端傳的是空字符串空字符串也能通過判斷最后 SQL 里就多了一個(gè)AND course_id 怎么辦結(jié)果是查不到數(shù)據(jù)。正確寫法是if testcourseId ! null and courseId ! 。5.3 登錄后Token失效排查比較典型的報(bào)錯(cuò)是“登錄成功后一訪問數(shù)據(jù)接口就返回401”。排查點(diǎn)集中在 JWT 秘鑰的簽發(fā)與校驗(yàn)是否一致、token 過期時(shí)間是否設(shè)置太短、前端請(qǐng)求頭是否帶上了 token 這三個(gè)位置。我遇到過最隱蔽的一次是JWT 工具類中有一個(gè)地方把exp過期時(shí)間設(shè)置成了 10 分鐘因?yàn)橛?JWT 默認(rèn)過期時(shí)間兜底代碼不報(bào)錯(cuò)但業(yè)務(wù)接口頻繁在用戶操作到一半時(shí)返回401。后來統(tǒng)一把過期時(shí)間配置抽到application.yml里用Value注入才算真正杜絕這類問題。我給 token 設(shè)置的有效期是 24 小時(shí)。這個(gè)時(shí)長(zhǎng)不是隨便定的而是結(jié)合使用場(chǎng)景考慮的成績(jī)系統(tǒng)不是金融應(yīng)用安全敏感度沒那么高太長(zhǎng)則被泄露后風(fēng)險(xiǎn)增加太短則用戶每半天要重新登錄一次體驗(yàn)極差。結(jié)語關(guān)于這個(gè)系統(tǒng)的擴(kuò)展建議項(xiàng)目做完之后我個(gè)人的體會(huì)是成績(jī)分析和弱項(xiàng)輔助系統(tǒng)的核心競(jìng)爭(zhēng)力不在報(bào)表展示而在“怎么把分析結(jié)果變成有用的行動(dòng)指引”。如果后續(xù)想繼續(xù)擴(kuò)充路徑很清晰——引入知識(shí)點(diǎn)維度的成績(jī)追蹤數(shù)據(jù)弱項(xiàng)分析從科目的粒度細(xì)化到知識(shí)點(diǎn)的粒度或者引入更多維度的學(xué)習(xí)行為數(shù)據(jù)比如在線做題記錄、錯(cuò)題本讓輔助建議更加個(gè)性化和精準(zhǔn)。最后分享一個(gè)寫這類全棧項(xiàng)目的小技巧先畫清楚數(shù)據(jù)庫(kù)表結(jié)構(gòu)再定義好 API 接口文檔最后動(dòng)手寫代碼。你會(huì)發(fā)現(xiàn)整個(gè)開發(fā)過程順暢很多因?yàn)樾枨蟮慕^大部分不確定性在數(shù)據(jù)模型確定的那一刻已經(jīng)消失了。