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