最近幫一個(gè)學(xué)弟復(fù)盤他的課程設(shè)計(jì)項(xiàng)目題目是實(shí)驗(yàn)中心器材管理系統(tǒng)。這個(gè)題目在高校的Web課程設(shè)計(jì)里出現(xiàn)頻率非常高幾乎每個(gè)學(xué)期都有人選版本也從早期的ServletJSP一直做到現(xiàn)在的Spring BootVue前后端分離。但有意思的是同一個(gè)題目有人做出來(lái)是能用有人做出來(lái)是能答辯差距往往不在功能多不多而在邏輯閉不閉環(huán)、踩過(guò)的坑有沒(méi)有真正想明白。這篇文章就是我基于這次復(fù)盤整理出來(lái)的一份完整總結(jié)把實(shí)驗(yàn)中心器材管理系統(tǒng)從題目拆解、技術(shù)選型、數(shù)據(jù)庫(kù)設(shè)計(jì)到借用歸還流程、并發(fā)庫(kù)存扣減、前后端聯(lián)調(diào)再到答辯準(zhǔn)備一條線全部過(guò)一遍。不管你是正準(zhǔn)備動(dòng)手寫這個(gè)課設(shè)還是已經(jīng)寫完但總覺(jué)得哪里說(shuō)不太清楚這篇文章都能給你一個(gè)可以直接參考的完整思路。1. 課程設(shè)計(jì)的目標(biāo)拆解器材管理系統(tǒng)到底要解決什么很多同學(xué)拿到這個(gè)題目第一反應(yīng)是器材就是增刪改查嘛然后直接上手寫代碼。這個(gè)思路不能說(shuō)錯(cuò)但會(huì)漏掉課設(shè)真正的得分點(diǎn)。課程設(shè)計(jì)考核的核心從來(lái)不是功能堆砌而是你對(duì)一個(gè)完整業(yè)務(wù)場(chǎng)景的理解誰(shuí)在用、流程怎么走、狀態(tài)怎么變、數(shù)據(jù)怎么保證一致。1.1 實(shí)驗(yàn)中心的核心業(yè)務(wù)流程是什么實(shí)驗(yàn)中心器材管理的本質(zhì)是資產(chǎn)流通管理。器材不是放在倉(cāng)庫(kù)里吃灰的而是要借給老師、學(xué)生做實(shí)驗(yàn)用完之后歸還期間可能損壞需要報(bào)修。把這個(gè)流程拆開(kāi)至少有這些環(huán)節(jié)器材入庫(kù)、器材借用申請(qǐng)、管理員審核、出庫(kù)、使用中、歸還、入庫(kù)檢查、報(bào)修、報(bào)廢。對(duì)應(yīng)到系統(tǒng)里就是要用數(shù)據(jù)把器材的完整生命周期記錄下來(lái)。這也是答辯時(shí)老師最愛(ài)問(wèn)的一個(gè)點(diǎn)——你的系統(tǒng)怎么知道這臺(tái)設(shè)備現(xiàn)在在哪、在誰(shuí)手上、借了多久如果你的數(shù)據(jù)模型沒(méi)有支撐這個(gè)問(wèn)題的答案那系統(tǒng)就是純展示型的談不上管理。1.2 角色權(quán)限怎么劃分才能讓評(píng)分老師滿意器材管理系統(tǒng)的用戶角色我建議分三類管理員、教師、學(xué)生。管理員負(fù)責(zé)器材入庫(kù)、審核借用申請(qǐng)、登記歸還信息、處理報(bào)修教師和學(xué)生可以瀏覽器材庫(kù)存、發(fā)起借用申請(qǐng)、查看自己的借用歷史。有些課設(shè)會(huì)把教師和學(xué)生合并成一個(gè)角色功能上確實(shí)夠用但答辯時(shí)容易被追問(wèn)不同身份的人借器材的優(yōu)先級(jí)和數(shù)量限制怎么處理到時(shí)候只能現(xiàn)場(chǎng)加邏輯比較被動(dòng)。權(quán)限控制這塊我采用的是后端攔截器校驗(yàn)加前端路由守衛(wèi)的組合。后端攔截器根據(jù)session或token中的role字段判斷接口是否允許訪問(wèn)管理員接口統(tǒng)一以/admin/**開(kāi)頭普通用戶接口以/user/**開(kāi)頭攔截器直接按路徑前綴匹配簡(jiǎn)單可靠。1.3 技術(shù)選型為什么是Spring Boot Vue而不是ServletJSP技術(shù)選型是課程設(shè)計(jì)報(bào)告里必須寫的內(nèi)容也是有些人容易在這里丟印象分?，F(xiàn)在很多高校的課程設(shè)計(jì)已經(jīng)不限制技術(shù)棧了但評(píng)分老師心里是有預(yù)期的。我在這次方案里選的是Spring Boot 2.x MyBatis-Plus MySQL 8.0作為后端前端用Vue 2 Element UI。做個(gè)簡(jiǎn)單對(duì)比方案開(kāi)發(fā)效率學(xué)習(xí)成本資料豐富度就業(yè)匹配度ServletJSP低手寫大量代碼低老但全偏低SSM框架中配置繁瑣中很全中Spring Boot Vue高配置少中高非常多高Spring Boot勝在約定大于配置一個(gè)課設(shè)項(xiàng)目基本不需要寫XML配置注解搞定一切。MyBatis-Plus又提供了內(nèi)置的CRUD方法單表操作不需要手寫SQL開(kāi)發(fā)速度會(huì)快很多。前端用Vue做前后端分離接口用JSON交互這正好也迎合了目前企業(yè)開(kāi)發(fā)的主流模式。如果你們課程還沒(méi)教到Spring Boot選SSM也可以但整體思路和本文完全通用。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)三張核心表如何把業(yè)務(wù)狀態(tài)焊死數(shù)據(jù)庫(kù)設(shè)計(jì)是整個(gè)系統(tǒng)最值得花時(shí)間的地方也是最容易被忽視的地方。很多人的表結(jié)構(gòu)就是每頁(yè)配置一張表頁(yè)面有什么字段表里就有什么字段查單個(gè)器材沒(méi)問(wèn)題一到這個(gè)器材被誰(shuí)借走了就查不出來(lái)。歸根結(jié)底是因?yàn)闆](méi)有設(shè)計(jì)好業(yè)務(wù)關(guān)系的落點(diǎn)。2.1 用戶表角色字段用什么類型密碼怎么存用戶表我命名為sys_user字段包括id、username、password、real_name、role、department、phone、create_time。這里有兩個(gè)細(xì)節(jié)值得注意。第一個(gè)是角色字段role用字符串還是數(shù)字。我用的是字符串tAdmin/teacher/student理由是代碼可讀性強(qiáng)日志里看到roleadmin一眼就明白不用再去字典表查1代表什么。用數(shù)字存的人會(huì)說(shuō)省空間但課設(shè)這個(gè)規(guī)模完全不必考慮。第二個(gè)是密碼不能明文存儲(chǔ)。答辯的時(shí)候老師很可能直接打開(kāi)數(shù)據(jù)庫(kù)看看到明文密碼會(huì)扣分。我用了BCrypt加密Spring Security里的BCryptPasswordEncoder單獨(dú)引出來(lái)用就行。登錄時(shí)用matches()校驗(yàn)注冊(cè)或新增用戶時(shí)用encode()生成密文。這不需要引入完整的Spring Security只依賴spring-security-crypto這一個(gè)包輕量夠用。2.2 器材表庫(kù)存為什么拆成兩個(gè)字段器材表equipment是核心資產(chǎn)表字段有id、equipment_name、category、model、location、total_quantity、available_quantity、status、purchase_date、price、description。這里最關(guān)鍵的設(shè)計(jì)決策是不存一個(gè)庫(kù)存總數(shù)而是拆成total_quantity和available_quantity兩個(gè)字段。total_quantity是這臺(tái)器材的入庫(kù)總量是一次性初始化寫入的available_quantity是當(dāng)前可借數(shù)量每次借用扣減、每次歸還增加。為什么不只用一個(gè)字段因?yàn)槲倚枰肋@批器材一共有多少、現(xiàn)在剩多少兩個(gè)數(shù)字一對(duì)比就能得到借出中的數(shù)量不需要額外查詢借用記錄來(lái)實(shí)時(shí)計(jì)算。這就是典型的用空間換時(shí)間也符合資產(chǎn)管理的直覺(jué)——庫(kù)存臺(tái)賬本來(lái)就該有入庫(kù)量和現(xiàn)存量?jī)蓚€(gè)維度。status字段表示器材的整體狀態(tài)我用字典值管理normal正常、repair維修中、scrapped已報(bào)廢。注意這個(gè)狀態(tài)和available_quantity是互補(bǔ)的——報(bào)廢的器材total和available都應(yīng)該凍結(jié)。2.3 借用記錄表一條流水撐起全流程查詢借用記錄表borrow_record是整個(gè)系統(tǒng)真正的業(yè)務(wù)中樞字段包括id、record_no、user_id、equipment_id、borrow_quantity、borrow_time、plan_return_time、actual_return_time、status、audit_user_id、remark。record_no生成規(guī)則是時(shí)間戳加隨機(jī)數(shù)比如BR2025060715300001人工排錯(cuò)的時(shí)候能快速定位。status字段貫穿整個(gè)借用生命周期我用值pending待審核、borrowed借用中、returned已歸還、rejected已駁回、overdue已逾期。其中overdue不單獨(dú)存在于表里而是在查詢時(shí)通過(guò)plan_return_time NOW() AND statusborrowed實(shí)時(shí)計(jì)算出來(lái)的這樣不用定時(shí)任務(wù)去批量修改狀態(tài)邏輯更干凈。這樣一個(gè)表就能回答非常多業(yè)務(wù)問(wèn)題某個(gè)用戶借過(guò)哪些器材、某個(gè)器材現(xiàn)在被誰(shuí)借著、哪些記錄超期未還、每個(gè)月的借用量是多少。SQL寫起來(lái)也簡(jiǎn)單連表查詢一下就行。2.4 建表時(shí)容易被忽略的三個(gè)細(xì)節(jié)第一所有表都加上create_time和update_time字段用數(shù)據(jù)庫(kù)的DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP自動(dòng)維護(hù)省去大量手工賦值。第二邏輯刪除字段deleted用tinyint默認(rèn)0刪除器材時(shí)執(zhí)行UPDATE而不是DELETE保證記錄可追溯。第三在borrow_record表的user_id和equipment_id上建普通索引因?yàn)檫@是查詢頻率最高的兩個(gè)條件不建索引的話數(shù)據(jù)一多聯(lián)表查詢就開(kāi)始變慢。外鍵約束這塊我的建議是課設(shè)可以不加物理外鍵只保留邏輯關(guān)聯(lián)。理由很簡(jiǎn)單一旦加了外鍵刪除器材、刪除用戶的時(shí)候會(huì)頻繁觸發(fā)約束錯(cuò)誤課設(shè)這種數(shù)據(jù)量完全靠代碼保證關(guān)聯(lián)完整性就夠了省掉外鍵能少踩很多坑。3. 借用與歸還流程實(shí)現(xiàn)并發(fā)扣庫(kù)存和狀態(tài)流轉(zhuǎn)如果說(shuō)數(shù)據(jù)庫(kù)設(shè)計(jì)決定系統(tǒng)能不能站住那借用歸還流程就決定系統(tǒng)好不好用。這部分是課設(shè)的核心邏輯也是答辯時(shí)最能展現(xiàn)你水平的地方。3.1 借用申請(qǐng)到審核出庫(kù)的完整鏈路我把借用流程拆成兩段。第一段是用戶提交申請(qǐng)第二段是管理員審核。用戶提交借用申請(qǐng)時(shí)后端需要做四件事校驗(yàn)用戶是否登錄、校驗(yàn)申請(qǐng)數(shù)量是否大于0、校驗(yàn)器材當(dāng)前狀態(tài)是否normal、校驗(yàn)available_quantity是否夠用。這些都通過(guò)后插入一條statuspending的借用記錄。注意這個(gè)階段先不扣減庫(kù)存——這是很多新手容易搞錯(cuò)的地方申請(qǐng)還沒(méi)審核通過(guò)不能先把可用數(shù)量扣掉否則別人看到庫(kù)存被占用了卻沒(méi)真正借出去。管理員審核時(shí)如果通過(guò)執(zhí)行兩個(gè)操作把記錄status改為borrowed同時(shí)UPDATE設(shè)備表的available_quantity available_quantity - borrow_quantity。如果駁回把status改為rejected就結(jié)束。這里為什么要放在審核通過(guò)時(shí)才扣庫(kù)存原因很樸素庫(kù)存應(yīng)該和實(shí)際可被借出的狀態(tài)綁定申請(qǐng)只是意向?qū)徍送ㄟ^(guò)才是承諾。3.2 并發(fā)扣庫(kù)存的正確姿勢(shì)用一條SQL解決原子性課設(shè)系統(tǒng)雖然并發(fā)量不高但答辯必問(wèn)如果兩個(gè)管理員同時(shí)審核同一條借用申請(qǐng)會(huì)不會(huì)出現(xiàn)庫(kù)存超扣如果你寫的是先SELECT available_quantity、在Java代碼里比較、再UPDATE那確實(shí)會(huì)出問(wèn)題——兩個(gè)請(qǐng)求都查到available_quantity1都判斷夠用結(jié)果都扣減成功庫(kù)存就變成-1了。正確的做法是把扣減放到一條原子的UPDATE語(yǔ)句里UPDATE equipment SET available_quantity available_quantity - #{quantity}, update_time NOW() WHERE id #{equipmentId} AND status normal AND available_quantity #{quantity}這條SQL的威力在于available_quantity #{quantity}這個(gè)條件是在數(shù)據(jù)庫(kù)層面判斷的InnoDB對(duì)單行更新會(huì)加行鎖兩個(gè)并發(fā)請(qǐng)求同時(shí)執(zhí)行時(shí)只有一個(gè)能更新成功另一個(gè)更新影響行數(shù)為0。Java代碼里判斷返回的受影響行數(shù)等于0就說(shuō)明庫(kù)存已不足直接拋出業(yè)務(wù)異常即可。我還在equipment表上加了version字段做樂(lè)觀鎖兜底。具體操作是UPDATE時(shí)帶上WHERE version #{oldVersion}同時(shí)version version 1。這樣即使業(yè)務(wù)復(fù)雜到要擴(kuò)展通用更新方法也能防止覆蓋更新。3.3 歸還流程先改記錄還是先加庫(kù)存歸還流程看起來(lái)簡(jiǎn)單但操作順序有講究。用戶歸還時(shí)管理員登記歸還信息系統(tǒng)要做的是把借用記錄的status改為returned并寫入actual_return_time同時(shí)把器材表的available_quantity 歸還數(shù)量。我推薦的順序是先更新借用記錄狀態(tài)再增加庫(kù)存。理由是從業(yè)務(wù)一致性來(lái)說(shuō)歸還動(dòng)作的核心是這筆借用完結(jié)了記錄狀態(tài)是源頭如果先加庫(kù)存但更新記錄失敗庫(kù)存是對(duì)的但記錄還是borrowed后面統(tǒng)計(jì)逾期和資產(chǎn)去向就會(huì)漏反過(guò)來(lái)先更新記錄再加庫(kù)存就算加庫(kù)存失敗記錄已經(jīng)終止最多是庫(kù)存少加一筆可以通過(guò)對(duì)賬發(fā)現(xiàn)。兩害相權(quán)取其輕。歸還時(shí)還要做超期判斷。如果actual_return_time晚于plan_return_time就把這條記錄標(biāo)記為逾期歸還在remark里寫一句超期天數(shù)方便后續(xù)統(tǒng)計(jì)。這個(gè)邏輯不需要定時(shí)任務(wù)在歸還操作里順手判斷就好。3.4 事務(wù)邊界為什么必須放在Service層審核通過(guò)、歸還登記這兩個(gè)動(dòng)作都涉及多張表更新必須加Transactional事務(wù)注解。我踩過(guò)的坑是事務(wù)放在Controller上結(jié)果無(wú)效——Spring事務(wù)默認(rèn)基于代理Controller不是代理對(duì)象事務(wù)根本沒(méi)生效。正確做法是寫在Service實(shí)現(xiàn)類的方法上讓代理攔截到Service方法邊界。另外事務(wù)方法內(nèi)部不能用try-catch把異常吞掉。一旦catch住異常事務(wù)就感知不到已執(zhí)行的SQL不會(huì)回滾。課設(shè)里最容易犯的錯(cuò)誤就是在Service方法里寫try { ... } catch (Exception e) { return 失敗; }。正確做法是Service層拋?zhàn)远x業(yè)務(wù)異常由全局異常處理器捕獲事務(wù)才能正?；貪L到調(diào)用前狀態(tài)。4. 前端頁(yè)面與接口聯(lián)調(diào)從能點(diǎn)到好用前端是評(píng)分老師的第一印象。很多項(xiàng)目后端邏輯設(shè)計(jì)得不錯(cuò)但頁(yè)面交互粗糙、校驗(yàn)缺失拉低了整體分。這一節(jié)重點(diǎn)說(shuō)說(shuō)頁(yè)面規(guī)劃、分頁(yè)查詢、表單校驗(yàn)和聯(lián)調(diào)幾個(gè)容易出問(wèn)題的地方。4.1 頁(yè)面規(guī)劃最少需要幾個(gè)頁(yè)面按照角色和使用場(chǎng)景我規(guī)劃了六個(gè)核心頁(yè)面登錄頁(yè)、器材列表頁(yè)所有角色可見(jiàn)、器材管理頁(yè)管理員用含新增、編輯、報(bào)廢、借用申請(qǐng)頁(yè)、借用審核頁(yè)、借用記錄頁(yè)。如果還想加亮點(diǎn)可以做一個(gè)小型的統(tǒng)計(jì)頁(yè)用ECharts展示每月的借用數(shù)量趨勢(shì)和各分類器材的占比。每個(gè)頁(yè)面用到的Element UI組件也基本固定器材列表用el-table加el-pagination分頁(yè)表單用el-form加rules校驗(yàn)規(guī)則狀態(tài)展示用el-tag配不同顏色比如待審核用info色、借用中用warning色、已歸還用success色。這樣頁(yè)面不需要額外設(shè)計(jì)也能做到信息清楚。4.2 分頁(yè)查詢接口怎么設(shè)計(jì)才規(guī)范器材列表和借用記錄列表都建議做分頁(yè)直接使用MyBatis-Plus的分頁(yè)插件PaginationInnerInterceptor不用手寫LIMIT。后端接口接收pageNum和pageSize兩個(gè)參數(shù)返回一個(gè)統(tǒng)一結(jié)構(gòu){ code: 200, message: success, data: { total: 135, records: [ { id: 1, equipmentName: 萬(wàn)用表, availableQuantity: 8 } ] } }統(tǒng)一返回結(jié)構(gòu)是我在課設(shè)里堅(jiān)持的一個(gè)點(diǎn)。前端只需要處理data.records渲染表格、data.total渲染分頁(yè)組件所有接口的交互模式都是一樣的聯(lián)調(diào)效率會(huì)高很多。條件查詢也在這個(gè)接口里支持比如按器材名稱模糊查詢、按分類篩選、按借用狀態(tài)篩選。實(shí)現(xiàn)方式是用MyBatis-Plus的LambdaQueryWrapper動(dòng)態(tài)拼接條件代碼里判斷參數(shù)不為空才like或eq避免寫一堆XML的if標(biāo)簽。4.3 前端校驗(yàn)和后端校驗(yàn)一個(gè)都不能少前端校驗(yàn)用el-form的rules規(guī)則比如借用數(shù)量必須為大于0的整數(shù)、歸還時(shí)間不能早于借用時(shí)間、查詢關(guān)鍵字長(zhǎng)度限制。這純粹是為了用戶體驗(yàn)——輸入錯(cuò)了立刻提示不用等后端返回。但后端必須再做一遍校驗(yàn)。前端校驗(yàn)可以被繞過(guò)接口直接調(diào)用時(shí)后端得兜住。我在借用接口里做了這些后端校驗(yàn)器材是否存在、器材是否正常、數(shù)量是否為正整數(shù)、可用庫(kù)存是否足夠。前后端雙重校驗(yàn)的最終效果是無(wú)論從哪個(gè)入口發(fā)起請(qǐng)求數(shù)據(jù)都不會(huì)跑偏。4.4 聯(lián)調(diào)階段最容易翻車的三個(gè)小問(wèn)題第一個(gè)是日期格式。Java后端返回的LocalDateTime默認(rèn)序列化成一個(gè)數(shù)組前端拿到?jīng)]法直接用需要配置JsonFormat(pattern yyyy-MM-dd HH:mm:ss)前端顯示表格時(shí)才正常。同樣前端傳日期參數(shù)過(guò)來(lái)需要在查詢參數(shù)對(duì)象上加DateTimeFormat(pattern yyyy-MM-dd)才能正確接收。第二個(gè)是跨域。前后端分離部署時(shí)前端端口是8080后端是8081瀏覽器會(huì)攔截跨域請(qǐng)求。配置方式是在后端寫一個(gè)WebMvcConfigurer的配置類addCorsMappings里設(shè)置允許的路徑、域名和請(qǐng)求頭。注意allowedOriginPatterns不要寫*加allowCredentials的組合某些瀏覽器版本會(huì)直接拒絕。第三個(gè)是修改時(shí)間字段不生效。前端傳了plan_return_time但數(shù)據(jù)庫(kù)里沒(méi)變多半是實(shí)體類字段名和數(shù)據(jù)庫(kù)列名映射不一致加個(gè)TableField(plan_return_time)注解或者檢查一下駝峰命名配置。MyBatis-Plus默認(rèn)開(kāi)啟駝峰映射但只要字段名對(duì)不上就會(huì)靜默失敗這種bug特別難找。4.5 權(quán)限控制不能只靠隱藏按鈕前端我用了路由守衛(wèi)和按鈕級(jí)v-if控制管理員才看得到器材管理菜單和審核按鈕。但這只是體驗(yàn)層的控制后端接口同樣要攔截。我寫了一個(gè)HandlerInterceptor在preHandle里從request獲取token解析出用戶信息和角色再檢查當(dāng)前請(qǐng)求路徑前綴/admin/**要求角色為admin否則直接返回401 JSON。為什么不只做前端隱藏因?yàn)榻涌诒┞对诰W(wǎng)絡(luò)上任何人可以繞過(guò)頁(yè)面直接請(qǐng)求接口。答辯時(shí)演示這點(diǎn)最能體現(xiàn)安全意識(shí)——前端只是界面后端才是守門員。5. 踩坑實(shí)錄課設(shè)中最容易翻車的五個(gè)細(xì)節(jié)這部分是做整個(gè)系統(tǒng)的過(guò)程中實(shí)際踩過(guò)的坑每一個(gè)都花了不少時(shí)間排查。我把完整鏈路寫出來(lái)不僅給結(jié)論更給排查思路這樣你們遇到類似問(wèn)題知道怎么一步步找原因。5.1 事務(wù)注解失效的排查過(guò)程現(xiàn)象審核通過(guò)時(shí)借用記錄狀態(tài)更新成功但器材庫(kù)存沒(méi)有扣減數(shù)據(jù)出現(xiàn)了不一致。第一反應(yīng)是SQL寫錯(cuò)了檢查了Mapper接口和XML單測(cè)調(diào)用也沒(méi)問(wèn)題。后來(lái)發(fā)現(xiàn)問(wèn)題是審核方法里同一類內(nèi)部調(diào)用了另一個(gè)帶Transactional的方法而Spring事務(wù)是通過(guò)代理類觸發(fā)的類內(nèi)部this.xxx()調(diào)用不會(huì)經(jīng)過(guò)代理事務(wù)注解直接失效。解決辦法是把需要事務(wù)保護(hù)的兩個(gè)操作放到獨(dú)立的Service方法里由Controller直接調(diào)用這個(gè)Service方法或者把內(nèi)部調(diào)用改成通過(guò)ApplicationContext獲取代理對(duì)象再調(diào)用。課設(shè)場(chǎng)景最簡(jiǎn)單可靠的方法是在Controller里調(diào)用Service方法Service方法內(nèi)部不要用this調(diào)用自己的另一個(gè)方法所有需要一起成功或一起失敗的操作就在同一個(gè)Transactional方法里做完。5.2 分頁(yè)插件統(tǒng)計(jì)總數(shù)不準(zhǔn)確的排查過(guò)程現(xiàn)象使用MyBatis-Plus分頁(yè)插件后返回的total明顯多于實(shí)際數(shù)據(jù)。排查時(shí)先打印SQL發(fā)現(xiàn)分頁(yè)插件攔截到的是一條關(guān)聯(lián)查詢自動(dòng)生成的count語(yǔ)句對(duì)多表關(guān)聯(lián)查詢?nèi)ブ剡壿嬘袉?wèn)題。解決不再依賴分頁(yè)插件自動(dòng)生成的count改成手寫一個(gè)selectCount方法統(tǒng)計(jì)的主表id數(shù)量分頁(yè)查詢和count查詢完全分開(kāi)。這也是一個(gè)通用經(jīng)驗(yàn)分頁(yè)插件在單表查詢時(shí)很好用多表關(guān)聯(lián)或帶group by的復(fù)雜查詢老老實(shí)實(shí)手寫count語(yǔ)句最穩(wěn)。5.3 模糊查詢關(guān)鍵字為空時(shí)查不出數(shù)據(jù)的排查過(guò)程現(xiàn)象前端在搜索框輸入關(guān)鍵字后再清空列表變成空的。查后端的SQL日志發(fā)現(xiàn)like后面的占位符變成了%%但MySQL里L(fēng)IKE %%理論上應(yīng)該匹配所有行。真正的原因出在MyBatis的XML里寫了if testkeyword ! null我在Java代碼里已經(jīng)判斷keyword是空字符串后賦值為null但XML里用的是! null判斷空字符串進(jìn)到了SQL成了一個(gè)當(dāng)成空白條件的參數(shù)最終導(dǎo)致查詢異常。排查方式是打印完整SQL對(duì)比參數(shù)而不是只看控制臺(tái)的半截SQL。后來(lái)我統(tǒng)一規(guī)范字符串類型的條件判斷一律寫成! null and ! 從根上杜絕這類問(wèn)題。5.4 刪除器材時(shí)外鍵報(bào)錯(cuò)的排查過(guò)程現(xiàn)象刪除一條被借用記錄引用的器材時(shí)報(bào)外鍵約束錯(cuò)誤。這個(gè)現(xiàn)象最直接的解決方式是打開(kāi)外鍵約束檢查和業(yè)務(wù)邏輯判斷。但經(jīng)過(guò)排查其實(shí)報(bào)錯(cuò)信息里已經(jīng)說(shuō)明了外鍵名稱我在建表時(shí)被框架的規(guī)范建議帶偏把外鍵約束寫到了borrow_record表上導(dǎo)致刪除器材時(shí)頻繁觸發(fā)約束。最后我把物理外鍵去掉改用業(yè)務(wù)代碼保證關(guān)聯(lián)完整性刪除器材前先查借用記錄中有沒(méi)有引用如果有就不允許刪除提示先處理借用關(guān)系。這個(gè)方案既保留了業(yè)務(wù)規(guī)則又避開(kāi)了物理外鍵帶來(lái)的刪除麻煩。5.5 Session失效導(dǎo)致登錄狀態(tài)反復(fù)丟失的排查過(guò)程現(xiàn)象登錄成功后過(guò)一會(huì)兒再操作接口提示未登錄。排查方向先是session過(guò)期時(shí)間Java后端session默認(rèn)30分鐘明明沒(méi)過(guò)期。后來(lái)發(fā)現(xiàn)前端請(qǐng)求時(shí)有幾個(gè)接口沒(méi)有帶cookie屬性導(dǎo)致sessionId每次都是新的服務(wù)端認(rèn)為用戶沒(méi)登錄。解決方案是前端統(tǒng)一使用axios.defaults.withCredentials true確保每次請(qǐng)求都攜帶cookie。后端跨域配置里也加了allowCredentials(true)兩邊配合好之后狀態(tài)才穩(wěn)定。這個(gè)小問(wèn)題在前后端分離項(xiàng)目里非常典型做課設(shè)的同學(xué)幾乎都會(huì)遇到一次。6. 測(cè)試、驗(yàn)收與答辯從能跑到能講清楚寫代碼只是課設(shè)的一半另一半是讓老師相信你寫的東西是可靠的、可用的。這部分涉及測(cè)試怎么設(shè)計(jì)、部署文檔怎么準(zhǔn)備、答辯怎么應(yīng)對(duì)。6.1 功能測(cè)試清單不能只測(cè)正常流程我在交付前整理了一份測(cè)試清單按角色和流程覆蓋正常、異常兩種場(chǎng)景。核心用例大概是這樣編號(hào)測(cè)試操作預(yù)期結(jié)果TC01未登錄訪問(wèn)器材列表跳轉(zhuǎn)登錄頁(yè)或返回401TC02學(xué)生登錄提交借用申請(qǐng)生成待審核記錄庫(kù)存不變TC03管理員審核通過(guò)申請(qǐng)記錄變借用中庫(kù)存扣減TC04管理員審核申請(qǐng)時(shí)庫(kù)存不足審核失敗提示庫(kù)存不足TC05用戶歸還器材記錄變已歸還庫(kù)存增加TC06同一器材并發(fā)審核兩條申請(qǐng)只有一條成功庫(kù)存不為負(fù)TC07管理員刪除被借用的器材拒絕刪除提示先處理借用記錄手動(dòng)測(cè)試時(shí)我用瀏覽器加Postman配合Postman重點(diǎn)測(cè)試接口對(duì)異常參數(shù)的反應(yīng)比如傳負(fù)數(shù)數(shù)量、傳不存在的器材id、跳過(guò)審核直接調(diào)歸還接口。異常場(chǎng)景往往比正常流程更能反映系統(tǒng)設(shè)計(jì)的嚴(yán)密程度。6.2 部署方式與交付材料課設(shè)的部署不要求上云本地能跑就行。但交付時(shí)要附上三個(gè)東西初始化數(shù)據(jù)庫(kù)的SQL腳本、README運(yùn)行說(shuō)明、課設(shè)報(bào)告。SQL腳本要保證在一個(gè)空庫(kù)上執(zhí)行能一步到位包含建庫(kù)、建表、插入初始數(shù)據(jù)和管理員賬號(hào)。README我寫清楚環(huán)境要求、數(shù)據(jù)庫(kù)配置、啟動(dòng)步驟、默認(rèn)賬號(hào)照著做三分鐘跑起來(lái)。打包運(yùn)行我給兩個(gè)選擇如果是在IDEA里運(yùn)行直接啟動(dòng)主類如果老師要求打包用mvn clean package生成jar包java -jar運(yùn)行。注意打包時(shí)resources里的配置文件別漏MyBatis的mapper XML文件如果寫在src/main/java下需要在pom里配置resource路徑包含xml。6.3 答辯高頻問(wèn)題與回答思路根據(jù)這次復(fù)盤的準(zhǔn)備過(guò)程我整理出八個(gè)答辯大概率會(huì)問(wèn)的問(wèn)題和回答思路為什么選Spring Boot答簡(jiǎn)化配置、內(nèi)置服務(wù)器、生態(tài)成熟適合快速做前后端分離項(xiàng)目。并發(fā)扣庫(kù)存怎么保證安全答利用數(shù)據(jù)庫(kù)行鎖在一條UPDATE語(yǔ)句里帶庫(kù)存條件判斷影響行數(shù)為0說(shuō)明庫(kù)存不足。事務(wù)注解失效有哪些可能答方法不是public、類內(nèi)部自調(diào)用、異常被try-catch吞掉。權(quán)限是怎么控制的答后端攔截器校驗(yàn)路徑和角色前端路由守衛(wèi)做體驗(yàn)層限制。密碼加密了嗎答B(yǎng)Crypt加密存儲(chǔ)登錄用matches校驗(yàn)。刪除器材時(shí)怎么處理關(guān)聯(lián)數(shù)據(jù)答先查借用記錄是否有引用有則禁止刪除。超期未還怎么判斷答借用中狀態(tài)下當(dāng)前時(shí)間晚于計(jì)劃歸還時(shí)間即視為逾期查詢時(shí)實(shí)時(shí)計(jì)算。如果設(shè)備維修中被人借怎么辦答器材status為repair時(shí)查詢列表就不可見(jiàn)借用接口也做了status校驗(yàn)。每個(gè)問(wèn)題回答時(shí)都要盡量往我實(shí)際怎么做的上面靠能說(shuō)出踩過(guò)什么坑、為什么這么設(shè)計(jì)比背概念好得多。6.4 從這次課程設(shè)計(jì)里真正帶走的東西做完這個(gè)器材管理系統(tǒng)我最大的體會(huì)是課程設(shè)計(jì)最有價(jià)值的部分不是最后那幾百分而是把一個(gè)模糊的題目變成一套能自洽運(yùn)行的系統(tǒng)這個(gè)過(guò)程。數(shù)據(jù)庫(kù)字段怎么拆、庫(kù)存扣減怎么保證不超賣、前端和后端怎么配合、異常場(chǎng)景怎么兜底——這些問(wèn)題每一個(gè)都需要你去查資料、寫代碼、跑測(cè)試最后變成自己的判斷力。答辯結(jié)束后我把代碼重新整理了一遍把每個(gè)類的職責(zé)、每個(gè)接口的入?yún)⒊鰠?、每條核心SQL的執(zhí)行邏輯都寫進(jìn)了報(bào)告。對(duì)我自己而言把一個(gè)項(xiàng)目能講清楚比能寫出來(lái)更能檢驗(yàn)掌握程度。這套方法論也不局限在器材管理系統(tǒng)以后做任何管理系統(tǒng)訂單也好、圖書(shū)也好、設(shè)備也好底層的流程設(shè)計(jì)思路都是相通的。