簡(jiǎn)介面向計(jì)算機(jī)專業(yè)畢業(yè)生與Java進(jìn)階學(xué)習(xí)者基于Spring BootVue.jsElementUI構(gòu)建的人力資源管理系統(tǒng)完整源碼定位于畢業(yè)設(shè)計(jì)、課程設(shè)計(jì)與期末大作業(yè)場(chǎng)景。項(xiàng)目覆蓋員工信息管理、部門維護(hù)、權(quán)限控制等典型HR業(yè)務(wù)模塊前后端分離架構(gòu)便于理解企業(yè)級(jí)開(kāi)發(fā)流程。壓縮包共178個(gè)文件總大小約3.49MB包含96個(gè)Java后端類、22個(gè)Vue組件、26個(gè)JS腳本以及SQL數(shù)據(jù)庫(kù)腳本、PDF/MD項(xiàng)目說(shuō)明文檔和多種配置文件源碼與文檔分層存放。資源為高分通過(guò)版本并經(jīng)教師指導(dǎo)已有805人學(xué)習(xí)或下載。借助內(nèi)附的項(xiàng)目說(shuō)明與數(shù)據(jù)庫(kù)初始化腳本可快速搭建運(yùn)行環(huán)境對(duì)照前后端代碼理清Spring Boot接口設(shè)計(jì)與Vue頁(yè)面交互邏輯為獨(dú)立完成同類系統(tǒng)提供完整參考。1. 拿到 Spring Boot Vue ElementUI 的人力資源系統(tǒng)包先摸清邊界再談復(fù)用如果你所在的小團(tuán)隊(duì)正準(zhǔn)備從零搭一套內(nèi)部人力資源系統(tǒng)或者你正在找一份能快速改造成畢業(yè)設(shè)計(jì)的基線代碼那么基于 Spring Boot Vue ElementUI 這套技術(shù)棧的資源包是值得認(rèn)真拆一遍的。我花了兩晚完整復(fù)現(xiàn)了這份含源碼、項(xiàng)目說(shuō)明、數(shù)據(jù)庫(kù)腳本和部署文檔的包最大感受是它解決的不只是有沒(méi)有代碼的問(wèn)題而是代碼能不能在本機(jī)跑起來(lái)、能不能接著改出第二個(gè)業(yè)務(wù)模塊的問(wèn)題。適合拿來(lái)當(dāng)管理系統(tǒng)骨架的參考也適合做畢設(shè)底子但前提是先搞清楚模塊邊界和表關(guān)系——這正是這篇文章要帶你做的事。2. 架構(gòu)與數(shù)據(jù)模型復(fù)現(xiàn)前先把模塊邊界和表關(guān)系理清2.1 后端、前端、SQL 三個(gè)目錄的職責(zé)邊界解壓這份壓縮包之后典型的結(jié)構(gòu)是這樣的hrms/ ├── backend/ # Spring Boot 后端工程 │ ├── src/main/java/ # 控制層、服務(wù)層、Mapper 層 │ ├── src/main/resources/ # application.yml、Mapper XML │ └── pom.xml ├── frontend/ # Vue 2 ElementUI 前端工程 │ ├── src/router/ # 路由與路由守衛(wèi) │ ├── src/views/ # 頁(yè)面組件 │ ├── src/api/ # 接口請(qǐng)求封裝 │ └── package.json ├── sql/ # 數(shù)據(jù)庫(kù)初始化腳本 ├── 項(xiàng)目說(shuō)明.md └── 部署文檔.md先把目錄邊界說(shuō)清楚后端只暴露 REST 接口前端只負(fù)責(zé)頁(yè)面渲染和請(qǐng)求分發(fā)數(shù)據(jù)庫(kù)腳本單獨(dú)放一份不依賴任何 ORM 自動(dòng)建表。這種劃分的好處是你可以單獨(dú)替換任何一層——比如后端從 MySQL 換成 PostgreSQL只要 SQL 腳本重寫一遍接口和前端完全不動(dòng)。這個(gè)系統(tǒng)在業(yè)務(wù)上覆蓋了幾個(gè)典型的人力資源模塊系統(tǒng)管理用戶/角色/菜單、組織架構(gòu)部門樹(shù)、員工檔案入職信息、考勤記錄、薪資記錄。需要提醒的是它不一定包含招聘和績(jī)效模塊如果你要拿它做完整商業(yè)系統(tǒng)得在擴(kuò)展章節(jié)里自己補(bǔ)業(yè)務(wù)。2.2 員工、部門、薪資表之間的外鍵約束與索引設(shè)計(jì)很多人拿到 SQL 腳本直接執(zhí)行從沒(méi)看過(guò)表結(jié)構(gòu)等到聯(lián)調(diào)階段發(fā)現(xiàn)數(shù)據(jù)對(duì)不上才回來(lái)補(bǔ)課。我先帶你過(guò)一遍最核心的四張表的關(guān)系表名作用外鍵依賴備注hr_dept部門表parent_id 自關(guān)聯(lián)組織樹(shù)結(jié)構(gòu)hr_employee員工檔案表dept_id 指向 hr_dept員工核心信息sys_user系統(tǒng)登錄賬號(hào)無(wú)與 hr_employee 一一對(duì)應(yīng)hr_salary薪資記錄表emp_id 指向 hr_employee按月記錄其中 hr_employee 的表結(jié)構(gòu)類似這樣CREATE TABLE hr_employee ( emp_id BIGINT NOT NULL AUTO_INCREMENT COMMENT 員工主鍵, emp_no VARCHAR(32) NOT NULL COMMENT 工號(hào), name VARCHAR(64) NOT NULL COMMENT 姓名, gender TINYINT DEFAULT 1 COMMENT 1男 2女, id_card VARCHAR(18) DEFAULT NULL COMMENT 身份證號(hào), phone VARCHAR(20) DEFAULT NULL COMMENT 手機(jī)號(hào), email VARCHAR(128) DEFAULT NULL COMMENT 郵箱, dept_id BIGINT DEFAULT NULL COMMENT 所屬部門, position VARCHAR(64) DEFAULT NULL COMMENT 崗位, hire_date DATE DEFAULT NULL COMMENT 入職日期, status TINYINT DEFAULT 1 COMMENT 1在職 2離職 3停薪留職, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (emp_id), UNIQUE KEY uk_emp_no (emp_no), KEY idx_dept (dept_id), CONSTRAINT fk_emp_dept FOREIGN KEY (dept_id) REFERENCES hr_dept (dept_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT員工檔案表;這里有三點(diǎn)值得注意。第一工號(hào) emp_no 上加了唯一索引這是防止重復(fù)錄入員工的第一道防線比在 Service 層做判斷更可靠。第二dept_id 外鍵指向部門表意味著刪除部門前必須先處理該部門下的員工否則會(huì)報(bào)外鍵約束錯(cuò)誤——很多初學(xué)者在這上面翻車。第三身份證號(hào) id_card 沒(méi)有加唯一索引因?yàn)楝F(xiàn)實(shí)中存在少量歷史數(shù)據(jù)身份證號(hào)缺失或重復(fù)的情況如果加唯一索引會(huì)導(dǎo)致初始化數(shù)據(jù)失敗。2.3 一次員工列表請(qǐng)求的完整鏈路從前端按鈕到后端 SQL理清表關(guān)系之后我們要把一個(gè)請(qǐng)求從頭到尾走一遍否則后面調(diào)接口時(shí)一臉懵。假設(shè)你在前端頁(yè)面點(diǎn)了一個(gè)查詢所有在職員工按鈕前端在src/api/employee.js里調(diào)用封裝的 Axios 請(qǐng)求傳入{ page: 1, pageSize: 10, status: 1 }Axios 請(qǐng)求攔截器把本地存儲(chǔ)的Authorization: Bearer token加到 Header 里請(qǐng)求到達(dá)后端EmployeeController控制器先通過(guò)攔截器確認(rèn)登錄狀態(tài)控制器調(diào)用EmployeeService.listPage(query)內(nèi)部通過(guò) MyBatis 的動(dòng)態(tài) SQL 拼接 where 條件查詢結(jié)果返回前端ElementUI 的 Table 組件渲染數(shù)據(jù)這套鏈路里最容易出問(wèn)題的是第 2 步和第 4 步。第 2 步如果 token 沒(méi)加到 Header后端會(huì)統(tǒng)一返回 401第 4 步如果動(dòng)態(tài) SQL 拼接時(shí)遺漏了 status 條件就會(huì)出現(xiàn)離職員工也出現(xiàn)在在職列表里這種數(shù)據(jù)污染問(wèn)題。后面兩章我會(huì)分別給出這兩處的具體代碼寫法。3. Spring Boot 后端落地鑒權(quán)、組織樹(shù)和員工查詢的寫法3.1 JWT 登錄鑒權(quán)密鑰、過(guò)期時(shí)間和攔截器參數(shù)設(shè)置后端代碼里第一個(gè)值得細(xì)讀的模塊是登錄鑒權(quán)。這里的常見(jiàn)做法是用 JWT 生成 token然后用一個(gè)攔截器過(guò)濾所有受保護(hù)接口。先看 token 生成工具類Component public class JwtUtil { // 實(shí)際項(xiàng)目中密鑰必須放到配置中心這里僅為本地演示 private static final String SECRET hrms-secret-key-demo-2024; // token 有效期24 小時(shí) private static final long EXPIRE_MS 24 * 60 * 60 * 1000L; public String createToken(Long userId, String username) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() EXPIRE_MS)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }這個(gè)工具類有四個(gè)關(guān)鍵點(diǎn)。setSubject(username)把用戶名放進(jìn) token 主體后續(xù)業(yè)務(wù)代碼可以直接獲取不用再查庫(kù)claim(userId, userId)存的是用戶主鍵用于關(guān)聯(lián)數(shù)據(jù)權(quán)限過(guò)期時(shí)間設(shè) 24 小時(shí)對(duì)內(nèi)部系統(tǒng)來(lái)說(shuō)夠用但如果要求更嚴(yán)格的安全策略建議縮短到 2~4 小時(shí)并增加 refresh token 機(jī)制SECRET寫死在代碼里是典型的壞味道部署時(shí)應(yīng)該改成讀取application.yml里的配置項(xiàng)。再看攔截器的寫法public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 登錄接口和靜態(tài)資源不攔截避免死循環(huán) if (request.getRequestURI().contains(/api/auth/login)) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登錄或token已過(guò)期\}); return false; } try { Claims claims jwtUtil.parseToken(token.substring(7)); request.setAttribute(userId, claims.get(userId)); request.setAttribute(username, claims.getSubject()); return true; } catch (Exception e) { response.setStatus(401); response.getWriter().write({\code\:401,\msg\:\token校驗(yàn)失敗\}); return false; } } }攔截器里我最常踩的坑是忘了放行登錄接口。一旦忘了前端拿著用戶名密碼去登錄請(qǐng)求又被攔截直接返回 401整個(gè)人會(huì)被繞暈。另一個(gè)細(xì)節(jié)是token.substring(7)因?yàn)?Header 里傳的是Bearer xxxxx去掉前綴才能拿到真正的 JWT 字符串截取位置必須和startsWith(Bearer )保持一致否則把 Bearer 這 7 個(gè)字符也算進(jìn) token解析必然失敗。3.2 部門組織樹(shù)遞歸查詢還是內(nèi)存聚合部門表用parent_id自關(guān)聯(lián)這是組織架構(gòu)的常見(jiàn)設(shè)計(jì)。但實(shí)現(xiàn)組織樹(shù)有兩種不同思路代碼寫起來(lái)差異很大。這個(gè)資源里用的是內(nèi)存聚合方式我把它簡(jiǎn)化一下public ListDeptVO listDeptTree() { // 一次性查出所有部門 ListDept allDepts deptMapper.selectAll(); // 按照 parentId 分組方便后續(xù)遞歸 MapLong, ListDept childrenMap allDepts.stream() .collect(Collectors.groupingBy(Dept::getParentId)); // 從根節(jié)點(diǎn)parentId0開(kāi)始組裝 return buildTree(0L, childrenMap); } private ListDeptVO buildTree(Long parentId, MapLong, ListDept childrenMap) { ListDept children childrenMap.getOrDefault(parentId, Collections.emptyList()); return children.stream().map(dept - { DeptVO vo new DeptVO(); vo.setDeptId(dept.getDeptId()); vo.setDeptName(dept.getDeptName()); vo.setChildren(buildTree(dept.getDeptId(), childrenMap)); return vo; }).collect(Collectors.toList()); }這里的關(guān)鍵設(shè)計(jì)是先一次查出全部部門再用groupingBy按parentId分組最后從根節(jié)點(diǎn)遞歸往下組裝。這樣只需要一條 SQL不會(huì)在數(shù)據(jù)庫(kù)里執(zhí)行 N 次遞歸查詢部門數(shù)幾百個(gè)時(shí)性能沒(méi)有問(wèn)題。需要注意的邊界條件是臟數(shù)據(jù)會(huì)死循環(huán)。如果某條記錄的parent_id指向了自己或者兩個(gè)部門互相指向?qū)Ψ竭f歸就沒(méi)有終止條件直接 StackOverflow。我一般在初始化 SQL 里要求parent_id不能等于dept_id同時(shí)在新增部門接口里校驗(yàn)父部門是否存在。還有一種方案是在數(shù)據(jù)庫(kù)里加level字段限制最大層級(jí)超過(guò)就拒絕插入但對(duì)大部分中小企業(yè)系統(tǒng)來(lái)說(shuō)做好插入校驗(yàn)就夠了。3.3 員工分頁(yè)查詢動(dòng)態(tài) SQL 的三個(gè)條件參數(shù)員工列表頁(yè)是整套系統(tǒng)里使用頻率最高的頁(yè)面它的核心是 MyBatis 里的動(dòng)態(tài)條件查詢。這個(gè)資源在EmployeeMapper.xml里把查詢條件做得很標(biāo)準(zhǔn)select idselectEmployeePage resultTypecom.demo.hrms.entity.Employee SELECT e.emp_id, e.emp_no, e.name, e.gender, e.phone, e.email, e.position, e.hire_date, e.status, d.dept_name AS deptName FROM hr_employee e LEFT JOIN hr_dept d ON e.dept_id d.dept_id where if testname ! null and name ! AND e.name LIKE CONCAT(%, #{name}, %) /if if testdeptId ! null AND e.dept_id #{deptId} /if if teststatus ! null AND e.status #{status} /if /where ORDER BY e.emp_no /select三個(gè)條件參數(shù)各自的用途name是模糊匹配注意用CONCAT(%, #{name}, %)而不是直接寫%#{name}%后者會(huì)被 MyBatis 當(dāng)成字符串處理查出來(lái)永遠(yuǎn)是空deptId是精確匹配用來(lái)做部門篩選當(dāng)前端傳了deptId0時(shí)要小心因?yàn)閐eptId ! null成立但等于 0可能會(huì)查出一批不該出現(xiàn)的數(shù)據(jù)status是狀態(tài)過(guò)濾在職、離職、停薪留職三個(gè)值之間切換。注意當(dāng)員工表數(shù)據(jù)量超過(guò)幾十萬(wàn)時(shí)LIKE %關(guān)鍵字%會(huì)走全表掃描。常見(jiàn)做法是限制必須同時(shí)傳入deptId或時(shí)間范圍否則提示用戶縮小查詢范圍而不是讓數(shù)據(jù)庫(kù)硬扛。這里還有一個(gè)性能細(xì)節(jié)分頁(yè)本身如果用PageHelper那就把pageNum和pageSize兩個(gè)參數(shù)單獨(dú)傳入不要在 SQL 里手動(dòng)寫LIMIT因?yàn)?PageHelper 會(huì)在 SQL 后面自動(dòng)拼LIMIT手寫反而可能導(dǎo)致分頁(yè)數(shù)據(jù)錯(cuò)亂。4. Vue ElementUI 前端落地路由守衛(wèi)、表格封裝和請(qǐng)求攔截4.1 路由守衛(wèi)與按鈕級(jí)權(quán)限的配合方式前端登錄流程的核心邏輯集中在路由守衛(wèi)里// src/router/index.js router.beforeEach((to, from, next) { const token localStorage.getItem(hrms_token) // 已登錄還去登錄頁(yè)直接回首頁(yè) if (token to.path /login) { next(/) return } if (!token) { // 記錄來(lái)源路徑登錄后跳回去 next(/login?redirect encodeURIComponent(to.fullPath)) return } // 路由 meta.perm 存的是后端菜單表里的權(quán)限標(biāo)識(shí) const requiredPerm to.meta.perm if (requiredPerm !store.state.permissions.includes(requiredPerm)) { // 沒(méi)有權(quán)限時(shí)提示但不跳 403避免暴露頁(yè)面結(jié)構(gòu) Message.error(當(dāng)前賬號(hào)無(wú)權(quán)訪問(wèn)該頁(yè)面) next(false) return } // 登錄后首次加載才拉取菜單和權(quán)限 if (!store.state.menuLoaded) { store.dispatch(loadMenuAndPermissions).then(() next()) return } next() })這個(gè)守衛(wèi)解決三個(gè)問(wèn)題未登錄訪問(wèn)受限頁(yè)面時(shí)自動(dòng)跳登錄頁(yè)已登錄卻訪問(wèn)登錄頁(yè)時(shí)強(qiáng)制回首頁(yè)無(wú)權(quán)限頁(yè)面直接攔截并提示。其中redirect參數(shù)是個(gè)容易被忽略的細(xì)節(jié)它讓登錄成功后還能回到你原本想去的頁(yè)面而不是每次都死在首頁(yè)。菜單的權(quán)限標(biāo)識(shí)不是前端寫死的而是登錄成功后從/api/user/menu接口拉取再由后端根據(jù)角色動(dòng)態(tài)返回sys_menu表里配置的按鈕權(quán)限字符串。前端只負(fù)責(zé)渲染收到的菜單和按鈕不負(fù)責(zé)判斷誰(shuí)能看到什么。如果某天你發(fā)現(xiàn)某個(gè)按鈕永遠(yuǎn)顯示不出來(lái)先查數(shù)據(jù)庫(kù)sys_menu表和角色關(guān)聯(lián)表大概率是初始化的權(quán)限數(shù)據(jù)沒(méi)配全。4.2 ElementUI 員工列表頁(yè)封裝表格、分頁(yè)和操作列員工列表頁(yè)面直接用的是 ElementUI 的el-table和el-pagination組合。這里直接看模板片段template div classemployee-page el-form inline el-form-item label姓名 el-input v-modelquery.name placeholder請(qǐng)輸入姓名 clearable / /el-form-item el-form-item label部門 el-tree-select v-modelquery.deptId :datadeptTree check-strictly clearable placeholder請(qǐng)選擇部門 / /el-form-item el-form-item el-button typeprimary clickhandleSearch查詢/el-button el-button clickhandleReset重置/el-button /el-form-item /el-form el-table :datatableData v-loadingloading border el-table-column propempNo label工號(hào) width120 / el-table-column propname label姓名 width120 / el-table-column propdeptName label部門 / el-table-column propphone label手機(jī)號(hào) width140 / el-table-column propstatus label狀態(tài) width100 template #default{ row } el-tag :typerow.status 1 ? success : info {{ row.status 1 ? 在職 : 離職 }} /el-tag /template /el-table-column el-table-column label操作 width180 fixedright template #default{ row } el-button sizemini clickhandleEdit(row)編輯/el-button el-button sizemini typedanger clickhandleDelete(row)刪除/el-button /template /el-table-column /el-table el-pagination background layouttotal, prev, pager, next, sizes :totaltotal :page-sizes[10, 20, 50] v-model:current-pagequery.page v-model:page-sizequery.pageSize size-changefetchList current-changefetchList / /div /template這里有兩個(gè)容易寫錯(cuò)的點(diǎn)。第一個(gè)是el-tree-select必須加check-strictly否則 ElementUI 默認(rèn)會(huì)級(jí)聯(lián)選擇父節(jié)點(diǎn)你選了子部門結(jié)果自動(dòng)帶出所有上級(jí)部門查出來(lái)的數(shù)據(jù)范圍完全不對(duì)。第二個(gè)是分頁(yè)參數(shù)雙向綁定的寫法v-model:current-page是 Vue 3 的寫法如果你用的是 Vue 2 搭配 ElementUI這里要寫成:current-page.sync版本差異會(huì)導(dǎo)致分頁(yè)完全不動(dòng)。4.3 Axios 攔截器統(tǒng)一處理 401 和業(yè)務(wù)錯(cuò)誤提示這套系統(tǒng)的前后端接口約定是一切正常返回{ code: 200, data: ... }業(yè)務(wù)異常返回{ code: 400, msg: xxx }未認(rèn)證返回{ code: 401 }。為了讓每個(gè)頁(yè)面都不重復(fù)寫錯(cuò)誤提示請(qǐng)求層做了統(tǒng)一攔截// src/utils/request.js import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 15000 }) // 請(qǐng)求攔截把 token 塞進(jìn) Header service.interceptors.request.use(config { const token localStorage.getItem(hrms_token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 響應(yīng)攔截統(tǒng)一處理業(yè)務(wù)碼 service.interceptors.response.use(res { const { code, data, msg } res.data if (code 200) return data if (code 401) { // 登錄態(tài)過(guò)期清空本地存登錄后重新登錄 // 注意這里不能用 router.push(/login)因?yàn)?router 文件是循環(huán)引用的 localStorage.removeItem(hrms_token) localStorage.removeItem(hrms_permissions) window.location.href /login return Promise.reject(new Error(登錄已過(guò)期)) } Message.error(msg || 請(qǐng)求失敗) return Promise.reject(new Error(msg || 請(qǐng)求失敗)) }, err { Message.error(網(wǎng)絡(luò)異常請(qǐng)稍后重試) return Promise.reject(err) })這里最值得說(shuō)的是 401 處理。很多人在攔截器里直接router.push(/login)然后發(fā)現(xiàn)整個(gè)路由都崩了這是因?yàn)閞equest.js被router/index.js引用同時(shí)router/index.js又引用了request.js形成循環(huán)依賴。規(guī)避方式就是用window.location.href /login做整頁(yè)跳轉(zhuǎn)代價(jià)是頁(yè)面完全刷新、狀態(tài)全部清空但對(duì)登錄過(guò)期這種場(chǎng)景來(lái)說(shuō)反而是可接受的。5. 避坑指南初始化失敗、版本沖突和分頁(yè)錯(cuò)位的五處踩坑記錄5.1 MySQL 8 連接報(bào)錯(cuò) Public Key Retrieval is not allowed現(xiàn)象后端服務(wù)啟動(dòng)時(shí)報(bào)java.sql.SQLException: Public Key Retrieval is not allowed數(shù)據(jù)庫(kù)連接失敗。原因MySQL 8 的默認(rèn)認(rèn)證插件是caching_sha2_password客戶端第一次連接時(shí)需要向服務(wù)器請(qǐng)求公鑰而 JDBC 驅(qū)動(dòng)默認(rèn)不允許自動(dòng)獲取公鑰。解決在application.yml的數(shù)據(jù)庫(kù)連接 URL 末尾加上allowPublicKeyRetrievaltrue同時(shí)配上useSSLfalse兩個(gè)參數(shù)缺一不可。配置如下spring: datasource: url: jdbc:mysql://localhost:3306/hrms?useUnicodetruecharacterEncodingutf8useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai username: root password: 你的密碼額外提醒serverTimezoneAsia/Shanghai也不能省。如果不加插入時(shí)間字段時(shí)會(huì)因?yàn)闀r(shí)區(qū)不一致出現(xiàn) 8 小時(shí)偏差表現(xiàn)是前端顯示時(shí)間和數(shù)據(jù)庫(kù)存儲(chǔ)時(shí)間差了半天。5.2 前端請(qǐng)求跨域?qū)е碌卿洺晒Φ珮I(yè)務(wù)接口全 401現(xiàn)象通過(guò)npm run dev啟動(dòng)前端后登錄接口通了但列表接口全部返回 401 或 CORS 錯(cuò)誤。原因前端開(kāi)發(fā)服務(wù)器默認(rèn)跑在http://localhost:3000后端跑在8080屬于跨域請(qǐng)求。后端如果開(kāi)啟 CORS 配置但允許的來(lái)源寫死為localhost:8080前端照樣被攔截。解決最穩(wěn)妥的跨域方案不是在后端寫CrossOrigin而是在前端開(kāi)發(fā)環(huán)境用代理轉(zhuǎn)發(fā)。在vue.config.js里配置module.exports { devServer: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }這樣前端請(qǐng)求/api/xxx時(shí)devServer 會(huì)把請(qǐng)求轉(zhuǎn)發(fā)給8080端口瀏覽器看所有請(qǐng)求都是同源的不會(huì)觸發(fā) CORS。生產(chǎn)環(huán)境則由 Nginx 做同樣的反向代理前端代碼里不需要寫完整的后端地址。5.3 Node 17 以上版本啟動(dòng)前端報(bào) OpenSSL 錯(cuò)誤現(xiàn)象執(zhí)行npm run dev時(shí)報(bào)error:0308010C:digital envelope routines::unsupported前端服務(wù)起不來(lái)。原因Vue 2 搭配 Webpack 4 的項(xiàng)目依賴舊版 OpenSSL 的加密算法Node 17 及以上版本默認(rèn)啟用了更強(qiáng)的哈希算法導(dǎo)致 Webpack 4 構(gòu)建失敗。這是版本代差造成的不是代碼問(wèn)題。解決在package.json的啟動(dòng)腳本里加一行環(huán)境變量{ scripts: { dev: NODE_OPTIONS--openssl-legacy-provider vue-cli-service serve } }Windows 環(huán)境下語(yǔ)法略有不同用cross-env NODE_OPTIONS--openssl-legacy-provider vue-cli-service serve需要先安裝cross-env依賴。如果項(xiàng)目里用的是 Webpack 5就不存在這個(gè)問(wèn)題但 Vue 2 天然傾向于 Webpack 4所以這是要斟酌的內(nèi)容。5.4 初始化 SQL 執(zhí)行后中文全部變成問(wèn)號(hào)現(xiàn)象執(zhí)行完sql/hrms.sql腳本后打開(kāi)數(shù)據(jù)庫(kù)看到部門表、員工表里的中文全部是???。原因大概率是 MySQL 客戶端連接時(shí)字符集設(shè)置不對(duì)SQL 腳本里的建表語(yǔ)句雖然寫了DEFAULT CHARSETutf8mb4但創(chuàng)建數(shù)據(jù)庫(kù)本身用的是utf8或者終端工具以latin1編碼執(zhí)行了腳本。解決創(chuàng)建數(shù)據(jù)庫(kù)時(shí)顯式指定字符集CREATE DATABASE hrms DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;如果已經(jīng)建過(guò)庫(kù)直接執(zhí)行ALTER DATABASE hrms CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;并把現(xiàn)有表的字符集也改一遍ALTER TABLE hr_employee CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;今后再遇到亂碼優(yōu)先檢查三個(gè)位置連接字符串的characterEncoding、數(shù)據(jù)庫(kù)默認(rèn)字符集、終端客戶端的連接編碼順序排查命中率極高。5.5 分頁(yè)接口第二頁(yè)和第一頁(yè)數(shù)據(jù)重復(fù)現(xiàn)象前端列表頁(yè)翻到第二頁(yè)時(shí)顯示的數(shù)據(jù)跟第一頁(yè)重復(fù)或者往下翻三五頁(yè)后出現(xiàn)缺失。原因分頁(yè)查詢 SQL 里沒(méi)有任何排序規(guī)則或者排序字段存在重復(fù)值。MySQL 在不顯式排序時(shí)返回順序是不保證穩(wěn)定的同一條 SQL 執(zhí)行兩次可能返回不同的順序。當(dāng)ORDER BY emp_id這個(gè)唯一字段沒(méi)寫進(jìn)分頁(yè) SQL 時(shí)LIMIT的偏移量切割出來(lái)的數(shù)據(jù)就不穩(wěn)定。解決分頁(yè)查詢的 SQL 必須帶穩(wěn)定排序字段最好用主鍵ORDER BY e.emp_id如果業(yè)務(wù)上要求按入職日期排序則必須加上第二排序條件ORDER BY e.hire_date DESC, e.emp_id ASC原因很簡(jiǎn)單hire_date可能有多個(gè)人同日入職單靠這一個(gè)字段排序翻頁(yè)時(shí)位置就會(huì)漂移。加上主鍵就能完全釘住順序這也是后端分頁(yè)場(chǎng)景里的通用法則。6. 進(jìn)階技巧十分鐘驗(yàn)證整套環(huán)境以及新增離職管理模塊的擴(kuò)展順序6.1 一鍵健康檢查后端接口自檢腳本拿到源碼后不要急著看業(yè)務(wù)代碼先跑一個(gè)最小驗(yàn)證腳本確認(rèn)環(huán)境是通的再?zèng)Q定從哪個(gè)模塊開(kāi)始讀#!/bin/bash # 快速驗(yàn)證后端服務(wù)是否正常 BASE_URLhttp://localhost:8080 # 第一步登錄拿到 token TOKEN$(curl -s -X POST $BASE_URL/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123} \ | python3 -c import sys,json; datajson.load(sys.stdin); print(data.get(data,{}).get(token,))) if [ -z $TOKEN ]; then echo 登錄失敗檢查數(shù)據(jù)庫(kù)初始化和后端日志 exit 1 fi echo 登錄成功token 提取完成 # 第二步帶 token 請(qǐng)求員工列表驗(yàn)證權(quán)限鏈路 curl -s $BASE_URL/api/employee/list?page1pageSize10 \ -H Authorization: Bearer $TOKEN | python3 -m json.tool | head -30這個(gè)腳本驗(yàn)證了兩層連通性POST 登錄接口能通說(shuō)明數(shù)據(jù)庫(kù)、MyBatis、Controller 三層的鏈路基本是完好的帶 token 請(qǐng)求列表接口能通說(shuō)明攔截器和權(quán)限機(jī)制生效。如果登錄通了但列表 401問(wèn)題基本集中在 token 解析或攔截器上。6.2 加一個(gè)離職管理模塊的擴(kuò)展順序假設(shè)你要在這個(gè)系統(tǒng)上擴(kuò)展一個(gè)離職管理模塊不需要大動(dòng)干戈按這套順序改即可步驟操作內(nèi)容涉及文件關(guān)鍵注意點(diǎn)1建表hr_resign并初始化菜單數(shù)據(jù)sql/hrms.sql菜單表里的按鈕權(quán)限標(biāo)識(shí)要預(yù)留出來(lái)2后端新增ResignController、ResignService、ResignMapperbackend/src/main/java復(fù)用現(xiàn)有的分頁(yè)查詢模式3前端新增views/resign/index.vuefrontend/src/views復(fù)制 employee 列表頁(yè)再改字段名4在路由表里注冊(cè)新頁(yè)面frontend/src/router頁(yè)面路徑要和菜單權(quán)限標(biāo)識(shí)保持一致5給指定角色分配離職管理菜單和按鈕sys_role_menu表不分配就不顯示這是權(quán)限設(shè)計(jì)帶來(lái)的硬約束我做完了這套流程后最大的教訓(xùn)是新增業(yè)務(wù)模塊時(shí)菜單權(quán)限數(shù)據(jù)比代碼本身更容易出問(wèn)題。代碼寫錯(cuò)了會(huì)直接報(bào)錯(cuò)好查但菜單沒(méi)配好前端頁(yè)面不顯示后端接口卻通著你只能一頭霧水地去核對(duì)角色表和菜單表。從那以后我每次打開(kāi)這類人力資源系統(tǒng)都先花三十分鐘把 SQL 腳本跑完、接口自檢一遍再動(dòng)手讀業(yè)務(wù)代碼。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取