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