：從Spring Boot到Vue 3的完整實(shí)踐)
這個(gè)項(xiàng)目嚴(yán)格來說是去年秋招間隙做出來的起因特別簡(jiǎn)單用常見的刷題產(chǎn)品總覺得不順手錯(cuò)題本太散、沒有知識(shí)點(diǎn)維度的統(tǒng)計(jì)、還總被推薦一些早就掌握的題。于是我就想著干脆自己造一個(gè)智能面試刷題系統(tǒng)既能滿足日常刷題需求又順便把前后端分離的架構(gòu)完整走一遍。整個(gè)項(xiàng)目從設(shè)計(jì)到第一版上線大概用了三周技術(shù)棧選的是 Spring Boot Vue 3前端走 RESTful API 跟后端通信核心特色是答題記錄驅(qū)動(dòng)的一套推薦邏輯和可視化統(tǒng)計(jì)。這篇文章把我當(dāng)時(shí)的決策過程、數(shù)據(jù)庫(kù)設(shè)計(jì)、實(shí)現(xiàn)細(xì)節(jié)、以及上線后踩過的坑都整理出來理論和代碼都有對(duì)正在做畢設(shè)或想加深架構(gòu)理解的開發(fā)者會(huì)比較有參考價(jià)值。1. 項(xiàng)目的真實(shí)起點(diǎn)一個(gè)刷題工具的需求演進(jìn)1.1 痛點(diǎn)分析為什么需要專門做一套刷題系統(tǒng)刷題這件事看起來極其簡(jiǎn)單注冊(cè)一個(gè)賬號(hào)然后對(duì)著題庫(kù)一題一題點(diǎn)就是了。但真正堅(jiān)持用一個(gè)月以后會(huì)發(fā)現(xiàn)盲目刷題有一個(gè)非常致命的問題你根本不知道自己哪里薄弱只會(huì)被動(dòng)地按照題目順序一路點(diǎn)下去今天錯(cuò)的知識(shí)點(diǎn)明天就忘下周又錯(cuò)一遍。我在做這個(gè)項(xiàng)目之前專門觀察了自己和身邊幾個(gè)準(zhǔn)備面試的同學(xué)的使用習(xí)慣。大家刷題時(shí)最有價(jià)值的動(dòng)作其實(shí)是提交答案那一刻的判斷過程和看解析后的復(fù)盤過程。但市面上通用產(chǎn)品大多只把判斷對(duì)錯(cuò)這一步留給了你錯(cuò)題回收、知識(shí)點(diǎn)統(tǒng)計(jì)、復(fù)習(xí)提醒這些環(huán)節(jié)要么很弱要么藏得很深。所以我自己做的第一版需求就非常明確要有一條完整的刷題—記錄—分析—推薦—再刷題閉環(huán)而不是一個(gè)單純堆砌題目的文檔系統(tǒng)。這個(gè)系統(tǒng)的用戶其實(shí)只有兩類一類是求職者需要在短期內(nèi)快速補(bǔ)足薄弱知識(shí)點(diǎn)另一類是運(yùn)營(yíng)題庫(kù)的人需要一個(gè)趁手的工具把題目和知識(shí)點(diǎn)維護(hù)好。畢設(shè)或者個(gè)人項(xiàng)目最怕的就是功能無限膨脹所以我在立項(xiàng)時(shí)就把邊界卡得很死不做社區(qū)、不做社交、不做課程售賣只做跟有效刷題強(qiáng)相關(guān)的功能。1.2 功能邊界劃定與角色設(shè)計(jì)第一版的功能清單是這樣定的。用戶端只有五個(gè)核心模塊注冊(cè)登錄、刷題練習(xí)、模擬面試、錯(cuò)題本、學(xué)習(xí)統(tǒng)計(jì)。管理端是三個(gè)題庫(kù)管理、知識(shí)點(diǎn)管理、用戶數(shù)據(jù)概覽。登錄注冊(cè)這個(gè)模塊沒什么好說的唯一要注意的是密碼不能明文存我用的是標(biāo)準(zhǔn)加鹽哈希。刷題練習(xí)是主入口用戶可以選擇按順序刷、按知識(shí)點(diǎn)刷、或者直接進(jìn)入智能推薦模式。模擬面試是一個(gè)獨(dú)立的會(huì)話式場(chǎng)景按照崗位方向和難度生成一套題答題過程中有倒計(jì)時(shí)結(jié)束后給出得分和解析。錯(cuò)題本不是簡(jiǎn)單收藏夾它要記錄每個(gè)錯(cuò)題的錯(cuò)誤次數(shù)、最近錯(cuò)誤時(shí)間并且可以一鍵把錯(cuò)題重新變成一套練習(xí)卷。學(xué)習(xí)統(tǒng)計(jì)則把答題記錄聚合起來按天輸出刷題熱力圖按知識(shí)點(diǎn)輸出正確率和掌握度雷達(dá)圖。管理端的題庫(kù)管理要覆蓋題目新增、編輯、上下架、批量導(dǎo)入。知識(shí)點(diǎn)管理維護(hù)一棵知識(shí)點(diǎn)樹每個(gè)題目可以掛到一個(gè)葉子節(jié)點(diǎn)上。用戶數(shù)據(jù)概覽我做得比較克制只展示注冊(cè)用戶數(shù)、刷題總量、平均正確率這些基礎(chǔ)指標(biāo)。管理端和用戶端共用同一套后端接口權(quán)限靠 JWT 里的 role 字段區(qū)分后端在最外層攔截器里做角色校驗(yàn)這樣兩個(gè)前端應(yīng)用都能保持比較薄的邏輯。1.3 為什么堅(jiān)持前后端分離很多在校同學(xué)做系統(tǒng)時(shí)習(xí)慣把頁(yè)面模板和后端渲染混在一起理由是這樣簡(jiǎn)單減少跨域問題。但我個(gè)人強(qiáng)烈建議這類偏業(yè)務(wù)型的項(xiàng)目一開始就走前后端分離原因有三個(gè)。第一前端交互復(fù)雜度決定了它不適合服務(wù)端渲染。刷題頁(yè)面有倒計(jì)時(shí)、選項(xiàng)狀態(tài)、實(shí)時(shí)統(tǒng)計(jì)圖表、答題記錄更新這些都是典型的 SPA 場(chǎng)景用傳統(tǒng)模板一個(gè)個(gè)同步渲染會(huì)非常痛苦。第二一個(gè)后端 API 能同時(shí)喂給用戶端、管理端甚至以后接一個(gè)小程序代碼不需要重寫。第三前后端分離以后接口邊界變得清晰我可以先把接口文檔定好再讓兩個(gè)部分并行推進(jìn)整個(gè)開發(fā)節(jié)奏會(huì)快很多。當(dāng)然也要清醒認(rèn)識(shí)到分離的代價(jià)跨域配置、登錄態(tài)管理、接口聯(lián)調(diào)都是以前不需要操心的東西。這些問題在后面的各部分里都有對(duì)應(yīng)解法不存在無解的情況只是需要多學(xué)幾種新技能而已。2. 技術(shù)選型與架構(gòu)設(shè)計(jì)前后端分離的骨架搭建2.1 后端用什么、為什么不后悔后端技術(shù)棧是 Spring Boot 3.x Java 17 MyBatis-Plus MySQL 8 Redis。為什么這么選其實(shí)是在學(xué)習(xí)價(jià)值和落地速度之間做平衡。如果只是想跑通一個(gè)項(xiàng)目用 Node.js 寫接口可能更快但考慮到系統(tǒng)涉及復(fù)雜的數(shù)據(jù)統(tǒng)計(jì)、事務(wù)處理和權(quán)限模型Java 生態(tài)的穩(wěn)定性是實(shí)打?qū)嵉膬?yōu)勢(shì)。Spring Boot 幫我把絕大多數(shù)配置自動(dòng)化了我只需要關(guān)注 Controller、Service、Mapper 這一層業(yè)務(wù)代碼。MyBatis-Plus 的單表 CRUD 和分頁(yè)插件非常好用條件構(gòu)造器寫動(dòng)態(tài)查詢也很順手復(fù)雜統(tǒng)計(jì)我用自定義 XML 寫 SQL兩邊互不干擾。Redis 我用在兩個(gè)地方。第一是緩存知識(shí)點(diǎn)統(tǒng)計(jì)結(jié)果統(tǒng)計(jì)接口如果每次都去 MySQL 聚合全表數(shù)據(jù)量大了以后響應(yīng)會(huì)明顯變慢所以我在寫入 answer_record 時(shí)會(huì)同步把對(duì)應(yīng)知識(shí)點(diǎn)的統(tǒng)計(jì)緩存刪除下次讀取時(shí)再重新計(jì)算。第二是存放模擬面試的上下文一場(chǎng)面試過程中的進(jìn)度、剩余時(shí)間、題目列表都存在 Redis 里過期時(shí)間設(shè)成兩小時(shí)既能防止接口頻繁命中數(shù)據(jù)庫(kù)也能自然清理掉不活躍的會(huì)話。2.2 前端選型與工程化配置前端用了 Vue 3 Vite Pinia Vue Router Element Plus這套組合現(xiàn)在基本是中小型管理系統(tǒng)的默認(rèn)選項(xiàng)但選它不純粹是因?yàn)榱餍?。Vue 3 的組合式 API 對(duì)答題頁(yè)這種邏輯密集的頁(yè)面特別友好。選項(xiàng)式 API 寫小頁(yè)面沒問題一旦頁(yè)面里有倒計(jì)時(shí)、答題狀態(tài)、抽題邏輯、提交反饋邏輯就會(huì)散落在各個(gè)生命周期鉤子里用 setup 語法可以把同一塊業(yè)務(wù)的 ref、computed、watch 聚在一起維護(hù)成本低一個(gè)量級(jí)。Pinia 比 Vuex 輕省掉 mutation 這層概念在個(gè)人項(xiàng)目里少寫不少樣板代碼。Element Plus 我只按需引入不整包加載避免首屏?xí)r間被組件庫(kù)拖垮。Vite 帶來的體驗(yàn)提升是感知最強(qiáng)的。以前用 Webpack 啟動(dòng)一套前后端分離項(xiàng)目冷啟動(dòng)十幾秒都是常態(tài)改一行代碼還要等編譯。Vite 基于原生 ESM 實(shí)現(xiàn)按需編譯項(xiàng)目不管多大首啟基本都是秒級(jí)熱更新也是毫秒級(jí)反饋。開發(fā)刷題系統(tǒng)要反復(fù)在兩個(gè)頁(yè)面之間跳轉(zhuǎn)調(diào)整樣式這個(gè)體驗(yàn)優(yōu)勢(shì)能省下大量時(shí)間。2.3 接口規(guī)范、權(quán)限模型與跨域處理前后端分離項(xiàng)目能不能順利聯(lián)調(diào)接口規(guī)范起決定性作用。我定義了一個(gè)很簡(jiǎn)單的統(tǒng)一返回包裝類后端所有接口出參都是 { code, message, data }業(yè)務(wù)異常通過全局異常處理器轉(zhuǎn)成對(duì)應(yīng)的 code前端只需要在響應(yīng)攔截器里統(tǒng)一判斷 code。分頁(yè)接口統(tǒng)一接受 page 和 size返回 PageResult里面包含 total、records 兩個(gè)字段避免每個(gè)接口各搞一套返回結(jié)構(gòu)。資源命名走 RESTful 風(fēng)格/api/questions、/api/answer-records、/api/exam-sessions。這類系統(tǒng)里面試題目和答題記錄都是完整資源用 RESTful 的方式描述非常自然。前端請(qǐng)求路徑不再出現(xiàn)動(dòng)詞接口語義也更清晰。權(quán)限模型沒有上 Spring Security而是用 JWT 加攔截器的輕量方案。登錄成功后后端返回一個(gè)包含 userId 和 role 的 JWT前端放在 localStorage 里每次請(qǐng)求通過 axios 攔截器加在 Authorization 頭。后端攔截器對(duì)所有 /api/** 請(qǐng)求做 token 校驗(yàn)管理端接口額外檢查 role 是否為管理員解析失敗或角色不對(duì)直接返回 401 和 403。這套方案對(duì)中小項(xiàng)目完全夠用代碼少也容易讀懂。跨域問題我分開處理。開發(fā)環(huán)境用 Vite 的 proxy 把 /api 代理到后端地址瀏覽器看到的是同源請(qǐng)求不存在跨域。生產(chǎn)環(huán)境用 Nginx 反向代理直接把對(duì) /api 的請(qǐng)求轉(zhuǎn)發(fā)到 Java 服務(wù)同樣不需要后端開啟 CORS。這樣處理的好處是減少攻擊面也更貼近真實(shí)線上部署的形態(tài)。而且開發(fā)環(huán)境和生產(chǎn)環(huán)境的行為保持一致前端代碼不需要根據(jù)環(huán)境維護(hù)兩套 baseURL排查接口問題時(shí)只需要抓 Nginx 日志和 Java 應(yīng)用日志兩處就夠了。3. 數(shù)據(jù)模型設(shè)計(jì)與核心業(yè)務(wù)實(shí)現(xiàn)3.1 數(shù)據(jù)庫(kù)到底建了幾張表我把表控制在六張核心表不建一堆中間表來增加維護(hù)成本。設(shè)計(jì)原則只有一個(gè)所有后續(xù)要做統(tǒng)計(jì)和推薦的數(shù)據(jù)必須在產(chǎn)生那一刻就能支撐查詢避免統(tǒng)計(jì)時(shí)到處 join。表名關(guān)鍵字段說明userid, username, password_hash, nickname, role用戶表role 區(qū)分普通用戶/管理員knowledge_pointid, name, parent_id, weight知識(shí)點(diǎn)樹weight 表示重要度questionid, type, difficulty, point_id, stem, options, answer, analysis, status題庫(kù)type 區(qū)分選擇題/簡(jiǎn)答題/編程題answer_recordid, user_id, question_id, point_id, difficulty, is_correct, answer_content, use_time, created_at答題流水表業(yè)務(wù)核心wrong_bookid, user_id, question_id, error_count, last_wrong_at, review_status錯(cuò)題狀態(tài)表exam_sessionid, user_id, mode, difficulty, question_ids, status, score模擬面試會(huì)話表這里我想強(qiáng)調(diào) answer_record 這張表。它本質(zhì)上是一張事實(shí)表每一行代表一次真實(shí)的刷題行為。字段里冗余了 point_id 和 difficulty雖然打破了盡量不冗余的潔癖但對(duì)統(tǒng)計(jì)性能幫助很大按知識(shí)點(diǎn)算正確率時(shí)不需要再回表查 question 表直接 group by point_id 就行。建議在這張表上建立聯(lián)合索引 (user_id, point_id, created_at)這是整個(gè)系統(tǒng)最高頻的查詢路徑。當(dāng)初如果不建這個(gè)索引統(tǒng)計(jì)數(shù)據(jù)一多接口響應(yīng)時(shí)間會(huì)從毫秒級(jí)一路漲到秒級(jí)。3.2 刷題主流程一次完整答題的數(shù)據(jù)流轉(zhuǎn)一次完整答題的數(shù)據(jù)流轉(zhuǎn)是整個(gè)項(xiàng)目里最核心的一條鏈路。用戶點(diǎn)開始刷題后前端向后端請(qǐng)求推薦題目后端根據(jù)推薦策略返回一道題用戶提交答案后端判斷對(duì)錯(cuò)寫入 answer_record更新掌握度緩存和錯(cuò)題本最后把正確答案、解析和新掌握度返回給前端。提交答案的處理邏輯用代碼寫是這樣Transactional public AnswerResult submitAnswer(SubmitRequest request) { Question question questionMapper.selectById(request.getQuestionId()); boolean correct question.getAnswer().equalsIgnoreCase(request.getAnswer()); AnswerRecord record new AnswerRecord(); record.setUserId(request.getUserId()); record.setQuestionId(question.getId()); record.setPointId(question.getPointId()); record.setDifficulty(question.getDifficulty()); record.setCorrect(correct); record.setUseTime(request.getUseTime()); answerRecordMapper.insert(record); masteryCache.evict(request.getUserId(), question.getPointId()); if (!correct) { wrongBookMapper.upsert(request.getUserId(), question.getId()); } return new AnswerResult(question, correct); }注意事務(wù)注解一定不能少。一開始我漏了事務(wù)結(jié)果出現(xiàn)用戶提交答案后answer_record 寫入了而錯(cuò)題本沒有更新的情況自我排查時(shí)非常難受。因?yàn)樵谕皇聞?wù)里要么全部成功要么全部回滾這條鏈路絕不能出現(xiàn)中間狀態(tài)。3.3 錯(cuò)題本與刷題統(tǒng)計(jì)的底層邏輯錯(cuò)題本用 upsert 語義實(shí)現(xiàn)這是一個(gè)容易想錯(cuò)的地方。如果每次答錯(cuò)都 insert 一條錯(cuò)題記錄同一個(gè)題在錯(cuò)題本里會(huì)出現(xiàn)多條展示時(shí)還要去重邏輯非常別扭。正確做法是在錯(cuò)題表里用 (user_id, question_id) 建唯一索引答錯(cuò)時(shí)執(zhí)行存在就累加錯(cuò)誤次數(shù)不存在才插入的更新語句。復(fù)習(xí)狀態(tài)我是用一個(gè) review_status 字段管理的初始值是等待復(fù)習(xí)用戶把錯(cuò)題重新做對(duì)一次后變成已掌握下次再錯(cuò)再回退。這個(gè)字段我一開始沒想清楚直接把錯(cuò)題表當(dāng)收藏夾用后來加了字段才讓復(fù)習(xí)一下變成可操作的動(dòng)作。前端在錯(cuò)題本里提供篩選條件只看待復(fù)習(xí)、只看已掌握加上一鍵復(fù)習(xí)按鈕比單純展示所有錯(cuò)題實(shí)用得多。統(tǒng)計(jì)模塊相對(duì)直接。按天刷題量用一個(gè) SQL 就能查出來SELECT DATE_FORMAT(created_at, %Y-%m-%d) AS day, COUNT(*) AS total FROM answer_record WHERE user_id #{userId} GROUP BY day ORDER BY day;知識(shí)點(diǎn)掌握度統(tǒng)計(jì)類似group by point_id 后計(jì)算正確率和答題量前端再用雷達(dá)圖渲染出來。這套統(tǒng)計(jì)鏈路不復(fù)雜但前提是 answer_record 表的結(jié)構(gòu)一開始就設(shè)計(jì)對(duì)數(shù)據(jù)來源不能亂統(tǒng)計(jì)結(jié)果才有意義。4. 智能推薦策略讓刷題有方向而不是瞎碰4.1 可解釋的推薦比看不見的玄學(xué)推薦更重要說到智能很多人第一反應(yīng)是上協(xié)同過濾或者跑一個(gè)神經(jīng)網(wǎng)絡(luò)模型。但對(duì)這類個(gè)人項(xiàng)目來說效果并不好用戶和題目的交互矩陣極度稀疏冷啟動(dòng)問題根本繞不開而且推薦結(jié)果無法解釋用戶會(huì)困惑為什么給我推這道題。我的設(shè)計(jì)原則是把推薦做成可解釋的。推薦一道題時(shí)前端可以明確展示推薦理由比如你最近關(guān)于二分查找的掌握度偏低推薦完成這道題。這種可解釋性既讓用戶信服也讓代碼邏輯更好維護(hù)。推薦鏈路只依賴 answer_record 和 knowledge_point 兩張表可控性很強(qiáng)后續(xù)想調(diào)整規(guī)則也只是改一個(gè) Service 的事情。從實(shí)際使用反饋來看用戶對(duì)這種知道為什么推題的接受度比我預(yù)期高很多。4.2 掌握度計(jì)算與推薦優(yōu)先級(jí)掌握度是整個(gè)推薦策略的核心指標(biāo)。我不采用簡(jiǎn)單的歷史正確率因?yàn)檎_率沒法體現(xiàn)時(shí)間衰減很久以前錯(cuò)過的知識(shí)點(diǎn)如果最近一直做對(duì)應(yīng)該認(rèn)為它正在被掌握。所以用帶時(shí)間衰減的加權(quán)平均核心邏輯如下public double calculateMastery(ListAnswerRecord records) { double sumWeight 0.0; double sumCorrect 0.0; for (AnswerRecord record : records) { double days Duration.between(record.getCreatedAt(), LocalDateTime.now()).toDays(); double weight Math.exp(-days / 7.0); sumWeight weight; sumCorrect record.isCorrect() ? weight : 0.0; } return sumWeight 0 ? sumCorrect / sumWeight : 0.5; }衰減周期設(shè)成 7 天相當(dāng)于一周前的答題權(quán)重衰減到約 37%兩周前基本忽略。這個(gè)參數(shù)我一開始是拍腦袋定的但實(shí)測(cè)體驗(yàn)比純正確率平滑很多后來也就沒有再調(diào)。需要注意的是掌握度計(jì)算不要放在每次請(qǐng)求里實(shí)時(shí)掃全表正確做法是答題提交時(shí)更新知識(shí)點(diǎn)的掌握度緩存推薦接口直接讀緩存。推薦優(yōu)先級(jí)分三層。第一層是最薄弱知識(shí)點(diǎn)下、且重要度 weight 高的未做題目直接強(qiáng)推薦。第二層是掌握度在 0.4 到 0.6 之間的知識(shí)點(diǎn)說明處于邊界狀態(tài)需要加強(qiáng)。第三層是近期完全沒有刷過題的知識(shí)點(diǎn)用隨機(jī)池?fù)埔粌傻纴肀３指采w面。每次后端生成一個(gè)候選題池在池內(nèi)隨機(jī)選一道返回避免用戶連續(xù)刷到同一題。這套規(guī)則我用一個(gè)策略接口封裝每層策略只負(fù)責(zé)篩選候選題后面想加按崗位過濾或者按題目熱度排序也只是新增策略類的問題。4.3 模擬面試與智能組卷的輕量實(shí)現(xiàn)模擬面試模式是為了給用戶一個(gè)完整的作答節(jié)奏。用戶選擇崗位方向和難度后后端按知識(shí)點(diǎn)權(quán)重進(jìn)行配額抽題保證一套試卷覆蓋多個(gè)知識(shí)點(diǎn)而不是全抽到同一個(gè)點(diǎn)。組卷邏輯聽起來復(fù)雜落實(shí)下來其實(shí)就是一個(gè)按知識(shí)點(diǎn)配額的抽樣算法先算出每個(gè)知識(shí)點(diǎn)要抽多少題再?gòu)脑撝R(shí)點(diǎn)的題目池里隨機(jī)抽抽過的題要放到排除集合里避免重復(fù)。核心思路用代碼寫是這樣MapLong, Integer quotaMap buildQuotaMap(knowledgePoints, totalCount); for (Map.EntryLong, Integer entry : quotaMap.entrySet()) { ListQuestion pool questionMapper.selectByPointAndDifficulty( entry.getKey(), difficulty, excludedIds); selected.addAll(randomPick(pool, entry.getValue())); }選擇題提交后立刻自動(dòng)判分簡(jiǎn)答題初版采用關(guān)鍵詞匹配評(píng)分把參考答案里預(yù)先標(biāo)注的核心關(guān)鍵詞和用戶答案做包含比對(duì)按命中率給分編程題因?yàn)樵诰€判題工程量太大第一版只展示參考答案讓用戶自評(píng)。分?jǐn)?shù)統(tǒng)計(jì)和面試報(bào)告仍然完整生成用戶可以翻看每個(gè)知識(shí)點(diǎn)的表現(xiàn)。5. 前端落地與體驗(yàn)打磨5.1 SPA應(yīng)用的結(jié)構(gòu)規(guī)劃前端項(xiàng)目結(jié)構(gòu)按照視圖、狀態(tài)、網(wǎng)絡(luò)三層來劃分。src/views 只放頁(yè)面組件src/stores 放全局狀態(tài)src/api 統(tǒng)一封裝網(wǎng)絡(luò)請(qǐng)求。API 層不對(duì)業(yè)務(wù)頁(yè)面暴露 axios 實(shí)例只暴露 getQuestionById、submitAnswer 這樣的語義化方法。頁(yè)面組件里不出現(xiàn)任何請(qǐng)求方法邏輯只認(rèn) store 和 api 層的返回值。views 下目前有 Login、Dashboard、QuestionBank、Practice、MockInterview、Stats、AdminQuestion、AdminKnowledge 這些頁(yè)面。路由用 Vue Router 管理菜單和路由表一一對(duì)應(yīng)用戶端和管理端通過不同的路由前綴和導(dǎo)航菜單隔離。目錄結(jié)構(gòu)清爽之后新加頁(yè)面很少會(huì)牽扯到舊代碼這個(gè)收益在開發(fā)到中后期體現(xiàn)得非常明顯。5.2 登錄態(tài)與路由守衛(wèi)的處理前后端分離最容易出問題的是登錄態(tài)。我的處理方案是token 同時(shí)存在 localStorage 和 Pinia 里頁(yè)面刷新時(shí)從 localStorage 恢復(fù)保證刷新后不丟登錄狀態(tài)。axios 請(qǐng)求攔截器統(tǒng)一在請(qǐng)求頭里加 Authorization響應(yīng)攔截器遇到 401 時(shí)清掉用戶狀態(tài)并跳轉(zhuǎn)到登錄頁(yè)。核心代碼http.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer ${userStore.token} } return config }) http.interceptors.response.use( res res.data, err { if (err.response?.status 401) { useUserStore().logout() router.push(/login) } return Promise.reject(err) } )路由守衛(wèi)是第二道防線。在 beforeEach 里判斷如果訪問的是需要登錄的頁(yè)面且本地沒有 token直接跳登錄頁(yè)。要注意把登錄頁(yè)、注冊(cè)頁(yè)加入白名單否則會(huì)出現(xiàn)登錄時(shí)跳轉(zhuǎn)登錄頁(yè)的循環(huán)問題。這個(gè)坑我踩過表現(xiàn)形式是用戶輸完賬號(hào)密碼剛要點(diǎn)登錄頁(yè)面就被守衛(wèi)踢回登錄頁(yè)現(xiàn)象非常詭異排查了幾分鐘才發(fā)現(xiàn)是白名單漏配導(dǎo)致的。5.3 從交互細(xì)節(jié)到性能優(yōu)化性能優(yōu)化我做了五件事。組件庫(kù)按需引入用 Vite 的插件自動(dòng)把未使用的 Element Plus 組件搖掉路由懶加載每個(gè)頁(yè)面拆成獨(dú)立 chunk初始加載只下載首屏資源題目列表用分頁(yè)加條件篩選不做一次性全量加載ECharts 圖表按需引入只注冊(cè)用到的雷達(dá)圖和熱力圖模塊長(zhǎng)列表的統(tǒng)計(jì)頁(yè)用虛擬滾動(dòng)避免幾千個(gè)節(jié)點(diǎn)同時(shí)渲染。交互細(xì)節(jié)上答題頁(yè)最值得打磨。選項(xiàng)點(diǎn)擊后要有即時(shí)選中態(tài)提交過程中按鈕置灰防重復(fù)提交倒計(jì)時(shí)離開頁(yè)面時(shí)銷毀定時(shí)器防止內(nèi)存泄漏。還有一個(gè)容易忽略的點(diǎn)用戶從刷題頁(yè)跳到別的路由再回來答題狀態(tài)要能恢復(fù)我通過把當(dāng)前題目ID和已選答案存在 Pinia 里來解決。這些細(xì)節(jié)不復(fù)雜但用戶感知非常明顯也是產(chǎn)品打磨和半成品之間的核心差別。6. 部署實(shí)戰(zhàn)與高頻踩坑記錄6.1 Nginx Spring Boot 的部署組合部署方案很簡(jiǎn)單后端打成 jar 包用 systemd 守護(hù)進(jìn)程跑在 8080 端口前端 npm run build 后把 dist 目錄扔給 Nginx。Nginx 同時(shí)承擔(dān)靜態(tài)文件服務(wù)和反向代理配置如下server { listen 80; server_name your-domain.com; root /var/www/dist; index 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; } location / { try_files $uri $uri/ /index.html; } }這個(gè)配置有兩個(gè)容易踩的坑。一個(gè)是 proxy_pass 后面的路徑因?yàn)楹蠖私涌谝彩?/api 開頭所以保留了 /api/ 后綴避免路徑拼接錯(cuò)誤另一個(gè)是 try_files 的 fallback 一定要落到 /index.html否則前端路由刷新時(shí)會(huì)出現(xiàn) 404。生產(chǎn)環(huán)境上線后我還加了 systemd 的自動(dòng)重啟機(jī)制Java 進(jìn)程如果意外退出會(huì)被自動(dòng)拉起來省掉半夜爬起來重啟服務(wù)的情況。6.2 典型問題與排查速查表我把上線前后遇到的高頻問題整理成一張表基本覆蓋了這個(gè)項(xiàng)目里出現(xiàn)過的所有典型故障。現(xiàn)象原因解法頁(yè)面刷新后回到登錄頁(yè)沒有從 localStorage 恢復(fù) token初始化時(shí)從 localStorage 寫入 Pinia401 后循環(huán)跳轉(zhuǎn)登錄頁(yè)白名單配置漏了登錄頁(yè)在路由守衛(wèi)里顯式放行 /login接口返回跨域錯(cuò)誤開發(fā)代理沒配置Vite proxy 指向正確后端地址直接訪問異步路由刷新 404Nginx 沒有 fallback配置 try_files $uri $uri/ /index.html錯(cuò)題本出現(xiàn)重復(fù)記錄沒有唯一索引 / 沒做 upsert加聯(lián)合唯一索引改 upsert SQL統(tǒng)計(jì)圖數(shù)據(jù)比實(shí)際少事務(wù)未提交或條件不一致統(tǒng)一使用 created_at 并按天分組模擬面試出現(xiàn)重復(fù)題目組卷抽樣沒有排除已選題用排除集合記錄已選題目 ID這些坑基本都屬于知道原理后一分鐘解決不知道原理要查半天的類型。我把它們寫進(jìn)項(xiàng)目 README 的部署清單里后面維護(hù)或給其他人接手時(shí)會(huì)省掉很多溝通成本。6.3 做完這個(gè)項(xiàng)目我才明白的幾件事第一接口設(shè)計(jì)比實(shí)現(xiàn)接口更花時(shí)間但收益最大。我前期把接口文檔定義清楚后前后端開發(fā)幾乎不需要互相等待遇到的返工也比以往項(xiàng)目少很多。第二數(shù)據(jù)表設(shè)計(jì)決定功能上限。answer_record 冗余字段這個(gè)決定讓后面的統(tǒng)計(jì)、推薦、錯(cuò)題分析都變得簡(jiǎn)單如果當(dāng)時(shí)圖省事不冗余現(xiàn)在每個(gè)統(tǒng)計(jì)接口都要回表 join性能和可讀性都會(huì)下降。第三前后端分離不是為了炫技它帶來的真正價(jià)值是讓用戶端、管理端、未來可能的客戶端共享一套業(yè)務(wù)能力把重復(fù)代碼壓縮到最低。最后再分享一個(gè)經(jīng)驗(yàn)。這個(gè)項(xiàng)目最有價(jià)值的不是某個(gè)頁(yè)面寫得多漂亮而是那套刷題記錄—掌握度計(jì)算—推薦的數(shù)據(jù)鏈路。你在實(shí)現(xiàn)類似系統(tǒng)時(shí)不管智能功能做多深都要先把 answer_record 這張事實(shí)表設(shè)計(jì)好讓它能完整表達(dá)每一次刷題行為。數(shù)據(jù)扎實(shí)了后面加規(guī)律提醒、加復(fù)習(xí)計(jì)劃、加任何智能玩法都只是在一個(gè)穩(wěn)定的地基上添磚加瓦。我做完這個(gè)項(xiàng)目后再刷題最大的變化是心里清楚自己到底該補(bǔ)哪一塊而不是憑感覺亂翻題庫(kù)。 前后端分離的智能面試刷題系統(tǒng)：從Spring Boot到Vue 3的完整實(shí)踐
這個(gè)項(xiàng)目嚴(yán)格來說是去年秋招間隙做出來的起因特別簡(jiǎn)單用常見的刷題產(chǎn)品總覺得不順手錯(cuò)題本太散、沒有知識(shí)點(diǎn)維度的統(tǒng)計(jì)、還總被推薦一些早就掌握的題。于是我就想著干脆自己造一個(gè)智能面試刷題系統(tǒng)既能滿足日常刷題需求又順便把前后端分離的架構(gòu)完整走一遍。整個(gè)項(xiàng)目從設(shè)計(jì)到第一版上線大概用了三周技術(shù)棧選的是 Spring Boot Vue 3前端走 RESTful API 跟后端通信核心特色是答題記錄驅(qū)動(dòng)的一套推薦邏輯和可視化統(tǒng)計(jì)。這篇文章把我當(dāng)時(shí)的決策過程、數(shù)據(jù)庫(kù)設(shè)計(jì)、實(shí)現(xiàn)細(xì)節(jié)、以及上線后踩過的坑都整理出來理論和代碼都有對(duì)正在做畢設(shè)或想加深架構(gòu)理解的開發(fā)者會(huì)比較有參考價(jià)值。1. 項(xiàng)目的真實(shí)起點(diǎn)一個(gè)刷題工具的需求演進(jìn)1.1 痛點(diǎn)分析為什么需要專門做一套刷題系統(tǒng)刷題這件事看起來極其簡(jiǎn)單注冊(cè)一個(gè)賬號(hào)然后對(duì)著題庫(kù)一題一題點(diǎn)就是了。但真正堅(jiān)持用一個(gè)月以后會(huì)發(fā)現(xiàn)盲目刷題有一個(gè)非常致命的問題你根本不知道自己哪里薄弱只會(huì)被動(dòng)地按照題目順序一路點(diǎn)下去今天錯(cuò)的知識(shí)點(diǎn)明天就忘下周又錯(cuò)一遍。我在做這個(gè)項(xiàng)目之前專門觀察了自己和身邊幾個(gè)準(zhǔn)備面試的同學(xué)的使用習(xí)慣。大家刷題時(shí)最有價(jià)值的動(dòng)作其實(shí)是提交答案那一刻的判斷過程和看解析后的復(fù)盤過程。但市面上通用產(chǎn)品大多只把判斷對(duì)錯(cuò)這一步留給了你錯(cuò)題回收、知識(shí)點(diǎn)統(tǒng)計(jì)、復(fù)習(xí)提醒這些環(huán)節(jié)要么很弱要么藏得很深。所以我自己做的第一版需求就非常明確要有一條完整的刷題—記錄—分析—推薦—再刷題閉環(huán)而不是一個(gè)單純堆砌題目的文檔系統(tǒng)。這個(gè)系統(tǒng)的用戶其實(shí)只有兩類一類是求職者需要在短期內(nèi)快速補(bǔ)足薄弱知識(shí)點(diǎn)另一類是運(yùn)營(yíng)題庫(kù)的人需要一個(gè)趁手的工具把題目和知識(shí)點(diǎn)維護(hù)好。畢設(shè)或者個(gè)人項(xiàng)目最怕的就是功能無限膨脹所以我在立項(xiàng)時(shí)就把邊界卡得很死不做社區(qū)、不做社交、不做課程售賣只做跟有效刷題強(qiáng)相關(guān)的功能。1.2 功能邊界劃定與角色設(shè)計(jì)第一版的功能清單是這樣定的。用戶端只有五個(gè)核心模塊注冊(cè)登錄、刷題練習(xí)、模擬面試、錯(cuò)題本、學(xué)習(xí)統(tǒng)計(jì)。管理端是三個(gè)題庫(kù)管理、知識(shí)點(diǎn)管理、用戶數(shù)據(jù)概覽。登錄注冊(cè)這個(gè)模塊沒什么好說的唯一要注意的是密碼不能明文存我用的是標(biāo)準(zhǔn)加鹽哈希。刷題練習(xí)是主入口用戶可以選擇按順序刷、按知識(shí)點(diǎn)刷、或者直接進(jìn)入智能推薦模式。模擬面試是一個(gè)獨(dú)立的會(huì)話式場(chǎng)景按照崗位方向和難度生成一套題答題過程中有倒計(jì)時(shí)結(jié)束后給出得分和解析。錯(cuò)題本不是簡(jiǎn)單收藏夾它要記錄每個(gè)錯(cuò)題的錯(cuò)誤次數(shù)、最近錯(cuò)誤時(shí)間并且可以一鍵把錯(cuò)題重新變成一套練習(xí)卷。學(xué)習(xí)統(tǒng)計(jì)則把答題記錄聚合起來按天輸出刷題熱力圖按知識(shí)點(diǎn)輸出正確率和掌握度雷達(dá)圖。管理端的題庫(kù)管理要覆蓋題目新增、編輯、上下架、批量導(dǎo)入。知識(shí)點(diǎn)管理維護(hù)一棵知識(shí)點(diǎn)樹每個(gè)題目可以掛到一個(gè)葉子節(jié)點(diǎn)上。用戶數(shù)據(jù)概覽我做得比較克制只展示注冊(cè)用戶數(shù)、刷題總量、平均正確率這些基礎(chǔ)指標(biāo)。管理端和用戶端共用同一套后端接口權(quán)限靠 JWT 里的 role 字段區(qū)分后端在最外層攔截器里做角色校驗(yàn)這樣兩個(gè)前端應(yīng)用都能保持比較薄的邏輯。1.3 為什么堅(jiān)持前后端分離很多在校同學(xué)做系統(tǒng)時(shí)習(xí)慣把頁(yè)面模板和后端渲染混在一起理由是這樣簡(jiǎn)單減少跨域問題。但我個(gè)人強(qiáng)烈建議這類偏業(yè)務(wù)型的項(xiàng)目一開始就走前后端分離原因有三個(gè)。第一前端交互復(fù)雜度決定了它不適合服務(wù)端渲染。刷題頁(yè)面有倒計(jì)時(shí)、選項(xiàng)狀態(tài)、實(shí)時(shí)統(tǒng)計(jì)圖表、答題記錄更新這些都是典型的 SPA 場(chǎng)景用傳統(tǒng)模板一個(gè)個(gè)同步渲染會(huì)非常痛苦。第二一個(gè)后端 API 能同時(shí)喂給用戶端、管理端甚至以后接一個(gè)小程序代碼不需要重寫。第三前后端分離以后接口邊界變得清晰我可以先把接口文檔定好再讓兩個(gè)部分并行推進(jìn)整個(gè)開發(fā)節(jié)奏會(huì)快很多。當(dāng)然也要清醒認(rèn)識(shí)到分離的代價(jià)跨域配置、登錄態(tài)管理、接口聯(lián)調(diào)都是以前不需要操心的東西。這些問題在后面的各部分里都有對(duì)應(yīng)解法不存在無解的情況只是需要多學(xué)幾種新技能而已。2. 技術(shù)選型與架構(gòu)設(shè)計(jì)前后端分離的骨架搭建2.1 后端用什么、為什么不后悔后端技術(shù)棧是 Spring Boot 3.x Java 17 MyBatis-Plus MySQL 8 Redis。為什么這么選其實(shí)是在學(xué)習(xí)價(jià)值和落地速度之間做平衡。如果只是想跑通一個(gè)項(xiàng)目用 Node.js 寫接口可能更快但考慮到系統(tǒng)涉及復(fù)雜的數(shù)據(jù)統(tǒng)計(jì)、事務(wù)處理和權(quán)限模型Java 生態(tài)的穩(wěn)定性是實(shí)打?qū)嵉膬?yōu)勢(shì)。Spring Boot 幫我把絕大多數(shù)配置自動(dòng)化了我只需要關(guān)注 Controller、Service、Mapper 這一層業(yè)務(wù)代碼。MyBatis-Plus 的單表 CRUD 和分頁(yè)插件非常好用條件構(gòu)造器寫動(dòng)態(tài)查詢也很順手復(fù)雜統(tǒng)計(jì)我用自定義 XML 寫 SQL兩邊互不干擾。Redis 我用在兩個(gè)地方。第一是緩存知識(shí)點(diǎn)統(tǒng)計(jì)結(jié)果統(tǒng)計(jì)接口如果每次都去 MySQL 聚合全表數(shù)據(jù)量大了以后響應(yīng)會(huì)明顯變慢所以我在寫入 answer_record 時(shí)會(huì)同步把對(duì)應(yīng)知識(shí)點(diǎn)的統(tǒng)計(jì)緩存刪除下次讀取時(shí)再重新計(jì)算。第二是存放模擬面試的上下文一場(chǎng)面試過程中的進(jìn)度、剩余時(shí)間、題目列表都存在 Redis 里過期時(shí)間設(shè)成兩小時(shí)既能防止接口頻繁命中數(shù)據(jù)庫(kù)也能自然清理掉不活躍的會(huì)話。2.2 前端選型與工程化配置前端用了 Vue 3 Vite Pinia Vue Router Element Plus這套組合現(xiàn)在基本是中小型管理系統(tǒng)的默認(rèn)選項(xiàng)但選它不純粹是因?yàn)榱餍?。Vue 3 的組合式 API 對(duì)答題頁(yè)這種邏輯密集的頁(yè)面特別友好。選項(xiàng)式 API 寫小頁(yè)面沒問題一旦頁(yè)面里有倒計(jì)時(shí)、答題狀態(tài)、抽題邏輯、提交反饋邏輯就會(huì)散落在各個(gè)生命周期鉤子里用 setup 語法可以把同一塊業(yè)務(wù)的 ref、computed、watch 聚在一起維護(hù)成本低一個(gè)量級(jí)。Pinia 比 Vuex 輕省掉 mutation 這層概念在個(gè)人項(xiàng)目里少寫不少樣板代碼。Element Plus 我只按需引入不整包加載避免首屏?xí)r間被組件庫(kù)拖垮。Vite 帶來的體驗(yàn)提升是感知最強(qiáng)的。以前用 Webpack 啟動(dòng)一套前后端分離項(xiàng)目冷啟動(dòng)十幾秒都是常態(tài)改一行代碼還要等編譯。Vite 基于原生 ESM 實(shí)現(xiàn)按需編譯項(xiàng)目不管多大首啟基本都是秒級(jí)熱更新也是毫秒級(jí)反饋。開發(fā)刷題系統(tǒng)要反復(fù)在兩個(gè)頁(yè)面之間跳轉(zhuǎn)調(diào)整樣式這個(gè)體驗(yàn)優(yōu)勢(shì)能省下大量時(shí)間。2.3 接口規(guī)范、權(quán)限模型與跨域處理前后端分離項(xiàng)目能不能順利聯(lián)調(diào)接口規(guī)范起決定性作用。我定義了一個(gè)很簡(jiǎn)單的統(tǒng)一返回包裝類后端所有接口出參都是 { code, message, data }業(yè)務(wù)異常通過全局異常處理器轉(zhuǎn)成對(duì)應(yīng)的 code前端只需要在響應(yīng)攔截器里統(tǒng)一判斷 code。分頁(yè)接口統(tǒng)一接受 page 和 size返回 PageResult里面包含 total、records 兩個(gè)字段避免每個(gè)接口各搞一套返回結(jié)構(gòu)。資源命名走 RESTful 風(fēng)格/api/questions、/api/answer-records、/api/exam-sessions。這類系統(tǒng)里面試題目和答題記錄都是完整資源用 RESTful 的方式描述非常自然。前端請(qǐng)求路徑不再出現(xiàn)動(dòng)詞接口語義也更清晰。權(quán)限模型沒有上 Spring Security而是用 JWT 加攔截器的輕量方案。登錄成功后后端返回一個(gè)包含 userId 和 role 的 JWT前端放在 localStorage 里每次請(qǐng)求通過 axios 攔截器加在 Authorization 頭。后端攔截器對(duì)所有 /api/** 請(qǐng)求做 token 校驗(yàn)管理端接口額外檢查 role 是否為管理員解析失敗或角色不對(duì)直接返回 401 和 403。這套方案對(duì)中小項(xiàng)目完全夠用代碼少也容易讀懂。跨域問題我分開處理。開發(fā)環(huán)境用 Vite 的 proxy 把 /api 代理到后端地址瀏覽器看到的是同源請(qǐng)求不存在跨域。生產(chǎn)環(huán)境用 Nginx 反向代理直接把對(duì) /api 的請(qǐng)求轉(zhuǎn)發(fā)到 Java 服務(wù)同樣不需要后端開啟 CORS。這樣處理的好處是減少攻擊面也更貼近真實(shí)線上部署的形態(tài)。而且開發(fā)環(huán)境和生產(chǎn)環(huán)境的行為保持一致前端代碼不需要根據(jù)環(huán)境維護(hù)兩套 baseURL排查接口問題時(shí)只需要抓 Nginx 日志和 Java 應(yīng)用日志兩處就夠了。3. 數(shù)據(jù)模型設(shè)計(jì)與核心業(yè)務(wù)實(shí)現(xiàn)3.1 數(shù)據(jù)庫(kù)到底建了幾張表我把表控制在六張核心表不建一堆中間表來增加維護(hù)成本。設(shè)計(jì)原則只有一個(gè)所有后續(xù)要做統(tǒng)計(jì)和推薦的數(shù)據(jù)必須在產(chǎn)生那一刻就能支撐查詢避免統(tǒng)計(jì)時(shí)到處 join。表名關(guān)鍵字段說明userid, username, password_hash, nickname, role用戶表role 區(qū)分普通用戶/管理員knowledge_pointid, name, parent_id, weight知識(shí)點(diǎn)樹weight 表示重要度questionid, type, difficulty, point_id, stem, options, answer, analysis, status題庫(kù)type 區(qū)分選擇題/簡(jiǎn)答題/編程題answer_recordid, user_id, question_id, point_id, difficulty, is_correct, answer_content, use_time, created_at答題流水表業(yè)務(wù)核心wrong_bookid, user_id, question_id, error_count, last_wrong_at, review_status錯(cuò)題狀態(tài)表exam_sessionid, user_id, mode, difficulty, question_ids, status, score模擬面試會(huì)話表這里我想強(qiáng)調(diào) answer_record 這張表。它本質(zhì)上是一張事實(shí)表每一行代表一次真實(shí)的刷題行為。字段里冗余了 point_id 和 difficulty雖然打破了盡量不冗余的潔癖但對(duì)統(tǒng)計(jì)性能幫助很大按知識(shí)點(diǎn)算正確率時(shí)不需要再回表查 question 表直接 group by point_id 就行。建議在這張表上建立聯(lián)合索引 (user_id, point_id, created_at)這是整個(gè)系統(tǒng)最高頻的查詢路徑。當(dāng)初如果不建這個(gè)索引統(tǒng)計(jì)數(shù)據(jù)一多接口響應(yīng)時(shí)間會(huì)從毫秒級(jí)一路漲到秒級(jí)。3.2 刷題主流程一次完整答題的數(shù)據(jù)流轉(zhuǎn)一次完整答題的數(shù)據(jù)流轉(zhuǎn)是整個(gè)項(xiàng)目里最核心的一條鏈路。用戶點(diǎn)開始刷題后前端向后端請(qǐng)求推薦題目后端根據(jù)推薦策略返回一道題用戶提交答案后端判斷對(duì)錯(cuò)寫入 answer_record更新掌握度緩存和錯(cuò)題本最后把正確答案、解析和新掌握度返回給前端。提交答案的處理邏輯用代碼寫是這樣Transactional public AnswerResult submitAnswer(SubmitRequest request) { Question question questionMapper.selectById(request.getQuestionId()); boolean correct question.getAnswer().equalsIgnoreCase(request.getAnswer()); AnswerRecord record new AnswerRecord(); record.setUserId(request.getUserId()); record.setQuestionId(question.getId()); record.setPointId(question.getPointId()); record.setDifficulty(question.getDifficulty()); record.setCorrect(correct); record.setUseTime(request.getUseTime()); answerRecordMapper.insert(record); masteryCache.evict(request.getUserId(), question.getPointId()); if (!correct) { wrongBookMapper.upsert(request.getUserId(), question.getId()); } return new AnswerResult(question, correct); }注意事務(wù)注解一定不能少。一開始我漏了事務(wù)結(jié)果出現(xiàn)用戶提交答案后answer_record 寫入了而錯(cuò)題本沒有更新的情況自我排查時(shí)非常難受。因?yàn)樵谕皇聞?wù)里要么全部成功要么全部回滾這條鏈路絕不能出現(xiàn)中間狀態(tài)。3.3 錯(cuò)題本與刷題統(tǒng)計(jì)的底層邏輯錯(cuò)題本用 upsert 語義實(shí)現(xiàn)這是一個(gè)容易想錯(cuò)的地方。如果每次答錯(cuò)都 insert 一條錯(cuò)題記錄同一個(gè)題在錯(cuò)題本里會(huì)出現(xiàn)多條展示時(shí)還要去重邏輯非常別扭。正確做法是在錯(cuò)題表里用 (user_id, question_id) 建唯一索引答錯(cuò)時(shí)執(zhí)行存在就累加錯(cuò)誤次數(shù)不存在才插入的更新語句。復(fù)習(xí)狀態(tài)我是用一個(gè) review_status 字段管理的初始值是等待復(fù)習(xí)用戶把錯(cuò)題重新做對(duì)一次后變成已掌握下次再錯(cuò)再回退。這個(gè)字段我一開始沒想清楚直接把錯(cuò)題表當(dāng)收藏夾用后來加了字段才讓復(fù)習(xí)一下變成可操作的動(dòng)作。前端在錯(cuò)題本里提供篩選條件只看待復(fù)習(xí)、只看已掌握加上一鍵復(fù)習(xí)按鈕比單純展示所有錯(cuò)題實(shí)用得多。統(tǒng)計(jì)模塊相對(duì)直接。按天刷題量用一個(gè) SQL 就能查出來SELECT DATE_FORMAT(created_at, %Y-%m-%d) AS day, COUNT(*) AS total FROM answer_record WHERE user_id #{userId} GROUP BY day ORDER BY day;知識(shí)點(diǎn)掌握度統(tǒng)計(jì)類似group by point_id 后計(jì)算正確率和答題量前端再用雷達(dá)圖渲染出來。這套統(tǒng)計(jì)鏈路不復(fù)雜但前提是 answer_record 表的結(jié)構(gòu)一開始就設(shè)計(jì)對(duì)數(shù)據(jù)來源不能亂統(tǒng)計(jì)結(jié)果才有意義。4. 智能推薦策略讓刷題有方向而不是瞎碰4.1 可解釋的推薦比看不見的玄學(xué)推薦更重要說到智能很多人第一反應(yīng)是上協(xié)同過濾或者跑一個(gè)神經(jīng)網(wǎng)絡(luò)模型。但對(duì)這類個(gè)人項(xiàng)目來說效果并不好用戶和題目的交互矩陣極度稀疏冷啟動(dòng)問題根本繞不開而且推薦結(jié)果無法解釋用戶會(huì)困惑為什么給我推這道題。我的設(shè)計(jì)原則是把推薦做成可解釋的。推薦一道題時(shí)前端可以明確展示推薦理由比如你最近關(guān)于二分查找的掌握度偏低推薦完成這道題。這種可解釋性既讓用戶信服也讓代碼邏輯更好維護(hù)。推薦鏈路只依賴 answer_record 和 knowledge_point 兩張表可控性很強(qiáng)后續(xù)想調(diào)整規(guī)則也只是改一個(gè) Service 的事情。從實(shí)際使用反饋來看用戶對(duì)這種知道為什么推題的接受度比我預(yù)期高很多。4.2 掌握度計(jì)算與推薦優(yōu)先級(jí)掌握度是整個(gè)推薦策略的核心指標(biāo)。我不采用簡(jiǎn)單的歷史正確率因?yàn)檎_率沒法體現(xiàn)時(shí)間衰減很久以前錯(cuò)過的知識(shí)點(diǎn)如果最近一直做對(duì)應(yīng)該認(rèn)為它正在被掌握。所以用帶時(shí)間衰減的加權(quán)平均核心邏輯如下public double calculateMastery(ListAnswerRecord records) { double sumWeight 0.0; double sumCorrect 0.0; for (AnswerRecord record : records) { double days Duration.between(record.getCreatedAt(), LocalDateTime.now()).toDays(); double weight Math.exp(-days / 7.0); sumWeight weight; sumCorrect record.isCorrect() ? weight : 0.0; } return sumWeight 0 ? sumCorrect / sumWeight : 0.5; }衰減周期設(shè)成 7 天相當(dāng)于一周前的答題權(quán)重衰減到約 37%兩周前基本忽略。這個(gè)參數(shù)我一開始是拍腦袋定的但實(shí)測(cè)體驗(yàn)比純正確率平滑很多后來也就沒有再調(diào)。需要注意的是掌握度計(jì)算不要放在每次請(qǐng)求里實(shí)時(shí)掃全表正確做法是答題提交時(shí)更新知識(shí)點(diǎn)的掌握度緩存推薦接口直接讀緩存。推薦優(yōu)先級(jí)分三層。第一層是最薄弱知識(shí)點(diǎn)下、且重要度 weight 高的未做題目直接強(qiáng)推薦。第二層是掌握度在 0.4 到 0.6 之間的知識(shí)點(diǎn)說明處于邊界狀態(tài)需要加強(qiáng)。第三層是近期完全沒有刷過題的知識(shí)點(diǎn)用隨機(jī)池?fù)埔粌傻纴肀３指采w面。每次后端生成一個(gè)候選題池在池內(nèi)隨機(jī)選一道返回避免用戶連續(xù)刷到同一題。這套規(guī)則我用一個(gè)策略接口封裝每層策略只負(fù)責(zé)篩選候選題后面想加按崗位過濾或者按題目熱度排序也只是新增策略類的問題。4.3 模擬面試與智能組卷的輕量實(shí)現(xiàn)模擬面試模式是為了給用戶一個(gè)完整的作答節(jié)奏。用戶選擇崗位方向和難度后后端按知識(shí)點(diǎn)權(quán)重進(jìn)行配額抽題保證一套試卷覆蓋多個(gè)知識(shí)點(diǎn)而不是全抽到同一個(gè)點(diǎn)。組卷邏輯聽起來復(fù)雜落實(shí)下來其實(shí)就是一個(gè)按知識(shí)點(diǎn)配額的抽樣算法先算出每個(gè)知識(shí)點(diǎn)要抽多少題再?gòu)脑撝R(shí)點(diǎn)的題目池里隨機(jī)抽抽過的題要放到排除集合里避免重復(fù)。核心思路用代碼寫是這樣MapLong, Integer quotaMap buildQuotaMap(knowledgePoints, totalCount); for (Map.EntryLong, Integer entry : quotaMap.entrySet()) { ListQuestion pool questionMapper.selectByPointAndDifficulty( entry.getKey(), difficulty, excludedIds); selected.addAll(randomPick(pool, entry.getValue())); }選擇題提交后立刻自動(dòng)判分簡(jiǎn)答題初版采用關(guān)鍵詞匹配評(píng)分把參考答案里預(yù)先標(biāo)注的核心關(guān)鍵詞和用戶答案做包含比對(duì)按命中率給分編程題因?yàn)樵诰€判題工程量太大第一版只展示參考答案讓用戶自評(píng)。分?jǐn)?shù)統(tǒng)計(jì)和面試報(bào)告仍然完整生成用戶可以翻看每個(gè)知識(shí)點(diǎn)的表現(xiàn)。5. 前端落地與體驗(yàn)打磨5.1 SPA應(yīng)用的結(jié)構(gòu)規(guī)劃前端項(xiàng)目結(jié)構(gòu)按照視圖、狀態(tài)、網(wǎng)絡(luò)三層來劃分。src/views 只放頁(yè)面組件src/stores 放全局狀態(tài)src/api 統(tǒng)一封裝網(wǎng)絡(luò)請(qǐng)求。API 層不對(duì)業(yè)務(wù)頁(yè)面暴露 axios 實(shí)例只暴露 getQuestionById、submitAnswer 這樣的語義化方法。頁(yè)面組件里不出現(xiàn)任何請(qǐng)求方法邏輯只認(rèn) store 和 api 層的返回值。views 下目前有 Login、Dashboard、QuestionBank、Practice、MockInterview、Stats、AdminQuestion、AdminKnowledge 這些頁(yè)面。路由用 Vue Router 管理菜單和路由表一一對(duì)應(yīng)用戶端和管理端通過不同的路由前綴和導(dǎo)航菜單隔離。目錄結(jié)構(gòu)清爽之后新加頁(yè)面很少會(huì)牽扯到舊代碼這個(gè)收益在開發(fā)到中后期體現(xiàn)得非常明顯。5.2 登錄態(tài)與路由守衛(wèi)的處理前后端分離最容易出問題的是登錄態(tài)。我的處理方案是token 同時(shí)存在 localStorage 和 Pinia 里頁(yè)面刷新時(shí)從 localStorage 恢復(fù)保證刷新后不丟登錄狀態(tài)。axios 請(qǐng)求攔截器統(tǒng)一在請(qǐng)求頭里加 Authorization響應(yīng)攔截器遇到 401 時(shí)清掉用戶狀態(tài)并跳轉(zhuǎn)到登錄頁(yè)。核心代碼http.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer ${userStore.token} } return config }) http.interceptors.response.use( res res.data, err { if (err.response?.status 401) { useUserStore().logout() router.push(/login) } return Promise.reject(err) } )路由守衛(wèi)是第二道防線。在 beforeEach 里判斷如果訪問的是需要登錄的頁(yè)面且本地沒有 token直接跳登錄頁(yè)。要注意把登錄頁(yè)、注冊(cè)頁(yè)加入白名單否則會(huì)出現(xiàn)登錄時(shí)跳轉(zhuǎn)登錄頁(yè)的循環(huán)問題。這個(gè)坑我踩過表現(xiàn)形式是用戶輸完賬號(hào)密碼剛要點(diǎn)登錄頁(yè)面就被守衛(wèi)踢回登錄頁(yè)現(xiàn)象非常詭異排查了幾分鐘才發(fā)現(xiàn)是白名單漏配導(dǎo)致的。5.3 從交互細(xì)節(jié)到性能優(yōu)化性能優(yōu)化我做了五件事。組件庫(kù)按需引入用 Vite 的插件自動(dòng)把未使用的 Element Plus 組件搖掉路由懶加載每個(gè)頁(yè)面拆成獨(dú)立 chunk初始加載只下載首屏資源題目列表用分頁(yè)加條件篩選不做一次性全量加載ECharts 圖表按需引入只注冊(cè)用到的雷達(dá)圖和熱力圖模塊長(zhǎng)列表的統(tǒng)計(jì)頁(yè)用虛擬滾動(dòng)避免幾千個(gè)節(jié)點(diǎn)同時(shí)渲染。交互細(xì)節(jié)上答題頁(yè)最值得打磨。選項(xiàng)點(diǎn)擊后要有即時(shí)選中態(tài)提交過程中按鈕置灰防重復(fù)提交倒計(jì)時(shí)離開頁(yè)面時(shí)銷毀定時(shí)器防止內(nèi)存泄漏。還有一個(gè)容易忽略的點(diǎn)用戶從刷題頁(yè)跳到別的路由再回來答題狀態(tài)要能恢復(fù)我通過把當(dāng)前題目ID和已選答案存在 Pinia 里來解決。這些細(xì)節(jié)不復(fù)雜但用戶感知非常明顯也是產(chǎn)品打磨和半成品之間的核心差別。6. 部署實(shí)戰(zhàn)與高頻踩坑記錄6.1 Nginx Spring Boot 的部署組合部署方案很簡(jiǎn)單后端打成 jar 包用 systemd 守護(hù)進(jìn)程跑在 8080 端口前端 npm run build 后把 dist 目錄扔給 Nginx。Nginx 同時(shí)承擔(dān)靜態(tài)文件服務(wù)和反向代理配置如下server { listen 80; server_name your-domain.com; root /var/www/dist; index 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; } location / { try_files $uri $uri/ /index.html; } }這個(gè)配置有兩個(gè)容易踩的坑。一個(gè)是 proxy_pass 后面的路徑因?yàn)楹蠖私涌谝彩?/api 開頭所以保留了 /api/ 后綴避免路徑拼接錯(cuò)誤另一個(gè)是 try_files 的 fallback 一定要落到 /index.html否則前端路由刷新時(shí)會(huì)出現(xiàn) 404。生產(chǎn)環(huán)境上線后我還加了 systemd 的自動(dòng)重啟機(jī)制Java 進(jìn)程如果意外退出會(huì)被自動(dòng)拉起來省掉半夜爬起來重啟服務(wù)的情況。6.2 典型問題與排查速查表我把上線前后遇到的高頻問題整理成一張表基本覆蓋了這個(gè)項(xiàng)目里出現(xiàn)過的所有典型故障。現(xiàn)象原因解法頁(yè)面刷新后回到登錄頁(yè)沒有從 localStorage 恢復(fù) token初始化時(shí)從 localStorage 寫入 Pinia401 后循環(huán)跳轉(zhuǎn)登錄頁(yè)白名單配置漏了登錄頁(yè)在路由守衛(wèi)里顯式放行 /login接口返回跨域錯(cuò)誤開發(fā)代理沒配置Vite proxy 指向正確后端地址直接訪問異步路由刷新 404Nginx 沒有 fallback配置 try_files $uri $uri/ /index.html錯(cuò)題本出現(xiàn)重復(fù)記錄沒有唯一索引 / 沒做 upsert加聯(lián)合唯一索引改 upsert SQL統(tǒng)計(jì)圖數(shù)據(jù)比實(shí)際少事務(wù)未提交或條件不一致統(tǒng)一使用 created_at 并按天分組模擬面試出現(xiàn)重復(fù)題目組卷抽樣沒有排除已選題用排除集合記錄已選題目 ID這些坑基本都屬于知道原理后一分鐘解決不知道原理要查半天的類型。我把它們寫進(jìn)項(xiàng)目 README 的部署清單里后面維護(hù)或給其他人接手時(shí)會(huì)省掉很多溝通成本。6.3 做完這個(gè)項(xiàng)目我才明白的幾件事第一接口設(shè)計(jì)比實(shí)現(xiàn)接口更花時(shí)間但收益最大。我前期把接口文檔定義清楚后前后端開發(fā)幾乎不需要互相等待遇到的返工也比以往項(xiàng)目少很多。第二數(shù)據(jù)表設(shè)計(jì)決定功能上限。answer_record 冗余字段這個(gè)決定讓后面的統(tǒng)計(jì)、推薦、錯(cuò)題分析都變得簡(jiǎn)單如果當(dāng)時(shí)圖省事不冗余現(xiàn)在每個(gè)統(tǒng)計(jì)接口都要回表 join性能和可讀性都會(huì)下降。第三前后端分離不是為了炫技它帶來的真正價(jià)值是讓用戶端、管理端、未來可能的客戶端共享一套業(yè)務(wù)能力把重復(fù)代碼壓縮到最低。最后再分享一個(gè)經(jīng)驗(yàn)。這個(gè)項(xiàng)目最有價(jià)值的不是某個(gè)頁(yè)面寫得多漂亮而是那套刷題記錄—掌握度計(jì)算—推薦的數(shù)據(jù)鏈路。你在實(shí)現(xiàn)類似系統(tǒng)時(shí)不管智能功能做多深都要先把 answer_record 這張事實(shí)表設(shè)計(jì)好讓它能完整表達(dá)每一次刷題行為。數(shù)據(jù)扎實(shí)了后面加規(guī)律提醒、加復(fù)習(xí)計(jì)劃、加任何智能玩法都只是在一個(gè)穩(wěn)定的地基上添磚加瓦。我做完這個(gè)項(xiàng)目后再刷題最大的變化是心里清楚自己到底該補(bǔ)哪一塊而不是憑感覺亂翻題庫(kù)。