實(shí)踐)
做信息知識賽系統(tǒng)這件事我前后折騰了兩個(gè)版本。第一個(gè)版本是給一個(gè)培訓(xùn)機(jī)構(gòu)做的內(nèi)部競賽平臺需求很樸素在線答題、自動(dòng)判分、成績排行。當(dāng)時(shí)時(shí)間緊我圖省事直接把題庫和答題邏輯堆在一個(gè)單體應(yīng)用里前端用服務(wù)端模板渲染勉強(qiáng)能跑但后續(xù)加功能的時(shí)候差點(diǎn)把自己逼瘋。第二個(gè)版本徹底重寫采用 SpringBoot Vue3 MyBatis MySQL 的前后端分離架構(gòu)也就是這個(gè)信息知識賽系統(tǒng)現(xiàn)在的樣子。整套系統(tǒng)沉淀下來我覺得最值得記錄的并不是“怎么把代碼跑起來”而是整個(gè)設(shè)計(jì)過程中的技術(shù)選型邏輯、數(shù)據(jù)表如何建模、答題判分的事務(wù)一致性怎么保證、以及部署上線后那些摸爬滾打的優(yōu)化過程。這個(gè)項(xiàng)目適合正在學(xué)習(xí)前后端分離開發(fā)的人參考也適合需要快速搭建競賽答題類系統(tǒng)的團(tuán)隊(duì)直接借鑒。我會把核心實(shí)現(xiàn)思路、關(guān)鍵代碼、踩坑記錄都攤開來講不會只貼一堆跑不通的碎片代碼。1. 信息知識賽系統(tǒng)的業(yè)務(wù)邊界不只做答題還要管人、管題、管成績1.1 競賽系統(tǒng)的基礎(chǔ)角色與核心流程信息知識賽系統(tǒng)本質(zhì)上是一個(gè)在線考試/競賽平臺但和學(xué)校里的期末考試系統(tǒng)有一個(gè)明顯差異競賽場景更強(qiáng)調(diào)即時(shí)反饋和排行榜激勵(lì)。整套系統(tǒng)的核心流程其實(shí)不復(fù)雜管理員維護(hù)題庫、創(chuàng)建一場比賽、配置比賽規(guī)則選手在指定時(shí)間內(nèi)進(jìn)入賽場答題提交后系統(tǒng)自動(dòng)判分最終生成個(gè)人成績和排行榜。圍繞這個(gè)流程系統(tǒng)需要拆出三大模塊用戶模塊管理選手和管理員的身份涉及注冊、登錄、權(quán)限控制。題庫與比賽模塊維護(hù)題目單選、多選、判斷、填空、創(chuàng)建賽場、配置答題時(shí)間和題目數(shù)量。答題與成績模塊選手答題、自動(dòng)判分、個(gè)人成績記錄、排行榜統(tǒng)計(jì)。這三個(gè)模塊劃分清楚之后前后端分離API的設(shè)計(jì)邊界也就自然出來了。后端只需要按業(yè)務(wù)域暴露RESTful接口前端Vue3負(fù)責(zé)呈現(xiàn)和交互不用再像傳統(tǒng)單體應(yīng)用那樣把頁面邏輯和服務(wù)端渲染混在一起。1.2 為什么選前后端分離而不是繼續(xù)用模板引擎如果你只是做一個(gè)小型內(nèi)部工具用Thymeleaf或者JSP這種服務(wù)端渲染方案確實(shí)更快項(xiàng)目結(jié)構(gòu)也更簡單。但信息知識賽系統(tǒng)有一個(gè)特性管理員后臺和選手端頁面交互差異極大。后臺是典型的管理系統(tǒng)布局側(cè)邊欄、表格、表單彈窗選手端則是答題倒計(jì)時(shí)、題目切換、實(shí)時(shí)進(jìn)度。這兩套UI如果都塞在服務(wù)端渲染里前端JS邏輯會非常臃腫后端的Controller層也會被迫去適配兩類頁面的數(shù)據(jù)拼裝。前后端分離之后后端只做API提供方前端可以分別構(gòu)建管理員端和選手端兩套獨(dú)立的Vue3應(yīng)用開發(fā)和聯(lián)調(diào)完全并行。還有一個(gè)隱性的好處后續(xù)如果要出一套小程序或者移動(dòng)端App后端API可以直接復(fù)用不需要重寫業(yè)務(wù)邏輯。對于競賽系統(tǒng)這種需要短期上線、后續(xù)多有迭代需求的場景來說這個(gè)架構(gòu)彈性非常重要。團(tuán)隊(duì)技術(shù)棧需要統(tǒng)一前端Vue3 Vite后端SpringBoot數(shù)據(jù)庫MySQL。前后端通過JSON格式數(shù)據(jù)交互、JWT做身份認(rèn)證聯(lián)調(diào)時(shí)只需約定接口文檔。這套組合的優(yōu)勢在后續(xù)開發(fā)和維護(hù)中體現(xiàn)得特別明顯。2. 數(shù)據(jù)表設(shè)計(jì)與版本選型先理順數(shù)據(jù)關(guān)系再寫業(yè)務(wù)代碼2.1 核心表結(jié)構(gòu)設(shè)計(jì)思路數(shù)據(jù)表是整個(gè)系統(tǒng)的地基。信息知識賽系統(tǒng)的數(shù)據(jù)模型其實(shí)不復(fù)雜核心是四張表用戶表、題目表、比賽表、答題記錄表。命名上我統(tǒng)一采用小寫下劃線風(fēng)格字段都給上注釋方便后期維護(hù)。用戶表的關(guān)鍵字段是角色字段用于區(qū)分管理員和普通選手題目表要區(qū)分題型而且要考慮到選項(xiàng)的存儲方式這是第一次設(shè)計(jì)時(shí)容易踩坑的地方。答題記錄表則要記錄每次作答的內(nèi)容和判分結(jié)果。我當(dāng)時(shí)設(shè)計(jì)的時(shí)候經(jīng)歷了一次變更第一版的題目表直接用一個(gè)options字段以JSON字符串存儲選項(xiàng)想著這樣靈活但后續(xù)做題目統(tǒng)計(jì)和選項(xiàng)分析時(shí)很難直接用SQL處理。第二次重構(gòu)時(shí)拆出了題目選項(xiàng)表和答題明細(xì)表雖然查詢時(shí)關(guān)聯(lián)表多了一層但靈活性和可維護(hù)性提升非常明顯。如果你的系統(tǒng)未來有導(dǎo)出成績、統(tǒng)計(jì)正確率、做試題分析的需求建議從一開始就按這種規(guī)范化表結(jié)構(gòu)設(shè)計(jì)。2.2 SpringBoot版本的坑2.7還是3.x這可能是新手組項(xiàng)目時(shí)最容易踩的坑。SpringBoot 3.x 已經(jīng)發(fā)布很長時(shí)間了新項(xiàng)目大概率會默認(rèn)選擇3.3或更高版本但有一個(gè)硬性門檻SpringBoot 3.x 強(qiáng)制要求 JDK17。如果你的團(tuán)隊(duì)本機(jī)環(huán)境還是 JDK8很多現(xiàn)網(wǎng)服務(wù)器確實(shí)是那會出現(xiàn)一啟動(dòng)就報(bào)錯(cuò)、Maven依賴下載失敗等一堆莫名其妙的問題。我的建議是分成兩種情況團(tuán)隊(duì)有統(tǒng)一的 JDK17 環(huán)境或者這是全新項(xiàng)目直接上 SpringBoot 3.x JDK17后續(xù)維護(hù)周期更長。團(tuán)隊(duì)還在用 JDK8或者要兼容老服務(wù)器那就老老實(shí)實(shí)選 SpringBoot 2.7.x 版本它是 2.x 系列的最后一個(gè)大版本穩(wěn)定性和生態(tài)兼容性都非常好。我這個(gè)項(xiàng)目因?yàn)樾枰嫒輬F(tuán)隊(duì)現(xiàn)有的 JDK8 環(huán)境最終選的是 SpringBoot 2.7.18 JDK8 MyBatis 3.5.x。這套組合運(yùn)行非常穩(wěn)定而且網(wǎng)上遇到問題能搜到的解決方案最多不會因?yàn)榘姹咎露也坏酱鸢?。注意SpringBoot 2.7.x 和 3.x 在配置項(xiàng)上也有一些差異比如spring.redis.host在3.x變成了spring.data.redis.host從 2.7 遷移到 3.x 時(shí)得逐一排查。如果項(xiàng)目已經(jīng)上線不建議在業(yè)務(wù)繁忙期直接升版本。2.3 “版本太高”的那些連帶問題Banner、打包、依賴沖突網(wǎng)上關(guān)于“springboot版本太高”的搜索量一直不低說明很多人被版本問題坑過。除了上面說的 JDK 版本還有幾個(gè)連帶問題值得注意新版本SpringBoot對Maven和Gradle的版本有要求如果用太老的構(gòu)建工具版本會直接報(bào)錯(cuò)。部分第三方starter沒有及時(shí)跟進(jìn)新版本比如一些老牌的驗(yàn)證碼、Excel處理庫在SpringBoot 3.x下可能不兼容Jakarta命名空間。高版本默認(rèn)開啟了更嚴(yán)格的依賴檢查多模塊項(xiàng)目里容易出現(xiàn)依賴沖突。再說個(gè)好玩的事SpringBoot 有一個(gè) banner 生成器的小玩意可以在啟動(dòng)時(shí)打印一個(gè)自定義ASCII藝術(shù)字。很多教程喜歡拿這個(gè)當(dāng)入門案例但要注意 —— 某些在線banner生成器通過特殊字體生成的字符里包含一些特殊控制字符直接貼到banner.txt里會導(dǎo)致控制臺輸出亂碼。我踩過一次后來直接把banner.txt刪了也順便省了一點(diǎn)點(diǎn)啟動(dòng)時(shí)間。2.4 MySQL版本與字符集設(shè)置MySQL 我用的是 8.0。8.0 相比 5.7 在窗口函數(shù)、CTE、JSON支持上強(qiáng)太多而且默認(rèn)字符集從 latin1 改成了 utf8mb4對中文內(nèi)容尤其友好。需要特別注意的是建庫建表時(shí)要顯式指定字符集CREATE DATABASE IF NOT EXISTS info_contest DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;如果使用 5.7一定更要注意顯式指定字符集否則出現(xiàn)中文亂碼問題的根源可能就在這里。另外表設(shè)計(jì)時(shí) id 字段建議使用BIGINT AUTO_INCREMENT不要用INT。你可能搜過“mysql中int5”這里有個(gè)細(xì)節(jié)MySQL 里的INT(5)并不限制存儲范圍只是顯示寬度跟字段能存多少數(shù)值沒有關(guān)系。所以不要指望用括號里的數(shù)字限制某個(gè)字段的取值范圍這是新手容易理解的誤區(qū)。成績排名、排行榜的場景建議用DECIMAL(5,2)存儲百分制成績避免后續(xù)統(tǒng)計(jì)浮點(diǎn)誤差。3. 讓Shell真正可用從零到一的完整落地過程3.1 初始化項(xiàng)目骨架與統(tǒng)一響應(yīng)封裝后端項(xiàng)目我用 Spring Initializr 生成基礎(chǔ)結(jié)構(gòu)依賴選擇 Web、MyBatis、MySQL Driver、Lombok、Validation。生成之后第一步不是寫業(yè)務(wù)代碼而是先做統(tǒng)一響應(yīng)封裝。前后端分離的項(xiàng)目前后端必須約定一套統(tǒng)一的響應(yīng)格式否則接口聯(lián)調(diào)時(shí)每個(gè)人都有自己的返回結(jié)構(gòu)調(diào)試起來非常崩潰。我用的響應(yīng)結(jié)構(gòu)是這樣的Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }所有 Controller 都返回這個(gè)統(tǒng)一結(jié)構(gòu)前端 axios 攔截器里只需要判斷code是否為 200不用每個(gè)頁面單獨(dú)處理錯(cuò)誤分支。這里的code我自定義了一套401代表未登錄或token失效403代表沒有權(quán)限500代表服務(wù)端異常。前端拿到401時(shí)統(tǒng)一跳轉(zhuǎn)到登錄頁這個(gè)設(shè)計(jì)在后續(xù)聯(lián)調(diào)中省了大量砍邏輯的時(shí)間。3.2 登錄鑒權(quán)與JWT的實(shí)現(xiàn)細(xì)節(jié)信息知識賽系統(tǒng)涉及管理員和選手兩種角色必須有登錄鑒權(quán)。我選的是 JWTJSON Web Token方案沒有引入 Spring Security而是自己寫了一個(gè)簡單的攔截器來處理。為什么不用 Security因?yàn)橛脩舻慕巧w系簡單只有兩種角色沒有復(fù)雜的權(quán)限模型Security 的過濾器鏈反而顯得重配置不當(dāng)還會莫名其妙攔截靜態(tài)資源。自己寫攔截器代碼可控性更高邏輯也直觀。核心依賴是jjwt庫登錄成功后生成token把用戶ID和角色編碼塞進(jìn) token 的 claims 中public static String generateToken(Long userId, String role) { Calendar calendar Calendar.getInstance(); calendar.add(Calendar.SECOND, 7200); // token 有效期2小時(shí) return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setExpiration(calendar.getTime()) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }攔截器里通過 HandlerInterceptor 實(shí)現(xiàn)只攔截除了登錄、注冊以外的所有接口。核心邏輯是從請求頭拿到Authorization: Bearer xxx解析 token 并將 userId 放入 request 的 attribute 中后續(xù) Controller 可以直接獲取當(dāng)前登錄用戶。這里要注意一個(gè)最容易被忽視的點(diǎn)token 在有效期內(nèi)無法手動(dòng)失效如果用戶改了密碼或管理員封禁了某選手舊token依然有效。如果系統(tǒng)對安全性要求高需要引入 Redis 做 token 狀態(tài)管理。3.3 MyBatis動(dòng)態(tài)SQL與“if test indexof”的使用方法題庫管理功能涉及多條件篩選按題型、知識點(diǎn)、難度、關(guān)鍵字搜索題目。這種多條件動(dòng)態(tài)查詢是 MyBatis 最擅長處理的問題核心就是動(dòng)態(tài)SQL。在ExamQuestionMapper.xml中寫動(dòng)態(tài)SQL時(shí)除了常見的if、where標(biāo)簽還有一個(gè)技巧值得分享用if testkeyword ! null and keyword.indexOf(xx) ! -1來判斷傳入的字符串中是否包含某個(gè)特征。比如我需要在搜索時(shí)判斷“傳入的搜索詞是否包含了指定前綴”可以在 Mapper 接口中傳入一個(gè)字符串參數(shù)在 XML 中這樣處理select idselectQuestionList resultTypecom.example.entity.Question SELECT * FROM exam_question where if testquestionType ! null AND question_type #{questionType} /if if testkeyword ! null and keyword ! AND (question_content LIKE CONCAT(%, #{keyword}, %)) /if if testcategoryId ! null and categoryId 0 AND category_id #{categoryId} /if /where ORDER BY create_time DESC /select這個(gè)場景里隱含一個(gè)重要的字符串處理思路在test表達(dá)式中不能直接調(diào)用 Java 字符串的contains方法但indexOf() ! -1可以雖然臃腫但完全夠用。如果你項(xiàng)目里用了 MyBatis-PlusWrapper 里面也支持類似的方式但基礎(chǔ) MyBatis 在實(shí)際項(xiàng)目中依然有大量場景不可替代尤其是復(fù)雜SQL和多表關(guān)聯(lián)的時(shí)候。3.4 答題判分的核心邏輯事務(wù)與并發(fā)自動(dòng)判分是競賽系統(tǒng)的命脈。判分邏輯必須保證一致性選手提交答案后系統(tǒng)要同時(shí)完成三件事——保存答題明細(xì)、更新選手比賽成績、更新排行榜數(shù)據(jù)。這三件事是一個(gè)原子操作任何一步失敗都不能讓其他兩步生效所以必須用數(shù)據(jù)庫事務(wù)。SpringBoot 里用Transactional注解直接搞定。但我遇到過一個(gè)問題當(dāng)大量選手同時(shí)提交答題時(shí)因?yàn)槭聞?wù)里做了多個(gè)表的寫操作數(shù)據(jù)庫連接池一度被耗盡高峰期出現(xiàn)接口超時(shí)。后來做了兩個(gè)優(yōu)化將判分和保存成績解耦先保存答題明細(xì)再異步更新成績和排行榜。這樣主線程只用操作一張表事務(wù)時(shí)間大幅縮短。排行榜數(shù)據(jù)不實(shí)時(shí)全量重算而是采用 Redis 的zset按分?jǐn)?shù)排行賽后批量落庫。異步處理我引入了Async注解配合線程池而不是直接用new Thread()。線程池統(tǒng)一管理并發(fā)資源不會因?yàn)榇罅空埱笾苯哟虮缿?yīng)用。Override Transactional(rollbackFor Exception.class) public SubmitResultVO submitAnswer(SubmitRequestVO requestVO) { // 1. 保存答題明細(xì) // 2. 保存答題記錄主表 // 3. 觸發(fā)異步成績更新 }這里有一個(gè)重要的經(jīng)驗(yàn)事務(wù)和異步方法不要寫在同一個(gè)類里否則Async會因?yàn)?Spring AOP 的代理機(jī)制失效異步方法變成了同步執(zhí)行。具體原因是this調(diào)用不會經(jīng)過代理對象Spring 無法攔截。我第一版就是寫在了同一個(gè)Service里結(jié)果并發(fā)一上來性能直接下降排查了很久才發(fā)現(xiàn)是自調(diào)用問題。解法很簡單把異步方法抽到另一個(gè)ScoreUpdateService中通過注入調(diào)用。3.5 邏輯刪除的坑統(tǒng)計(jì)場景下需要“看見”已刪除數(shù)據(jù)MyBatis-Plus 提供了邏輯刪除功能這是配置TableLogic注解后所有查詢和刪除操作都會自動(dòng)追加WHERE deleted 0條件。這個(gè)設(shè)計(jì)很方便但有一個(gè)隱藏的坑在競賽系統(tǒng)里很致命成績統(tǒng)計(jì)時(shí)需要回溯某些已經(jīng)被管理員邏輯刪除的題目默認(rèn)查詢無論如何都查不出來。場景是這樣的比賽結(jié)束后我要統(tǒng)計(jì)一道錯(cuò)題的正確率來優(yōu)化題庫但其中幾個(gè)選項(xiàng)有問題管理員已經(jīng)刪除了這道題。默認(rèn)的MyBatis-Plus查詢會把這條記錄過濾掉結(jié)果統(tǒng)計(jì)數(shù)量對不上還找不到原因。解決方案有兩種使用InterceptorIgnore注解在指定Mapper方法上臨時(shí)忽略邏輯刪除攔截InterceptorIgnore(tenantLine true) Select(SELECT * FROM exam_question WHERE question_id #{id}) Question selectIgnoreLogicDelete(Param(id) Long id);用自定義SQL直接寫原生語句不走M(jìn)yBatis-Plus內(nèi)置方法。這里要說明一個(gè)容易混淆的細(xì)節(jié)如果自定義SQL是通過注解形式寫在Mapper接口上邏輯刪除攔截通常不生效因?yàn)閿r截器主要作用于MyBatis-Plus生成的方法。但如果自定義SQL寫在XML里同樣可能不受邏輯刪除限制具體要看配置。所以遇到“查不到數(shù)據(jù)”時(shí)先檢查是不是被邏輯刪除攔截了這是排查方向之一?；A(chǔ)操作中使用MP內(nèi)置方法刪除和查詢時(shí)都會自動(dòng)帶條件但在報(bào)表統(tǒng)計(jì)場景就要特別注意這個(gè)“禁用邏輯刪除”的問題。4. Vue3前臺與后臺雙端分離開發(fā)選手端答題體驗(yàn)與管理員后臺4.1 Vite Vue3項(xiàng)目基礎(chǔ)搭建與目錄劃分前端我創(chuàng)建了兩個(gè)獨(dú)立項(xiàng)目一個(gè)是選手端一個(gè)是管理員端。雖然Vue3支持路由懶加載和動(dòng)態(tài)組件但兩個(gè)端UI差異太大放一起會導(dǎo)致構(gòu)建體積越來越大訪問速度受到明顯影響。分離之后選手端打包產(chǎn)物只有幾十KB首屏加載非?？?。初始化命令用 Vite 就行比 Vue CLI 快很多npm create vitelatest contest-user -- --template vue npm create vitelatest contest-admin -- --template vueVite 的好處不用多說開發(fā)服務(wù)器啟動(dòng)快、熱更新快Vue3 官方也推薦。裝好之后我會先做一個(gè)基礎(chǔ)目錄規(guī)劃main.js 里配好路由和狀態(tài)管理。我沒有使用 Pinia 做全局狀態(tài)因?yàn)闃I(yè)務(wù)場景中需要跨頁面共享的狀態(tài)很少無非是用戶token和當(dāng)前比賽信息用 localStorage 加組件間傳參就能解決過度設(shè)計(jì)反而增加維護(hù)成本。4.2 Vue3核心特性在答題模塊中的應(yīng)用computed與倒計(jì)時(shí)選手端答題頁面是整個(gè)系統(tǒng)中交互最復(fù)雜的部分。題目的切換、選項(xiàng)選中狀態(tài)、答題進(jìn)度、剩余時(shí)間這些都是有狀態(tài)的UI。Vue3 的組合式APIComposition API處理起來邏輯集中比 Options API 清晰得多。我最常用的是computed用來根據(jù)當(dāng)前答案狀態(tài)動(dòng)態(tài)計(jì)算進(jìn)度script setup import { ref, computed } from vue const answerMap ref({}) const questionTotal ref(10) const answeredCount computed(() { return Object.keys(answerMap.value).filter(key answerMap.value[key] ! ).length }) const progressPercent computed(() { if (questionTotal.value 0) return 0 return Math.round((answeredCount.value / questionTotal.value) * 100) }) /scriptcomputed是Vue3里被問得最多的高頻API它和watch的最大區(qū)別是computed 關(guān)注的是“基于已有數(shù)據(jù)計(jì)算并返回新值”watch 關(guān)注的是“數(shù)據(jù)變化時(shí)執(zhí)行副作用”。在做答題倒計(jì)時(shí)功能時(shí)我會把剩余時(shí)間用ref保存配合setInterval每秒修改const remainSeconds ref(1800) let timer null function startTimer() { timer setInterval(() { remainSeconds.value-- if (remainSeconds.value 0) { clearInterval(timer) autoSubmit() } }, 1000) }用ref包一層的時(shí)間變量才能在UI中響應(yīng)式變化這是一個(gè)容易踩坑的點(diǎn)。直接把let remainSeconds 1800寫在setup里頁面是永遠(yuǎn)不會更新的。還需要注意在組件卸載時(shí)一定要清除定時(shí)器否則切路由后定時(shí)器還在跑會出現(xiàn)頁面已經(jīng)跳走了但自動(dòng)交卷邏輯還在執(zhí)行的詭異現(xiàn)象。4.3 動(dòng)態(tài)路由與權(quán)限控制管理員后臺最多的時(shí)候有兩類入口管理員和選手模擬練習(xí)場景。如果不用權(quán)限控制任何登進(jìn)系統(tǒng)的人都能訪問后臺接口這是嚴(yán)重的安全漏洞。我采用動(dòng)態(tài)路由方案登錄后根據(jù)返回的角色編碼使用 Vue Router 的addRoute方法動(dòng)態(tài)添加對應(yīng)權(quán)限的路由表。核心思路是定義一份常量路由表登錄頁、首頁、比賽列表和一份動(dòng)態(tài)路由表后臺管理頁。用戶登錄成功后前端判斷角色如果是admin就動(dòng)態(tài)注冊后臺管理路由如果是user只注冊選手相關(guān)的路由。const router createRouter({ history: createWebHistory(), routes: constantRoutes }) export function setupDynamicRoutes(role) { if (role admin) { adminRoutes.forEach(route { router.addRoute(route) }) } }這里注意一個(gè)很多教程不會明說的細(xì)節(jié)addRoute添加的路由是響應(yīng)式的但如果用戶刷新頁面動(dòng)態(tài)添加的路由會丟失因?yàn)榍岸藘?nèi)存被重新加載了。因此刷新后的路由重建邏輯必須放在路由守衛(wèi)里每次進(jìn)入應(yīng)用時(shí)根據(jù) token 中的角色重新注冊。如果不做這一步程序員后臺刷新一下就會白屏。4.4 axios封裝與請求攔截axios 封裝是所有前后端分離項(xiàng)目的標(biāo)配。我會首先創(chuàng)建 axios 實(shí)例設(shè)置基礎(chǔ)URL然后添加請求攔截器和響應(yīng)攔截器。請求攔截器里附帶 token響應(yīng)攔截器里統(tǒng)一處理錯(cuò)誤碼import axios from axios import router from ../router const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code 401) { localStorage.removeItem(token) router.push(/login) return Promise.reject(new Error(未登錄)) } if (res.code ! 200) { return Promise.reject(new Error(res.message)) } return res.data }, error { return Promise.reject(error) } )把401處理放在攔截器里的好處是所有接口不用各自判斷登錄過期統(tǒng)一跳轉(zhuǎn)登錄頁。業(yè)務(wù)代碼里拿到的直接就是data部分不用層層剝開response.data.data這種冗余結(jié)構(gòu)。這套封裝寫完以后整場開發(fā)里新增頁面都只用寫業(yè)務(wù)請求方法不用關(guān)心錯(cuò)誤處理。4.5 Vite代理與后端聯(lián)調(diào)開發(fā)環(huán)境聯(lián)調(diào)時(shí)前端頁面在localhost:5173后端接口在localhost:8080必然存在跨域問題。解決方式有兩種后端配置 CORS 全局跨域或者前端 Vite 配置代理。我推薦用 Vite 代理因?yàn)殚_發(fā)環(huán)境走代理更接近生產(chǎn)環(huán)境部署方式而且后端不用額外改配置。在vite.config.js中export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })這樣前端請求/api/xxx會被代理轉(zhuǎn)發(fā)到后端http://localhost:8080/api/xxx。生產(chǎn)環(huán)境部署時(shí)用 Nginx 將/api反向代理到 Java 服務(wù)即可前后端代碼不用做任何修改。這個(gè)方案在本地開發(fā)、服務(wù)器部署、域名綁定三個(gè)環(huán)節(jié)中都驗(yàn)證過是目前最推薦的做法。5. 部署落地與線上問題排查MySQL安裝、Docker部署、OOM、慢SQL5.1 MySQL部署方式選擇本機(jī)安裝還是Docker信息知識賽系統(tǒng)的部署方案我前后試過兩種。第一種是本機(jī)安裝 MySQL適合團(tuán)隊(duì)開發(fā)環(huán)境直接在官網(wǎng)下載安裝包步驟比較繁瑣官方安裝包在 Windows 下還要做環(huán)境變量配置、初始化數(shù)據(jù)目錄、注冊服務(wù)對新手來說難度不小網(wǎng)上搜“mysql安裝教程”和“mysql安裝配置教程”的人數(shù)也證明了這是一個(gè)不低的門檻。第二種是 Docker 方式適合服務(wù)器環(huán)境一個(gè)命令就能拉起數(shù)據(jù)庫。生產(chǎn)環(huán)境我用的是 Docker 部署 MySQLdocker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e MYSQL_DATABASEinfo_contest \ --restartalways \ mysql:8.0用 Docker 之后最大的好處是可移植性非常強(qiáng)換一臺服務(wù)器一條命令加一個(gè)數(shù)據(jù)目錄掛載就能恢復(fù)整個(gè)數(shù)據(jù)庫。需要注意容器刪除后數(shù)據(jù)會丟失所以一定要掛載數(shù)據(jù)目錄-v /opt/mysql-data:/var/lib/mysql如果你是在服務(wù)器上裝 Docker 也遇到 pull 鏡像慢的問題可以配置國內(nèi)鏡像源或者檢查網(wǎng)絡(luò)環(huán)境是否穩(wěn)定這些在實(shí)際操作中都比改代碼更耗時(shí)間。5.2 SpringBoot應(yīng)用打包JDK8在Docker中的那點(diǎn)事我云服務(wù)器上安裝的是 Docker Desktop 環(huán)境實(shí)際上服務(wù)器用的是 Docker Engine本地開發(fā)機(jī)用 Docker Desktop 測試鏡像。項(xiàng)目的JDK版本是8SpringBoot 2.7 默認(rèn)的打包方式打出來的是可執(zhí)行 jar 包理論上java -jar app.jar就能運(yùn)行。但容器部署時(shí)還是需要一個(gè)帶 JDK8 基礎(chǔ)鏡像的 DockerfileFROM openjdk:8-jre-alpine LABEL maintaineryourname COPY target/info-contest.jar /app.jar ENV JAVA_OPTS-Xms256m -Xmx512m -Dfile.encodingUTF-8 ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar /app.jar]這里有一個(gè)非常容易踩的坑SpringBoot 2.7 打包出的 jar 在 Docker 中啟動(dòng)時(shí)可能會出現(xiàn)java: outofmemoryerror: insufficient memory之類的內(nèi)存不足錯(cuò)誤。原因通常是 Docker 容器的內(nèi)存限制過于緊張或者 JVM 默認(rèn)按照宿主機(jī)內(nèi)存大小分配堆內(nèi)存結(jié)果容器配額不夠。解決方式是顯式指定 JVM 參數(shù)-Xms256m -Xmx512m限制堆內(nèi)存大小并加上-XX:UseG1GC。還有一點(diǎn)如果基礎(chǔ)鏡像用的是openjdk:8-jre而不是alpine瘦身版鏡像體積會多出上百M(fèi)B按需取舍?；谌萜飨拗苼碓O(shè)置-Xmx參數(shù)有時(shí)候還可以用-XX:MaxRAMPercentage75.0替代固定數(shù)值讓JVM按容器內(nèi)存配額自動(dòng)按比例分配這樣在高并發(fā)和低負(fù)載場景下都能自適應(yīng)。5.3 慢查詢與索引優(yōu)化排行榜為什么越跑越慢項(xiàng)目上線后跑了三場比賽排行榜接口開始出現(xiàn)明顯的延遲。最開始我以為是服務(wù)器帶寬和并發(fā)的問題后來查看日志發(fā)現(xiàn)一條 SQL 執(zhí)行超過了 2 秒定位到成績表的查詢沒走索引。原因很直白成績表里user_id和contest_id字段沒有建立聯(lián)合索引數(shù)據(jù)量到了幾萬條之后全表掃描時(shí)間陡增。解決辦法是加聯(lián)合索引ALTER TABLE exam_score ADD INDEX idx_user_contest (user_id, contest_id);加完之后接口響應(yīng)時(shí)間從2秒降到了100毫秒以內(nèi)變化非常明顯。這個(gè)經(jīng)歷給我一個(gè)很深的教訓(xùn)數(shù)據(jù)量小的時(shí)候感知不到索引的重要性但一定要在設(shè)計(jì)階段就要做好索引規(guī)劃。下面是建表時(shí)就用到的參考索引設(shè)計(jì)表名索引字段場景exam_questioncategory_id按分類篩選題目exam_questionquestion_type按題型篩選題目exam_scoreuser_id, contest_id查詢用戶某場比賽成績exam_scorecontest_id, score排行榜按分?jǐn)?shù)排序exam_questiondifficulty按難度篩選在 MySQL 中批量插入數(shù)據(jù)的場景下還遇到過int5這個(gè)關(guān)鍵詞相關(guān)的疑惑。很多人在寫 update 語句時(shí)會對整數(shù)字段做score score 5的累加操作并且在 MySQL 中這種表達(dá)式不是按照字符串拼接來處理的是真的數(shù)值相加。但要注意如果字段定義為INT累加超過溢出時(shí) MySQL 會報(bào)錯(cuò)所以設(shè)計(jì)成績或計(jì)數(shù)類字段時(shí)預(yù)留合理的字段范圍很重要。5.4 MyBatis緩存一級緩存引發(fā)的數(shù)據(jù)不一致問題線上有一個(gè)詭異的問題同一個(gè)用戶查詢比賽成績連續(xù)調(diào)用兩次接口第一次返回了更新后的成績第二次竟然返回了舊數(shù)據(jù)?；舜蟀胩炫挪樽詈蠖ㄎ坏绞?MyBatis 一級緩存導(dǎo)致的。MyBatis 默認(rèn)開啟一級緩存作用范圍是同一個(gè) SqlSession 內(nèi)。在 Spring 整合環(huán)境中每次請求都會新建 SqlSession看起來不會觸發(fā)緩存問題但如果某個(gè)Service方法里多次執(zhí)行了同一個(gè)查詢而中間又更新了數(shù)據(jù)此時(shí)一級緩存可能會把第二次查詢結(jié)果攔截住返回舊數(shù)據(jù)。解決方式有三種在 Mapper 查詢語句上設(shè)置flushCachetrue強(qiáng)制每次查詢都清空一級緩存。在更新操作后手動(dòng)調(diào)用SqlSession.clearCache()但代碼侵入性有點(diǎn)強(qiáng)。如果用了 MyBatis-Plus可以在查詢時(shí)指定last(LIMIT 1)也不一定能完全繞過緩存最穩(wěn)妥的還是結(jié)合具體場景控制。這個(gè)問題的核心是理解 MyBatis 的緩存機(jī)制。一級緩存默認(rèn)開啟二級緩存默認(rèn)關(guān)閉。對于競賽系統(tǒng)這種對數(shù)據(jù)一致性要求較高的場景我建議盡量不依賴MyBatis緩存而是把緩存層放在 Redis 上手動(dòng)控制失效時(shí)機(jī)。這樣在成績、排行榜等數(shù)據(jù)變化頻繁的場景下才能保證用戶看不到過期數(shù)據(jù)。5.5 Vue3前端部署與Nginx配置前端打包后是一堆靜態(tài)文件部署到 Nginx 時(shí)有一個(gè)常見的坑直接刷新頁面會返回404。原因在于 Vue Router 使用的是 history 模式前端路由在瀏覽器上表現(xiàn)為真實(shí)的url路徑但服務(wù)器上并沒有對應(yīng)的物理文件Nginx 找不到文件就返回404了。解決方案是配置 try_files將所有的路由請求都重定向到 index.htmlserver { listen 80; server_name yourdomain.com; root /opt/contest-web/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }這是一份非常常見且能直接用的 Nginx 配置。靜態(tài)文件交給 Nginx 托管Java 接口走反向代理Nginx 同時(shí)承擔(dān)了靜態(tài)資源服務(wù)器和反向代理的雙重角色。部署完之后前端刷新不再404接口請求也走同域沒有跨域問題。6. 從第一版到第二版我踩過的坑和重構(gòu)思路這個(gè)信息知識賽系統(tǒng)做到今天前后經(jīng)歷了兩次比較大的重構(gòu)。第一次重構(gòu)是前端從 Vue2 ElementUI 遷移到 Vue3 Vite這里涉及了組件庫兼容性、響應(yīng)式API的改寫、路由模式升級等一堆問題工作量比想象中大。第二次重構(gòu)是后端引入了 Redis 緩存排行榜和異步判分這部分改動(dòng)主要針對并發(fā)場景因?yàn)榈谝话嬖谡鎸?shí)比賽一開、幾百人同時(shí)提交時(shí)數(shù)據(jù)庫連接池差點(diǎn)被打滿。如果讓我重新做一遍我會在第一版就做三個(gè)決定數(shù)據(jù)表一定按規(guī)范化設(shè)計(jì)不圖省事用JSON字段存復(fù)雜結(jié)構(gòu)。業(yè)務(wù)邏輯中一定區(qū)分主流程和異步流程答題保存、判分、匯總、排行可以異步化。前端從一開始就用 Vue3 Vite用組合式API組織邏輯不要用 Options API 寫舊的思路。關(guān)于 MySQL 和 MyBatis 的關(guān)系想再補(bǔ)充一句個(gè)人看法。MyBatis 是一個(gè)非常靈活的持久層框架它不像 JPA 那樣給你一套完整的對象關(guān)系映射而是把SQL的控制權(quán)完全交給開發(fā)人員。這對信息知識賽系統(tǒng)這種有多條件查詢、多表關(guān)聯(lián)、事務(wù)一致性要求的場景反而更友好。因?yàn)槟憧梢跃_控制每一條SQL知道它執(zhí)行了什么慢在哪。但這也意味著開發(fā)者必須自己保證SQL質(zhì)量不能指望框架優(yōu)化。所以寫動(dòng)態(tài)SQL時(shí)一定要慢下心多考慮是否走索引是否能避免SELECT *這些細(xì)節(jié)在數(shù)據(jù)量上來后都會顯現(xiàn)出來。MyBatis 的工作原理簡單說就是通過動(dòng)態(tài)代理為 Mapper 接口生成代理對象解析 SQL 并執(zhí)行把結(jié)果集通過反射映射成實(shí)體對象。真正理解這一點(diǎn)后你排查問題就會有的放矢而不是遇到Bug只能盲猜配置。這套系統(tǒng)目前的版本在功能上已經(jīng)完整覆蓋了信息知識賽項(xiàng)目的基本需求用戶注冊登錄、題庫管理、比賽創(chuàng)建、在線答題、自動(dòng)判分、排行榜、成績查詢。后續(xù)計(jì)劃中的擴(kuò)展方向是支持自定義組卷規(guī)則、多級知識點(diǎn)樹、賽后報(bào)告導(dǎo)出等。核心架構(gòu)已經(jīng)穩(wěn)定擴(kuò)展只是往上加模塊的問題。最后分享一個(gè)我實(shí)際開發(fā)中的體會做這類系統(tǒng)技術(shù)難點(diǎn)其實(shí)不是讓代碼“跑起來”而是讓整個(gè)項(xiàng)目在多人協(xié)作、快速迭代的過程中始終維持清晰的結(jié)構(gòu)。前后端分離、統(tǒng)一接口規(guī)范、日志排查鏈路完整、部署可復(fù)現(xiàn)這些工程化的事做到位功能開發(fā)本身就只是時(shí)間問題。信息知識賽系統(tǒng)的源碼是我逐步打磨出來的希望這篇拆解能幫你繞開那些我踩過的坑。 基于SpringBoot+Vue3的前后端分離知識競賽系統(tǒng)實(shí)踐
做信息知識賽系統(tǒng)這件事我前后折騰了兩個(gè)版本。第一個(gè)版本是給一個(gè)培訓(xùn)機(jī)構(gòu)做的內(nèi)部競賽平臺需求很樸素在線答題、自動(dòng)判分、成績排行。當(dāng)時(shí)時(shí)間緊我圖省事直接把題庫和答題邏輯堆在一個(gè)單體應(yīng)用里前端用服務(wù)端模板渲染勉強(qiáng)能跑但后續(xù)加功能的時(shí)候差點(diǎn)把自己逼瘋。第二個(gè)版本徹底重寫采用 SpringBoot Vue3 MyBatis MySQL 的前后端分離架構(gòu)也就是這個(gè)信息知識賽系統(tǒng)現(xiàn)在的樣子。整套系統(tǒng)沉淀下來我覺得最值得記錄的并不是“怎么把代碼跑起來”而是整個(gè)設(shè)計(jì)過程中的技術(shù)選型邏輯、數(shù)據(jù)表如何建模、答題判分的事務(wù)一致性怎么保證、以及部署上線后那些摸爬滾打的優(yōu)化過程。這個(gè)項(xiàng)目適合正在學(xué)習(xí)前后端分離開發(fā)的人參考也適合需要快速搭建競賽答題類系統(tǒng)的團(tuán)隊(duì)直接借鑒。我會把核心實(shí)現(xiàn)思路、關(guān)鍵代碼、踩坑記錄都攤開來講不會只貼一堆跑不通的碎片代碼。1. 信息知識賽系統(tǒng)的業(yè)務(wù)邊界不只做答題還要管人、管題、管成績1.1 競賽系統(tǒng)的基礎(chǔ)角色與核心流程信息知識賽系統(tǒng)本質(zhì)上是一個(gè)在線考試/競賽平臺但和學(xué)校里的期末考試系統(tǒng)有一個(gè)明顯差異競賽場景更強(qiáng)調(diào)即時(shí)反饋和排行榜激勵(lì)。整套系統(tǒng)的核心流程其實(shí)不復(fù)雜管理員維護(hù)題庫、創(chuàng)建一場比賽、配置比賽規(guī)則選手在指定時(shí)間內(nèi)進(jìn)入賽場答題提交后系統(tǒng)自動(dòng)判分最終生成個(gè)人成績和排行榜。圍繞這個(gè)流程系統(tǒng)需要拆出三大模塊用戶模塊管理選手和管理員的身份涉及注冊、登錄、權(quán)限控制。題庫與比賽模塊維護(hù)題目單選、多選、判斷、填空、創(chuàng)建賽場、配置答題時(shí)間和題目數(shù)量。答題與成績模塊選手答題、自動(dòng)判分、個(gè)人成績記錄、排行榜統(tǒng)計(jì)。這三個(gè)模塊劃分清楚之后前后端分離API的設(shè)計(jì)邊界也就自然出來了。后端只需要按業(yè)務(wù)域暴露RESTful接口前端Vue3負(fù)責(zé)呈現(xiàn)和交互不用再像傳統(tǒng)單體應(yīng)用那樣把頁面邏輯和服務(wù)端渲染混在一起。1.2 為什么選前后端分離而不是繼續(xù)用模板引擎如果你只是做一個(gè)小型內(nèi)部工具用Thymeleaf或者JSP這種服務(wù)端渲染方案確實(shí)更快項(xiàng)目結(jié)構(gòu)也更簡單。但信息知識賽系統(tǒng)有一個(gè)特性管理員后臺和選手端頁面交互差異極大。后臺是典型的管理系統(tǒng)布局側(cè)邊欄、表格、表單彈窗選手端則是答題倒計(jì)時(shí)、題目切換、實(shí)時(shí)進(jìn)度。這兩套UI如果都塞在服務(wù)端渲染里前端JS邏輯會非常臃腫后端的Controller層也會被迫去適配兩類頁面的數(shù)據(jù)拼裝。前后端分離之后后端只做API提供方前端可以分別構(gòu)建管理員端和選手端兩套獨(dú)立的Vue3應(yīng)用開發(fā)和聯(lián)調(diào)完全并行。還有一個(gè)隱性的好處后續(xù)如果要出一套小程序或者移動(dòng)端App后端API可以直接復(fù)用不需要重寫業(yè)務(wù)邏輯。對于競賽系統(tǒng)這種需要短期上線、后續(xù)多有迭代需求的場景來說這個(gè)架構(gòu)彈性非常重要。團(tuán)隊(duì)技術(shù)棧需要統(tǒng)一前端Vue3 Vite后端SpringBoot數(shù)據(jù)庫MySQL。前后端通過JSON格式數(shù)據(jù)交互、JWT做身份認(rèn)證聯(lián)調(diào)時(shí)只需約定接口文檔。這套組合的優(yōu)勢在后續(xù)開發(fā)和維護(hù)中體現(xiàn)得特別明顯。2. 數(shù)據(jù)表設(shè)計(jì)與版本選型先理順數(shù)據(jù)關(guān)系再寫業(yè)務(wù)代碼2.1 核心表結(jié)構(gòu)設(shè)計(jì)思路數(shù)據(jù)表是整個(gè)系統(tǒng)的地基。信息知識賽系統(tǒng)的數(shù)據(jù)模型其實(shí)不復(fù)雜核心是四張表用戶表、題目表、比賽表、答題記錄表。命名上我統(tǒng)一采用小寫下劃線風(fēng)格字段都給上注釋方便后期維護(hù)。用戶表的關(guān)鍵字段是角色字段用于區(qū)分管理員和普通選手題目表要區(qū)分題型而且要考慮到選項(xiàng)的存儲方式這是第一次設(shè)計(jì)時(shí)容易踩坑的地方。答題記錄表則要記錄每次作答的內(nèi)容和判分結(jié)果。我當(dāng)時(shí)設(shè)計(jì)的時(shí)候經(jīng)歷了一次變更第一版的題目表直接用一個(gè)options字段以JSON字符串存儲選項(xiàng)想著這樣靈活但后續(xù)做題目統(tǒng)計(jì)和選項(xiàng)分析時(shí)很難直接用SQL處理。第二次重構(gòu)時(shí)拆出了題目選項(xiàng)表和答題明細(xì)表雖然查詢時(shí)關(guān)聯(lián)表多了一層但靈活性和可維護(hù)性提升非常明顯。如果你的系統(tǒng)未來有導(dǎo)出成績、統(tǒng)計(jì)正確率、做試題分析的需求建議從一開始就按這種規(guī)范化表結(jié)構(gòu)設(shè)計(jì)。2.2 SpringBoot版本的坑2.7還是3.x這可能是新手組項(xiàng)目時(shí)最容易踩的坑。SpringBoot 3.x 已經(jīng)發(fā)布很長時(shí)間了新項(xiàng)目大概率會默認(rèn)選擇3.3或更高版本但有一個(gè)硬性門檻SpringBoot 3.x 強(qiáng)制要求 JDK17。如果你的團(tuán)隊(duì)本機(jī)環(huán)境還是 JDK8很多現(xiàn)網(wǎng)服務(wù)器確實(shí)是那會出現(xiàn)一啟動(dòng)就報(bào)錯(cuò)、Maven依賴下載失敗等一堆莫名其妙的問題。我的建議是分成兩種情況團(tuán)隊(duì)有統(tǒng)一的 JDK17 環(huán)境或者這是全新項(xiàng)目直接上 SpringBoot 3.x JDK17后續(xù)維護(hù)周期更長。團(tuán)隊(duì)還在用 JDK8或者要兼容老服務(wù)器那就老老實(shí)實(shí)選 SpringBoot 2.7.x 版本它是 2.x 系列的最后一個(gè)大版本穩(wěn)定性和生態(tài)兼容性都非常好。我這個(gè)項(xiàng)目因?yàn)樾枰嫒輬F(tuán)隊(duì)現(xiàn)有的 JDK8 環(huán)境最終選的是 SpringBoot 2.7.18 JDK8 MyBatis 3.5.x。這套組合運(yùn)行非常穩(wěn)定而且網(wǎng)上遇到問題能搜到的解決方案最多不會因?yàn)榘姹咎露也坏酱鸢?。注意SpringBoot 2.7.x 和 3.x 在配置項(xiàng)上也有一些差異比如spring.redis.host在3.x變成了spring.data.redis.host從 2.7 遷移到 3.x 時(shí)得逐一排查。如果項(xiàng)目已經(jīng)上線不建議在業(yè)務(wù)繁忙期直接升版本。2.3 “版本太高”的那些連帶問題Banner、打包、依賴沖突網(wǎng)上關(guān)于“springboot版本太高”的搜索量一直不低說明很多人被版本問題坑過。除了上面說的 JDK 版本還有幾個(gè)連帶問題值得注意新版本SpringBoot對Maven和Gradle的版本有要求如果用太老的構(gòu)建工具版本會直接報(bào)錯(cuò)。部分第三方starter沒有及時(shí)跟進(jìn)新版本比如一些老牌的驗(yàn)證碼、Excel處理庫在SpringBoot 3.x下可能不兼容Jakarta命名空間。高版本默認(rèn)開啟了更嚴(yán)格的依賴檢查多模塊項(xiàng)目里容易出現(xiàn)依賴沖突。再說個(gè)好玩的事SpringBoot 有一個(gè) banner 生成器的小玩意可以在啟動(dòng)時(shí)打印一個(gè)自定義ASCII藝術(shù)字。很多教程喜歡拿這個(gè)當(dāng)入門案例但要注意 —— 某些在線banner生成器通過特殊字體生成的字符里包含一些特殊控制字符直接貼到banner.txt里會導(dǎo)致控制臺輸出亂碼。我踩過一次后來直接把banner.txt刪了也順便省了一點(diǎn)點(diǎn)啟動(dòng)時(shí)間。2.4 MySQL版本與字符集設(shè)置MySQL 我用的是 8.0。8.0 相比 5.7 在窗口函數(shù)、CTE、JSON支持上強(qiáng)太多而且默認(rèn)字符集從 latin1 改成了 utf8mb4對中文內(nèi)容尤其友好。需要特別注意的是建庫建表時(shí)要顯式指定字符集CREATE DATABASE IF NOT EXISTS info_contest DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;如果使用 5.7一定更要注意顯式指定字符集否則出現(xiàn)中文亂碼問題的根源可能就在這里。另外表設(shè)計(jì)時(shí) id 字段建議使用BIGINT AUTO_INCREMENT不要用INT。你可能搜過“mysql中int5”這里有個(gè)細(xì)節(jié)MySQL 里的INT(5)并不限制存儲范圍只是顯示寬度跟字段能存多少數(shù)值沒有關(guān)系。所以不要指望用括號里的數(shù)字限制某個(gè)字段的取值范圍這是新手容易理解的誤區(qū)。成績排名、排行榜的場景建議用DECIMAL(5,2)存儲百分制成績避免后續(xù)統(tǒng)計(jì)浮點(diǎn)誤差。3. 讓Shell真正可用從零到一的完整落地過程3.1 初始化項(xiàng)目骨架與統(tǒng)一響應(yīng)封裝后端項(xiàng)目我用 Spring Initializr 生成基礎(chǔ)結(jié)構(gòu)依賴選擇 Web、MyBatis、MySQL Driver、Lombok、Validation。生成之后第一步不是寫業(yè)務(wù)代碼而是先做統(tǒng)一響應(yīng)封裝。前后端分離的項(xiàng)目前后端必須約定一套統(tǒng)一的響應(yīng)格式否則接口聯(lián)調(diào)時(shí)每個(gè)人都有自己的返回結(jié)構(gòu)調(diào)試起來非常崩潰。我用的響應(yīng)結(jié)構(gòu)是這樣的Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }所有 Controller 都返回這個(gè)統(tǒng)一結(jié)構(gòu)前端 axios 攔截器里只需要判斷code是否為 200不用每個(gè)頁面單獨(dú)處理錯(cuò)誤分支。這里的code我自定義了一套401代表未登錄或token失效403代表沒有權(quán)限500代表服務(wù)端異常。前端拿到401時(shí)統(tǒng)一跳轉(zhuǎn)到登錄頁這個(gè)設(shè)計(jì)在后續(xù)聯(lián)調(diào)中省了大量砍邏輯的時(shí)間。3.2 登錄鑒權(quán)與JWT的實(shí)現(xiàn)細(xì)節(jié)信息知識賽系統(tǒng)涉及管理員和選手兩種角色必須有登錄鑒權(quán)。我選的是 JWTJSON Web Token方案沒有引入 Spring Security而是自己寫了一個(gè)簡單的攔截器來處理。為什么不用 Security因?yàn)橛脩舻慕巧w系簡單只有兩種角色沒有復(fù)雜的權(quán)限模型Security 的過濾器鏈反而顯得重配置不當(dāng)還會莫名其妙攔截靜態(tài)資源。自己寫攔截器代碼可控性更高邏輯也直觀。核心依賴是jjwt庫登錄成功后生成token把用戶ID和角色編碼塞進(jìn) token 的 claims 中public static String generateToken(Long userId, String role) { Calendar calendar Calendar.getInstance(); calendar.add(Calendar.SECOND, 7200); // token 有效期2小時(shí) return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setExpiration(calendar.getTime()) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }攔截器里通過 HandlerInterceptor 實(shí)現(xiàn)只攔截除了登錄、注冊以外的所有接口。核心邏輯是從請求頭拿到Authorization: Bearer xxx解析 token 并將 userId 放入 request 的 attribute 中后續(xù) Controller 可以直接獲取當(dāng)前登錄用戶。這里要注意一個(gè)最容易被忽視的點(diǎn)token 在有效期內(nèi)無法手動(dòng)失效如果用戶改了密碼或管理員封禁了某選手舊token依然有效。如果系統(tǒng)對安全性要求高需要引入 Redis 做 token 狀態(tài)管理。3.3 MyBatis動(dòng)態(tài)SQL與“if test indexof”的使用方法題庫管理功能涉及多條件篩選按題型、知識點(diǎn)、難度、關(guān)鍵字搜索題目。這種多條件動(dòng)態(tài)查詢是 MyBatis 最擅長處理的問題核心就是動(dòng)態(tài)SQL。在ExamQuestionMapper.xml中寫動(dòng)態(tài)SQL時(shí)除了常見的if、where標(biāo)簽還有一個(gè)技巧值得分享用if testkeyword ! null and keyword.indexOf(xx) ! -1來判斷傳入的字符串中是否包含某個(gè)特征。比如我需要在搜索時(shí)判斷“傳入的搜索詞是否包含了指定前綴”可以在 Mapper 接口中傳入一個(gè)字符串參數(shù)在 XML 中這樣處理select idselectQuestionList resultTypecom.example.entity.Question SELECT * FROM exam_question where if testquestionType ! null AND question_type #{questionType} /if if testkeyword ! null and keyword ! AND (question_content LIKE CONCAT(%, #{keyword}, %)) /if if testcategoryId ! null and categoryId 0 AND category_id #{categoryId} /if /where ORDER BY create_time DESC /select這個(gè)場景里隱含一個(gè)重要的字符串處理思路在test表達(dá)式中不能直接調(diào)用 Java 字符串的contains方法但indexOf() ! -1可以雖然臃腫但完全夠用。如果你項(xiàng)目里用了 MyBatis-PlusWrapper 里面也支持類似的方式但基礎(chǔ) MyBatis 在實(shí)際項(xiàng)目中依然有大量場景不可替代尤其是復(fù)雜SQL和多表關(guān)聯(lián)的時(shí)候。3.4 答題判分的核心邏輯事務(wù)與并發(fā)自動(dòng)判分是競賽系統(tǒng)的命脈。判分邏輯必須保證一致性選手提交答案后系統(tǒng)要同時(shí)完成三件事——保存答題明細(xì)、更新選手比賽成績、更新排行榜數(shù)據(jù)。這三件事是一個(gè)原子操作任何一步失敗都不能讓其他兩步生效所以必須用數(shù)據(jù)庫事務(wù)。SpringBoot 里用Transactional注解直接搞定。但我遇到過一個(gè)問題當(dāng)大量選手同時(shí)提交答題時(shí)因?yàn)槭聞?wù)里做了多個(gè)表的寫操作數(shù)據(jù)庫連接池一度被耗盡高峰期出現(xiàn)接口超時(shí)。后來做了兩個(gè)優(yōu)化將判分和保存成績解耦先保存答題明細(xì)再異步更新成績和排行榜。這樣主線程只用操作一張表事務(wù)時(shí)間大幅縮短。排行榜數(shù)據(jù)不實(shí)時(shí)全量重算而是采用 Redis 的zset按分?jǐn)?shù)排行賽后批量落庫。異步處理我引入了Async注解配合線程池而不是直接用new Thread()。線程池統(tǒng)一管理并發(fā)資源不會因?yàn)榇罅空埱笾苯哟虮缿?yīng)用。Override Transactional(rollbackFor Exception.class) public SubmitResultVO submitAnswer(SubmitRequestVO requestVO) { // 1. 保存答題明細(xì) // 2. 保存答題記錄主表 // 3. 觸發(fā)異步成績更新 }這里有一個(gè)重要的經(jīng)驗(yàn)事務(wù)和異步方法不要寫在同一個(gè)類里否則Async會因?yàn)?Spring AOP 的代理機(jī)制失效異步方法變成了同步執(zhí)行。具體原因是this調(diào)用不會經(jīng)過代理對象Spring 無法攔截。我第一版就是寫在了同一個(gè)Service里結(jié)果并發(fā)一上來性能直接下降排查了很久才發(fā)現(xiàn)是自調(diào)用問題。解法很簡單把異步方法抽到另一個(gè)ScoreUpdateService中通過注入調(diào)用。3.5 邏輯刪除的坑統(tǒng)計(jì)場景下需要“看見”已刪除數(shù)據(jù)MyBatis-Plus 提供了邏輯刪除功能這是配置TableLogic注解后所有查詢和刪除操作都會自動(dòng)追加WHERE deleted 0條件。這個(gè)設(shè)計(jì)很方便但有一個(gè)隱藏的坑在競賽系統(tǒng)里很致命成績統(tǒng)計(jì)時(shí)需要回溯某些已經(jīng)被管理員邏輯刪除的題目默認(rèn)查詢無論如何都查不出來。場景是這樣的比賽結(jié)束后我要統(tǒng)計(jì)一道錯(cuò)題的正確率來優(yōu)化題庫但其中幾個(gè)選項(xiàng)有問題管理員已經(jīng)刪除了這道題。默認(rèn)的MyBatis-Plus查詢會把這條記錄過濾掉結(jié)果統(tǒng)計(jì)數(shù)量對不上還找不到原因。解決方案有兩種使用InterceptorIgnore注解在指定Mapper方法上臨時(shí)忽略邏輯刪除攔截InterceptorIgnore(tenantLine true) Select(SELECT * FROM exam_question WHERE question_id #{id}) Question selectIgnoreLogicDelete(Param(id) Long id);用自定義SQL直接寫原生語句不走M(jìn)yBatis-Plus內(nèi)置方法。這里要說明一個(gè)容易混淆的細(xì)節(jié)如果自定義SQL是通過注解形式寫在Mapper接口上邏輯刪除攔截通常不生效因?yàn)閿r截器主要作用于MyBatis-Plus生成的方法。但如果自定義SQL寫在XML里同樣可能不受邏輯刪除限制具體要看配置。所以遇到“查不到數(shù)據(jù)”時(shí)先檢查是不是被邏輯刪除攔截了這是排查方向之一?；A(chǔ)操作中使用MP內(nèi)置方法刪除和查詢時(shí)都會自動(dòng)帶條件但在報(bào)表統(tǒng)計(jì)場景就要特別注意這個(gè)“禁用邏輯刪除”的問題。4. Vue3前臺與后臺雙端分離開發(fā)選手端答題體驗(yàn)與管理員后臺4.1 Vite Vue3項(xiàng)目基礎(chǔ)搭建與目錄劃分前端我創(chuàng)建了兩個(gè)獨(dú)立項(xiàng)目一個(gè)是選手端一個(gè)是管理員端。雖然Vue3支持路由懶加載和動(dòng)態(tài)組件但兩個(gè)端UI差異太大放一起會導(dǎo)致構(gòu)建體積越來越大訪問速度受到明顯影響。分離之后選手端打包產(chǎn)物只有幾十KB首屏加載非?？?。初始化命令用 Vite 就行比 Vue CLI 快很多npm create vitelatest contest-user -- --template vue npm create vitelatest contest-admin -- --template vueVite 的好處不用多說開發(fā)服務(wù)器啟動(dòng)快、熱更新快Vue3 官方也推薦。裝好之后我會先做一個(gè)基礎(chǔ)目錄規(guī)劃main.js 里配好路由和狀態(tài)管理。我沒有使用 Pinia 做全局狀態(tài)因?yàn)闃I(yè)務(wù)場景中需要跨頁面共享的狀態(tài)很少無非是用戶token和當(dāng)前比賽信息用 localStorage 加組件間傳參就能解決過度設(shè)計(jì)反而增加維護(hù)成本。4.2 Vue3核心特性在答題模塊中的應(yīng)用computed與倒計(jì)時(shí)選手端答題頁面是整個(gè)系統(tǒng)中交互最復(fù)雜的部分。題目的切換、選項(xiàng)選中狀態(tài)、答題進(jìn)度、剩余時(shí)間這些都是有狀態(tài)的UI。Vue3 的組合式APIComposition API處理起來邏輯集中比 Options API 清晰得多。我最常用的是computed用來根據(jù)當(dāng)前答案狀態(tài)動(dòng)態(tài)計(jì)算進(jìn)度script setup import { ref, computed } from vue const answerMap ref({}) const questionTotal ref(10) const answeredCount computed(() { return Object.keys(answerMap.value).filter(key answerMap.value[key] ! ).length }) const progressPercent computed(() { if (questionTotal.value 0) return 0 return Math.round((answeredCount.value / questionTotal.value) * 100) }) /scriptcomputed是Vue3里被問得最多的高頻API它和watch的最大區(qū)別是computed 關(guān)注的是“基于已有數(shù)據(jù)計(jì)算并返回新值”watch 關(guān)注的是“數(shù)據(jù)變化時(shí)執(zhí)行副作用”。在做答題倒計(jì)時(shí)功能時(shí)我會把剩余時(shí)間用ref保存配合setInterval每秒修改const remainSeconds ref(1800) let timer null function startTimer() { timer setInterval(() { remainSeconds.value-- if (remainSeconds.value 0) { clearInterval(timer) autoSubmit() } }, 1000) }用ref包一層的時(shí)間變量才能在UI中響應(yīng)式變化這是一個(gè)容易踩坑的點(diǎn)。直接把let remainSeconds 1800寫在setup里頁面是永遠(yuǎn)不會更新的。還需要注意在組件卸載時(shí)一定要清除定時(shí)器否則切路由后定時(shí)器還在跑會出現(xiàn)頁面已經(jīng)跳走了但自動(dòng)交卷邏輯還在執(zhí)行的詭異現(xiàn)象。4.3 動(dòng)態(tài)路由與權(quán)限控制管理員后臺最多的時(shí)候有兩類入口管理員和選手模擬練習(xí)場景。如果不用權(quán)限控制任何登進(jìn)系統(tǒng)的人都能訪問后臺接口這是嚴(yán)重的安全漏洞。我采用動(dòng)態(tài)路由方案登錄后根據(jù)返回的角色編碼使用 Vue Router 的addRoute方法動(dòng)態(tài)添加對應(yīng)權(quán)限的路由表。核心思路是定義一份常量路由表登錄頁、首頁、比賽列表和一份動(dòng)態(tài)路由表后臺管理頁。用戶登錄成功后前端判斷角色如果是admin就動(dòng)態(tài)注冊后臺管理路由如果是user只注冊選手相關(guān)的路由。const router createRouter({ history: createWebHistory(), routes: constantRoutes }) export function setupDynamicRoutes(role) { if (role admin) { adminRoutes.forEach(route { router.addRoute(route) }) } }這里注意一個(gè)很多教程不會明說的細(xì)節(jié)addRoute添加的路由是響應(yīng)式的但如果用戶刷新頁面動(dòng)態(tài)添加的路由會丟失因?yàn)榍岸藘?nèi)存被重新加載了。因此刷新后的路由重建邏輯必須放在路由守衛(wèi)里每次進(jìn)入應(yīng)用時(shí)根據(jù) token 中的角色重新注冊。如果不做這一步程序員后臺刷新一下就會白屏。4.4 axios封裝與請求攔截axios 封裝是所有前后端分離項(xiàng)目的標(biāo)配。我會首先創(chuàng)建 axios 實(shí)例設(shè)置基礎(chǔ)URL然后添加請求攔截器和響應(yīng)攔截器。請求攔截器里附帶 token響應(yīng)攔截器里統(tǒng)一處理錯(cuò)誤碼import axios from axios import router from ../router const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code 401) { localStorage.removeItem(token) router.push(/login) return Promise.reject(new Error(未登錄)) } if (res.code ! 200) { return Promise.reject(new Error(res.message)) } return res.data }, error { return Promise.reject(error) } )把401處理放在攔截器里的好處是所有接口不用各自判斷登錄過期統(tǒng)一跳轉(zhuǎn)登錄頁。業(yè)務(wù)代碼里拿到的直接就是data部分不用層層剝開response.data.data這種冗余結(jié)構(gòu)。這套封裝寫完以后整場開發(fā)里新增頁面都只用寫業(yè)務(wù)請求方法不用關(guān)心錯(cuò)誤處理。4.5 Vite代理與后端聯(lián)調(diào)開發(fā)環(huán)境聯(lián)調(diào)時(shí)前端頁面在localhost:5173后端接口在localhost:8080必然存在跨域問題。解決方式有兩種后端配置 CORS 全局跨域或者前端 Vite 配置代理。我推薦用 Vite 代理因?yàn)殚_發(fā)環(huán)境走代理更接近生產(chǎn)環(huán)境部署方式而且后端不用額外改配置。在vite.config.js中export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })這樣前端請求/api/xxx會被代理轉(zhuǎn)發(fā)到后端http://localhost:8080/api/xxx。生產(chǎn)環(huán)境部署時(shí)用 Nginx 將/api反向代理到 Java 服務(wù)即可前后端代碼不用做任何修改。這個(gè)方案在本地開發(fā)、服務(wù)器部署、域名綁定三個(gè)環(huán)節(jié)中都驗(yàn)證過是目前最推薦的做法。5. 部署落地與線上問題排查MySQL安裝、Docker部署、OOM、慢SQL5.1 MySQL部署方式選擇本機(jī)安裝還是Docker信息知識賽系統(tǒng)的部署方案我前后試過兩種。第一種是本機(jī)安裝 MySQL適合團(tuán)隊(duì)開發(fā)環(huán)境直接在官網(wǎng)下載安裝包步驟比較繁瑣官方安裝包在 Windows 下還要做環(huán)境變量配置、初始化數(shù)據(jù)目錄、注冊服務(wù)對新手來說難度不小網(wǎng)上搜“mysql安裝教程”和“mysql安裝配置教程”的人數(shù)也證明了這是一個(gè)不低的門檻。第二種是 Docker 方式適合服務(wù)器環(huán)境一個(gè)命令就能拉起數(shù)據(jù)庫。生產(chǎn)環(huán)境我用的是 Docker 部署 MySQLdocker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e MYSQL_DATABASEinfo_contest \ --restartalways \ mysql:8.0用 Docker 之后最大的好處是可移植性非常強(qiáng)換一臺服務(wù)器一條命令加一個(gè)數(shù)據(jù)目錄掛載就能恢復(fù)整個(gè)數(shù)據(jù)庫。需要注意容器刪除后數(shù)據(jù)會丟失所以一定要掛載數(shù)據(jù)目錄-v /opt/mysql-data:/var/lib/mysql如果你是在服務(wù)器上裝 Docker 也遇到 pull 鏡像慢的問題可以配置國內(nèi)鏡像源或者檢查網(wǎng)絡(luò)環(huán)境是否穩(wěn)定這些在實(shí)際操作中都比改代碼更耗時(shí)間。5.2 SpringBoot應(yīng)用打包JDK8在Docker中的那點(diǎn)事我云服務(wù)器上安裝的是 Docker Desktop 環(huán)境實(shí)際上服務(wù)器用的是 Docker Engine本地開發(fā)機(jī)用 Docker Desktop 測試鏡像。項(xiàng)目的JDK版本是8SpringBoot 2.7 默認(rèn)的打包方式打出來的是可執(zhí)行 jar 包理論上java -jar app.jar就能運(yùn)行。但容器部署時(shí)還是需要一個(gè)帶 JDK8 基礎(chǔ)鏡像的 DockerfileFROM openjdk:8-jre-alpine LABEL maintaineryourname COPY target/info-contest.jar /app.jar ENV JAVA_OPTS-Xms256m -Xmx512m -Dfile.encodingUTF-8 ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar /app.jar]這里有一個(gè)非常容易踩的坑SpringBoot 2.7 打包出的 jar 在 Docker 中啟動(dòng)時(shí)可能會出現(xiàn)java: outofmemoryerror: insufficient memory之類的內(nèi)存不足錯(cuò)誤。原因通常是 Docker 容器的內(nèi)存限制過于緊張或者 JVM 默認(rèn)按照宿主機(jī)內(nèi)存大小分配堆內(nèi)存結(jié)果容器配額不夠。解決方式是顯式指定 JVM 參數(shù)-Xms256m -Xmx512m限制堆內(nèi)存大小并加上-XX:UseG1GC。還有一點(diǎn)如果基礎(chǔ)鏡像用的是openjdk:8-jre而不是alpine瘦身版鏡像體積會多出上百M(fèi)B按需取舍?；谌萜飨拗苼碓O(shè)置-Xmx參數(shù)有時(shí)候還可以用-XX:MaxRAMPercentage75.0替代固定數(shù)值讓JVM按容器內(nèi)存配額自動(dòng)按比例分配這樣在高并發(fā)和低負(fù)載場景下都能自適應(yīng)。5.3 慢查詢與索引優(yōu)化排行榜為什么越跑越慢項(xiàng)目上線后跑了三場比賽排行榜接口開始出現(xiàn)明顯的延遲。最開始我以為是服務(wù)器帶寬和并發(fā)的問題后來查看日志發(fā)現(xiàn)一條 SQL 執(zhí)行超過了 2 秒定位到成績表的查詢沒走索引。原因很直白成績表里user_id和contest_id字段沒有建立聯(lián)合索引數(shù)據(jù)量到了幾萬條之后全表掃描時(shí)間陡增。解決辦法是加聯(lián)合索引ALTER TABLE exam_score ADD INDEX idx_user_contest (user_id, contest_id);加完之后接口響應(yīng)時(shí)間從2秒降到了100毫秒以內(nèi)變化非常明顯。這個(gè)經(jīng)歷給我一個(gè)很深的教訓(xùn)數(shù)據(jù)量小的時(shí)候感知不到索引的重要性但一定要在設(shè)計(jì)階段就要做好索引規(guī)劃。下面是建表時(shí)就用到的參考索引設(shè)計(jì)表名索引字段場景exam_questioncategory_id按分類篩選題目exam_questionquestion_type按題型篩選題目exam_scoreuser_id, contest_id查詢用戶某場比賽成績exam_scorecontest_id, score排行榜按分?jǐn)?shù)排序exam_questiondifficulty按難度篩選在 MySQL 中批量插入數(shù)據(jù)的場景下還遇到過int5這個(gè)關(guān)鍵詞相關(guān)的疑惑。很多人在寫 update 語句時(shí)會對整數(shù)字段做score score 5的累加操作并且在 MySQL 中這種表達(dá)式不是按照字符串拼接來處理的是真的數(shù)值相加。但要注意如果字段定義為INT累加超過溢出時(shí) MySQL 會報(bào)錯(cuò)所以設(shè)計(jì)成績或計(jì)數(shù)類字段時(shí)預(yù)留合理的字段范圍很重要。5.4 MyBatis緩存一級緩存引發(fā)的數(shù)據(jù)不一致問題線上有一個(gè)詭異的問題同一個(gè)用戶查詢比賽成績連續(xù)調(diào)用兩次接口第一次返回了更新后的成績第二次竟然返回了舊數(shù)據(jù)?；舜蟀胩炫挪樽詈蠖ㄎ坏绞?MyBatis 一級緩存導(dǎo)致的。MyBatis 默認(rèn)開啟一級緩存作用范圍是同一個(gè) SqlSession 內(nèi)。在 Spring 整合環(huán)境中每次請求都會新建 SqlSession看起來不會觸發(fā)緩存問題但如果某個(gè)Service方法里多次執(zhí)行了同一個(gè)查詢而中間又更新了數(shù)據(jù)此時(shí)一級緩存可能會把第二次查詢結(jié)果攔截住返回舊數(shù)據(jù)。解決方式有三種在 Mapper 查詢語句上設(shè)置flushCachetrue強(qiáng)制每次查詢都清空一級緩存。在更新操作后手動(dòng)調(diào)用SqlSession.clearCache()但代碼侵入性有點(diǎn)強(qiáng)。如果用了 MyBatis-Plus可以在查詢時(shí)指定last(LIMIT 1)也不一定能完全繞過緩存最穩(wěn)妥的還是結(jié)合具體場景控制。這個(gè)問題的核心是理解 MyBatis 的緩存機(jī)制。一級緩存默認(rèn)開啟二級緩存默認(rèn)關(guān)閉。對于競賽系統(tǒng)這種對數(shù)據(jù)一致性要求較高的場景我建議盡量不依賴MyBatis緩存而是把緩存層放在 Redis 上手動(dòng)控制失效時(shí)機(jī)。這樣在成績、排行榜等數(shù)據(jù)變化頻繁的場景下才能保證用戶看不到過期數(shù)據(jù)。5.5 Vue3前端部署與Nginx配置前端打包后是一堆靜態(tài)文件部署到 Nginx 時(shí)有一個(gè)常見的坑直接刷新頁面會返回404。原因在于 Vue Router 使用的是 history 模式前端路由在瀏覽器上表現(xiàn)為真實(shí)的url路徑但服務(wù)器上并沒有對應(yīng)的物理文件Nginx 找不到文件就返回404了。解決方案是配置 try_files將所有的路由請求都重定向到 index.htmlserver { listen 80; server_name yourdomain.com; root /opt/contest-web/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }這是一份非常常見且能直接用的 Nginx 配置。靜態(tài)文件交給 Nginx 托管Java 接口走反向代理Nginx 同時(shí)承擔(dān)了靜態(tài)資源服務(wù)器和反向代理的雙重角色。部署完之后前端刷新不再404接口請求也走同域沒有跨域問題。6. 從第一版到第二版我踩過的坑和重構(gòu)思路這個(gè)信息知識賽系統(tǒng)做到今天前后經(jīng)歷了兩次比較大的重構(gòu)。第一次重構(gòu)是前端從 Vue2 ElementUI 遷移到 Vue3 Vite這里涉及了組件庫兼容性、響應(yīng)式API的改寫、路由模式升級等一堆問題工作量比想象中大。第二次重構(gòu)是后端引入了 Redis 緩存排行榜和異步判分這部分改動(dòng)主要針對并發(fā)場景因?yàn)榈谝话嬖谡鎸?shí)比賽一開、幾百人同時(shí)提交時(shí)數(shù)據(jù)庫連接池差點(diǎn)被打滿。如果讓我重新做一遍我會在第一版就做三個(gè)決定數(shù)據(jù)表一定按規(guī)范化設(shè)計(jì)不圖省事用JSON字段存復(fù)雜結(jié)構(gòu)。業(yè)務(wù)邏輯中一定區(qū)分主流程和異步流程答題保存、判分、匯總、排行可以異步化。前端從一開始就用 Vue3 Vite用組合式API組織邏輯不要用 Options API 寫舊的思路。關(guān)于 MySQL 和 MyBatis 的關(guān)系想再補(bǔ)充一句個(gè)人看法。MyBatis 是一個(gè)非常靈活的持久層框架它不像 JPA 那樣給你一套完整的對象關(guān)系映射而是把SQL的控制權(quán)完全交給開發(fā)人員。這對信息知識賽系統(tǒng)這種有多條件查詢、多表關(guān)聯(lián)、事務(wù)一致性要求的場景反而更友好。因?yàn)槟憧梢跃_控制每一條SQL知道它執(zhí)行了什么慢在哪。但這也意味著開發(fā)者必須自己保證SQL質(zhì)量不能指望框架優(yōu)化。所以寫動(dòng)態(tài)SQL時(shí)一定要慢下心多考慮是否走索引是否能避免SELECT *這些細(xì)節(jié)在數(shù)據(jù)量上來后都會顯現(xiàn)出來。MyBatis 的工作原理簡單說就是通過動(dòng)態(tài)代理為 Mapper 接口生成代理對象解析 SQL 并執(zhí)行把結(jié)果集通過反射映射成實(shí)體對象。真正理解這一點(diǎn)后你排查問題就會有的放矢而不是遇到Bug只能盲猜配置。這套系統(tǒng)目前的版本在功能上已經(jīng)完整覆蓋了信息知識賽項(xiàng)目的基本需求用戶注冊登錄、題庫管理、比賽創(chuàng)建、在線答題、自動(dòng)判分、排行榜、成績查詢。后續(xù)計(jì)劃中的擴(kuò)展方向是支持自定義組卷規(guī)則、多級知識點(diǎn)樹、賽后報(bào)告導(dǎo)出等。核心架構(gòu)已經(jīng)穩(wěn)定擴(kuò)展只是往上加模塊的問題。最后分享一個(gè)我實(shí)際開發(fā)中的體會做這類系統(tǒng)技術(shù)難點(diǎn)其實(shí)不是讓代碼“跑起來”而是讓整個(gè)項(xiàng)目在多人協(xié)作、快速迭代的過程中始終維持清晰的結(jié)構(gòu)。前后端分離、統(tǒng)一接口規(guī)范、日志排查鏈路完整、部署可復(fù)現(xiàn)這些工程化的事做到位功能開發(fā)本身就只是時(shí)間問題。信息知識賽系統(tǒng)的源碼是我逐步打磨出來的希望這篇拆解能幫你繞開那些我踩過的坑。