簡(jiǎn)介一份基于Java的學(xué)生在線考試系統(tǒng)畢業(yè)設(shè)計(jì)論文主要面向計(jì)算機(jī)相關(guān)專業(yè)的學(xué)生、畢業(yè)設(shè)計(jì)選題者及在線考試系統(tǒng)開(kāi)發(fā)人員針對(duì)傳統(tǒng)考試信息管理難度大、容錯(cuò)率低、數(shù)據(jù)處理耗費(fèi)時(shí)間等問(wèn)題給出完整的系統(tǒng)設(shè)計(jì)思路與實(shí)現(xiàn)方案。文檔為單個(gè)docx文件壓縮包大小約2.94MB內(nèi)含中英文摘要、目錄以及緒論、開(kāi)發(fā)環(huán)境、系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)等完整章節(jié)。該課題以Mysql數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)使用Java語(yǔ)言進(jìn)行開(kāi)發(fā)并采用SSM框架完成業(yè)務(wù)分層系統(tǒng)覆蓋教師管理、試卷管理、錯(cuò)題本管理、試題管理、考試記錄、論壇管理和公告管理等功能同時(shí)闡述了數(shù)據(jù)加密、權(quán)限控制、備份機(jī)制、遠(yuǎn)程監(jiān)考與實(shí)時(shí)評(píng)分等安全性和交互性設(shè)計(jì)。論文結(jié)構(gòu)完整、層次清晰既能幫助讀者掌握在線考試系統(tǒng)的功能規(guī)劃與編碼思路也可作為撰寫畢業(yè)設(shè)計(jì)論文的格式與內(nèi)容參考。目前已有63人學(xué)習(xí)下載適合正在準(zhǔn)備類似課題或需要完整畢設(shè)方案的學(xué)生。1. 基于 Java 的學(xué)生在線考試系統(tǒng)從課堂測(cè)驗(yàn)到期末大考的完整落地很多剛?cè)胄械?Java 開(kāi)發(fā)者在簡(jiǎn)歷上寫“學(xué)生在線考試系統(tǒng)”但真正被問(wèn)到“你的數(shù)據(jù)庫(kù)是怎么防并發(fā)交卷的”或者“考試中途斷網(wǎng)怎么處理”就卡殼了。這個(gè)題目其實(shí)是一個(gè)典型的企業(yè)級(jí) Web 應(yīng)用縮影它涉及權(quán)限模型、事務(wù)一致性、定時(shí)任務(wù)、文件導(dǎo)入導(dǎo)出甚至還有一點(diǎn)防作弊的對(duì)抗思維。這篇文章從零開(kāi)始帶你用一個(gè) Spring Boot MyBatis 的組合把系統(tǒng)跑通包含數(shù)據(jù)庫(kù)設(shè)計(jì)、核心接口實(shí)現(xiàn)、前端頁(yè)面和部署腳本最后聊幾個(gè)線上才會(huì)遇到的真實(shí)坑——時(shí)區(qū)錯(cuò)亂、并發(fā)交卷、瀏覽器緩存這些黑匣子問(wèn)題我都會(huì)給出排查思路和解決方案。無(wú)論你是準(zhǔn)備 Java 面試、做課程設(shè)計(jì)還是想給學(xué)?；蚺嘤?xùn)機(jī)構(gòu)搭一套真正能用的考試環(huán)境這條路徑都值得跟著走一遍。2. 系統(tǒng)設(shè)計(jì)與技術(shù)選型為什么用 Spring Boot MyBatis 而不是其他組合2.1 考試系統(tǒng)的核心角色與用例拆解在線考試系統(tǒng)看著簡(jiǎn)單其實(shí)角色劃分很細(xì)。最常見(jiàn)的三類角色是管理員、教師、學(xué)生但如果你真要做成一個(gè)能交付的產(chǎn)品還得加上“超級(jí)管理員”和“閱卷人”這兩個(gè)身份。每個(gè)角色對(duì)應(yīng)不同的用例集合——超級(jí)管理員管教師賬號(hào)和系統(tǒng)參數(shù)教師負(fù)責(zé)出題、組卷、發(fā)布考試、閱卷學(xué)生則要完成考試、查看成績(jī)、參與補(bǔ)考。這個(gè)模型的復(fù)雜度不在于數(shù)據(jù)表多而在于狀態(tài)流轉(zhuǎn)考試從“編輯中”到“已發(fā)布”再到“進(jìn)行中”“已結(jié)束”每一步都有權(quán)限校驗(yàn)和時(shí)間窗口判斷。技術(shù)選型上Spring Boot 是當(dāng)前 Java 后端的事實(shí)標(biāo)準(zhǔn)它內(nèi)置了 Tomcat、自動(dòng)配置了數(shù)據(jù)源和事務(wù)管理器能省掉大量 XML 配置。MyBatis 作為持久層框架相比 JPA 更貼近 SQL適合考試系統(tǒng)這種查詢條件多變的場(chǎng)景——比如“查詢某教師名下所有已發(fā)布的考試并按時(shí)間倒序排列”這種 SQL 寫在 XML 里維護(hù)起來(lái)非常直觀。我一般不用 MyBatis Plus 的代碼生成器因?yàn)樽詣?dòng)生成的 Service 層反而把業(yè)務(wù)邏輯搞亂了。前端方面如果你是要交課程設(shè)計(jì)直接用 Thymeleaf 模板引擎渲染服務(wù)端頁(yè)面就夠用沒(méi)必要上 Vue 全家桶增加復(fù)雜度。如果你是要做商用的在線考試平臺(tái)那前端單獨(dú)部署一個(gè) Vue 項(xiàng)目會(huì)更靈活后端只提供 JSON 接口。下文的代碼示例以后端接口為主前端只貼關(guān)鍵片段因?yàn)檫@個(gè)項(xiàng)目的重頭戲在業(yè)務(wù)邏輯和并發(fā)控制上。2.2 數(shù)據(jù)庫(kù)表設(shè)計(jì)五張核心表與三張關(guān)聯(lián)表考試系統(tǒng)的數(shù)據(jù)庫(kù)建模是面試官最愛(ài)問(wèn)的環(huán)節(jié)也是第一個(gè)翻車高發(fā)區(qū)。很多初學(xué)者把“學(xué)生表”和“用戶表”分開(kāi)建然后發(fā)現(xiàn)權(quán)限校驗(yàn)要 join 三張表非常別扭。正確做法是統(tǒng)一用一張sys_user表用role字段區(qū)分身份再用關(guān)聯(lián)表維護(hù)業(yè)務(wù)關(guān)系。核心表的設(shè)計(jì)邏輯是這樣的exam表存儲(chǔ)考試元數(shù)據(jù)包括考試名稱、開(kāi)始時(shí)間、結(jié)束時(shí)間、時(shí)長(zhǎng)、總分、及格線、是否允許補(bǔ)考question表存儲(chǔ)題目包含題目類型單選、多選、判斷、填空、簡(jiǎn)答、題干、選項(xiàng) JSON、標(biāo)準(zhǔn)答案、分值paper表是試卷模板記錄題目 ID 列表和分值分布exam_paper是關(guān)聯(lián)表把考試和試卷綁定起來(lái)exam_record表記錄學(xué)生的答題明細(xì)每道題一行包含學(xué)生答案和得分狀態(tài)exam_result表保存最終成績(jī)匯總這個(gè)設(shè)計(jì)最容易被忽視的是exam_record表必須加submit_time字段。沒(méi)有這個(gè)字段你無(wú)法判斷學(xué)生是否在考試結(jié)束后才交卷也無(wú)法做“超時(shí)自動(dòng)交卷”的后臺(tái)任務(wù)。另一個(gè)容易踩坑的地方是多選題的答案存儲(chǔ)——用逗號(hào)分隔的字符串A,B,C會(huì)比用 JSON 數(shù)組更簡(jiǎn)單判分時(shí)直接按字符串匹配即可但如果題目選項(xiàng)順序會(huì)變化就必須用 JSON 加排序后再比較。建表 SQL 的核心片段如下其中考試時(shí)間全部用datetime類型不要用timestamp原因在后面的避坑章節(jié)會(huì)詳談CREATE TABLE exam ( id bigint(20) NOT NULL AUTO_INCREMENT, title varchar(200) NOT NULL COMMENT 考試名稱, exam_type tinyint(4) NOT NULL DEFAULT 1 COMMENT 1-正式考試 2-補(bǔ)考 3-模擬考試, start_time datetime NOT NULL, end_time datetime NOT NULL, duration_minutes int(11) NOT NULL COMMENT 考試時(shí)長(zhǎng)分鐘, total_score int(11) NOT NULL DEFAULT 100, pass_score int(11) NOT NULL DEFAULT 60, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0-編輯中 1-已發(fā)布 2-進(jìn)行中 3-已結(jié)束, allow_retry tinyint(4) NOT NULL DEFAULT 0 COMMENT 是否允許補(bǔ)考, create_by bigint(20) NOT NULL COMMENT 創(chuàng)建人教師ID, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_status_time (status, start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;這里的idx_status_time聯(lián)合索引非常關(guān)鍵。按狀態(tài)和時(shí)間檢索是考試系統(tǒng)最高頻的查詢模式——教師查看“已發(fā)布但還沒(méi)開(kāi)始的考試”需要where status1學(xué)生進(jìn)入考試系統(tǒng)要查“當(dāng)前正在進(jìn)行且當(dāng)前時(shí)間在窗口內(nèi)”的考試這個(gè)索引能讓查詢走覆蓋索引避免全表掃描。2.3 項(xiàng)目工程結(jié)構(gòu)按業(yè)務(wù)模塊分包別按技術(shù)層分包很多教材習(xí)慣按controller/service/mapper三層分包小項(xiàng)目可以但考試系統(tǒng)業(yè)務(wù)一多就會(huì)變成災(zāi)難。比如“發(fā)布考試”這個(gè)動(dòng)作牽涉到試卷狀態(tài)修改、通知推送如果是站內(nèi)信、定時(shí)任務(wù)注冊(cè)按技術(shù)層分包你要改三個(gè)包下的類。我更推薦按業(yè)務(wù)模塊分包每個(gè)模塊自帶自己的 controller、service、mappercom.example.exam ├── common // 通用工具、異常處理、常量 ├── config // Spring 配置類 ├── module │ ├── auth // 登錄認(rèn)證、權(quán)限攔截 │ ├── user // 用戶管理教師、學(xué)生 │ ├── exam // 考試管理創(chuàng)建、發(fā)布、狀態(tài)流轉(zhuǎn) │ ├── paper // 試卷管理組卷、題目維護(hù) │ ├── answer // 答題與判分交卷、自動(dòng)閱卷 │ └── result // 成績(jī)管理與報(bào)表 └── security // 攔截器、過(guò)濾器模塊化分包的好處是面試時(shí)你能直接說(shuō)出“我負(fù)責(zé)的是 exam 和 answer 兩個(gè)模塊各自包含完整的業(yè)務(wù)鏈路”。實(shí)際協(xié)作開(kāi)發(fā)時(shí)多個(gè)成員改不同模塊的代碼幾乎不沖突。更重要的是模塊邊界清晰后事務(wù)管理才能做對(duì)——比如“交卷”這個(gè)操作必須保證exam_record批量插入和exam_result更新在同一個(gè)事務(wù)里如果散落在不同包事務(wù)注解很容易漏加。2.4 身份認(rèn)證與權(quán)限控制基于 Token 的攔截器實(shí)現(xiàn)考試系統(tǒng)不能用傳統(tǒng)的 Session 方案因?yàn)閷W(xué)生可能用手機(jī)和電腦兩個(gè)設(shè)備同時(shí)登錄Session 會(huì)互相頂?shù)?。我?JWTJSON Web Token做無(wú)狀態(tài)認(rèn)證后端攔截器統(tǒng)一校驗(yàn) Token 中的角色信息。登錄接口返回 Token 后前端存在localStorage里每次請(qǐng)求在 Header 帶Authorization: Bearer token。權(quán)限控制的粒度要做到“接口級(jí)別”而不是“頁(yè)面級(jí)別”。比如POST /api/exam/{id}/publish這個(gè)接口必須校驗(yàn)當(dāng)前用戶是教師且該考試是這位教師本人創(chuàng)建的學(xué)生只能訪問(wèn)POST /api/exam/{id}/submit交卷接口。攔截器里先解析 Token 拿到角色再在 Service 層校驗(yàn)資源歸屬權(quán)Component public class AuthInterceptor 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 )) { throw new BusinessException(401, 未登錄或登錄已過(guò)期); } // 解析 JWT將用戶信息放入 ThreadLocal 供后續(xù)使用 Claims claims JwtUtil.parseToken(token.replace(Bearer , )); UserContext.setUserId(claims.get(userId, Long.class)); UserContext.setRole(claims.get(role, String.class)); return true; } }這段代碼里最關(guān)鍵的是ThreadLocal的使用。當(dāng)請(qǐng)求經(jīng)過(guò)攔截器后后續(xù)的 Service 層、Mapper 層都可以通過(guò)UserContext.getUserId()獲取當(dāng)前用戶不必每個(gè)方法都傳一遍用戶 ID 參數(shù)。我在實(shí)際項(xiàng)目里吃過(guò)虧一開(kāi)始用request.getAttribute()傳遞用戶信息結(jié)果遇到異步任務(wù)時(shí)request對(duì)象已經(jīng)不可用數(shù)據(jù)全亂了。換成ThreadLocal后問(wèn)題消失但要注意在攔截器的afterCompletion里調(diào)用UserContext.clear()防止線程池復(fù)用導(dǎo)致的數(shù)據(jù)串號(hào)。3. 核心功能實(shí)現(xiàn)從題庫(kù)管理到自動(dòng)閱卷的完整鏈路3.1 題庫(kù)管理單選、多選、判斷、填空、簡(jiǎn)答的統(tǒng)一存儲(chǔ)方案題庫(kù)模塊是考試系統(tǒng)的地基。設(shè)計(jì)題目表時(shí)最大的坑是要兼容多種題型。我的做法是題干統(tǒng)一存content字段選項(xiàng)統(tǒng)一存options字段用 JSON 格式存儲(chǔ)——單選題的 options 是字符串?dāng)?shù)組判斷題沒(méi)有選項(xiàng)就存空數(shù)組填空題的標(biāo)準(zhǔn)答案用數(shù)組存多個(gè)空格對(duì)應(yīng)的答案。這樣查詢列表時(shí)可以用一條 SQL 查出全部題目前端根據(jù)question_type字段決定渲染方式。題目表的核心字段如下CREATE TABLE question ( id bigint(20) NOT NULL AUTO_INCREMENT, type tinyint(4) NOT NULL COMMENT 1-單選 2-多選 3-判斷 4-填空 5-簡(jiǎn)答, content text NOT NULL COMMENT 題干, options json DEFAULT NULL COMMENT 選項(xiàng)JSON數(shù)組, answer text COMMENT 標(biāo)準(zhǔn)答案, analysis text COMMENT 答案解析, difficulty tinyint(4) NOT NULL DEFAULT 2 COMMENT 1-易 2-中 3-難, subject_id bigint(20) DEFAULT NULL COMMENT 所屬科目, create_by bigint(20) NOT NULL, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;選項(xiàng)用 JSON 存儲(chǔ)的好處是擴(kuò)展性好以后想加“選項(xiàng)隨機(jī)排序”功能只需要在前端打亂數(shù)組渲染順序即可后端不用改表結(jié)構(gòu)。壞處是統(tǒng)計(jì)題目時(shí)無(wú)法用 SQL 直接分析選項(xiàng)分布但這需求在考試系統(tǒng)里基本不會(huì)出現(xiàn)。這里必須提一個(gè)語(yǔ)文層面的問(wèn)題題干中的圖片和公式怎么處理我看到很多課程設(shè)計(jì)里直接把圖片 URL 拼進(jìn)content字段一旦系統(tǒng)遷移到新域名所有圖片全部失效。更穩(wěn)妥的方案是把圖片轉(zhuǎn)為 Base64 存入數(shù)據(jù)庫(kù)不行這會(huì)撐爆數(shù)據(jù)庫(kù)內(nèi)存。正道是單獨(dú)一張resource表存文件路徑題干中用占位符引用渲染時(shí)替換為完整 URL 路徑。資源表沒(méi)有建那系統(tǒng)里凡是帶圖的題目都會(huì)成為日后遷移項(xiàng)目時(shí)的定時(shí)炸彈。3.2 組卷邏輯按題型和難度比例自動(dòng)抽題組卷是考試系統(tǒng)里算法含量最高的部分。最簡(jiǎn)單的手動(dòng)組卷方案是教師從題庫(kù)里逐題點(diǎn)擊添加但這樣做 60 道題的試卷要花半小時(shí)。更實(shí)用的做法是“自動(dòng)組卷 人工微調(diào)”教師指定“單選題 20 道、多選題 10 道、判斷題 10 道、總難度為中等”系統(tǒng)從題庫(kù)中隨機(jī)抽取滿足條件的題目。自動(dòng)組卷的核心 SQL 使用了ORDER BY RAND()配合LIMITSELECT id, content, options, answer, difficulty FROM question WHERE type 1 AND subject_id #{subjectId} ORDER BY RAND() LIMIT #{count}這個(gè)方案在題目量小于一萬(wàn)時(shí)性能沒(méi)有問(wèn)題。題目量大了之后ORDER BY RAND()會(huì)全表掃描可以先查出符合條件的題目 ID 集合在 Java 內(nèi)存中用Collections.shuffle()打亂后取前 N 個(gè)再一次性查出題目完整信息。我實(shí)際采用的是后一種方案因?yàn)楫?dāng)題目量突破 5 萬(wàn)時(shí)前一種方案的單次查詢耗時(shí)已經(jīng)超過(guò) 800ms接近數(shù)據(jù)庫(kù)慢查詢閾值。組卷完成后試卷的題目列表存在paper_question關(guān)聯(lián)表里同時(shí)記錄每道題在試卷中的序號(hào)。抽題時(shí)要考慮“相鄰題目不能是同一知識(shí)點(diǎn)”這種約束但這屬于產(chǎn)品細(xì)節(jié)不是技術(shù)必選。如果你要對(duì)面試官或答辯老師展示亮點(diǎn)可以在隨機(jī)抽題后加一個(gè)“知識(shí)點(diǎn)分散度”校驗(yàn)把題目的subject_id按試卷序號(hào)統(tǒng)計(jì)分布如果連續(xù) 3 題屬于同一知識(shí)點(diǎn)則重新抽一次。3.3 考試進(jìn)行中倒計(jì)時(shí)、自動(dòng)保存與斷線重連考試進(jìn)行中的用戶體驗(yàn)直接決定系統(tǒng)的口碑。倒計(jì)時(shí)功能很多人用前端setInterval實(shí)現(xiàn)但前端定時(shí)器在瀏覽器切換到后臺(tái)時(shí)會(huì)被掛起時(shí)間會(huì)越走越慢。正確的做法是前端只負(fù)責(zé)展示剩余時(shí)間后端在exam_record表記錄start_time前端每次調(diào)用GET /api/exam/{id}/remaining-time接口時(shí)后端用當(dāng)前服務(wù)器時(shí)間減去start_time計(jì)算出剩余秒數(shù)。這樣即使學(xué)生換了一臺(tái)電腦倒計(jì)時(shí)依然準(zhǔn)確。自動(dòng)保存功能是避免學(xué)生辛辛苦苦答完題卻因斷網(wǎng)全部丟失的后悔藥。我通常的做法是學(xué)生在切換題目時(shí)觸發(fā)保存每道題一答完就調(diào)一次保存接口另外用一個(gè)前端定時(shí)器每 60 秒強(qiáng)制保存一次當(dāng)前試卷的全部答案。保存接口是冪等的同一道題重復(fù)提交不會(huì)造成數(shù)據(jù)異常PostMapping(/api/answer/save) public Result saveAnswer(RequestBody SaveAnswerRequest request) { // request 中包含 examId、questionId、answer // 先查這道題是否已經(jīng)存在于 exam_record 表 ExamRecord record examRecordMapper.selectByExamAndQuestion( request.getExamId(), request.getQuestionId()); if (record null) { // 不存在則插入 record new ExamRecord(); record.setExamId(request.getExamId()); record.setQuestionId(request.getQuestionId()); record.setStudentId(UserContext.getUserId()); record.setAnswer(request.getAnswer()); record.setSubmitTime(new Date()); examRecordMapper.insert(record); } else { // 存在則更新注意只更新答案和提交時(shí)間 record.setAnswer(request.getAnswer()); record.setSubmitTime(new Date()); examRecordMapper.updateById(record); } return Result.success(); }這個(gè)接口的邏輯并不復(fù)雜但被問(wèn)到的頻率極高——它的本質(zhì)是“先查后改”的 Upsert 操作。在多線程并發(fā)場(chǎng)景下兩個(gè)相同請(qǐng)求同時(shí)到達(dá)可能出現(xiàn)唯一鍵沖突所以exam_record表一定要建聯(lián)合唯一索引(exam_id, student_id, question_id)插入時(shí)捕獲DuplicateKeyException后轉(zhuǎn)成更新操作。斷線重連的處理是另一個(gè)值得寫進(jìn)簡(jiǎn)歷的點(diǎn)。前端檢測(cè)到網(wǎng)絡(luò)斷開(kāi)時(shí)把用戶當(dāng)前頁(yè)面的作答數(shù)據(jù)存到localStorage網(wǎng)絡(luò)恢復(fù)后檢測(cè)到本地有未提交答案自動(dòng)彈窗提示并提交。這個(gè)方案的坑在于 localStorage 有容量上限通常 5MB如果考生答的是簡(jiǎn)答題輸入了大量文字可能超出限制。我見(jiàn)過(guò)的更先進(jìn)方案是讓前端在斷線時(shí)改用navigator.sendBeacon()把數(shù)據(jù)發(fā)送到后端接口這個(gè) API 在頁(yè)面關(guān)閉時(shí)也能生效且能傳送較大數(shù)據(jù)量。3.4 自動(dòng)閱卷與人工閱卷客觀題秒判主觀題異步批改交卷接口是整個(gè)系統(tǒng)并發(fā)壓力最大的地方——考試結(jié)束的瞬間全班同學(xué)同一秒點(diǎn)提交按鈕。如果代碼寫成“先逐題判分再算總分最后更新成績(jī)單”數(shù)據(jù)庫(kù)會(huì)被瞬間的寫并發(fā)打滿。我的設(shè)計(jì)是分兩步走交卷時(shí)只做答案的持久化不實(shí)時(shí)判分判分通過(guò)異步任務(wù)處理延遲不過(guò)幾秒但并發(fā)承載能力提高了十倍?？陀^題判分邏輯如下public ScoreResult markObjectivePaper(Long examId, Long studentId) { ListExamRecord records examRecordMapper.selectByExamAndStudent(examId, studentId); int totalScore 0; int correctCount 0; for (ExamRecord record : records) { Question question questionMapper.selectById(record.getQuestionId()); if (question null || question.getAnswer() null) { continue; // 題目被刪除或沒(méi)有標(biāo)準(zhǔn)答案的跳過(guò) } if (question.getType() 1 || question.getType() 2) { // 單選和多選字符串完全匹配 if (normalizeAnswer(question.getAnswer()).equals(normalizeAnswer(record.getAnswer()))) { record.setScore(question.getScore()); totalScore question.getScore(); correctCount; } else { record.setScore(0); } } else if (question.getType() 3) { // 判斷題答案只有 T/F if (question.getAnswer().equalsIgnoreCase(record.getAnswer())) { record.setScore(question.getScore()); totalScore question.getScore(); correctCount; } } examRecordMapper.updateScore(record.getId(), record.getScore()); } // 更新成績(jī)匯總 ExamResult result examResultMapper.selectByExamAndStudent(examId, studentId); result.setObjectiveScore(totalScore); result.setStatus(PENDING_MARK); // 等待人工閱卷主觀題 examResultMapper.updateById(result); return new ScoreResult(totalScore, correctCount); }這段代碼最關(guān)鍵的是normalizeAnswer方法。多選題的答案可能存在空格、全角逗號(hào)和半角逗號(hào)混用的情況比如學(xué)生提交的是A,C標(biāo)準(zhǔn)答案是A,C肉眼看著一樣但字符串比較就是不相等。normalizeAnswer要做的事是去掉所有空格、統(tǒng)一把全角逗號(hào)替換為半角逗號(hào)、把逗號(hào)分隔的選項(xiàng)排序后重組。排序這一步很重要因?yàn)闃?biāo)準(zhǔn)答案可能是A,B,D學(xué)生選的是B,A,D從邏輯上講是對(duì)的但直接比較就會(huì)誤判為錯(cuò)誤。這個(gè)細(xì)節(jié)是考試系統(tǒng)里最容易被初學(xué)者忽略的坑。3.5 補(bǔ)考機(jī)制同一考試、不同試卷、獨(dú)立成績(jī)補(bǔ)考功能是區(qū)分“demo 級(jí)系統(tǒng)”和“能上線的系統(tǒng)”的重要標(biāo)志。補(bǔ)考的邏輯核心是一個(gè)學(xué)生不能重復(fù)參加同一場(chǎng)考試的同一次機(jī)會(huì)但可以參加補(bǔ)考機(jī)會(huì)。為此我單獨(dú)建了exam_attempt表記錄每個(gè)學(xué)生針對(duì)每場(chǎng)考試的參與次數(shù)CREATE TABLE exam_attempt ( id bigint(20) NOT NULL AUTO_INCREMENT, exam_id bigint(20) NOT NULL, student_id bigint(20) NOT NULL, attempt_no int(11) NOT NULL DEFAULT 1 COMMENT 第幾次考試, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0-未開(kāi)始 1-進(jìn)行中 2-已完成 3-缺考, paper_id bigint(20) NOT NULL COMMENT 本次考試使用的試卷ID, start_time datetime DEFAULT NULL, submit_time datetime DEFAULT NULL, score decimal(5,2) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_exam_student_attempt (exam_id, student_id, attempt_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;統(tǒng)一用attempt_no區(qū)分正式考試和補(bǔ)考成績(jī)表也一樣每次參加考試生成一條獨(dú)立的成績(jī)記錄。這樣查詢“學(xué)生最終成績(jī)”時(shí)取attempt_no最大的一條記錄改革成績(jī)時(shí)可以同時(shí)保留正式考和補(bǔ)考成績(jī)數(shù)據(jù)不會(huì)覆蓋。這個(gè)設(shè)計(jì)在公司里被 DBA 夸過(guò)因?yàn)楹罄m(xù)要做“成績(jī)進(jìn)步分析”報(bào)表時(shí)直接用attempt_no分組就可以實(shí)現(xiàn)不需要再 JOIN 多張表。補(bǔ)考觸發(fā)規(guī)則在業(yè)務(wù)層控制正式考試成績(jī)低于及格線時(shí)系統(tǒng)更新該學(xué)生的考試狀態(tài)為“可補(bǔ)考”并自動(dòng)生成一條attempt_no2的考試記錄試卷從題庫(kù)中重新抽一套難度相同的。注意補(bǔ)考的試卷不能和正式考試重復(fù)率太高否則學(xué)生之間可以直接互相問(wèn)答案作弊。我做過(guò)的最簡(jiǎn)單方案補(bǔ)考卷從正式試卷的備選池中抽取備選池里的題目與正式卷中超過(guò) 30% 的題目不重復(fù)。4. 避坑指南并發(fā)、時(shí)區(qū)、緩存與瀏覽器兼容性4.1 并發(fā)交卷導(dǎo)致成績(jī)丟失現(xiàn)象考試結(jié)束瞬間全班 50 人同時(shí)提交成績(jī)表中部分學(xué)生沒(méi)有任何記錄。原因交卷接口里“保存明細(xì)”和“計(jì)算總分”分開(kāi)了兩個(gè)事務(wù)。學(xué)生手動(dòng)交卷時(shí)走的是完整事務(wù)明細(xì)成績(jī)一起寫入但自動(dòng)交卷的定時(shí)任務(wù)沒(méi)有加事務(wù)導(dǎo)致明細(xì)寫入后系統(tǒng)恰好崩潰來(lái)不及更新成績(jī)表。解決為自動(dòng)交卷任務(wù)增加Transactional(rollbackFor Exception.class)注解并把保存明細(xì)和生成成績(jī)放在同一個(gè)方法內(nèi)。同時(shí)手動(dòng)交卷接口要捕獲唯一鍵沖突異常防止同一學(xué)生重復(fù)提交時(shí)成績(jī)被覆蓋。這個(gè)場(chǎng)景是我在本公司真實(shí)踩過(guò)的。當(dāng)時(shí)定時(shí)任務(wù)每 5 秒掃描一次超時(shí)未交卷的考生某次數(shù)據(jù)庫(kù)連接池耗盡部分任務(wù)的成績(jī)更新被異步丟進(jìn)失敗隊(duì)列結(jié)果那場(chǎng)考試 18 個(gè)學(xué)生的成績(jī)從系統(tǒng)里蒸發(fā)了。從那以后所有涉及關(guān)鍵數(shù)據(jù)的異步任務(wù)必須加失敗重試機(jī)制重試 3 次仍失敗就發(fā)告警郵件給運(yùn)維。4.2 數(shù)據(jù)庫(kù)時(shí)區(qū)與服務(wù)器時(shí)區(qū)不一致導(dǎo)致考試時(shí)間混亂現(xiàn)象管理員在后臺(tái)設(shè)置考試 14:00 開(kāi)始考生到 13:58 就發(fā)現(xiàn)可以進(jìn)入考試系統(tǒng)了或者反過(guò)來(lái)考試已經(jīng)結(jié)束但系統(tǒng)還顯示進(jìn)行中。原因MySQL 的datetime類型不帶時(shí)區(qū)信息但 JDBC 連接字符串沒(méi)有顯式指定serverTimezone系統(tǒng)會(huì)使用服務(wù)器默認(rèn)時(shí)區(qū)可能是 UTC導(dǎo)致new Date()寫入的時(shí)間和數(shù)據(jù)庫(kù)讀到的時(shí)間偏差 8 小時(shí)。解決JDBC 連接串統(tǒng)一加上serverTimezoneAsia/ShanghaiuseLegacyDatetimeCodefalse同時(shí) MySQL 服務(wù)端default-time-zone 08:00。代碼層的日期對(duì)象統(tǒng)一采用LocalDateTime不要用new Date()和Timestamp混用因?yàn)門imestamp內(nèi)部帶時(shí)區(qū)偏移量在不同 JDK 版本下行為不一致。另外要提醒的是千萬(wàn)別用timestamp類型存考試時(shí)間——它的范圍只有 1970 到 2038 年如果考試系統(tǒng)要面向長(zhǎng)期運(yùn)營(yíng)選datetime會(huì)更安全。這個(gè)細(xì)節(jié)考過(guò)不少 Java 八股文面試題很多答案其實(shí)沒(méi)說(shuō)到點(diǎn)子上。4.3 瀏覽器自動(dòng)填充和緩存導(dǎo)致表單提交舊數(shù)據(jù)現(xiàn)象考生對(duì)某道題改了答案后頁(yè)面顯示已保存成功但后端數(shù)據(jù)庫(kù)里還是舊答案。原因前端用了fetch的默認(rèn)緩存策略或者表單控件被瀏覽器自動(dòng)填充頁(yè)面上顯示的是緩存值。還有一種是前端發(fā)送請(qǐng)求時(shí)并發(fā)第一次請(qǐng)求舊答案比第二次新答案晚到達(dá)后端后來(lái)者覆蓋了前者。解決所有考試相關(guān)接口的響應(yīng)頭統(tǒng)一加Cache-Control: no-store前端提交答案時(shí)加時(shí)間戳參數(shù)并在攔截器里做防重入處理。更正規(guī)的方案是給保存接口加上“樂(lè)觀鎖”版本號(hào)每次保存答案時(shí)附帶該題的update_time后端在更新時(shí)檢查update_time是否小于請(qǐng)求攜帶值若小于則拒絕更新。代碼參考Update(UPDATE exam_record SET answer #{answer}, update_time #{now} WHERE id #{id} AND update_time #{clientTime}) int updateAnswerWithoutConflict(Param(id) Long id, Param(answer) String answer, Param(now) Date now, Param(clientTime) Date clientTime);如果返回行數(shù)為 0說(shuō)明有更早的請(qǐng)求先落庫(kù)了此時(shí)可以忽略當(dāng)前請(qǐng)求或提醒學(xué)生重新確認(rèn)。這種做法能規(guī)避掉大部分“前端手滑點(diǎn)了兩次保存”造成的覆蓋問(wèn)題。4.4 題目圖片在 HTTPS 環(huán)境下無(wú)法加載現(xiàn)象題干中包含圖片的題目在部署到 HTTPS 域名后圖片加載失敗控制臺(tái)報(bào)Mixed Content錯(cuò)誤。原因題干中的圖片地址是以http://協(xié)議存儲(chǔ)的HTTPS 頁(yè)面默認(rèn)禁止加載非安全協(xié)議的資源。解決最簡(jiǎn)單的方法是部署階段統(tǒng)一對(duì)題干內(nèi)容做正則替換把所有http://替換為https://。更穩(wěn)妥的做法是寫一個(gè)攔截器在返回題庫(kù)列表時(shí)動(dòng)態(tài)拼接圖片域名確保圖片地址始終使用當(dāng)前協(xié)議。這個(gè)問(wèn)題在本地開(kāi)發(fā)時(shí)不會(huì)出現(xiàn)因?yàn)楸镜卦L問(wèn)就是 HTTP一旦上生產(chǎn)環(huán)境換 HTTPS就立刻踩雷屬于部署階段必然會(huì)遇到的坑。4.5 考試中間刷新頁(yè)面導(dǎo)致記錄被當(dāng)成“交卷”現(xiàn)象考生在考試中途按了 F5 刷新系統(tǒng)判定為已交卷無(wú)法再進(jìn)入考場(chǎng)。原因前端刷新時(shí)重新加載頁(yè)面此時(shí)調(diào)用了GET /api/exam/entry接口查詢考生是否已參加考試而該接口的實(shí)現(xiàn)邏輯是“如果exam_attempt.status 1則返回試卷否則返回 403”。解決入口接口改為“如果存在進(jìn)行中的考試記錄則繼續(xù)返回試卷內(nèi)容如果不存在則創(chuàng)建新記錄只有狀態(tài)為已提交或已過(guò)期時(shí)才拒絕進(jìn)入”。更靠譜的做法是在前端將考試狀態(tài)暫存到sessionStorage刷新后優(yōu)先讀取本地狀態(tài)同時(shí)后端接口只負(fù)責(zé)查詢數(shù)據(jù)不負(fù)責(zé)創(chuàng)建記錄。5. 部署與驗(yàn)收從本地跑通到云服務(wù)器上線5.1 環(huán)境準(zhǔn)備與首次啟動(dòng)本地開(kāi)發(fā)環(huán)境我習(xí)慣用 Docker 起 MySQL這樣團(tuán)隊(duì)協(xié)作時(shí)數(shù)據(jù)庫(kù)版本完全一致不會(huì)出現(xiàn)你本地 8.0 同事 5.7 導(dǎo)致 SQL 語(yǔ)法兼容問(wèn)題。啟動(dòng)命令如下docker run -d \ --name exam-mysql \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDroot123 \ -e MYSQL_DATABASEexam_system \ -e TZAsia/Shanghai \ -v /myapp/mysql-data:/var/lib/mysql \ mysql:8.0 --default-time-zone08:00啟動(dòng)后檢查容器狀態(tài)docker ps | grep exam-mysql。如果容器始終處于Restarting狀態(tài)大概率是宿主機(jī) 3306 端口被占用或 MySQL 數(shù)據(jù)目錄權(quán)限不對(duì)——把掛載目錄權(quán)限改成 777 即可解決別問(wèn)我為什么知道。Spring Boot 項(xiàng)目的application.yml配置要點(diǎn)MyBatis 的map-underscore-to-camel-case設(shè)為true這樣數(shù)據(jù)庫(kù)的submit_time字段能自動(dòng)映射到 JavaBean 的submitTime省去大量TableField注解。數(shù)據(jù)源配置如下spring: datasource: url: jdbc:mysql://localhost:3306/exam_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: root123 hikari: maximum-pool-size: 20 minimum-idle: 5 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/ShanghaiallowPublicKeyRetrievaltrue是 MySQL 8.0 連接的必要參數(shù)不加會(huì)報(bào)Public Key Retrieval is not allowed。這個(gè)報(bào)錯(cuò)彈出的瞬間很多從 5.7 遷移過(guò)來(lái)的老 Java 工程師都會(huì)愣住。5.2 一鍵啟動(dòng)腳本與系統(tǒng)自檢項(xiàng)目根目錄放一個(gè).sh腳本實(shí)現(xiàn)一鍵啟動(dòng)加端口檢測(cè)#!/bin/bash APP_NAMEexam-system.jar LOG_FILElogs/exam.log if [ ! -d logs ]; then mkdir logs fi # 檢查端口是否被占用 PORT8080 if lsof -i:$PORT /dev/null 21; then echo 端口 $PORT 被占用嘗試自動(dòng)釋放... lsof -i:$PORT | awk NR2 {print $2} | xargs kill -9 sleep 2 fi nohup java -jar target/$APP_NAME --spring.profiles.activeprod $LOG_FILE 21 # 檢測(cè)應(yīng)用是否就緒 for i in $(seq 1 30); do if curl -s http://localhost:$PORT/actuator/health | grep -q UP; then echo 應(yīng)用啟動(dòng)成功 exit 0 fi sleep 2 done echo 應(yīng)用啟動(dòng)超時(shí)請(qǐng)查看日志 exit 1用curl探測(cè)健康檢查端點(diǎn)而不是盲目sleep 10這是運(yùn)維老手和新手的區(qū)別。Systemd 的ExecStart配置也可以按同樣思路寫但腳本方式更適合課程設(shè)計(jì)和中小團(tuán)隊(duì)交付。部署完成后建議按順序走一遍全鏈路驗(yàn)收學(xué)生登錄 → 查看考試列表 → 進(jìn)入考試 → 答題并保存 → 自動(dòng)交卷 → 查看成績(jī)。這里面最容易出問(wèn)題的環(huán)節(jié)是“學(xué)生端時(shí)間顯示”和“教師端試卷預(yù)覽”的時(shí)區(qū)一致性測(cè)試時(shí)要刻意把服務(wù)器時(shí)區(qū)和本地電腦時(shí)區(qū)調(diào)成不同區(qū)域檢測(cè)系統(tǒng)是否出現(xiàn)時(shí)間漂移。5.3 性能摸底模擬 200 人同時(shí)在線考試考試系統(tǒng)的并發(fā)峰值非常集中——開(kāi)考后第 1 分鐘大量考生同時(shí)進(jìn)入交卷前 1 分鐘大量考生同時(shí)提交。用 JMeter 做一次粗略壓測(cè)能測(cè)出系統(tǒng)是否扛得住真實(shí)考試場(chǎng)景。JMeter 的線程組配置要點(diǎn)線程數(shù) 200Ramp-up 設(shè)為 10 秒模擬 10 秒內(nèi) 200 人同時(shí)登錄加“HTTP Cookie 管理器”模擬 Session 保持如果用的是 JWT則在 HTTP Header Manager 中配置 Authorization 變量重點(diǎn)壓測(cè)三個(gè)接口登錄、答題保存、交卷壓測(cè)時(shí)觀察阿里的 Arthas 火焰圖如果saveAnswer接口的 TP99 超過(guò) 800ms先查數(shù)據(jù)庫(kù)連接池是否不夠再把保存接口的 SQL 優(yōu)化到只更新必要的字段。我在壓測(cè)中真實(shí)遇到過(guò)一次數(shù)據(jù)庫(kù)死鎖——原因是exam_record表的UPDATE語(yǔ)句沒(méi)有走唯一索引導(dǎo)致行鎖升級(jí)成表鎖。解決方式是確保 SQL 的WHERE條件帶上聯(lián)合唯一索引的所有字段。6. 進(jìn)階功能與落地技巧導(dǎo)出成績(jī)報(bào)表與自動(dòng)排考系統(tǒng)上線后教師和管理員最剛需的功能是成績(jī)導(dǎo)出和排考管理。成績(jī)導(dǎo)出用阿里開(kāi)源的 EasyExcel 庫(kù)一行代碼搞定 Excel 生成自動(dòng)排考則需要一個(gè)相對(duì)復(fù)雜的調(diào)度算法。我把這兩個(gè)功能作為進(jìn)階擴(kuò)展寫在這一節(jié)因?yàn)樗鼈兡艽蠓嵘到y(tǒng)的“產(chǎn)品完成度”。成績(jī)導(dǎo)出的常見(jiàn)做法是先查出成績(jī)列表再遍歷填充 Excel 行ListExamResult results examResultMapper.selectByExamId(examId); String fileName exam_ examId _scores.xlsx; ExcelWriter writer EasyExcel.write(response.getOutputStream(), ExamResult.class).build(); WriteSheet sheet EasyExcel.writerSheet(成績(jī)單).build(); writer.write(results, sheet); writer.finish();實(shí)際使用時(shí)要加一個(gè)風(fēng)險(xiǎn)提醒response.getOutputStream()在數(shù)據(jù)量很大時(shí)可能一次性寫入內(nèi)存導(dǎo)致 OOM。穩(wěn)妥的做法是把查詢改為分頁(yè)查詢配合ExcelWriter的write多批次傳入數(shù)據(jù)。另外導(dǎo)出的成績(jī)單必須按“總分從高到低”排序否則教師拿到的報(bào)表沒(méi)有可用性。自動(dòng)排考的算法相對(duì)復(fù)雜。當(dāng)一場(chǎng)考試有多個(gè)教室、多個(gè)時(shí)間段可選時(shí)系統(tǒng)需要把學(xué)生分配到具體的座位和批次。最簡(jiǎn)方案是貪心算法按學(xué)號(hào)順序依次分配每個(gè)教室容量滿員后自動(dòng)切換到下一教室更優(yōu)的方案是“沖突檢測(cè) 回溯”避免同一班級(jí)學(xué)生在同一時(shí)間段被分到不同教室導(dǎo)致監(jiān)考老師不夠。用貪心排考場(chǎng)我寫過(guò)一次結(jié)果一個(gè)班 30 人被拆到 3 個(gè)教室考務(wù)辦老師都快哭了。后來(lái)改成按班級(jí)分組分配才算真正符合業(yè)務(wù)預(yù)期。這個(gè)細(xì)節(jié)提醒我技術(shù)方案再優(yōu)雅也要先理解業(yè)務(wù)方的真實(shí)流程——考試系統(tǒng)不是只給技術(shù)人員用的是要給教務(wù)人員和學(xué)生天天用的用戶說(shuō)“不好用”比“有 bug”還致命?；乜催@個(gè)項(xiàng)目從設(shè)計(jì)到落地的全過(guò)程我覺(jué)得最有價(jià)值的不是某段代碼寫得多么花哨而是把考試系統(tǒng)中“時(shí)間一致性、并發(fā)安全、數(shù)據(jù)可追溯”這三個(gè)核心問(wèn)題都想透了。如果你也在做類似的項(xiàng)目我的建議是先花 30 分鐘把數(shù)據(jù)庫(kù)關(guān)系梳理清楚再寫一行代碼中途遇到玄學(xué)問(wèn)題時(shí)優(yōu)先看日志和數(shù)據(jù)庫(kù)當(dāng)前值不要盲目改代碼。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取