把“企業(yè)人才招聘系統(tǒng)”這個(gè)題目拆開(kāi)看它其實(shí)不是在做網(wǎng)站而是在解決一個(gè)三方協(xié)作的效率問(wèn)題候選人要快速找到匹配崗位HR要高效篩選簡(jiǎn)歷、推進(jìn)面試流程管理層要能實(shí)時(shí)掌握招聘進(jìn)度。這三方訴求完全不同但又被同一條招聘流程串在一起。我用Spring Boot Vue這套前后端分離的技術(shù)棧把這個(gè)項(xiàng)目完整落地之后最大的感受是招聘系統(tǒng)的難點(diǎn)不在CURD而在流程狀態(tài)管理、簡(jiǎn)歷數(shù)據(jù)結(jié)構(gòu)化、以及不同角色之間的數(shù)據(jù)權(quán)限邊界。這篇文章我會(huì)從業(yè)務(wù)建模、技術(shù)選型、后端核心模塊、前端工程化、聯(lián)調(diào)排坑到部署上線把整套系統(tǒng)的設(shè)計(jì)思路和實(shí)現(xiàn)細(xì)節(jié)一次講透。適合正在做畢業(yè)設(shè)計(jì)、想積累全棧項(xiàng)目經(jīng)驗(yàn)的在校生也適合準(zhǔn)備從單體應(yīng)用轉(zhuǎn)向前后端分離開(kāi)發(fā)的Java工程師參考。1. 招聘系統(tǒng)的業(yè)務(wù)痛點(diǎn)在哪里不只是“發(fā)職位、收簡(jiǎn)歷”很多新手拿到這個(gè)題目第一反應(yīng)就是做幾個(gè)頁(yè)面職位列表、簡(jiǎn)歷投遞、后臺(tái)管理。但真把需求理一遍你會(huì)發(fā)現(xiàn)招聘業(yè)務(wù)的復(fù)雜度遠(yuǎn)超表面。1.1 三方角色的核心訴求拆解這個(gè)系統(tǒng)里至少有三種完全不同的用戶角色每種角色的使用場(chǎng)景和操作頻率都不一樣候選人端核心訴求是“快速找到合適的崗位、投遞簡(jiǎn)歷、跟蹤進(jìn)度”。候選人不會(huì)天天登錄系統(tǒng)但一旦登錄就希望看到我的投遞記錄、面試狀態(tài)有沒(méi)有更新。這決定了前端需要有清晰的狀態(tài)展示后端需要支撐按候選人維度查詢投遞記錄。HR/招聘官端核心訴求是“高效篩選簡(jiǎn)歷、安排面試、記錄評(píng)價(jià)”。HR每天要處理幾十甚至上百份簡(jiǎn)歷如果每次操作都要點(diǎn)好幾個(gè)頁(yè)面她寧可用Excel。所以簡(jiǎn)歷列表的批量操作、快速篩選、狀態(tài)流轉(zhuǎn)的效率直接決定這個(gè)系統(tǒng)會(huì)不會(huì)被真正用起來(lái)。管理端核心訴求是“掌握招聘全局、統(tǒng)計(jì)渠道效果”。管理者不會(huì)關(guān)心某一份簡(jiǎn)歷的具體情況他們要的是“本月各崗位收到多少簡(jiǎn)歷、面試通過(guò)率多少、哪個(gè)渠道簡(jiǎn)歷質(zhì)量最高”。這意味著數(shù)據(jù)統(tǒng)計(jì)接口和可視化報(bào)表是管理端的重頭戲。1.2 招聘主流程的狀態(tài)機(jī)設(shè)計(jì)我把招聘主流程抽象成一條完整的狀態(tài)鏈這是整個(gè)系統(tǒng)最核心的業(yè)務(wù)邏輯簡(jiǎn)歷投遞 - 簡(jiǎn)歷篩選(通過(guò)/淘汰) - 初試安排 - 初試通過(guò) - 復(fù)試安排 - 復(fù)試通過(guò) - Offer審批 - 已錄用 - 已入職每個(gè)狀態(tài)節(jié)點(diǎn)都包含“進(jìn)入條件”和“觸發(fā)動(dòng)作”。比如簡(jiǎn)歷篩選通過(guò)后系統(tǒng)要自動(dòng)生成一條面試安排記錄并給候選人發(fā)送通知。狀態(tài)流轉(zhuǎn)不是簡(jiǎn)單改一個(gè)字段而是要在事務(wù)里同時(shí)更新主表狀態(tài)、寫(xiě)入操作日志、觸發(fā)后續(xù)業(yè)務(wù)動(dòng)作。狀態(tài)機(jī)設(shè)計(jì)上我用了一個(gè)很直接的方式在簡(jiǎn)歷投遞表resume_delivery里維護(hù)一個(gè)current_status字段同時(shí)用一張delivery_status_log表記錄每一次狀態(tài)變更的完整歷史。這樣既能快速查詢當(dāng)前狀態(tài)又能追溯整個(gè)流轉(zhuǎn)過(guò)程。2. 技術(shù)選型復(fù)盤(pán)Spring Boot Vue的組合優(yōu)勢(shì)與配套組件取舍選型這件事直接決定項(xiàng)目開(kāi)發(fā)的順暢度和后期維護(hù)成本。我最終確定的技術(shù)棧是Spring Boot 2.7 Vue 3 MyBatis-Plus MySQL 8.0 Redis Elasticsearch下面具體說(shuō)每個(gè)選擇的理由。2.1 為什么前端選Vue 3而不是Vue 2或ReactVue 3的組合式APIComposition API對(duì)中后臺(tái)系統(tǒng)的開(kāi)發(fā)友好度非常高。招聘系統(tǒng)的頁(yè)面有大量“篩選條件 表格 分頁(yè) 彈窗”的固定模式用組合式API可以把每個(gè)頁(yè)面的邏輯按功能拆成獨(dú)立的useXxx函數(shù)比如usePositionList、useResumeFilter代碼復(fù)用和可維護(hù)性比Vue 2的選項(xiàng)式API好很多。Vue官方的構(gòu)建工具Vite也值得一夸開(kāi)發(fā)環(huán)境下熱更新響應(yīng)速度比Webpack快一個(gè)量級(jí)。對(duì)候選人端這種需要頻繁調(diào)整樣式的場(chǎng)景Vite的HMR體驗(yàn)?zāi)芄?jié)省大量開(kāi)發(fā)時(shí)間。至于React不是說(shuō)它不好而是對(duì)于這個(gè)項(xiàng)目來(lái)說(shuō)Vue的學(xué)習(xí)曲線更平緩中文生態(tài)更完善ant-design-vue、Element Plus這些組件庫(kù)開(kāi)箱即用團(tuán)隊(duì)成員上手成本低。2.2 后端框架選型Spring Boot為主為什么沒(méi)有直接套用若依Spring Boot的優(yōu)勢(shì)不用說(shuō)太多自動(dòng)配置、起步依賴、生態(tài)成熟。關(guān)鍵是我在開(kāi)發(fā)前糾結(jié)過(guò)一個(gè)問(wèn)題要不要直接用若依RuoYi這種快速開(kāi)發(fā)平臺(tái)。若依確實(shí)提供了現(xiàn)成的用戶管理、角色權(quán)限、代碼生成等功能可以直接在上面二次開(kāi)發(fā)。但仔細(xì)權(quán)衡后我放棄了原因有二第一若依的代碼侵入性強(qiáng)它的權(quán)限模型、數(shù)據(jù)字典、代碼生成規(guī)則都是自己一套如果你的業(yè)務(wù)結(jié)構(gòu)和它的假設(shè)不完全匹配改造成本比從零開(kāi)發(fā)還高第二招聘系統(tǒng)的核心價(jià)值在業(yè)務(wù)邏輯而非管理后臺(tái)把時(shí)間花在理解若依的框架規(guī)則上性價(jià)比不如自己搭建一套符合業(yè)務(wù)直覺(jué)的輕量級(jí)架構(gòu)。所以我的做法是參考若依的權(quán)限設(shè)計(jì)思路RBAC模型但自己實(shí)現(xiàn)精簡(jiǎn)版。用Sa-Token做認(rèn)證授權(quán)它比Shiro配置更簡(jiǎn)單、比Spring Security的“官方套娃”風(fēng)格更清爽天然支持前后端分離的Token認(rèn)證模式。2.3 流程引擎的引入Flowable在面試流程中的應(yīng)用面試流程相比簡(jiǎn)歷投遞復(fù)雜得多尤其是大企業(yè)里“HR初篩 - 技術(shù)面 - 技術(shù)面二輪 - HR面 - 薪資溝通 - Offer審批”這種多級(jí)流程如果每個(gè)節(jié)點(diǎn)都用if-else硬編碼后續(xù)調(diào)整流程順序會(huì)非常痛苦。我用Flowable做了面試流程的編排把面試流程定義為一個(gè)BPMN流程模板。這樣面試官審批、HR流轉(zhuǎn)、候選人狀態(tài)變更都走工作流引擎流程的節(jié)點(diǎn)順序、審批人規(guī)則可以通過(guò)流程定義文件靈活調(diào)整不用改代碼。比如“技術(shù)面二輪”這一節(jié)點(diǎn)可以在流程定義里配置為“如果技術(shù)面一輪評(píng)分大于80分則自動(dòng)跳轉(zhuǎn)到HR面否則結(jié)束流程”。不過(guò)這里要提醒一下Flowable的學(xué)習(xí)曲線不低如果項(xiàng)目只是簡(jiǎn)單的一輪面試需求不建議上工作流引擎用狀態(tài)機(jī)加一張流程配置表完全夠用。工作流引擎適合流程復(fù)雜且經(jīng)常變化的場(chǎng)景過(guò)度設(shè)計(jì)反而增加維護(hù)成本。3. 后端核心模塊的落地簡(jiǎn)歷解析、職位匹配、面試流程狀態(tài)機(jī)招聘系統(tǒng)后端最核心的技術(shù)點(diǎn)我總結(jié)為三個(gè)簡(jiǎn)歷數(shù)據(jù)的結(jié)構(gòu)化解析、職位與候選人的智能匹配、以及貫穿始終的面試流程狀態(tài)機(jī)。這三個(gè)點(diǎn)對(duì)應(yīng)了候選人、HR、管理者三個(gè)角色的核心痛點(diǎn)。下面逐一拆解。3.1 簡(jiǎn)歷解析從“收到一份PDF”到“結(jié)構(gòu)化候選人數(shù)據(jù)”簡(jiǎn)歷解析是招聘系統(tǒng)特有的技術(shù)難點(diǎn)。候選人上傳的簡(jiǎn)歷可能是PDF、Word、圖片格式內(nèi)容版式千差萬(wàn)別。如果只是把簡(jiǎn)歷文件存起來(lái)HR每次都要下載打開(kāi)看那就沒(méi)有發(fā)揮系統(tǒng)的信息整合優(yōu)勢(shì)。我的實(shí)現(xiàn)方案分三步走第一步文本提取。PDF用Apache PDFBox提取文本W(wǎng)ord用Apache POI的HWPF/XWPF讀取圖片類簡(jiǎn)歷先接OCR服務(wù)識(shí)別。這里有個(gè)很容易踩的坑PDFBox對(duì)掃描版PDF其實(shí)就是圖片提取不到任何文本所以要先探測(cè)PDF是否包含文本層如果沒(méi)有就走OCR流程。第二步規(guī)則 模型結(jié)合的信息抽取。純規(guī)則解析簡(jiǎn)歷的效果很差因?yàn)楹?jiǎn)歷的版式太多樣了。我的做法是用HanLP分詞工具做NER命名實(shí)體識(shí)別配合正則規(guī)則提取姓名、手機(jī)號(hào)、郵箱、教育經(jīng)歷、工作經(jīng)歷、技能關(guān)鍵詞。HanLP在Spring Boot工程里的接入成本也不高引入依賴后封裝一個(gè)NLP服務(wù)就行。第三步解析結(jié)果落庫(kù)并建立索引。解析出的結(jié)構(gòu)化數(shù)據(jù)存入候選人表candidate同時(shí)把技能標(biāo)簽、工作經(jīng)歷摘要同步到Elasticsearch索引為后面的職位匹配和簡(jiǎn)歷搜索做準(zhǔn)備。3.2 職位匹配基于關(guān)鍵詞權(quán)重和相似度評(píng)分的推薦邏輯職位匹配是招聘系統(tǒng)另一個(gè)亮點(diǎn)功能。我的思路是給職位JD和候選人簡(jiǎn)歷分別打標(biāo)簽然后計(jì)算相似度得分。具體做法職位JD在發(fā)布時(shí)系統(tǒng)自動(dòng)提取技能要求關(guān)鍵詞人工可二次調(diào)整每個(gè)關(guān)鍵詞的權(quán)重比如“Java”權(quán)重5、“Spring Boot”權(quán)重3、“項(xiàng)目管理”權(quán)重1。候選人簡(jiǎn)歷解析后同樣生成技能標(biāo)簽集合。匹配度計(jì)算采用加權(quán)Jaccard相似系數(shù)公式如下score sum(候選人技能標(biāo)簽中命中JD關(guān)鍵詞的權(quán)重) / sum(JD全部關(guān)鍵詞權(quán)重)舉個(gè)例子某崗位要求Java(權(quán)重5)、Spring Boot(權(quán)重3)、Redis(權(quán)重2)。候選人A的技能標(biāo)簽命中Java和Spring Boot那匹配度就是 (53)/(532) 0.8。系統(tǒng)按分?jǐn)?shù)從高到低排序超過(guò)60分的簡(jiǎn)歷在HR端的簡(jiǎn)歷列表中加“高匹配”標(biāo)簽。這個(gè)邏輯不復(fù)雜但很實(shí)用。它比純ES的全文檢索多了一個(gè)精細(xì)化權(quán)重控制又不像機(jī)器學(xué)習(xí)模型那樣需要訓(xùn)練數(shù)據(jù)屬于性價(jià)比非常高的方案。3.3 簡(jiǎn)歷投遞和面試狀態(tài)機(jī)的實(shí)現(xiàn)細(xì)節(jié)狀態(tài)機(jī)的實(shí)現(xiàn)我用了策略模式加一張狀態(tài)流轉(zhuǎn)配置表。表結(jié)構(gòu)大致是delivery_flow_config: id, from_status, event, to_status, role_type比如一條配置記錄是from_status 簡(jiǎn)歷篩選, event 初試通過(guò), to_status 復(fù)試安排, role_type HR。代碼里定義好DELIVERY_STATUS枚舉狀態(tài)流轉(zhuǎn)時(shí)先查配置表校驗(yàn)狀態(tài)變更是否合法再在同一個(gè)事務(wù)里執(zhí)行狀態(tài)更新、日志記錄、通知觸發(fā)。這樣做的好處是如果想增加一個(gè)“電話初篩”狀態(tài)只需在配置表里加幾條記錄完全不用改Java代碼。候選人的投遞記錄表設(shè)計(jì)也有講究不是簡(jiǎn)單存一個(gè)崗位ID和簡(jiǎn)歷ID而是做了快照冗余resume_delivery投遞主表記錄候選人、崗位、當(dāng)前狀態(tài)、投遞時(shí)間。delivery_snapshot投遞快照表保存投遞那一刻的簡(jiǎn)歷核心內(nèi)容摘要。因?yàn)楹蜻x人簡(jiǎn)歷后期可能會(huì)更新但HR在某次面試中看到的應(yīng)該是投遞時(shí)的版本這是業(yè)務(wù)上很細(xì)節(jié)但很重要的點(diǎn)。這被稱為時(shí)點(diǎn)一致性。如果不做快照候選人修改簡(jiǎn)歷后歷史投遞記錄中看到的簡(jiǎn)歷也變了這對(duì)面試評(píng)價(jià)非常不友好。4. 前端工程化實(shí)踐Vue 3 Vite Element Plus的組合實(shí)戰(zhàn)后端設(shè)計(jì)得再好前端體驗(yàn)不行整個(gè)項(xiàng)目的完成度也會(huì)大打折扣。這一部分聊聊我在Vue 3工程化落地過(guò)程中的關(guān)鍵實(shí)踐。4.1 項(xiàng)目初始化與目錄結(jié)構(gòu)設(shè)計(jì)我用Vite創(chuàng)建項(xiàng)目工程目錄直接按業(yè)務(wù)域劃分而不是按技術(shù)類型劃分src/ api/ // 接口請(qǐng)求封裝 layout/ // 布局組件側(cè)邊欄 頂欄 內(nèi)容區(qū) views/ candidate/ // 候選人端頁(yè)面 hr/ // HR端頁(yè)面 admin/ // 管理端頁(yè)面 login/ // 登錄/注冊(cè) components/ // 通用組件 router/ // 路由配置 store/ // Pinia狀態(tài)管理 utils/ // 工具函數(shù)這里有一個(gè)很多初學(xué)者容易犯的錯(cuò)誤把組件按名稱平鋪在一個(gè)目錄下文件多了之后找起來(lái)非常痛苦。按業(yè)務(wù)域劃分之后所有和候選人相關(guān)的頁(yè)面、組件都在candidate/下維護(hù)起來(lái)思路清晰。4.2 路由守衛(wèi)與權(quán)限控制前端路由的權(quán)限控制是前后端分離項(xiàng)目“安全邊界”的一部分。我把前端路由分為三類公開(kāi)路由比如登錄頁(yè)、注冊(cè)頁(yè)、職位瀏覽列表任何人可以訪問(wèn)。候選人路由需要候選人Token才能訪問(wèn)我的投遞、個(gè)人中心。HR/管理路由需要HR或管理員角色權(quán)限才能訪問(wèn)簡(jiǎn)歷管理、職位管理、數(shù)據(jù)看板。在路由守衛(wèi)router.beforeEach里做全局?jǐn)r截邏輯思路是router.beforeEach(async (to, from, next) { const token localStorage.getItem(token) if (!token to.meta.public ! true) { next(/login) return } if (token !store.userInfo) { await store.fetchUserInfo() // 請(qǐng)求后端獲取用戶信息和角色 } if (to.meta.roles !to.meta.roles.includes(store.userInfo.role)) { next(/403) return } next() })這里特別要注意的是前端路由守衛(wèi)只是用戶體驗(yàn)層面的控制真正的安全校驗(yàn)必須以后端接口鑒權(quán)為準(zhǔn)。前端隱藏了某個(gè)入口不代表接口不能被直接調(diào)用所以后端的每個(gè)接口都要校驗(yàn)當(dāng)前登錄人的角色權(quán)限。4.3 簡(jiǎn)歷篩選頁(yè)面的性能優(yōu)化虛擬滾動(dòng)與條件篩選簡(jiǎn)歷列表是HR端最核心的頁(yè)面一條數(shù)據(jù)列表項(xiàng)里包含候選人姓名、崗位、匹配度標(biāo)簽、當(dāng)前狀態(tài)、投遞時(shí)間一頁(yè)20條數(shù)據(jù)渲染起來(lái)本來(lái)沒(méi)問(wèn)題。但HR經(jīng)常會(huì)連續(xù)翻幾十頁(yè)加上篩選條件的聯(lián)動(dòng)頁(yè)面復(fù)雜度上來(lái)之后操作卡頓感就非常明顯。針對(duì)這個(gè)場(chǎng)景我做了兩個(gè)關(guān)鍵優(yōu)化優(yōu)化一篩選條件防抖 后端分頁(yè)。篩選條件的表單綁定值變化時(shí)用watch加防抖300ms避免用戶每敲一個(gè)字就觸發(fā)一次接口請(qǐng)求。watch(filterForm, debounce((newVal) { loadPage(1) }, 300))優(yōu)化二長(zhǎng)列表虛擬滾動(dòng)。當(dāng)切換到“全部簡(jiǎn)歷”等大數(shù)據(jù)量視圖時(shí)用虛擬滾動(dòng)組件按需渲染可視區(qū)域內(nèi)的行DOM節(jié)點(diǎn)數(shù)從幾千降到幾十個(gè)滾動(dòng)流暢度提升非常明顯。對(duì)內(nèi)部系統(tǒng)來(lái)說(shuō)優(yōu)先用表格的懶加載分頁(yè)即可特殊場(chǎng)景才按需引入虛擬滾動(dòng)。4.4 候選人端的狀態(tài)跟蹤看板設(shè)計(jì)候選人端的核心頁(yè)面是“我的投遞”我用時(shí)間線組件展示每條投遞的狀態(tài)流轉(zhuǎn)歷史。比如3月10日 10:23 簡(jiǎn)歷已投遞 3月11日 14:05 簡(jiǎn)歷篩選通過(guò)進(jìn)入初試安排 3月13日 09:30 初試安排3月15日 10:00 3月15日 11:20 初試完成等待復(fù)試通知這個(gè)時(shí)間線數(shù)據(jù)從哪里來(lái)就是我前面提到的delivery_status_log表。后端提供一個(gè)按投遞ID查詢狀態(tài)日志的接口按時(shí)間倒序返回前端用時(shí)間線組件渲染。這個(gè)設(shè)計(jì)讓候選人清楚地知道自己的簡(jiǎn)歷處于什么階段極大減少了“簡(jiǎn)歷投了沒(méi)回音”的焦慮感也減少了HR重復(fù)回答“您幫我看看進(jìn)度”的溝通成本。頁(yè)面實(shí)現(xiàn)中我還用了Vue 3的computed屬性來(lái)做狀態(tài)文案映射避免在模板里寫(xiě)大段的v-if判斷const statusMap computed(() ({ 1: { text: 簡(jiǎn)歷已投遞, type: info }, 2: { text: 簡(jiǎn)歷篩選通過(guò), type: success }, 3: { text: 初試安排中, type: warning }, // ... }))5. 前后端分離聯(lián)調(diào)中的真實(shí)問(wèn)題跨域、鑒權(quán)和長(zhǎng)接口超時(shí)項(xiàng)目開(kāi)發(fā)到后期真正的挑戰(zhàn)不是某個(gè)技術(shù)點(diǎn)實(shí)現(xiàn)不了而是前后端配合時(shí)的各種“隱形問(wèn)題”。我把聯(lián)調(diào)期間踩過(guò)的幾個(gè)典型問(wèn)題拿出來(lái)分享每個(gè)都是反復(fù)排查后才搞定的。5.1 跨域問(wèn)題不只是加個(gè)注解那么簡(jiǎn)單開(kāi)發(fā)環(huán)境下前端跑在Vite的5173端口后端跑在8080端口跨域問(wèn)題必然出現(xiàn)。網(wǎng)上的常見(jiàn)答案是CrossOrigin或者在配置類里寫(xiě)addCorsMappings但我在實(shí)際項(xiàng)目中建議用統(tǒng)一配置 生產(chǎn)環(huán)境Nginx反向代理的方案。開(kāi)發(fā)環(huán)境的跨域配置在一個(gè)WebMvcConfigurer里統(tǒng)一處理Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(http://localhost:*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true); } }生產(chǎn)環(huán)境則由Nginx做反向代理前端請(qǐng)求/api前綴的接口時(shí)由Nginx轉(zhuǎn)發(fā)到后端服務(wù)不存在跨域問(wèn)題。這也是前后端分離項(xiàng)目生產(chǎn)部署的標(biāo)準(zhǔn)姿勢(shì)。排查經(jīng)驗(yàn)跨域問(wèn)題還有一個(gè)隱蔽的坑就是瀏覽器預(yù)檢請(qǐng)求OPTIONS請(qǐng)求沒(méi)有通過(guò)導(dǎo)致實(shí)際的GET/POST請(qǐng)求根本沒(méi)發(fā)出去。如果后端JWT過(guò)濾器攔截了OPTIONS請(qǐng)求并返回401前端會(huì)看到一個(gè)特別迷惑的報(bào)錯(cuò)。解決方案是在過(guò)濾鏈里對(duì)OPTIONS請(qǐng)求直接放行。5.2 Token鑒權(quán)機(jī)制Sa-Token的前后端分離集成Sa-Token是一個(gè)輕量級(jí)的Java權(quán)限認(rèn)證框架官方對(duì)前后端分離模式的支持很完善。集成思路是用戶登錄成功后后端簽發(fā)Token返回給前端。前端把Token存在本地存儲(chǔ)中每次請(qǐng)求在攔截器里帶著satoken頭。后端配置Sa-Token攔截器除了登錄、注冊(cè)、職位列表等公開(kāi)接口外其余接口全部校驗(yàn)Token有效性。Configuration public class SaTokenConfigure implements WebMvcInterceptor { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new SaInterceptor(handle - StpUtil.checkLogin())) .addPathPatterns(/**) .excludePathPatterns(/api/auth/login, /api/auth/register, /api/position/list, /api/position/detail/**); } }多角色權(quán)限校驗(yàn)用SaCheckRole(hr)注解直接標(biāo)在接口方法上非常簡(jiǎn)潔。這套方案對(duì)比Spring Security最大優(yōu)勢(shì)就是上手簡(jiǎn)單、沒(méi)有厚厚一層配置類。如果你項(xiàng)目對(duì)安全要求不是銀行級(jí)別Sa-Token的性價(jià)比很高。5.3 長(zhǎng)接口超時(shí)問(wèn)題簡(jiǎn)歷解析的異步化處理簡(jiǎn)歷解析接口在候選人上傳大體積附件時(shí)可能耗時(shí)數(shù)秒如果同步返回前端等這么久體驗(yàn)極差還容易觸發(fā)HTTP連接超時(shí)。我的方案是把簡(jiǎn)歷解析改成異步流程候選人上傳簡(jiǎn)歷后接口只做文件存儲(chǔ)和寫(xiě)入解析任務(wù)記錄立刻返回“上傳成功正在解析”。后端用線程池異步執(zhí)行解析邏輯解析完成后更新解析狀態(tài)字段并把結(jié)構(gòu)化數(shù)據(jù)寫(xiě)入候選人和ES索引。候選人端通過(guò)輪詢或者WebSocket接收解析完成通知。這個(gè)設(shè)計(jì)同時(shí)解決了用戶體驗(yàn)和服務(wù)器資源占用兩個(gè)問(wèn)題。線程池我用的Spring自帶的Async配置了一個(gè)獨(dú)立的Executor核心線程數(shù)8、最大線程數(shù)20、隊(duì)列容量200避免簡(jiǎn)歷解析這種IO密集和CPU密集混合的任務(wù)阻塞主業(yè)務(wù)接口。6. 數(shù)據(jù)庫(kù)與接口設(shè)計(jì)從表結(jié)構(gòu)到前后端接口約定后端工程里數(shù)據(jù)庫(kù)表設(shè)計(jì)和接口定義直接決定前端開(kāi)發(fā)的順暢程度。這塊我單獨(dú)講。6.1 核心數(shù)據(jù)表的設(shè)計(jì)思路招聘系統(tǒng)的數(shù)據(jù)庫(kù)表結(jié)構(gòu)我按業(yè)務(wù)域拆成五組用戶與權(quán)限域sys_user用戶主表id, username, password, phone, email, role_type, statussys_role/sys_user_roleRBAC權(quán)限模型職位與公司域company企業(yè)信息表position職位表id, company_id, title, department, salary_min, salary_max, tags, requirement, statusposition_channel職位渠道表記錄職位發(fā)布的渠道用于統(tǒng)計(jì)渠道效果候選人域candidate候選人基本信息擴(kuò)展表id, user_id, real_name, resume_file_url, skill_tags, work_years, educationresume_delivery投遞記錄表id, candidate_id, position_id, current_status, delivery_timedelivery_status_log投遞狀態(tài)日志表id, delivery_id, from_status, to_status, operator_id, remark, create_time面試域interview面試安排表id, delivery_id, interview_type, interview_time, interviewer_id, address, statusinterview_feedback面試評(píng)價(jià)表id, interview_id, interviewer_id, score, strengths, weaknesses, conclusion統(tǒng)計(jì)域主要是各類聚合統(tǒng)計(jì)直接SQL查詢生成不單獨(dú)建表避免數(shù)據(jù)冗余。一個(gè)關(guān)鍵的設(shè)計(jì)決策是sys_user和candidate分開(kāi)存。因?yàn)橐粋€(gè)人可能先以候選人身份注冊(cè)后來(lái)入職成為HR甚至同一人在不同企業(yè)下有不同身份。用戶基礎(chǔ)信息放sys_user候選人擴(kuò)展信息放candidate用user_id關(guān)聯(lián)。這樣既避免了單表字段過(guò)多也保留了身份演變的靈活性。6.2 接口設(shè)計(jì)的統(tǒng)一規(guī)范前后端分離的項(xiàng)目接口規(guī)范一定要在開(kāi)發(fā)前定清楚不然后期聯(lián)調(diào)全是口水仗。我的約定是以下這幾點(diǎn)接口路徑候選人端接口/api/candidate/**HR端接口/api/hr/**管理端接口/api/admin/**公開(kāi)接口/api/public/**統(tǒng)一響應(yīng)結(jié)構(gòu){ code: 200, message: success, data: {} }所有接口都返回這個(gè)結(jié)構(gòu)前端封裝的axios攔截器里統(tǒng)一判斷code不等于200就走錯(cuò)誤提示邏輯。異常處理用RestControllerAdvice全局捕獲業(yè)務(wù)異常和系統(tǒng)異常避免拋出難看的堆棧給前端。分頁(yè)參數(shù)統(tǒng)一后端統(tǒng)一接收pageNum和pageSize返回結(jié)構(gòu)里帶total和records前端表格組件直接對(duì)接。MyBatis-Plus的分頁(yè)插件配置好之后寫(xiě)分頁(yè)查詢不需要額外操作只管寫(xiě)普通查詢方法傳分頁(yè)參數(shù)進(jìn)去即可。7. 部署上線與維護(hù)從本機(jī)聯(lián)調(diào)到服務(wù)器發(fā)布的經(jīng)驗(yàn)小結(jié)項(xiàng)目開(kāi)發(fā)完成不是終點(diǎn)能穩(wěn)定跑在服務(wù)器上才是。部署環(huán)節(jié)我遇到過(guò)不少問(wèn)題這里挑關(guān)鍵的寫(xiě)。7.1 JDK版本與Spring Boot版本匹配的坑項(xiàng)目本地用的是JDK 17 Spring Boot 2.7。打包部署時(shí)開(kāi)發(fā)同學(xué)和運(yùn)維同學(xué)經(jīng)常栽在環(huán)境差異上——本地好好的服務(wù)器上啟動(dòng)報(bào)錯(cuò)。最先排查的必然是Java版本。Spring Boot 2.x要求JDK 8以上但如果你用了Spring Boot 3.x就必須配JDK 17。所以一個(gè)簡(jiǎn)單原則Spring Boot 2.7配JDK 8或11Spring Boot 3.x配JDK 17。有些朋友習(xí)慣用IDEA默認(rèn)的Spring Initializr創(chuàng)建項(xiàng)目默認(rèn)可能就是3.x版本在只裝了JDK 8的服務(wù)器上編譯打包直接報(bào)錯(cuò)。這塊出錯(cuò)率非常高選擇版本時(shí)建議統(tǒng)一并鎖死在項(xiàng)目配置中。7.2 打包部署的完整流程我的打包部署流程可供參考后端用Maven打包mvn clean package -Dmaven.test.skiptrue產(chǎn)出jar包。前端構(gòu)建npm run build產(chǎn)出dist目錄。Nginx配置root指向dist目錄location /api/反向代理到Spring Boot服務(wù)的8080端口并配置client_max_body_size 50m簡(jiǎn)歷文件可能比較大默認(rèn)1M肯定不夠。后端服務(wù)用java -jar app.jar --spring.profiles.activeprod啟動(dòng)加載生產(chǎn)環(huán)境配置。生產(chǎn)環(huán)境的數(shù)據(jù)庫(kù)連接、Redis地址等敏感配置不寫(xiě)死在代碼里用application-prod.yml文件在服務(wù)器上單獨(dú)放置。7.3 用Docker Desktop做環(huán)境一致性驗(yàn)證我個(gè)人的習(xí)慣是項(xiàng)目正式上服務(wù)器前先在本地用Docker Desktop跑一遍鏡像驗(yàn)證環(huán)境一致性。主要思路是后端工程寫(xiě)一個(gè)Dockerfile基礎(chǔ)鏡像用eclipse-temurin:8-jdk或17-jdk根據(jù)之前的JDK版本結(jié)論決定。MySQL、Redis都通過(guò)docker-compose一鍵啟動(dòng)。前端構(gòu)建完的dist目錄直接用Nginx的鏡像托管。這套方案的好處是所有依賴環(huán)境都在鏡像里定義好了服務(wù)器上只要裝了Docker不需要再去排查缺什么依賴環(huán)境。團(tuán)隊(duì)里來(lái)新人拉下來(lái)一鍵啟動(dòng)跟跑起來(lái)本地開(kāi)發(fā)環(huán)境幾乎無(wú)差異省掉了大量“在我電腦上是好的”這種問(wèn)題。7.4 簡(jiǎn)歷文件存儲(chǔ)方案簡(jiǎn)歷文件我選了阿里云OSS做存儲(chǔ)而不是存在服務(wù)器本地磁盤(pán)。原因很現(xiàn)實(shí)應(yīng)用服務(wù)器是無(wú)狀態(tài)的才方便擴(kuò)容如果簡(jiǎn)歷都存在一臺(tái)服務(wù)器的磁盤(pán)上那臺(tái)掛了文件就丟了而且多臺(tái)應(yīng)用服務(wù)器之前文件不共享。OSS用起來(lái)也簡(jiǎn)單// OSS客戶端上傳 public String uploadResume(MultipartFile file, String candidateId) { String objectKey resume/ candidateId / System.currentTimeMillis() _ file.getOriginalFilename(); ossClient.putObject(bucketName, objectKey, file.getInputStream()); return https://cdn.example.com/ objectKey; }上傳成功后返回文件URL數(shù)據(jù)庫(kù)里存URL字符串。前端下載簡(jiǎn)歷只需要拿到URL直接讓瀏覽器打開(kāi)不需要后端做文件流中轉(zhuǎn)。7.5 簡(jiǎn)歷導(dǎo)出功能及大文件下載的內(nèi)存問(wèn)題這里有必要單拿出簡(jiǎn)歷導(dǎo)出案例。HR端有個(gè)“選中簡(jiǎn)歷批量導(dǎo)出”的功能一開(kāi)始我用POI在內(nèi)存里構(gòu)建Workbook一次性導(dǎo)出的簡(jiǎn)歷超過(guò)3000份時(shí)內(nèi)存直接爆了。排查后確認(rèn)是JVM堆內(nèi)存不足。踩坑之后我修正了思路用SXSSFWorkbook流式寫(xiě)入邊生成邊寫(xiě)臨時(shí)文件同時(shí)配合分頁(yè)查詢數(shù)據(jù)庫(kù)避免一次性加載大量數(shù)據(jù)。另外把導(dǎo)出接口改成異步導(dǎo)出完成后生成下載鏈接通過(guò)消息通知HR而不在前端頁(yè)面干等同步請(qǐng)求。這個(gè)“導(dǎo)出類接口一律異步化”的經(jīng)驗(yàn)后來(lái)在其他項(xiàng)目里也復(fù)用了幾次。7.6 文件上傳斷點(diǎn)續(xù)傳與并發(fā)控制招聘系統(tǒng)簡(jiǎn)歷上傳的場(chǎng)景候選人可能在網(wǎng)絡(luò)不穩(wěn)定的情況下上傳幾十MB的附件。如果直接做一個(gè)FormData整包上傳斷網(wǎng)就全沒(méi)了。我在項(xiàng)目里做了分片上傳前端把文件切割成2MB一片逐片上傳后端每片存一份臨時(shí)文件全部上傳完后合并。如果中途斷了下次續(xù)傳時(shí)先查一下哪些分片已上傳只補(bǔ)傳缺失的分片。這個(gè)方案實(shí)現(xiàn)成本可控但對(duì)體驗(yàn)提升非常明顯。后端合并時(shí)要注意文件鎖防止并發(fā)合并同一個(gè)文件造成損壞我用的是Redis分布式鎖以fileUpload:{userId}:{fileHash}作為鎖key合并完再刪除鎖。寫(xiě)在最后的幾個(gè)實(shí)操建議整個(gè)項(xiàng)目從設(shè)計(jì)、編碼、聯(lián)調(diào)到部署我用周末和晚上時(shí)間做了一個(gè)多月動(dòng)手做一次全棧項(xiàng)目的收獲遠(yuǎn)大于看十篇教程。這里分享幾個(gè)我復(fù)盤(pán)后覺(jué)得最重要的經(jīng)驗(yàn)第一先設(shè)計(jì)狀態(tài)機(jī)和表結(jié)構(gòu)再寫(xiě)代碼至少能少走一半彎路。招聘系統(tǒng)的核心是流程驅(qū)動(dòng)的狀態(tài)流轉(zhuǎn)圖哪怕畫(huà)在紙上都比一邊寫(xiě)代碼一邊想“這個(gè)狀態(tài)怎么變”要強(qiáng)得多。第二權(quán)限設(shè)計(jì)不要一開(kāi)始就搞特別復(fù)雜的模型。先滿足候選人、HR、管理員三種角色RBAC的擴(kuò)展能力足夠應(yīng)對(duì)后續(xù)需求。一上來(lái)就搞多租戶、數(shù)據(jù)權(quán)限隔離很可能會(huì)被復(fù)雜度拖垮。第三前后端接口聯(lián)調(diào)時(shí)Mock數(shù)據(jù)準(zhǔn)備得越充分聯(lián)調(diào)效率越高。我建議每個(gè)接口定義完成后立即在Swagger/Knife4j里寫(xiě)好前端可以馬上對(duì)照文檔開(kāi)始開(kāi)發(fā)不用等后端代碼寫(xiě)完。接口字段改動(dòng)時(shí)文檔同步更新減少溝通成本。第四日志記錄從一開(kāi)始就做好。招聘系統(tǒng)的狀態(tài)流轉(zhuǎn)、面試安排修改、簡(jiǎn)歷下載這些關(guān)鍵操作都必須有操作日志。不然上線后用戶說(shuō)“我明明沒(méi)收到通知怎么狀態(tài)變成初試通過(guò)了”你連查都無(wú)從查起。第五性能優(yōu)化要有數(shù)據(jù)支撐不要憑感覺(jué)。哪里的接口慢先看慢SQL日志、看接口耗時(shí)統(tǒng)計(jì)定位到瓶頸再優(yōu)化。招聘系統(tǒng)在中等并發(fā)下最值得優(yōu)化的通常是數(shù)據(jù)庫(kù)索引設(shè)計(jì)和列表查詢的N1問(wèn)題而不是糾結(jié)用沒(méi)用微服務(wù)。這個(gè)系統(tǒng)后續(xù)還可以擴(kuò)展的方向包括對(duì)接企業(yè)微信消息通知、接入AI簡(jiǎn)歷初篩、增加視頻面試模塊、打通入職后的員工檔案系統(tǒng)。每一步擴(kuò)展在當(dāng)前的架構(gòu)下都有清晰的位置可以插入不會(huì)推翻重來(lái)這也是當(dāng)初沒(méi)有用重度框架、保持模塊邊界清晰換來(lái)的好處。如果你們團(tuán)隊(duì)也在做類似的項(xiàng)目歡迎在評(píng)論區(qū)交流具體的實(shí)現(xiàn)細(xì)節(jié)。