“汝瓷博物館在線預(yù)約系統(tǒng)”這個(gè)題目一眼看過(guò)去就知道是典型的SpringBoot全棧實(shí)戰(zhàn)項(xiàng)目。每年畢業(yè)設(shè)計(jì)季預(yù)約類系統(tǒng)都能占掉半壁江山——景點(diǎn)預(yù)約、圖書館預(yù)約、健身房預(yù)約換湯不換藥。但把博物館和汝瓷文化主題加進(jìn)去這題就比普通的“某某管理系統(tǒng)的增刪改查”高了一截既有業(yè)務(wù)深度又能往數(shù)字化展館方向去延伸。我從實(shí)際開發(fā)的角度把這套系統(tǒng)從需求拆解到技術(shù)選型再到核心代碼和上線避坑完整捋一遍。你如果正在做類似的畢設(shè)或者想接一個(gè)預(yù)約類項(xiàng)目練手這篇內(nèi)容可以直接當(dāng)參考底稿。1. 項(xiàng)目到底在做什么需求拆解與業(yè)務(wù)價(jià)值先別急著寫代碼任何一個(gè)預(yù)約系統(tǒng)第一步都是把業(yè)務(wù)邏輯想明白。博物館預(yù)約系統(tǒng)和普通商品秒殺系統(tǒng)有相似之處但又有自己的特殊性。1.1 博物館預(yù)約系統(tǒng)的共性需求博物館類預(yù)約系統(tǒng)要解決的痛點(diǎn)其實(shí)就那么幾個(gè)限流控量、分時(shí)錯(cuò)峰、身份留痕、數(shù)據(jù)統(tǒng)計(jì)。博物館不像餐廳不是隨時(shí)來(lái)了就能進(jìn)出于文物保護(hù)和參觀體驗(yàn)的考慮館方必須控制同一時(shí)間在場(chǎng)館內(nèi)的人數(shù)。所以預(yù)約系統(tǒng)第一個(gè)核心功能就是“分時(shí)段預(yù)約”——比如上午場(chǎng)、下午場(chǎng)或者更細(xì)粒度到每個(gè)小時(shí)一個(gè)場(chǎng)次每場(chǎng)限定人數(shù)。第二個(gè)痛點(diǎn)是身份留痕。博物館需要知道今天來(lái)了多少人、誰(shuí)來(lái)了、從哪來(lái)一方面是安保需要另一方面也是觀眾畫像分析的數(shù)據(jù)來(lái)源。所以預(yù)約系統(tǒng)通常要求用戶注冊(cè)登錄填寫姓名、手機(jī)號(hào)、身份證號(hào)這些基礎(chǔ)信息預(yù)約成功后生成一個(gè)憑證碼入場(chǎng)時(shí)核銷。第三個(gè)痛點(diǎn)是信息觸達(dá)。觀眾在去之前需要知道開館時(shí)間、閉館日、當(dāng)前是否約滿、有什么特展、怎么去這些信息都需要通過(guò)系統(tǒng)統(tǒng)一發(fā)布。所以公告管理、展廳介紹、藏品展示本質(zhì)上都是在降低觀眾的認(rèn)知成本。1.2 汝瓷主題帶來(lái)的差異化設(shè)計(jì)“汝瓷”這兩個(gè)字是這個(gè)題目的靈魂。汝瓷是宋代五大名窯之首特點(diǎn)是“天青色釉、蟬翼紋開片”文化屬性非常強(qiáng)這意味著系統(tǒng)不能在功能上只是“通用預(yù)約”還要在內(nèi)容展示上做出文化數(shù)字展館的感覺(jué)。我建議把系統(tǒng)拆成兩條業(yè)務(wù)線一條是“票務(wù)預(yù)約線”解決進(jìn)館的問(wèn)題另一條是“數(shù)字展館線”解決云逛展的問(wèn)題。數(shù)字展館不是硬性需求但加上它整個(gè)項(xiàng)目的立意就上來(lái)了——你可以展示汝瓷藏品的高清圖片、文字介紹、語(yǔ)音講解甚至放一段展廳的VR漫游鏈接這在畢設(shè)答辯的時(shí)候非常加分。也就是說(shuō)這個(gè)系統(tǒng)的完整名字應(yīng)該是基于SpringBoot的汝瓷文化數(shù)字展館預(yù)約管理平臺(tái)。預(yù)約是核心業(yè)務(wù)數(shù)字展館是內(nèi)容載體兩者通過(guò)“用戶-藏品-展廳-預(yù)約記錄”這條數(shù)據(jù)鏈路串聯(lián)起來(lái)。1.3 畢設(shè)評(píng)委最看重的三個(gè)點(diǎn)從評(píng)審角度說(shuō)預(yù)約類項(xiàng)目最怕的就是做成了“純粹的增刪改查”。我見(jiàn)過(guò)太多同學(xué)用戶管理、預(yù)約管理、公告管理各做一套CRUD看起來(lái)功能齊全但問(wèn)到底層邏輯就露餡了。想讓這個(gè)題目有亮點(diǎn)重點(diǎn)卷這三個(gè)方向第一預(yù)約沖突與并發(fā)控制。同一個(gè)場(chǎng)次的余票從100變成0的過(guò)程中怎么保證兩個(gè)人不會(huì)同時(shí)約到最后一個(gè)名額這涉及到數(shù)據(jù)庫(kù)事務(wù)、樂(lè)觀鎖、唯一索引這些東西是評(píng)委最愛(ài)追問(wèn)的技術(shù)點(diǎn)。第二業(yè)務(wù)狀態(tài)機(jī)的完整性。一張預(yù)約單從頭到尾會(huì)經(jīng)歷“待支付/待審核-已預(yù)約-已核銷-已取消-已過(guò)期”這些狀態(tài)每個(gè)狀態(tài)之間的轉(zhuǎn)換規(guī)則是什么誰(shuí)有權(quán)限觸發(fā)轉(zhuǎn)換這是業(yè)務(wù)的靈魂。第三數(shù)據(jù)可視化和統(tǒng)計(jì)。館方登錄后臺(tái)最想知道的是今天預(yù)約了多少人、未來(lái)一周的預(yù)約趨勢(shì)怎么樣、哪個(gè)時(shí)段最受歡迎。能把這些用圖表展示出來(lái)項(xiàng)目的完整度立刻就不一樣了。2. 技術(shù)選型與實(shí)踐原則為什么用SpringBoot這套SpringBoot不是新技術(shù)但它依然是做這類系統(tǒng)最穩(wěn)的選擇。別的框架不是不好而是SpringBoot的工具鏈最全、資料最多、遇到問(wèn)題最容易找到答案。對(duì)畢設(shè)來(lái)說(shuō)“穩(wěn)”比“新”重要得多。2.1 后端主力SpringBoot MyBatis-Plus我建議后端直接用SpringBoot 2.7.x不要上SpringBoot 3.x。原因很簡(jiǎn)單3.x基于JDK17很多學(xué)校的實(shí)驗(yàn)環(huán)境還停留在JDK8而且3.x的某些第三方庫(kù)兼容性還需要額外處理犯不上為了追新給自己埋坑。ORM層我用的是MyBatis-Plus不是MyBatis原生的XML那一套。MyBatis-Plus的BaseMapper封裝了單表的CRUD配合條件構(gòu)造器QueryWrapper寫列表查詢和分頁(yè)基本不用手寫SQL。對(duì)一個(gè)預(yù)約系統(tǒng)來(lái)說(shuō)90%的查詢都是單表查詢加簡(jiǎn)單關(guān)聯(lián)MyBatis-Plus完全夠用而且大大縮短開發(fā)周期。數(shù)據(jù)庫(kù)選MySQL 5.7或8.0都行我習(xí)慣用5.7穩(wěn)。JDBC連接串上記得加幾個(gè)參數(shù)后面會(huì)細(xì)說(shuō)。2.2 擴(kuò)展點(diǎn)Flowable工作流引擎是否值得引入熱搜詞里有“springboot使用flowable”說(shuō)明不少同學(xué)已經(jīng)注意到工作流引擎這回事了。我的觀點(diǎn)很直接好奇可以但別硬上。Flowable是BPMN流程引擎適合審批鏈復(fù)雜、節(jié)點(diǎn)多、需要可視化編排流程的場(chǎng)景比如OA系統(tǒng)里的請(qǐng)假審批、報(bào)銷審批。但在博物館預(yù)約系統(tǒng)里核心流程其實(shí)是“用戶提交訂單-系統(tǒng)校驗(yàn)-自動(dòng)生成憑證”這個(gè)鏈路根本不需要人工審批節(jié)點(diǎn)用Flowable屬于殺雞用牛刀還平白增加學(xué)習(xí)成本和部署復(fù)雜度。如果你的導(dǎo)師明確要求你展示工作流能力可以這樣加把“團(tuán)體預(yù)約申請(qǐng)”做成需要館方人工審核的流程用戶提交團(tuán)體預(yù)約后流程進(jìn)入審核節(jié)點(diǎn)館方后臺(tái)審核通過(guò)后預(yù)約生效。這樣Flowable就有了合理的使用場(chǎng)景而不是硬塞進(jìn)去。但如果是自由發(fā)揮我建議用狀態(tài)字段 定時(shí)任務(wù)的方式實(shí)現(xiàn)一樣的效果。2.3 前端與運(yùn)維部分的最穩(wěn)選型前端不用想太復(fù)雜Vue2或Vue3配Element-UI就夠。用戶端做響應(yīng)式頁(yè)面移動(dòng)端優(yōu)先后臺(tái)管理端做桌面布局兩套頁(yè)面共用同一套后端API。如果不想寫頁(yè)面直接用Thymeleaf Bootstrap渲染服務(wù)端頁(yè)面也可以但前后端分離的架構(gòu)更適合在答辯時(shí)展示你的工程化思維。Redis要裝的話用來(lái)做驗(yàn)證碼存儲(chǔ)和防重復(fù)提交的分布式鎖。但考慮到很多同學(xué)的電腦上沒(méi)裝Redis我提供一個(gè)替代方案——先用本地緩存Caffeine接口設(shè)計(jì)上預(yù)留好Redis切換的位置。部署的時(shí)候后端打成jar包前端build成靜態(tài)文件后由Nginx托管MySQL單獨(dú)一臺(tái)或用本地整體下來(lái)一臺(tái)2核4G的云服務(wù)器綽綽有余。3. 功能模塊設(shè)計(jì)與數(shù)據(jù)庫(kù)表結(jié)構(gòu)功能模塊設(shè)計(jì)這塊我建議按“一個(gè)門戶 兩個(gè)中心”來(lái)劃分用戶門戶負(fù)責(zé)注冊(cè)登錄、展廳瀏覽、在線預(yù)約、個(gè)人訂單管理后臺(tái)負(fù)責(zé)藏品管理、公告管理、場(chǎng)次管理、預(yù)約審核與核銷、數(shù)據(jù)統(tǒng)計(jì)。每個(gè)模塊都不要貪多先保證流轉(zhuǎn)閉環(huán)。3.1 用戶端與后臺(tái)管理端功能拆分用戶端這一側(cè)核心是“快速預(yù)約”這條路徑。用戶進(jìn)來(lái)先看到的是展廳首頁(yè)和精品藏品推薦然后選擇參觀日期和場(chǎng)次系統(tǒng)立刻告訴他還有多少余票填寫參觀人信息提交后生成預(yù)約碼。整個(gè)流程最好不要超過(guò)三步每多一步用戶流失率就高一分。后臺(tái)管理端這一側(cè)按角色可以拆成管理員、審核員可選、講解員可選。管理員管全局能配置展廳場(chǎng)次、每日庫(kù)存、公告內(nèi)容審核員負(fù)責(zé)處理需要人工審核的預(yù)約單講解員可以維護(hù)藏品講解內(nèi)容。這里用Spring Security或Sa-Token做簡(jiǎn)單的RBAC權(quán)限控制給不同角色分配不同接口的訪問(wèn)權(quán)限也是個(gè)非常標(biāo)準(zhǔn)的加分點(diǎn)。3.2 核心數(shù)據(jù)模型與建表思路數(shù)據(jù)庫(kù)表設(shè)計(jì)是整個(gè)系統(tǒng)最不能偷懶的地方。我梳理一下核心表用戶表、藏品表、展廳表、場(chǎng)次表、預(yù)約單表、核銷記錄表、公告表。再簡(jiǎn)化一點(diǎn)展廳表和場(chǎng)次表可以合并成“參觀場(chǎng)次”一張表但展廳信息獨(dú)立出來(lái)會(huì)更清晰。用戶表的核心字段是用戶名、密碼BCrypt加密、姓名、手機(jī)號(hào)、身份證號(hào)、角色。密碼必須加密存儲(chǔ)這個(gè)在答辯時(shí)一定會(huì)被問(wèn)到。藏品表包含名稱、朝代、尺寸、文物編號(hào)、圖片URL、藏品故事、是否精品。汝瓷藏品的“文物編號(hào)”這個(gè)字段非常提氣模擬的是博物館真實(shí)的藏品賬目。場(chǎng)次表是預(yù)約系統(tǒng)的樞紐建議字段設(shè)計(jì)為展廳ID、參觀日期、開始時(shí)間、結(jié)束時(shí)間、總庫(kù)存、已約數(shù)量、狀態(tài)。日期和時(shí)段聯(lián)合起來(lái)就是一次可預(yù)約的資源。預(yù)約單表是這個(gè)系統(tǒng)的核心字段包括預(yù)約單號(hào)、用戶ID、場(chǎng)次ID、參觀人姓名、參觀人手機(jī)號(hào)、證件號(hào)碼、預(yù)約狀態(tài)、預(yù)約碼、下單時(shí)間。預(yù)約單號(hào)建議用“日期隨機(jī)串”生成方便查詢預(yù)約碼則用隨機(jī)UUID去掉橫杠后截取一段生成后把大寫字母和數(shù)字區(qū)分開避免手寫輸錯(cuò)。3.3 時(shí)段預(yù)約的庫(kù)存設(shè)計(jì)要點(diǎn)庫(kù)存和超賣問(wèn)題是整個(gè)系統(tǒng)的技術(shù)核心。我采用的設(shè)計(jì)思路是場(chǎng)次表里的“總庫(kù)存”和“已約數(shù)量”就是余票數(shù)據(jù)的唯一事實(shí)來(lái)源。用戶發(fā)起預(yù)約時(shí)后端先查一次場(chǎng)次庫(kù)存如果已約數(shù)量小于總庫(kù)存就執(zhí)行預(yù)約單插入同時(shí)把已約數(shù)量加一。這個(gè)流程如果分成“先查再更新”兩步在高并發(fā)下就會(huì)出問(wèn)題。兩個(gè)用戶同時(shí)查到已約數(shù)量是99總庫(kù)存是100兩個(gè)人都認(rèn)為還有票都去執(zhí)行預(yù)約單插入就超賣了。解決的辦法是加一個(gè)庫(kù)存扣減的原子操作UPDATE visit_session SET booked_count booked_count 1 WHERE id ? AND booked_count total_count這個(gè)SQL執(zhí)行后返回受影響行數(shù)如果為0說(shuō)明庫(kù)存不足直接拒絕。這就是典型的樂(lè)觀鎖思想不需要真的去寫悲觀鎖性能更好也足夠應(yīng)對(duì)畢設(shè)場(chǎng)景下的并發(fā)量。預(yù)約單表還要加一個(gè)唯一索引比如uk_id_card_session把證件號(hào)碼和場(chǎng)次ID做聯(lián)合唯一約束防止同一個(gè)人在同一場(chǎng)次重復(fù)預(yù)約。雙保險(xiǎn)兜底安全又可靠。序號(hào)表名用途核心約束1sys_user用戶與管理員賬號(hào)用戶名唯一2cultural_relic汝瓷藏品信息藏品編號(hào)唯一3visit_session參觀場(chǎng)次與庫(kù)存日期時(shí)段唯一4reservation_order預(yù)約單預(yù)約單號(hào)唯一/證件場(chǎng)次唯一5check_record入場(chǎng)核銷記錄核銷碼唯一6notice_info公告信息發(fā)布時(shí)間索引4. 核心流程的代碼級(jí)實(shí)現(xiàn)到這一步思路已經(jīng)通了剩下的就是落代碼。我挑幾個(gè)最核心的環(huán)節(jié)把實(shí)現(xiàn)思路和關(guān)鍵代碼貼出來(lái)。完整的代碼量很大這里只講骨架和關(guān)鍵點(diǎn)。4.1 預(yù)約提交接口的實(shí)現(xiàn)預(yù)約接口是整個(gè)系統(tǒng)的門面我按“校驗(yàn)參數(shù)-檢查庫(kù)存-扣減庫(kù)存-生成訂單-返回預(yù)約碼”的順序來(lái)寫。核心的Service方法如下Transactional(rollbackFor Exception.class) public ReservationResult createReservation(ReservationRequest request) { // 1. 校驗(yàn)場(chǎng)次是否存在且可預(yù)約 VisitSession session visitSessionMapper.selectById(request.getSessionId()); if (session null) { throw new BizException(參觀場(chǎng)次不存在); } // 2. 檢查場(chǎng)次是否處于開放預(yù)約狀態(tài) if (!OPEN.equals(session.getStatus())) { throw new BizException(該場(chǎng)次暫未開放預(yù)約); } // 3. 檢查是否重復(fù)預(yù)約同證件同場(chǎng)次 Integer cnt reservationOrderMapper.existReservation( request.getIdCard(), request.getSessionId(), Arrays.asList(BOOKED, PAID, CHECKED)); if (cnt 0) { throw new BizException(您已預(yù)約過(guò)該場(chǎng)次請(qǐng)勿重復(fù)提交); } // 4. 原子扣減庫(kù)存 int affected visitSessionMapper.decreaseStock(session.getId()); if (affected 0) { throw new BizException(該場(chǎng)次余票不足請(qǐng)選擇其他場(chǎng)次); } // 5. 生成預(yù)約單 ReservationOrder order new ReservationOrder(); order.setOrderNo(generateOrderNo()); order.setUserId(request.getUserId()); order.setSessionId(session.getId()); order.setVisitorName(request.getVisitorName()); order.setVisitorPhone(request.getVisitorPhone()); order.setIdCard(request.getIdCard()); order.setStatus(BOOKED); order.setReservationCode(generateReservationCode()); reservationOrderMapper.insert(order); return new ReservationResult(order.getOrderNo(), order.getReservationCode()); }decreaseStock的SQL是防超賣的關(guān)鍵我只更新庫(kù)存還有余量的那一條記錄。這里別用“先查后改”也別在代碼里做同步鎖數(shù)據(jù)庫(kù)原子更新才是正解。update iddecreaseStock UPDATE visit_session SET booked_count booked_count 1 WHERE id #{sessionId} AND booked_count lt; total_count /update4.2 防重復(fù)預(yù)約與冪等處理除了數(shù)據(jù)庫(kù)唯一索引接口層也要做防重復(fù)處理。按鈕的雙擊、前端網(wǎng)絡(luò)重試很容易造成一條記錄被插兩次。除了剛才唯一索引的兜底建議前端在提交后立刻置灰按鈕后端則在預(yù)約接口上加一個(gè)簡(jiǎn)單的冪等機(jī)制。我的做法是用Redis或本地緩存存一個(gè)“用戶ID場(chǎng)次ID”的短時(shí)key有效期設(shè)置為30秒。請(qǐng)求進(jìn)來(lái)時(shí)先嘗試寫入這個(gè)key如果寫入失敗說(shuō)明這段時(shí)間已經(jīng)提交過(guò)了直接拒絕。// key: reservation:dup:userId:sessionId Boolean first stringRedisTemplate.opsForValue() .setIfAbsent(key, 1, Duration.ofSeconds(30)); if (Boolean.FALSE.equals(first)) { throw new BizException(請(qǐng)勿重復(fù)提交預(yù)約請(qǐng)求); }這套方案寫起來(lái)簡(jiǎn)單但能擋住絕大多數(shù)重復(fù)請(qǐng)求。注意在事務(wù)提交之后再把key刪除避免用戶訂單一成功、key還存在導(dǎo)致短時(shí)間內(nèi)的再次預(yù)約被誤攔。4.3 預(yù)約審核與狀態(tài)流轉(zhuǎn)預(yù)約狀態(tài)我設(shè)計(jì)了五個(gè)BOOKED待核銷、CANCELLED已取消、CHECKED已核銷、EXPIRED已過(guò)期、REJECTED已拒絕。展館預(yù)約一般不需要支付所以省去支付狀態(tài)但保留一個(gè)待支付狀態(tài)也行看你的業(yè)務(wù)擴(kuò)展需求。狀態(tài)流轉(zhuǎn)的核心邏輯寫在ReservationOrderService里不希望在Controller里到處散落狀態(tài)判斷。用戶端可以取消自己的預(yù)約“已取消”后必須回補(bǔ)場(chǎng)次庫(kù)存這個(gè)回補(bǔ)操作也要用類似的原子更新SQL防止高并發(fā)下庫(kù)存不一致。管理員核銷時(shí)先校驗(yàn)預(yù)約碼是否存在且狀態(tài)為BOOKED核銷成功后把狀態(tài)置為CHECKED同時(shí)生成核銷記錄。核銷是線下閘機(jī)場(chǎng)景可以用簡(jiǎn)單的手機(jī)號(hào)預(yù)約碼查詢來(lái)實(shí)現(xiàn)。還有一個(gè)很實(shí)用但大家容易忘的功能定時(shí)任務(wù)掃描超過(guò)預(yù)約日期還未核銷的預(yù)約單把狀態(tài)置為EXPIRED。用Spring的Scheduled注解就能做每天凌晨跑一次字段就查visit_date CURDATE() AND status BOOKED狀態(tài)置為過(guò)期的同時(shí)也要回補(bǔ)庫(kù)存這里要注意過(guò)期回補(bǔ)庫(kù)存會(huì)讓歷史數(shù)據(jù)變得不準(zhǔn)確因?yàn)槟莻€(gè)場(chǎng)次已經(jīng)過(guò)去了定義上就不存在“還能再約”的說(shuō)法。所以過(guò)期單只用來(lái)統(tǒng)計(jì)不用回補(bǔ)庫(kù)存切記。4.4 讓數(shù)字展館“活”起來(lái)藏品列表與詳情接口藏品展示涉及圖片較多接口不需要做太復(fù)雜列表接口支持分頁(yè)和分類篩選詳情接口把指定藏品的完整信息返回。這里有一個(gè)技巧不要每次都全表查詢給category字段建索引列表查詢用MyBatis-Plus的分頁(yè)插件。public PageResultCulturalRelicVO pageRelic(int page, int size, String category) { LambdaQueryWrapperCulturalRelic wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.hasText(category), CulturalRelic::getCategory, category); wrapper.orderByAsc(CulturalRelic::getSortOrder); PageCulturalRelic pageData culturalRelicMapper.selectPage(new Page(page, size), wrapper); // 轉(zhuǎn)VO把detail字段在列表接口中置空減少大字段傳輸 }這里說(shuō)個(gè)經(jīng)驗(yàn)列表接口和詳情接口一定要分開列表只返回封面圖和標(biāo)題詳情才返回完整介紹不然列表接口會(huì)很慢前端也會(huì)卡。圖片建議用對(duì)象存儲(chǔ)或者放到單獨(dú)的靜態(tài)目錄用/upload/relic/汝窯天青釉xxx.jpg這樣的URL路徑來(lái)訪問(wèn)不要把圖片以base64形式塞進(jìn)數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)會(huì)被打爆查詢速度也直線下降。5. 部署上線與常見(jiàn)問(wèn)題排查實(shí)錄最后一個(gè)部分聊聊環(huán)境和部署。這個(gè)系統(tǒng)的坑我踩過(guò)一遍最大的幾個(gè)問(wèn)題往往不在業(yè)務(wù)代碼而在環(huán)境配置和基礎(chǔ)細(xì)節(jié)。5.1 本地開發(fā)環(huán)境搭建開發(fā)環(huán)境我建議用三個(gè)東西IDEA寫后端、Navicat操作數(shù)據(jù)庫(kù)、Postman或Apifox測(cè)接口。JDK用1.8Maven用3.6SpringBoot 2.7.18、MySQL 5.7這套組合兼容性最好。用IDEA初始化項(xiàng)目時(shí)直接去Spring Initializr選依賴Spring Web、MyBatis-Plus手動(dòng)加坐標(biāo)也行、MySQL Driver、Lombok、Validation。Redis如果裝了再加Spring Data Redis。重點(diǎn)提醒MyBatis-Plus和SpringBoot版本要匹配老版本MyBatis-Plus在SpringBoot 2.7下分頁(yè)插件會(huì)被禁用需要用較新的3.5.x版本。5.2 常見(jiàn)問(wèn)題速查表我整理了預(yù)約類系統(tǒng)最常踩的六個(gè)問(wèn)題和對(duì)應(yīng)的排查方法問(wèn)題現(xiàn)象排查思路解決建議接口返回500錯(cuò)誤打開控制臺(tái)看異常棧多半是SQL語(yǔ)法或空指針先看Mapper XML里的SQL和if條件拼接是否正常數(shù)據(jù)庫(kù)中文亂碼MySQL連接串沒(méi)帶編碼參數(shù)JDBC地址末尾加?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai前端拿到的時(shí)間比實(shí)際少8小時(shí)JSON序列化時(shí)區(qū)問(wèn)題在application.yml里設(shè)置spring.jackson.time-zoneGMT8跨域請(qǐng)求被攔截前后端分離端口不一致寫一個(gè)CorsConfig配置類允許前端地址跨域預(yù)約接口偶發(fā)超賣沒(méi)有做原子扣減用UPDATE ... SET booked_count booked_count 1 WHERE booked_count total_count明明登錄了接口還是返回401Token沒(méi)傳到后端或攔截器路徑配置錯(cuò)檢查Axios請(qǐng)求攔截器是否在Header里帶上了Token5.3 答辯時(shí)容易被問(wèn)到的問(wèn)題這個(gè)系統(tǒng)做完答辯的時(shí)候有幾個(gè)問(wèn)題你一定會(huì)被問(wèn)到提前把答案準(zhǔn)備好第一個(gè)“為什么字段要用枚舉狀態(tài)不用布爾值”答隨著業(yè)務(wù)復(fù)雜度上升那些狀態(tài)不只是是和否比如預(yù)約單有已預(yù)約、已取消、已核銷、已過(guò)期、已拒絕用字符串狀態(tài)加校驗(yàn)規(guī)則更清晰也方便以后擴(kuò)展。第二個(gè)“MySQL和Redis的數(shù)據(jù)如何保持一致”答核心預(yù)約數(shù)據(jù)在MySQL里Redis只用于驗(yàn)證碼和不重要的臨時(shí)緩存即使Redis掛了也不影響主要業(yè)務(wù)流程。第三個(gè)“如何應(yīng)對(duì)大量用戶同時(shí)搶一個(gè)時(shí)段的票”答數(shù)據(jù)庫(kù)原子扣減庫(kù)存加唯一索引兜底必要時(shí)可以在場(chǎng)次維度加分布式鎖但核心原則是“庫(kù)存扣減必須和預(yù)約單創(chuàng)建在同一個(gè)事務(wù)里”。第四個(gè)“系統(tǒng)的安全性怎么保障”答用戶密碼用BCrypt加密登錄接口增加驗(yàn)證碼校驗(yàn)通過(guò)HandlerInterceptor攔截未登錄請(qǐng)求關(guān)鍵數(shù)據(jù)做參數(shù)校驗(yàn)和SQL注入防護(hù)。寫在最后整個(gè)項(xiàng)目做下來(lái)我最大的感受是預(yù)約系統(tǒng)的技術(shù)難點(diǎn)不在某個(gè)單獨(dú)的功能上而在“狀態(tài)、庫(kù)存、權(quán)限”這條暗線里。你只要把狀態(tài)流轉(zhuǎn)理清楚、把庫(kù)存扣減做對(duì)、把角色權(quán)限分明白再樸素的技術(shù)選型也能做出一個(gè)完整度很高的畢業(yè)設(shè)計(jì)。汝瓷這個(gè)主題好好在藏品展示和數(shù)字展館上做點(diǎn)文章你的項(xiàng)目就能從一批“圖書管理系統(tǒng)”里面跳出來(lái)讓評(píng)委覺(jué)得你確實(shí)是在做“系統(tǒng)”而不只是在“交作業(yè)”。最后再分享一個(gè)小技巧答辯演示的時(shí)候千萬(wàn)不要只對(duì)著IDE講代碼先用瀏覽器完整跑一遍“注冊(cè)-登錄-選場(chǎng)次-預(yù)約成功-后臺(tái)核銷-數(shù)據(jù)統(tǒng)計(jì)”這條主鏈路讓評(píng)委看到系統(tǒng)是能用的再去講代碼亮點(diǎn)效果會(huì)好非常多。