簡介面向高校畢業(yè)設(shè)計(jì)、課程實(shí)踐或崗位實(shí)訓(xùn)的宿舍報(bào)修管理系統(tǒng)項(xiàng)目資料適合需要完成同類課題的計(jì)算機(jī)專業(yè)學(xué)生與開發(fā)者參考。系統(tǒng)采用Java語言與SpringBoot框架構(gòu)建后端搭配Vue前端與MySQL數(shù)據(jù)庫涵蓋用戶管理、維修員管理、宿舍信息管理、配件設(shè)備管理、報(bào)修接單、配件申請和維修進(jìn)度跟蹤等完整業(yè)務(wù)模塊能夠支撐校園宿舍后勤報(bào)修的日常流程。資源為1個(gè)docx文檔大小4.78MB內(nèi)容包括背景分析、國內(nèi)外研究現(xiàn)狀、相關(guān)理論與技術(shù)、系統(tǒng)分析、功能設(shè)計(jì)與測試驗(yàn)證等章節(jié)并給出了基于IDEA、Navicat、Tomcat等環(huán)境的開發(fā)與運(yùn)行思路。已有433人學(xué)習(xí)下載通過查閱這篇論文可以較快梳理出宿舍報(bào)修系統(tǒng)的數(shù)據(jù)庫表結(jié)構(gòu)、核心接口劃分與前后端交互邏輯對畢業(yè)設(shè)計(jì)答辯、系統(tǒng)二次開發(fā)或?qū)W習(xí)SpringBootVue項(xiàng)目都有直接的參考價(jià)值。1. 宿舍報(bào)修管理系統(tǒng)從論文到可運(yùn)行源碼的一次完整復(fù)現(xiàn)做后勤類管理系統(tǒng)的人應(yīng)該都有感觸報(bào)修流程看起來簡單但一旦涉及多角色協(xié)同業(yè)務(wù)狀態(tài)流轉(zhuǎn)就會迅速膨脹。這份基于 Java 的宿舍報(bào)修管理系統(tǒng)資源是一個(gè)把「報(bào)修」這件事做得很完整的畢業(yè)設(shè)計(jì)項(xiàng)目技術(shù)棧是 SpringBoot Vue MySQL角色分管理員、用戶、維修員三種覆蓋了從宿舍分配、配件申請到維修進(jìn)度追蹤的完整閉環(huán)。論文部分把系統(tǒng)分析、數(shù)據(jù)庫設(shè)計(jì)、功能實(shí)現(xiàn)和測試用例都寫清楚了源碼部分則能直接跑起來做二次開發(fā)。適合正在做類似課題的學(xué)生或者想把校園報(bào)修場景數(shù)字化、需要一套基礎(chǔ)代碼的開發(fā)者。我拆完這套資源最大的感受是它的價(jià)值不在某個(gè)高深算法而在于把報(bào)修業(yè)務(wù)里那些容易被忽略的狀態(tài)節(jié)點(diǎn)設(shè)計(jì)得很完整這對課程設(shè)計(jì)和實(shí)際小規(guī)模部署都夠用。2. 技術(shù)棧選型拆解為什么是 SpringBoot Vue MySQL2.1 后端框架SpringBoot 在報(bào)修系統(tǒng)里的真實(shí)定位這套資源后端用 Java SpringBoot 搭建SpringBoot 在這里解決的核心問題不是高性能而是「開發(fā)效率」。報(bào)修管理這類業(yè)務(wù)系統(tǒng)本質(zhì)上是圍繞數(shù)據(jù)庫表的增刪改查加上一點(diǎn)業(yè)務(wù)狀態(tài)流轉(zhuǎn)SpringBoot 的自動配置和約定優(yōu)于配置特性能極大減少 XML 配置和模板代碼讓開發(fā)者把精力集中在業(yè)務(wù)邏輯上。資源里的實(shí)現(xiàn)方式走的是典型的前后端分離思路。后端提供 RESTful API前端用 Vue 通過 HTTP 請求調(diào)用接口數(shù)據(jù)以 JSON 格式交互。這種模式的優(yōu)點(diǎn)是前端頁面調(diào)整不會影響后端邏輯對后續(xù)要擴(kuò)展移動端或者小程序端也比較方便。在一個(gè)典型的報(bào)修信息查詢接口里你可以看到這樣的 Controller 層代碼RestController RequestMapping(/baoxiu) public class BaoxiuInfoController { Autowired private BaoxiuInfoService baoxiuInfoService; GetMapping(/page) public Result queryPage(RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize, RequestParam(required false) String baoxiuren) { QueryWrapperBaoxiuInfo wrapper new QueryWrapper(); if (StringUtils.isNotBlank(baoxiuren)) { wrapper.like(baoxiuren, baoxiuren); } wrapper.orderByDesc(addtime); PageBaoxiuInfo page new Page(pageNum, pageSize); baoxiuInfoService.page(page, wrapper); return Result.success(page); } }這里需要說明幾個(gè)關(guān)鍵點(diǎn)。QueryWrapper是 MyBatis-Plus 提供的條件構(gòu)造器用like方法實(shí)現(xiàn)模糊查詢orderByDesc按時(shí)間倒序排列——報(bào)修信息通常需要展示最新記錄。分頁用的是 MyBatis-Plus 的Page對象前端傳入 pageNum 和 pageSize 兩個(gè)參數(shù)就能控制每頁數(shù)據(jù)量。Result.success是統(tǒng)一響應(yīng)封裝把返回?cái)?shù)據(jù)包一層前端就能根據(jù) code 判斷請求是否成功。資源里的后端結(jié)構(gòu)不是簡單的單文件堆砌而是分包明確controller 層處理請求路由service 層寫業(yè)務(wù)邏輯mapper 層負(fù)責(zé)數(shù)據(jù)庫操作entity 層定義實(shí)體類。這種分層做法在應(yīng)對報(bào)修業(yè)務(wù)里那些多表關(guān)聯(lián)查詢時(shí)很有用比如報(bào)修信息要關(guān)聯(lián)用戶表查姓名、關(guān)聯(lián)宿舍表查位置、關(guān)聯(lián)維修員表查分配情況。2.2 前端與數(shù)據(jù)庫Vue 組件化開發(fā)和 MySQL 表設(shè)計(jì)思路前端的 Vue 部分資源里用的是 Vue 2 Element UI 組件庫。Element UI 的表格、表單、彈窗組件能快速搭建管理后臺界面對做課設(shè)或者內(nèi)部管理系統(tǒng)來說是最省力的方案。頁面結(jié)構(gòu)上登錄頁、注冊頁、用戶報(bào)修頁、管理員后臺頁、維修員任務(wù)頁是分開的通過 Vue Router 做路由跳轉(zhuǎn)。數(shù)據(jù)庫設(shè)計(jì)是這套資源里比較扎實(shí)的部分。MySQL 數(shù)據(jù)庫配合 Navicat 可視化工具管理核心表包括管理員表 users、用戶表 yonghu、維修員表 weixiuyuan、宿舍信息表 sushexinxi、報(bào)修信息表 baoxiuxinxi、配件設(shè)備表 peijianshebei 等一共十幾張表每張表的字段設(shè)計(jì)都和業(yè)務(wù)場景對應(yīng)。以報(bào)修信息表為例字段設(shè)計(jì)基本覆蓋了報(bào)修業(yè)務(wù)流程的所有節(jié)點(diǎn)字段名類型說明備注idbigint主鍵自增baoxiubianhaovarchar報(bào)修編號唯一baoxiurenvarchar報(bào)修人關(guān)聯(lián)用戶賬號baoxiuneirongtext報(bào)修內(nèi)容故障描述baoxiushijiandatetime報(bào)修時(shí)間默認(rèn)當(dāng)前時(shí)間weixiuyuanvarchar維修員接單后回填weixiuzhuangtaivarchar維修狀態(tài)待接單/維修中/已完成wanchengshijiandatetime完成時(shí)間狀態(tài)變更時(shí)更新這套表設(shè)計(jì)的巧妙之處在于它把報(bào)修業(yè)務(wù)的狀態(tài)流轉(zhuǎn)直接體現(xiàn)在表的字段變更上。報(bào)修單創(chuàng)建時(shí)只有報(bào)修人和報(bào)修內(nèi)容維修員接單后回填維修員字段維修過程中更新狀態(tài)完成后再寫入完成時(shí)間。這個(gè)思路比額外建一張狀態(tài)流轉(zhuǎn)表要簡單直接對業(yè)務(wù)規(guī)模不大的場景完全夠用。2.3 權(quán)限控制三種角色在資源里是怎么落地的角色權(quán)限是管理系統(tǒng)的核心這套資源在登錄接口里實(shí)現(xiàn)了基于角色的路由控制。登錄成功后后端根據(jù)不同角色返回不同菜單權(quán)限前端再根據(jù)權(quán)限渲染對應(yīng)的導(dǎo)航欄。PostMapping(/login) public Result login(RequestBody Users user) { QueryWrapperUsers wrapper new QueryWrapper(); wrapper.eq(username, user.getUsername()) .eq(password, user.getPassword()); Users loginUser usersService.getOne(wrapper); if (loginUser null) { return Result.error(用戶名或密碼錯(cuò)誤); } String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(token, loginUser.getUsername(), 2, TimeUnit.HOURS); MapString, Object data new HashMap(); data.put(token, token); data.put(role, loginUser.getRole()); data.put(username, loginUser.getUsername()); return Result.success(data); }這段登錄邏輯有幾個(gè)地方值得注意。密碼校驗(yàn)用的是最簡單直接的等值查詢這是很多課設(shè)項(xiàng)目的常見做法但生產(chǎn)環(huán)境必須換成加密存儲。UUID.randomUUID()生成的隨機(jī)字符串作為 token存到 Redis 里并設(shè)置 2 小時(shí)過期時(shí)間這樣能控制會話有效期。返回的 role 字段告訴前端當(dāng)前用戶是什么角色前端拿這個(gè)字段控制菜單顯示。資源里的權(quán)限控制粒度是「角色-菜單」級別的也就是不同角色看到不同菜單但同角色內(nèi)沒有更細(xì)分的操作權(quán)限區(qū)分。對于課程設(shè)計(jì)和小型后勤系統(tǒng)來說這個(gè)粒度夠了但如果要做更嚴(yán)格的權(quán)限管理可以考慮引入 Spring Security 或者 Shiro 做細(xì)粒度控制。3. 數(shù)據(jù)庫物理設(shè)計(jì)從 E-R 圖到建表 SQL 的落地細(xì)節(jié)3.1 核心表關(guān)系用戶、宿舍、維修員、報(bào)修單怎么關(guān)聯(lián)這套資源的數(shù)據(jù)庫設(shè)計(jì)遵循了第三范式的基本要求各表之間通過外鍵邏輯建立關(guān)聯(lián)。用戶表 yonghu 和宿舍分配表 sushefenpei 通過用戶賬號字段關(guān)聯(lián)宿舍信息表 sushexinxi 和宿舍分配表通過宿舍名稱關(guān)聯(lián)報(bào)修信息表 baoxiuxinxi 同時(shí)關(guān)聯(lián)用戶表和維修員表。有一個(gè)設(shè)計(jì)細(xì)節(jié)值得展開說說。宿舍信息表和宿舍分配表是分開的宿舍信息表記錄的是靜態(tài)數(shù)據(jù)——宿舍名稱、類型、樓棟、房間號、可住人數(shù)、已住人數(shù)、床位數(shù)量宿舍分配表記錄的是動態(tài)數(shù)據(jù)——誰住在哪個(gè)宿舍的哪個(gè)床位、分配日期、備注。這種拆分避免了一個(gè)學(xué)生換宿舍時(shí)要去修改宿舍表的問題只需要在分配表里更新記錄。建表 SQL 里能看到一些常見的設(shè)計(jì)約定。所有表都有 id 主鍵和 addtime 時(shí)間戳字段id 用 bigint 類型自增addtime 默認(rèn)值設(shè)為CURRENT_TIMESTAMP。這類約定在 MyBatis-Plus 的自動填充功能下很好用插入數(shù)據(jù)時(shí)不用手動維護(hù)創(chuàng)建時(shí)間字段。CREATE TABLE baoxiuxinxi ( id bigint(20) NOT NULL AUTO_INCREMENT, addtime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, baoxiubianhao varchar(20) NOT NULL, baoxiuren varchar(20) DEFAULT NULL, baoxiuneirong longtext, weixiuyuan varchar(20) DEFAULT NULL, weixiuzhuangtai varchar(20) DEFAULT 待接單, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;這里有幾個(gè)細(xì)節(jié)要注意。longtext類型用于報(bào)修內(nèi)容字段因?yàn)楣收厦枋隹赡鼙容^長。weixiuzhuangtai字段設(shè)置了默認(rèn)值 待接單這樣創(chuàng)建報(bào)修單時(shí)不用顯式傳這個(gè)字段。字符集用utf8mb4而不是utf8原因是utf8mb4支持完整的 Unicode 字符包括 emoji 表情避免用戶在報(bào)修內(nèi)容里輸入特殊字符時(shí)出現(xiàn)亂碼。3.2 權(quán)限表的 token 處理機(jī)制管理員表 users 和 token 表的設(shè)計(jì)有一個(gè)值得學(xué)習(xí)的地方。token 表和用戶表是一對一關(guān)系token 表里有 userid、username、tablename、role、token、expiratedtime 字段。這里的 tablename 字段有點(diǎn)意思它記錄的是當(dāng)前 token 對應(yīng)哪個(gè)用戶表的表名。為什么需要這個(gè)字段因?yàn)橄到y(tǒng)有三類用戶——管理員、普通用戶、維修員——他們可能存儲在三張不同的表里。token 表里的 tablename 字段就是為了區(qū)分這個(gè) token 是哪個(gè)登錄主體的。這種設(shè)計(jì)在課設(shè)項(xiàng)目里比較常見雖然用統(tǒng)一的用戶表加角色字段也能實(shí)現(xiàn)但對于已有三張表的數(shù)據(jù)庫結(jié)構(gòu)這種擴(kuò)展方式改動最小。過期時(shí)間expiratedtime的處理邏輯也需要留意。資源里的實(shí)現(xiàn)是在登錄時(shí)生成過期時(shí)間在攔截器里校驗(yàn)當(dāng)前時(shí)間是否超過過期時(shí)間。如果你把這套代碼用于生產(chǎn)建議把這個(gè)校驗(yàn)邏輯統(tǒng)一放到攔截器或者過濾器里避免在每個(gè) Controller 里重復(fù)寫。3.3 常用查詢場景的索引視角從檢索能力角度看這套表設(shè)計(jì)報(bào)修信息表的 baoxiubianhao 字段值得建唯一索引因?yàn)闃I(yè)務(wù)上需要通過報(bào)修編號快速定位單子。用戶表的 yonghuzhanghao用戶賬號字段在登錄時(shí)做等值查詢也應(yīng)該建索引。宿舍信息表的 sushemingcheng 字段在宿舍分配時(shí)做關(guān)聯(lián)查詢加普通索引就夠了。資源里的 SQL 腳本已經(jīng)包含了一些索引定義但在 Navicat 里導(dǎo)入后建議再檢查一遍重點(diǎn)看那些經(jīng)常出現(xiàn)在 WHERE 條件和 JOIN 條件里的字段是否建了索引。實(shí)際操作中我遇到過這種情況數(shù)據(jù)量小的時(shí)候感覺不到區(qū)別一旦報(bào)修記錄累積到幾千條全表掃描的查詢延遲就會明顯增加。4. 核心功能實(shí)現(xiàn)報(bào)修閉環(huán)的三個(gè)關(guān)鍵模塊4.1 報(bào)修流程從用戶提單到維修員接單的狀態(tài)機(jī)報(bào)修管理是這套系統(tǒng)的核心業(yè)務(wù)流整個(gè)流程可以抽象成一條狀態(tài)鏈用戶提交報(bào)修 → 管理員審核或直接進(jìn)入待接單池 → 維修員接單 → 維修中 → 完成。資源里的實(shí)現(xiàn)方式是用戶在前端填寫報(bào)修內(nèi)容提交報(bào)修單進(jìn)入待接單狀態(tài)維修員在待接單列表里查看所有未接單的工單接單后狀態(tài)變?yōu)榫S修中維修完成后更新狀態(tài)為已完成。后端的接單接口是流程的關(guān)鍵節(jié)點(diǎn)代碼大致是PostMapping(/jiedan) public Result jiedan(RequestBody BaoxiuInfo baoxiuInfo) { BaoxiuInfo info baoxiuInfoService.getById(baoxiuInfo.getId()); if (info null) { return Result.error(報(bào)修單不存在); } if (!待接單.equals(info.getWeixiuzhuangtai())) { return Result.error(該報(bào)修單已被接單); } info.setWeixiuyuan(baoxiuInfo.getWeixiuyuan()); info.setWeixiuzhuangtai(維修中); info.setJiedanshijian(new Date()); baoxiuInfoService.updateById(info); return Result.success(接單成功); }這段代碼體現(xiàn)了一個(gè)容易被忽視的業(yè)務(wù)約束接單前的狀態(tài)校驗(yàn)。如果在更新狀態(tài)前不檢查當(dāng)前報(bào)修單是否已經(jīng)是「待接單」?fàn)顟B(tài)就可能出現(xiàn)兩個(gè)維修員同時(shí)搶同一張單子后提交的人把前一個(gè)人的信息覆蓋掉。這種并發(fā)問題在這個(gè)資源里用的是「先查再改」的方式雖然不做數(shù)據(jù)庫層面的樂觀鎖但對課設(shè)場景夠用。如果你想做得更穩(wěn)可以在表里加一個(gè) version 字段在更新 SQL 里加WHERE version #{oldVersion}的樂觀鎖條件。4.2 宿舍分配用戶、宿舍、床位三者關(guān)聯(lián)的精確度問題宿舍分配模塊解決的核心問題是「哪個(gè)學(xué)生住在哪個(gè)宿舍的哪個(gè)床位」。資源里的實(shí)現(xiàn)邏輯是管理員在后臺選擇宿舍再選擇用戶接著填入床位號保存后生成一條分配記錄同時(shí)更新宿舍表的已住人數(shù)。這里有一個(gè)容易踩坑的業(yè)務(wù)點(diǎn)宿舍的容量校驗(yàn)。分配宿舍時(shí)應(yīng)該校驗(yàn)該宿舍當(dāng)前已住人數(shù)是否小于可住人數(shù)否則會出現(xiàn)超員分配。我在拆解資源時(shí)看了一下這個(gè)校驗(yàn)邏輯在源碼里并不完整需要自己補(bǔ)上。補(bǔ)上這個(gè)校驗(yàn)的代碼邏輯如下// 查詢宿舍當(dāng)前狀態(tài) Sushexinxi sushe sushexinxiService.getById(sushefenpei.getSusheId()); if (sushe null) { return Result.error(宿舍不存在); } int yizhu Integer.parseInt(sushe.getYizhurenshu()); int kezhu Integer.parseInt(sushe.getKezhurenshu()); if (yizhu kezhu) { return Result.error(該宿舍已住滿); } // 執(zhí)行分配 sushefenpeiService.save(sushefenpei); // 更新已住人數(shù) sushe.setYizhurenshu(String.valueOf(yizhu 1)); sushexinxiService.updateById(sushe);這里有個(gè)細(xì)節(jié)值得注意yizhurenshu和kezhurenshu在表設(shè)計(jì)里用的是 varchar 類型而不是 int。這在數(shù)據(jù)庫設(shè)計(jì)里其實(shí)不算最佳實(shí)踐因?yàn)橐鰯?shù)值比較時(shí)必須先轉(zhuǎn)型。這個(gè)資源這么設(shè)計(jì)可能是因?yàn)閷?shí)體類里為了方便前端展示用了字符串類型。如果你在二次開發(fā)時(shí)要把這塊做嚴(yán)謹(jǐn)建議把這兩個(gè)字段改成 int 類型Mapper 層做一層類型轉(zhuǎn)換即可。4.3 配件申請與庫存聯(lián)動維修員領(lǐng)料的后臺邏輯配件申請模塊的連接點(diǎn)在維修員和配件設(shè)備之間。維修員接單后如果發(fā)現(xiàn)維修需要更換配件可以在線提交配件申請管理員審核通過后配件庫存數(shù)量需要相應(yīng)減少。PostMapping(/shenqing) public Result shenqing(RequestBody Peijianshenqing peijianShenqing) { Peijianshebei peijian peijianshebeiService.getById(peijianShenqing.getPeijianId()); if (peijian null) { return Result.error(配件不存在); } int kucun Integer.parseInt(peijian.getKucun()); int shenqingshu Integer.parseInt(peijianShenqing.getShenqingshu()); if (kucun shenqingshu) { return Result.error(庫存不足); } // 減少庫存 peijian.setKucun(String.valueOf(kucun - shenqingshu)); peijianshebeiService.updateById(peijian); // 記錄申請單 peijianShenqing.setZhuangtai(已發(fā)放); peijianshenqingService.save(peijianShenqing); return Result.success(申請成功); }這個(gè)接口是「先扣庫存再保存申請單」的順序按正常事務(wù)語義來說應(yīng)該在一個(gè)事務(wù)里執(zhí)行否則如果保存申請單失敗庫存已經(jīng)被扣掉了。資源里沒有顯式加Transactional注解這是一個(gè)潛在隱患。你在二次開發(fā)時(shí)建議加上這個(gè)注解讓這兩個(gè)數(shù)據(jù)庫操作處于同一事務(wù)中保證數(shù)據(jù)一致性。配件模塊還有一個(gè)值得提的設(shè)計(jì)配件分類表和配件設(shè)備表分離。分類表存配件類型設(shè)備表存具體配件通過分類 ID 關(guān)聯(lián)。這種設(shè)計(jì)的好處是新增配件時(shí)不用改表結(jié)構(gòu)選擇已有分類就行。4.4 維修進(jìn)度查詢用戶端的狀態(tài)可視化維修進(jìn)度模塊是用戶體驗(yàn)的加分項(xiàng)。用戶在提交報(bào)修單后可以在「維修進(jìn)度查詢」頁面看到自己所有報(bào)修單的當(dāng)前狀態(tài)。這里的實(shí)現(xiàn)思路很簡單就是按照當(dāng)前登錄用戶的賬號查詢該用戶所有報(bào)修單按時(shí)間倒序展示狀態(tài)字段。進(jìn)度展示的字段設(shè)計(jì)覆蓋了報(bào)修全生命周期提交時(shí)間、當(dāng)前狀態(tài)、維修員姓名、維修完成時(shí)間。用戶在列表里能直觀看到自己的單子處于什么環(huán)節(jié)是待接單、維修中還是已完成。這塊功能實(shí)現(xiàn)不復(fù)雜但它是用戶視角里感知系統(tǒng)價(jià)值最直接的地方。需要注意的是維修進(jìn)度查詢在資源里的實(shí)現(xiàn)是按報(bào)修單狀態(tài)字段實(shí)時(shí)讀取的不是寫一條進(jìn)度日志表記錄每次狀態(tài)變更。如果你需要做「完整操作留痕」比如記錄誰在什么時(shí)間把狀態(tài)從 A 改成了 B那就需要額外建一張狀態(tài)變更日志表在每次狀態(tài)變化的代碼邏輯里插入一條日志記錄。5. 避坑指南五個(gè)讓系統(tǒng)在演示現(xiàn)場翻車的常見問題5.1 端口被占用導(dǎo)致 Tomcat 啟動失敗現(xiàn)象在 IDEA 里啟動 SpringBoot 項(xiàng)目控制臺直接報(bào)Port 8080 was already in use整個(gè)應(yīng)用起不來。原因本機(jī)之前有別的程序占用了 8080 端口或者上一次運(yùn)行項(xiàng)目的進(jìn)程沒被完全殺掉。這在課設(shè)演示前最容易發(fā)生越急越找不到是哪個(gè)程序占的。解決Windows 系統(tǒng)用netstat -ano | findstr 8080查出占用端口的 PID然后到任務(wù)管理器里結(jié)束對應(yīng)進(jìn)程或者直接改application.properties里的server.port配置把端口換掉。我一般建議直接用后者省事改完重啟就行。5.2 MySQL 時(shí)區(qū)問題導(dǎo)致時(shí)間字段相差 8 小時(shí)現(xiàn)象系統(tǒng)里新增報(bào)修記錄的時(shí)間在頁面上顯示比當(dāng)前時(shí)間晚了 8 小時(shí)。原因MySQL 8.0 版本之后的連接驅(qū)動對時(shí)區(qū)敏感如果 JDBC URL 里沒有指定 serverTimezone 參數(shù)默認(rèn)使用服務(wù)器本地時(shí)區(qū)而國內(nèi)環(huán)境經(jīng)常會匹配到 UTC 標(biāo)準(zhǔn)時(shí)間。解決在數(shù)據(jù)庫連接 URL 里明確加上?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8。這個(gè)問題在資源配套的數(shù)據(jù)庫連接配置文件里其實(shí)已經(jīng)處理過但如果你自己重裝了 MySQL 或者改了連接串很容易重新踩進(jìn)去。配置改完重啟應(yīng)用時(shí)間就正常了。5.3 登錄頁驗(yàn)證碼或密碼校驗(yàn)不走攔截器現(xiàn)象未登錄狀態(tài)直接訪問后端接口地址居然能拿到數(shù)據(jù)登錄功能形同虛設(shè)。原因SpringBoot 項(xiàng)目里的攔截器只對部分 URL 生效如果配置 WebMvcConfigurer 時(shí)攔截路徑寫得不對比如只攔截了/admin/**漏掉了/api/**或者登錄接口本身就在攔截名單里就會導(dǎo)致鑒權(quán)邏輯不生效。解決先看資源里的攔截器配置類把不需要登錄就能訪問的接口路徑全部加到放行列表里比如/login、/register其余接口全部攔截。放行列表怎么寫可以看一下攔截器的實(shí)現(xiàn)一般是在excludePathPatterns()方法后面追加。把攔截器的匹配規(guī)則改成/**再排除掉白名單路徑是最穩(wěn)妥的。5.4 Navicat 導(dǎo)入 SQL 腳本時(shí)外鍵約束失敗現(xiàn)象把資源里的數(shù)據(jù)庫腳本用 Navicat 導(dǎo)入過程中報(bào)錯(cuò)提示Cannot add foreign key constraint導(dǎo)致部分表創(chuàng)建失敗。原因腳本里建表的順序可能有問題先創(chuàng)建了有外鍵的子表后創(chuàng)建了被引用的父表或者是兩張表的字段類型不完全匹配比如一邊是 bigint 另一邊是 int。解決不用 Navicat 直接導(dǎo)整份腳本改成先執(zhí)行建表語句創(chuàng)建所有表再單獨(dú)執(zhí)行外鍵約束的修改語句?；蛘吒纱喟涯_本里所有外鍵約束刪掉表結(jié)構(gòu)建好之后手動在 Navicat 里補(bǔ)外鍵關(guān)系。課設(shè)評審階段外鍵約束是否完整影響不大關(guān)鍵是表能建成功、數(shù)據(jù)能存進(jìn)去。5.5 前端頁面請求跨域?qū)е陆涌谀貌坏綌?shù)據(jù)現(xiàn)象前端 Vue 項(xiàng)目啟動后頁面能打開但所有數(shù)據(jù)都是空的瀏覽器控制臺報(bào)Access to XMLHttpRequest has been blocked by CORS policy錯(cuò)誤。原因前端運(yùn)行在 8080 端口后端運(yùn)行在 8081 端口瀏覽器出于同源策略限制禁止跨端口發(fā)起 AJAX 請求。解決后端加一個(gè)跨域配置類實(shí)現(xiàn) WebMvcConfigurer 接口并重寫 addCorsMappings 方法。代碼如下Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns和allowCredentials(true)要配合使用否則有的瀏覽器版本會報(bào)錯(cuò)。6. 從課程設(shè)計(jì)到能用二次開發(fā)時(shí)我最先動刀的五個(gè)位置拿到這套資源如果你是拿來交作業(yè)跑通就完事了。但如果你想讓這個(gè)系統(tǒng)真正能放進(jìn)一個(gè)宿舍樓里用我建議按下面的優(yōu)先級做改造。第一處是密碼加密。資源里的密碼是明文存儲的登錄也是直接WHERE username ? AND password ?查詢。現(xiàn)實(shí)場景里哪怕只是內(nèi)部系統(tǒng)明文密碼也是不可接受的。用 Spring Security 的 BCryptPasswordEncoder也就是一個(gè)加密工具類注冊時(shí)對密碼做哈希登錄時(shí)用matches方法做比對改動量在注冊接口和登錄接口兩個(gè)地方半小時(shí)能改完。第二處是報(bào)修單狀態(tài)的并發(fā)控制。之前提到接單接口的「先查再改」邏輯存在并發(fā)覆蓋風(fēng)險(xiǎn)加樂觀鎖是最省事的方案。在報(bào)修信息表加 version 字段更新時(shí)用UPDATE baoxiuxinxi SET weixiuzhuangtai 維修中, version version 1 WHERE id ? AND version ?受影響行數(shù)為 0 就說明有人搶先改過了提示用戶刷新后重試。第三處是文件上傳和圖片展示。報(bào)修單里如果能附帶現(xiàn)場照片會大幅減少溝通成本。資源里沒有實(shí)現(xiàn)圖片上傳需要自己補(bǔ)一個(gè)上傳接口把文件保存到服務(wù)器本地目錄訪問時(shí)通過一個(gè)映射路徑直接讀取。注意上傳目錄要放在應(yīng)用外部不然重新部署的時(shí)候文件會丟。第四處是數(shù)據(jù)備份。很多課設(shè)系統(tǒng)跑著跑著數(shù)據(jù)庫就崩了崩了就沒有后悔藥。至少配置一個(gè) MySQL 定時(shí)任務(wù)每天凌晨用mysqldump把整個(gè)庫導(dǎo)出一份 SQL 文件到備份目錄。這個(gè)操作不寫代碼一行 crontab 就能解決。從那以后我每次接手這類系統(tǒng)都強(qiáng)制自己先讀一遍數(shù)據(jù)庫表設(shè)計(jì)文檔再動手改代碼。表結(jié)構(gòu)理順了業(yè)務(wù)邏輯八九不離十就能看懂。這套資源的表設(shè)計(jì)雖然不是完美的但它把報(bào)修業(yè)務(wù)的關(guān)鍵實(shí)體和狀態(tài)都覆蓋到了適合做基礎(chǔ)再去改。希望這篇拆解能幫你在自己的項(xiàng)目里少走幾步彎路。本文還有配套的精品資源點(diǎn)擊獲取