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