1. 畢設(shè)選題為什么要做招聘系統(tǒng)一個既穩(wěn)又耐打的全棧練手項目每年到畢設(shè)季我都能收到一堆私信問的大多是同一個問題市面上那么多開源項目電商、博客、商城、后臺管理系統(tǒng)到處都是為什么我建議做招聘平臺這類項目尤其還是 SpringBoot Vue 這種已經(jīng)爛大街的組合做出來會不會顯得沒新意先說結(jié)論招聘系統(tǒng)不僅不會沒新意反而是最適合用來證明你掌握全棧開發(fā)能力的項目類型之一。原因有三。第一它天然帶有多角色概念。一個招聘平臺里有求職者、有企業(yè)招聘方、還要有平臺管理員這就意味著你的系統(tǒng)必須有完善的權(quán)限控制邏輯而權(quán)限設(shè)計恰恰是面試官最愛問、課設(shè)答辯時最容易拉分的點。電商項目大多數(shù)只有買家和管理員兩個角色招聘系統(tǒng)天然是三端甚至四端復(fù)雜度剛好比普通管理系統(tǒng)高一個臺階但又沒有高到做不完的程度。第二招聘系統(tǒng)的業(yè)務(wù)邏輯非常貼近真實企業(yè)級應(yīng)用。職位發(fā)布、簡歷投遞、收藏職位、簡歷篩選、面試邀請、消息通知、數(shù)據(jù)統(tǒng)計每一個模塊都對應(yīng)真實業(yè)務(wù)場景。你在學(xué)校寫的是一個畢設(shè)但做出來的東西實際上是一個行業(yè)軟件的迷你版這套業(yè)務(wù)模型對后續(xù)找工作、寫簡歷、進公司做需求理解都有幫助。第三從技術(shù)覆蓋面上講SpringBoot Vue 的組合能把你大學(xué)四年學(xué)過的東西全部串起來。后端你要寫 RESTful API要用 Spring Security 做認證和授權(quán)要用 MyBatis-Plus 操作 MySQL要用 JWT 做無狀態(tài)登錄前端你要用 Vue Router 管理頁面路由用 Vuex 或 Pinia 管理狀態(tài)用 Axios 封裝請求用 Element UI 搭建后臺頁面。整套流程走完Java 基礎(chǔ)、數(shù)據(jù)庫、前端、部署運維全都能過一遍手性價比極高。我見過很多學(xué)生一上來就想折騰微服務(wù)、分布式鎖、消息隊列結(jié)果做到一半發(fā)現(xiàn)連單體的 CRUD 都寫不利索最后只能從網(wǎng)上扒代碼改改交上去答辯時一問細節(jié)就露餡。所以如果你是大三下或大四上Java 基礎(chǔ)還行但沒完整做過一個系統(tǒng)的階段SpringBoot Vue 的大學(xué)生就業(yè)招聘系統(tǒng)管理平臺是一個非常推薦的選題既能控制開發(fā)周期又能保證技術(shù)深度。這篇內(nèi)容我會把整個項目從需求拆解、數(shù)據(jù)庫設(shè)計、后端接口、前端頁面到部署上線的完整鏈路都梳理一遍幫你在做畢設(shè)時少踩幾個坑。2. 系統(tǒng)邊界與角色權(quán)限設(shè)計別把需求只寫成管理員能刪帖子很多人的畢設(shè)死在第一步需求文檔寫得稀爛或者壓根沒寫直接打開 IDEA 就開始建表。建表建到一半發(fā)現(xiàn)字段缺東少西返回去改實體類、改 Mapper XML折騰幾輪后代碼一團亂麻。我建議所有做這類項目的同學(xué)先花一天時間把角色、功能、頁面清單梳理清楚這一步做好了后面寫代碼的速度能快一倍。2.1 三類角色分別需要什么頁面和接口大學(xué)生就業(yè)招聘系統(tǒng)管理平臺核心角色就是求職者學(xué)生、招聘企業(yè)企業(yè)賬號和系統(tǒng)管理員。有的項目還會拆出導(dǎo)師或就業(yè)指導(dǎo)中心這類角色但作為畢設(shè)來說三類角色已經(jīng)足夠撐起整個系統(tǒng)的復(fù)雜度再加角色反而容易把權(quán)限邏輯寫亂。先看求職者端。求職者最核心的需求是找工作和投簡歷。那他的功能就應(yīng)該是注冊登錄、完善個人簡歷基本信息、教育經(jīng)歷、實習(xí)經(jīng)歷、項目經(jīng)歷、技能標(biāo)簽、瀏覽職位列表、按關(guān)鍵詞和城市篩選職位、查看職位詳情、投遞簡歷、查看投遞狀態(tài)待查看、已查看、邀面試、已拒絕、收藏職位、查看面試通知、修改密碼、退出登錄。注意投遞狀態(tài)這條線一定要做這是招聘系統(tǒng)區(qū)別于普通信息發(fā)布平臺的核心特征你需要在后端維護一張投遞記錄表記錄每一次投遞的流轉(zhuǎn)狀態(tài)。企業(yè)端這邊核心需求是發(fā)布職位和篩選候選人。對應(yīng)功能是企業(yè)注冊/登錄、企業(yè)信息管理公司名稱、規(guī)模、行業(yè)、簡介、Logo、職位管理發(fā)布職位、上下架職位、編輯職位、收到的簡歷列表也就是投遞記錄管理、簡歷詳情查看、投遞狀態(tài)更新比如把某個候選人的狀態(tài)改為邀面試、面試邀請發(fā)送、職位數(shù)據(jù)統(tǒng)計比如收到的簡歷總數(shù)、職位瀏覽數(shù)這個可以作為加分項做。管理員端就相對簡單了主要做的是平臺治理用戶審核企業(yè)注冊后是否需要管理員審核通過才能登錄、職位審核企業(yè)發(fā)布的職位是否需要先過審、用戶管理禁用/啟用求職者賬號、企業(yè)管理和分類管理職位類別、城市字典這類基礎(chǔ)數(shù)據(jù)維護。這里我強烈建議給企業(yè)注冊加一個待審核狀態(tài)一旦加了管理員的存在的價值就體現(xiàn)出來了答辯時你可以理直氣壯地說我的系統(tǒng)有完整的內(nèi)容審核機制。2.2 角色權(quán)限怎么落到代碼上權(quán)限設(shè)計我推薦用最簡單有效的方式Spring Security JWT配合路徑級別和方法級別的雙重校驗。用戶登錄成功后后端根據(jù)角色返回不同的 Token 格式或在 Token 中放入角色標(biāo)識。前端拿到 Token 后存在 localStorage 中Axios 攔截器統(tǒng)一在請求頭加Authorization: Bearer token后端通過 Filter 解析 Token、拿用戶信息、判斷角色權(quán)限。具體到實現(xiàn)層我建議用自定義注解PreAuthorize(hasRole(COMPANY))之類的寫法控制在 Controller 層。有的同學(xué)會去引入 Spring Security 的完整 ACL 權(quán)限模型說實話對一個課設(shè)來說太重了也不好講清楚。你只需要保證未登錄用戶不能訪問任何業(yè)務(wù)接口求職者接口只允許學(xué)生角色調(diào)用企業(yè)接口只允許企業(yè)角色調(diào)用后臺管理接口只允許管理員調(diào)用這個粒度就足夠答辯了。這里有一個容易翻車的地方Spring Security 從 5.7 版本開始WebSecurityConfigurerAdapter被標(biāo)記為過時了。如果你用的是 SpringBoot 2.7 以上的版本網(wǎng)上大量老教程的寫法會報錯。我自己在實際項目里推薦直接使用SecurityFilterChain的 Bean 定義方式配置過濾鏈這是新版推薦做法也避免了答辯時被問為什么用過期寫法的尷尬。2.3 狀態(tài)機設(shè)計投遞記錄是系統(tǒng)的心臟招聘平臺最容易做成一堆 CRUD 堆積的地方就是把投遞記錄做成一張只有已投遞/未投遞兩個狀態(tài)的表。實際上投遞是有完整生命周期的學(xué)生投遞簡歷后狀態(tài)為待查看企業(yè)查看簡歷后狀態(tài)變?yōu)橐巡榭雌髽I(yè)覺得合適點擊邀請面試狀態(tài)變?yōu)槊嬖囇s同時系統(tǒng)生成一條面試通知給用戶企業(yè)覺得不合適狀態(tài)變?yōu)橐丫芙^。我建議你在設(shè)計數(shù)據(jù)表時給投遞記錄表加一個status字段用 TINYINT 類型存數(shù)字枚舉0 待查看、1 已查看、2 面試邀約、3 已拒絕。之所以用數(shù)字不用字符串是因為數(shù)字枚舉在數(shù)據(jù)庫層面更省空間、查詢更快后端做一個枚舉類映射即可。這個狀態(tài)流看著簡單但它是整個招聘業(yè)務(wù)的中樞你的消息通知、用戶中心列表、企業(yè)收到的簡歷列表全都依賴這張表的狀態(tài)變化把它做扎實了系統(tǒng)就立住了一半。3. 數(shù)據(jù)庫設(shè)計從 Table 結(jié)構(gòu)到字段類型的具體落地如果說權(quán)限設(shè)計是招聘系統(tǒng)的大動脈那數(shù)據(jù)庫設(shè)計就是這副骨架的基石。我見過很多學(xué)生的項目代碼寫著寫著發(fā)現(xiàn)關(guān)聯(lián)查詢關(guān)聯(lián)不上最后只能靠MapString, Object硬塞數(shù)據(jù)根本原因就是表結(jié)構(gòu)沒設(shè)計好。這一節(jié)我會把招聘系統(tǒng)的核心表結(jié)構(gòu)直接拆給你看。3.1 核心表清單與字段設(shè)計一個完整的招聘系統(tǒng)至少有八張核心表用戶表存放所有登錄賬號、求職者信息表擴展學(xué)生資料、企業(yè)信息表、職位表、投遞記錄表、收藏表、面試通知表、新聞/公告表可選用于前臺展示就業(yè)政策類內(nèi)容。下面是每張表的核心字段和設(shè)計思路。用戶表t_userid主鍵username用戶名password密碼BCrypt 加密后存儲phone手機號email郵箱role角色用 VARCHAR 存字符串值就是 STUDENT、COMPANY、ADMINstatus狀態(tài)0 正常、1 禁用create_time創(chuàng)建時間。注意用戶名建議加唯一索引登錄時用用戶名查表效率高。求職者信息表t_student_profileiduser_id關(guān)聯(lián)用戶表real_name真實姓名gender性別birth_date出生日期school學(xué)校major專業(yè)education學(xué)歷枚舉本科、碩士、博士等graduate_year畢業(yè)年份phone聯(lián)系方式emailintroduction個人簡介resume_file_url簡歷附件地址如果是 PDF 上傳的話avatar_url頭像。企業(yè)信息表t_companyiduser_idcompany_name公司全稱company_short_name公司簡稱industry所屬行業(yè)scale公司規(guī)模人數(shù)區(qū)間city所在城市address詳細地址introduction公司介紹logo_urlLogo 地址status企業(yè)狀態(tài)0 正常、1 禁用audit_status審核狀態(tài)0 待審核、1 審核通過、2 審核駁回。職位表t_jobidcompany_id關(guān)聯(lián)企業(yè)job_name職位名稱category_id職位分類city工作城市salary_min薪資下限salary_max薪資上限education_requirement學(xué)歷要求experience_requirement經(jīng)驗要求應(yīng)屆生/1-3年/3-5年等job_desc職位描述job_requirement任職要求status職位狀態(tài)0 上架、1 下架audit_status審核狀態(tài)0 待管理員審核、1 通過、2 駁回view_count瀏覽次數(shù)create_time發(fā)布時間。投遞記錄表t_delivery_recordidstudent_profile_id求職者job_id職位company_id冗余企業(yè) ID查詢方便status投遞狀態(tài)0 待查看、1 已查看、2 邀面試、3 已拒絕create_time投遞時間update_time狀態(tài)更新時間。這張表一定要給student_profile_id job_id建聯(lián)合唯一索引防止同一個學(xué)生重復(fù)投遞同一個職位。收藏表t_favoriteidstudent_profile_idjob_idcreate_time。同樣建聯(lián)合唯一索引。面試通知表t_interviewiddelivery_record_id關(guān)聯(lián)投遞記錄student_profile_idcompany_idjob_idinterview_time面試時間interview_address面試地點message通知內(nèi)容status狀態(tài)0 未讀、1 已讀create_time。公告/新聞表t_newsidtitle標(biāo)題content內(nèi)容cover_url封面圖create_time。這個表是為了讓前臺首頁有內(nèi)容可展示同時給管理員后臺的內(nèi)容管理模塊提供數(shù)據(jù)支撐屬于錦上添花型設(shè)計。3.2 字段類型的幾個實戰(zhàn)建議我看到不少學(xué)生的建表語句用了一堆VARCHAR(255)什么字段都往里塞這不合理。以下幾點是實際開發(fā)中非常容易踩的坑。第一個坑是密碼字段長度。BCrypt 加密后的字符串長度是 60 個字符如果你把密碼字段設(shè)為VARCHAR(32)注冊時一加密就報Data too long。很多新手因為這個查半天查不到原因。密碼字段直接給VARCHAR(100)留夠余量。第二個坑是文本類的字段。職位描述、公司介紹、個人簡介、新聞內(nèi)容這類字段一定要用TEXT類型而不是VARCHAR(255)。介紹性文字隨便寫兩三百字很常見VARCHAR 255 根本扛不住。如果你沒用 MyBatis-Plus 的自動填充插入大文本時也要留意不要超出限制。另外 MySQL 5.7 之后支持JSON類型如果你想把一個學(xué)生的技能標(biāo)簽存成一個數(shù)組用 JSON 類型會比拆一張標(biāo)簽表簡單很多但缺點是關(guān)聯(lián)查詢麻煩課設(shè)場景我不建議為了炫技用。第三個坑是金額和薪資字段。薪資上下限建議用INT類型存月薪千為單位的數(shù)比如salary_min 8代表月薪 8K。不要用DECIMAL(10,2)沒必要還把類型搞復(fù)雜了。如果是做真實項目薪資字段要考慮稅前稅后、年薪月薪的差異但課設(shè)場景用千為單位最直觀、最好展示。第四個坑是時間字段。創(chuàng)建時間、更新時間不要用VARCHAR直接用DATETIME。MyBatis-Plus 有自動填充功能你可以在實體類上配置TableField(fill FieldFill.INSERT)和TableField(fill FieldFill.INSERT_UPDATE)然后在項目里寫一個MetaObjectHandler的實現(xiàn)類每次插入和更新時自動填入當(dāng)前時間這樣你連setCreateTime都不用寫省事且統(tǒng)一。3.3 關(guān)聯(lián)查詢怎么設(shè)計才不跑偏表設(shè)計完了接下來是查詢。招聘系統(tǒng)里最復(fù)雜的查詢是職位列表 公司信息 收藏狀態(tài)的多表關(guān)聯(lián)。我見過有人直接寫一條大 SQLLEFT JOIN 三張表WHERE 條件里又帶分頁又帶子查詢結(jié)果查詢效率極低而且 MyBatis XML 里的 SQL 寫長了特別容易出錯。我的建議是能拆就拆。職位列表頁的核心查詢拆成兩步第一步按條件查職位表分頁返回職位基本信息第二步根據(jù)職位列表里的company_id批量查出企業(yè)信息然后用Map在內(nèi)存中做關(guān)聯(lián)。這一步看似多查了一次數(shù)據(jù)庫但對性能和代碼可讀性都有好處。實際開發(fā)中的次數(shù)并不重要課程設(shè)計這種并發(fā)量下多表 JOIN 帶來的維護成本遠大于性能損耗。另外如果你用 MyBatis-Plus我建議所有單表操作都用它自帶的BaseMapper方法多表關(guān)聯(lián)才寫自定義 XML。這樣你不用寫幾百行 XML代碼干凈答辯時也好講。4. 后端核心接口的編寫與踩坑從登錄鑒權(quán)到簡歷上傳數(shù)據(jù)庫設(shè)計好了接下來的硬骨頭在后端。這里我重點講三個模塊登錄鑒權(quán)、職位搜索、文件上傳。這三個模塊是招聘系統(tǒng)里最容易出問題、也最體現(xiàn)水平的地方。4.1 Spring Security 集成 JWT用新版寫法避開過時 API我用的是 SpringBoot 2.7 以上版本Security 的配置類直接注入SecurityFilterChainBean。Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests(auth - auth .antMatchers(/api/auth/login, /api/auth/register, /api/job/search, /api/news/list).permitAll() .antMatchers(/api/student/**).hasRole(STUDENT) .antMatchers(/api/company/**).hasRole(COMPANY) .antMatchers(/api/admin/**).hasRole(ADMIN) .anyRequest().authenticated() ) .exceptionHandling().authenticationEntryPoint(restAuthenticationEntryPoint()) .and() .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); return http.build(); } }這里有幾個關(guān)鍵點一定要講清楚。第一permitAll()的接口是公開接口比如登錄、注冊、搜索職位但職位詳情接口要不要公開我建議公開。因為用戶在未登錄狀態(tài)下瀏覽招聘網(wǎng)站是很正常的行為你要是在這個接口上加了認證限制前端寫起來會非常難受每次刷新頁面都要重新登錄才能看職位詳情。搜職位和看職位詳情應(yīng)該允許游客訪問只有在投遞和收藏時才強制要求登錄。第二JWT 過濾器里你解析 Token 拿到的userId怎么轉(zhuǎn)成 Spring Security 能認識的Authentication對象代碼大致是String username jwtTokenUtil.getUsernameFromToken(token); UserDetails userDetails userDetailsService.loadUserByUsername(username); UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities()); SecurityContextHolder.getContext().setAuthentication(authentication);拿到認證對象后在 Controller 里用AuthenticationPrincipal UserDetails userDetails就能直接拿當(dāng)前登錄用戶信息很方便。第三登錄接口返回的數(shù)據(jù)結(jié)構(gòu)。返回的 Token 不應(yīng)該只是裸字符串建議封裝成對象包含token、tokenType固定是 Bearer、expiresIn過期時間秒、role。前端拿到后存起來路由守衛(wèi)里判斷有沒有 Token 和角色匹不匹配。另外登錄接口里密碼校驗要用PasswordEncoder.matches(rawPassword, encodedPassword)千萬不能把數(shù)據(jù)庫里的密文拿來明文比對。4.2 職位搜索接口關(guān)鍵詞匹配和條件篩選的取舍職位搜索是前端首頁最核心的交互學(xué)生進來以后第一件事就是搜索。我建議搜索接口的參數(shù)設(shè)計為keyword職位名稱模糊搜索也可以匹配公司名稱、city城市、categoryId職位分類、salaryMin薪資下限篩選、educationRequirement學(xué)歷要求、page和size分頁參數(shù)。在寫 SQL 時關(guān)鍵詞搜索的邏輯用WHERE job_name LIKE CONCAT(%, #{keyword}, %)來實現(xiàn)同時如果你想搜公司名可以再OR company_name LIKE ...不過這會引入多表查詢。我的做法是職位表冗余一個company_name字段在企業(yè)修改公司信息時同步更新職位表里的冗余字段。雖然存在數(shù)據(jù)冗余但招聘系統(tǒng)職位量級不大同步更新一次成本很低換來的是搜索接口的單表查詢性能和簡潔度。另外搜索接口一定要做分頁。MyBatis-Plus 的分頁插件用法很簡單PageJob page new Page(pageNum, pageSize); LambdaQueryWrapperJob queryWrapper new LambdaQueryWrapper(); queryWrapper.eq(Job::getStatus, 0) .like(StringUtils.isNotBlank(keyword), Job::getJobName, keyword) .eq(StringUtils.isNotBlank(city), Job::getCity, city) .eq(categoryId ! null, Job::getCategoryId, categoryId) .ge(salaryMin ! null, Job::getSalaryMax, salaryMin) .orderByDesc(Job::getCreateTime); IPageJob result jobMapper.selectPage(page, queryWrapper);用LambdaQueryWrapper的好處是類型安全寫錯了編譯期就報錯不會像字符串column一樣跑到數(shù)據(jù)庫層才報unknown column。4.3 簡歷附件上傳本地存儲還是對象存儲的取舍最后說文件上傳。招聘系統(tǒng)里學(xué)生可能上傳一個 PDF 版的簡歷附件企業(yè)上傳 Logo 圖片。很多學(xué)生的習(xí)慣是把圖片轉(zhuǎn)成 Base64 塞數(shù)據(jù)庫這種做法我強烈不推薦數(shù)據(jù)庫會膨脹飛快而且查詢時把一個幾十 KB 的 Base64 字符串讀出來性能極差。正確做法是把文件存到服務(wù)器磁盤數(shù)據(jù)庫里只存一個訪問路徑。本地存儲流程是前端用el-upload組件選擇文件FormData 對象里 append 文件字段用 Axios POST 到后端接口后端接收MultipartFile用 UUID 重新生成文件名防止中文名亂碼和重名覆蓋然后按日期建目錄比如上傳的文件放在/upload/20240515/uuid.pdf把文件寫到磁盤上再把拼接好的 URL 路徑存到數(shù)據(jù)庫。需要注意兩個問題。第一個是靜態(tài)資源映射。SpringBoot 默認不直接暴露磁盤路徑你需要寫一個配置類或配置文件把本機磁盤目錄映射成 URL 訪問路徑。配置文件里的寫法是spring: web: resources: static-locations: file:D:/upload/這樣http://localhost:8080/files/uuid.pdf就能直接訪問到D:/upload/uuid.pdf這個文件注意配置里的路徑要和存儲路徑對應(yīng)上。第二個是上線后文件路徑會變你把項目部署到 Linux 服務(wù)器上絕對路徑就得變成/usr/local/upload/。我的做法是寫一個自定義配置項custom.upload-path在application.yml里配置不同環(huán)境切換只改配置不改代碼。文件類型和大小校驗也別忘了企業(yè)上傳 Logo 只允許 jpg/png簡歷附件只允許 pdf/docx大小限制在 5MB 以內(nèi)。用RequestParam(file) MultipartFile file接收后先校驗file.isEmpty()和file.getContentType()不合法直接拋業(yè)務(wù)異常。SpringBoot 默認上傳限制在 1MB 左右一定要在配置里調(diào)大不然前端選了個 3MB 的簡歷一傳就報錯還看不到明確的錯誤原因排查起來很頭疼。5. 前端 Vue 部分的關(guān)鍵實戰(zhàn)路由守衛(wèi)、狀態(tài)管理、組件復(fù)用后端接口寫完前端是另一個大塊。Vue 項目我建議用 Vue 2 還是 Vue 3如果你現(xiàn)在才開題直接 Vue 3 Vite Element Plus 是主流方向網(wǎng)上資料也足夠多。如果你的課程要求在 Vue 2 基礎(chǔ)上做也別慌這兩個版本的核心路由和狀態(tài)管理思路大差不差教材里那些Vue.use(Vuex)的寫法在 Vue 3 里換成createStore就行。5.1 路由設(shè)計一個路由文件搞定全部頁面招聘系統(tǒng)的前端頁面大致分幾類門戶頁面首頁、職位詳情、企業(yè)列表、資訊列表、學(xué)生中心個人中心布局內(nèi)含我的簡歷、我的投遞、我的收藏、面試通知、企業(yè)中心企業(yè)信息維護、職位發(fā)布、收到的簡歷、面試管理、管理后臺用戶管理、企業(yè)審核、職位審核、內(nèi)容管理、通用頁面登錄、注冊、404。我建議采用嵌套路由。門戶頁單獨一個 Layout 組件頂欄是 Logo 和導(dǎo)航菜單中間是router-view出口學(xué)生中心和企業(yè)中心也各做一套 Layout左側(cè)側(cè)邊欄菜單右側(cè)內(nèi)容區(qū)。這樣三個角色各自進到自己的專屬界面體驗上清清楚楚也方便在路由層面做權(quán)限控制。路由守衛(wèi)的核心邏輯是進入路由前檢查localStorage.getItem(token)是否存在。如果目標(biāo)路由需要登錄且沒有 Token跳轉(zhuǎn)登錄頁并帶上redirect參數(shù)如果已經(jīng)登錄且是登錄頁跳回首頁。對于角色控制可以在路由的meta字段里標(biāo)上roles: [STUDENT]然后守衛(wèi)里取當(dāng)前用戶角色做比對不匹配就跳轉(zhuǎn) 403 頁面。router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }); } else if (token to.path /login) { next(/); } else if (to.meta.roles) { const userInfo JSON.parse(localStorage.getItem(userInfo) || {}); if (!to.meta.roles.includes(userInfo.role)) { next(/403); } else { next(); } } else { next(); } });5.2 Axios 攔截器與狀態(tài)管理的配合前端接口請求統(tǒng)一用 Axios 封裝。核心做法是創(chuàng)建request.js設(shè)置baseURL然后在請求攔截器里把 Token 塞到請求頭。service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; });響應(yīng)攔截器有兩個作用第一個是統(tǒng)一處理業(yè)務(wù)錯誤碼。比如后端返回{ code: 401, message: 登錄已過期 }前端在攔截器里return Promise.reject(error)的同時跳轉(zhuǎn)到登錄頁并清掉本地 Token第二個是處理后端返回的code。我建議你的后端統(tǒng)一返回結(jié)構(gòu)為{ code: 200, message: success, data: {...} }前端攔截器判斷code 200時直接返回response.data.data這樣調(diào)用接口的方法里不用每次都從res.data.data里取數(shù)據(jù)。狀態(tài)管理我建議用 PiniaVue 3或 VuexVue 2核心只存兩個內(nèi)容token和userInfo。userInfo在登錄成功后從后端拿里面有id、username、role、avatar等字段存到localStorage里頁面刷新后還能拿到。不要每次刷新頁面都重新調(diào)一次getUserInfo接口后臺管理系統(tǒng)這么做沒問題但門戶網(wǎng)站刷新頻繁白白浪費時間。但是注意用戶信息有變動時比如改了頭像、企業(yè)資料審核通過要同步更新userInfo和localStorage兩個位置都改掉才不會出現(xiàn)頁面顯示和實際不一致的問題。5.3 核心頁面的組件拆分讓一個頁面代碼不超過 300 行學(xué)生端投遞記錄頁面、企業(yè)端收到的簡歷列表頁面是組件復(fù)用最能體現(xiàn)效果的地方。以投遞記錄為例學(xué)生端和企業(yè)端看到的其實是同一張投遞記錄表的不同視角學(xué)生端看的是我投了哪些職位、狀態(tài)如何企業(yè)端看的是誰投了我們公司的職位、我要怎么處理。兩個頁面共用一個DeliveryRecord展示組件只是傳進去的查詢參數(shù)不同、操作按鈕不同。把狀態(tài)標(biāo)簽封裝成StatusTag組件把分頁條封裝成通用分頁組件把空數(shù)據(jù)提示封裝成EmptyPlaceholder這些小組件在項目里能反復(fù)用。組件拆分的原則是一個組件只干一件事。如果發(fā)現(xiàn)一個文件里又調(diào)接口又渲染表格又彈窗又處理邏輯代碼超過 300 行就拆。不要為了炫技搞什么高階組件、插槽嵌套八層畢設(shè)項目代碼清晰比什么都重要答辯時老師看你的代碼結(jié)構(gòu)清爽印象分直接拉高。6. 部署上線與畢設(shè)答辯準(zhǔn)備的四個實用建議最后一個部分是很多學(xué)生忽略、但真正拉開差距的地方。做完系統(tǒng)不是終點能跑在公網(wǎng)上讓人看到、能在答辯時把項目講清楚才算真正完成。6.1 本地 IDEA 跑通項目的完整順序先從后端開始。把項目導(dǎo)入 IDEA確認 Maven 依賴都下載完成。然后本地裝一個 MySQL 5.7 或 8.0新建數(shù)據(jù)庫導(dǎo)入sql腳本。改application.yml里的數(shù)據(jù)庫地址、賬號、密碼把 Redis 相關(guān)配置干掉如果你沒用 Redis 的話。啟動類跑起來控制臺出現(xiàn) Spring Boot 啟動成功的日志后先用 Postman 調(diào)一下登錄接口確認能正常返回 Token再繼續(xù)測下面的接口。前端這邊npm install裝依賴。有時候會出現(xiàn) node-sass 安裝失敗的問題這是因為 node-sass 需要從 GitHub 下載二進制文件國內(nèi)網(wǎng)絡(luò)環(huán)境容易失敗。解決方案有兩種一是用 sass 替換 node-sass安裝命令是npm install sass -D二是配一下鏡像源npm config set registry https://registry.npmmirror.com大概率能解決。裝完依賴后npm run serve啟動瀏覽器打開本地地址如果接口通、頁面能渲染、登錄注冊能走通那就說明整個鏈路 OK 了。這里提醒一個非常常見的啟動失敗原因后端端口占用。SpringBoot 默認端口 8080如果你本地裝了 Nginx 或者其他項目占用了這個端口啟動會報Port already in use。改端口別硬改成 8081 就完事前端 Axios 里的baseURL也得同步改兩個地方改了才能通。6.2 打包部署到云服務(wù)器前后端分離項目的標(biāo)準(zhǔn)姿勢如果你想把項目部署到公網(wǎng)需要一臺云服務(wù)器。后端打成 jar 包前端npm run build生成 dist 靜態(tài)文件。部署方式推薦用 Nginx 做反向代理Nginx 托管前端靜態(tài)文件同時把/api開頭的請求反向代理到后端端口。Nginx 配置的關(guān)鍵部分是 location 塊server { listen 80; server_name your-domain.com; root /usr/local/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }注意proxy_pass后面的 URL 末尾加不加斜杠是有講究的proxy_pass http://127.0.0.1:8080;不加則/api/login會原樣轉(zhuǎn)發(fā)給后端如果加成了http://127.0.0.1:8080/;會把/api前綴吃掉變成/login這是新手最容易踩的坑沒有之一。后端的 jar 包啟動用nohup java -jar app.jar app.log 21 日志輸出到文件方便排查。部署完成后用curl http://127.0.0.1:8080/api/auth/login先自測一下通了再通過域名訪問前端頁面逐步排查不要一上來就打開瀏覽器然后一臉懵。6.3 答辯前要能講清楚的三件事第一個是項目架構(gòu)圖。不要求你用專業(yè)繪圖工具畫得多精美但一定要能準(zhǔn)確描述用戶通過瀏覽器訪問 Vue 前端前端通過 HTTP 請求調(diào)用 SpringBoot 后端接口后端通過 MyBatis 操作 MySQL 數(shù)據(jù)庫文件走本地磁盤存儲整個系統(tǒng)的認證由 JWT Spring Security 完成。這三層前端、后端、數(shù)據(jù)庫的調(diào)用關(guān)系是答辯必問的。第二個是核心業(yè)務(wù)邏輯。投遞簡歷的完整流程、面試通知怎么從企業(yè)端發(fā)到學(xué)生端、職位審核的流轉(zhuǎn)邏輯這三條鏈路你要能一口氣講清楚講的時候結(jié)合狀態(tài)字段提醒自己這個操作會改哪些表、更新哪些狀態(tài)。把這條線串起來講老師基本就能確認這個項目是你自己寫的。第三個是你自己做的功能亮點。比如我給項目加了職位瀏覽量統(tǒng)計用一個view_count字段記錄每次點擊職位詳情時的請求數(shù)給企業(yè)端加了崗位數(shù)據(jù)統(tǒng)計圖用 ECharts 展示一個月內(nèi)收到的簡歷趨勢。這些小功能不復(fù)雜但是能體現(xiàn)你考慮業(yè)務(wù)的完整度比干巴巴的 CRUD 強很多。6.4 學(xué)習(xí)這個項目的正確姿勢別變成純抄源碼我知道很多同學(xué)拿到項目源碼的第一個習(xí)慣是直接打開后端啟動類點運行看頁面然后就沒然后了。這種學(xué)法是學(xué)不到東西的答辯也過不了關(guān)。正確姿勢是這樣第一遍打開數(shù)據(jù)庫腳本把每張表看一遍搞懂字段含義第二遍打開項目結(jié)構(gòu)把 Controller、Service、Mapper 三層對應(yīng)關(guān)系捋順第三遍挑一個核心接口比如投遞簡歷從 Controller 入口一路追到 Mapper SQL把整個鏈路讀出來在紙上畫一下這個接口改了哪些表第四遍自己動手改一個小功能比如給職位搜索加一個薪資區(qū)間篩選或者給企業(yè)端加一個一鍵導(dǎo)出面邀名單的 Excel 功能。等你親手改動過一個模塊再講這個項目時就和純背代碼完全不一樣了。說到底SpringBoot Vue 這個技術(shù)組合本身沒有門檻真正拉開差距的是你對業(yè)務(wù)的理解深度和代碼的工程整潔度。招聘系統(tǒng)作為畢設(shè)題材業(yè)務(wù)模型完整、擴展空間大、答辯素材豐富認真做下來你學(xué)到的不僅是一套代碼而是一整套從需求到部署的思維方法。這套方法才是畢業(yè)設(shè)計真正應(yīng)該帶走的東西。