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