做自習(xí)室預(yù)約系統(tǒng)這件事我前后折騰了大半個(gè)月踩了不少坑也積累了不少心得。這個(gè)基于SpringBoot Vue的MVC自習(xí)室管理和預(yù)約系統(tǒng)大概是很多計(jì)算機(jī)專(zhuān)業(yè)同學(xué)畢業(yè)設(shè)計(jì)或課程項(xiàng)目的熱門(mén)選題也是很多小型創(chuàng)業(yè)團(tuán)隊(duì)做共享空間管理時(shí)愿意參考的一套基礎(chǔ)架子。今天我把整套系統(tǒng)的設(shè)計(jì)思路、核心代碼、數(shù)據(jù)庫(kù)方案和部署細(xì)節(jié)完整梳理一遍特別是那些網(wǎng)上教程一般不會(huì)主動(dòng)告訴你的坑都一并寫(xiě)出來(lái)。這套系統(tǒng)能做什么簡(jiǎn)單說(shuō)就是三件事管理自習(xí)室和座位信息、讓用戶在線預(yù)約座位、提供后臺(tái)的數(shù)據(jù)統(tǒng)計(jì)和基礎(chǔ)管理能力。技術(shù)棧非常經(jīng)典后端SpringBoot MyBatis MySQL前端Vue Vue Router Axios整體遵循MVC分層思想。適合正在做課設(shè)、畢設(shè)的學(xué)生也適合想快速搭一套輕量級(jí)預(yù)約系統(tǒng)的開(kāi)發(fā)者。1. 為什么做這個(gè)系統(tǒng)需求拆解與技術(shù)選型1.1 自習(xí)室預(yù)約到底解決了什么問(wèn)題去圖書(shū)館或者付費(fèi)自習(xí)室搶座位的經(jīng)歷相信不少人都有過(guò)。傳統(tǒng)方式要么是線下排隊(duì)登記要么是微信群接龍?jiān)僭家稽c(diǎn)就是放一張紙自己簽名。這些問(wèn)題很典型座位狀態(tài)不透明去了才發(fā)現(xiàn)滿座管理員無(wú)法實(shí)時(shí)掌握使用率座位長(zhǎng)期被占但沒(méi)人來(lái)用戶和管理員之間信息斷層投訴和糾紛不少。所以我做的這套系統(tǒng)核心就是解決三個(gè)問(wèn)題座位資源可視化、預(yù)約流程線上化、管理數(shù)據(jù)可統(tǒng)計(jì)。用戶端看到的是一個(gè)座位圖哪些座位空閑、哪些被占一目了然預(yù)約操作點(diǎn)幾下就能完成取消、續(xù)約也能自助處理。管理員端則能看每日預(yù)約量、座位利用率、用戶活躍度這些關(guān)鍵指標(biāo)不用再靠Excel手工統(tǒng)計(jì)。系統(tǒng)角色劃分也很清晰普通用戶負(fù)責(zé)預(yù)約、取消、查看個(gè)人記錄管理員負(fù)責(zé)自習(xí)室和座位維護(hù)、預(yù)約審核或關(guān)閉、查看統(tǒng)計(jì)報(bào)表。這套R(shí)BAC基于角色的訪問(wèn)控制模型不復(fù)雜但足夠支撐起一個(gè)完整的業(yè)務(wù)閉環(huán)。1.2 SpringBoot Vue MyBatis MySQL這套組合的取舍我在一開(kāi)始也糾結(jié)過(guò)技術(shù)選型。Node.js Express做后端Python Django最終還是選了SpringBoot這套組合理由非常實(shí)際。SpringBoot是目前國(guó)內(nèi)企業(yè)級(jí)開(kāi)發(fā)占有率最高的框架之一。它最核心的價(jià)值就是簡(jiǎn)化配置內(nèi)嵌Tomcat一個(gè)jar包就能跑起來(lái)不需要額外部署WAR包。配合Maven或Gradle管理依賴幾行配置就能集成MyBatis、MySQL、Redis這些中間件。對(duì)于校內(nèi)項(xiàng)目或者中小團(tuán)隊(duì)來(lái)說(shuō)SpringBoot的學(xué)習(xí)資料最豐富遇到問(wèn)題的解決方案也最多這個(gè)優(yōu)勢(shì)在開(kāi)發(fā)中非常實(shí)際。Vue選擇的是Vue 2還是Vue 3我建議新項(xiàng)目直接上Vue 3 Composition API。2025年這個(gè)時(shí)間點(diǎn)Vue 2已經(jīng)停止維護(hù)了生態(tài)里新的UI庫(kù)也基本都適配Vue 3。Vue全家桶里真正開(kāi)發(fā)必須掌握的就三樣Vue Router負(fù)責(zé)頁(yè)面路由Pinia或Vuex負(fù)責(zé)狀態(tài)管理Axios負(fù)責(zé)和后端接口通信。MyBatis和MySQL的組合更是經(jīng)典中的經(jīng)典。MySQL是開(kāi)源關(guān)系型數(shù)據(jù)庫(kù)里生態(tài)最成熟的安裝部署簡(jiǎn)單性能足夠中小規(guī)模應(yīng)用使用而且和SpringBoot整合非常順滑。MyBatis則讓你保持對(duì)SQL的完全控制權(quán)復(fù)雜查詢不會(huì)被ORM框架的限制卡住。有些人會(huì)問(wèn)為什么不用MyBatis-Plus我這里用原生的MyBatis是為了把XML映射和動(dòng)態(tài)SQL這些底層機(jī)制講清楚理解了這一層再上手MyBatis-Plus就是一天的事。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與核心表結(jié)構(gòu)2.1 核心數(shù)據(jù)表用戶、自習(xí)室、座位、預(yù)約單數(shù)據(jù)庫(kù)設(shè)計(jì)是這套系統(tǒng)的地基表結(jié)構(gòu)設(shè)計(jì)得好不好直接影響后續(xù)業(yè)務(wù)邏輯的復(fù)雜度。我設(shè)計(jì)的核心表一共有五張用戶表、自習(xí)室表、座位表、預(yù)約單表還有一張管理員表。下面把每張表的重點(diǎn)字段講清楚。用戶表比較常規(guī)重點(diǎn)字段有id、用戶名、密碼BCrypt加密存儲(chǔ)、手機(jī)號(hào)、角色標(biāo)識(shí)user/admin、狀態(tài)字段和創(chuàng)建時(shí)間。密碼一定不能明文存儲(chǔ)這個(gè)是最基本的安全底線。狀態(tài)字段用來(lái)表示賬號(hào)是否被凍結(jié)方便管理員做限制。自習(xí)室表相對(duì)簡(jiǎn)單一個(gè)自習(xí)室包含名稱、位置、開(kāi)放時(shí)間、座位總數(shù)、描述信息。這里有個(gè)小設(shè)計(jì)點(diǎn)座位總數(shù)不要冗余存儲(chǔ)而是通過(guò)統(tǒng)計(jì)座位表中某個(gè)自習(xí)室id的數(shù)量實(shí)時(shí)計(jì)算。如果你想優(yōu)化查詢性能可以在自習(xí)室表里加一個(gè)total_seats字段做冗余但要注意維護(hù)數(shù)據(jù)一致性。座位表是整套系統(tǒng)的核心字段包括id、自習(xí)室id、座位編號(hào)自習(xí)室內(nèi)唯一、座位類(lèi)型比如單人桌、雙人桌、靠窗座位、安靜區(qū)座位等還有座位狀態(tài)和座位坐標(biāo)等。為什么加坐標(biāo)字段因?yàn)榍岸艘秩咀粓D沒(méi)有坐標(biāo)你就無(wú)法準(zhǔn)確把座位畫(huà)在對(duì)應(yīng)位置上。預(yù)約單表字段最多也是最容易設(shè)計(jì)出錯(cuò)的一張表。核心字段有預(yù)約單號(hào)業(yè)務(wù)編號(hào)方便人工核驗(yàn)、用戶id、自習(xí)室id、座位id、預(yù)約日期、開(kāi)始時(shí)間、結(jié)束時(shí)間、狀態(tài)字段待使用/已使用/已取消/已過(guò)期等、創(chuàng)建時(shí)間。這里要特別強(qiáng)調(diào)一個(gè)設(shè)計(jì)經(jīng)驗(yàn)業(yè)務(wù)上需要向用戶展示的編號(hào)和數(shù)據(jù)庫(kù)主鍵id一定要分開(kāi)。數(shù)據(jù)庫(kù)主鍵autoincrement的id不要直接暴露給用戶因?yàn)闀?huì)泄露系統(tǒng)數(shù)據(jù)量也容易被人遍歷接口。2.2 座位狀態(tài)與預(yù)約狀態(tài)的流轉(zhuǎn)設(shè)計(jì)狀態(tài)設(shè)計(jì)是最容易做亂的環(huán)節(jié)。我前后改了三版才理清。核心思路是把座位狀態(tài)和預(yù)約狀態(tài)拆開(kāi)不能混在一起。座位只有三種狀態(tài)空閑、占用、禁用。占用表示這個(gè)座位在當(dāng)前時(shí)間段被預(yù)約了禁用是管理員手動(dòng)關(guān)閉某些座位比如空調(diào)壞了、燈管不亮臨時(shí)維修。這里有一個(gè)非常容易掉坑的地方座位本身沒(méi)有“時(shí)間”的概念。同一個(gè)座位早上可能是空閑的下午可能是占用的。所以我用的是預(yù)約記錄來(lái)反推座位狀態(tài)而不是在座位表上存一個(gè)update_status_time字段。座位表上的status字段更準(zhǔn)確說(shuō)是“運(yùn)營(yíng)狀態(tài)”可用或禁用。真正的實(shí)時(shí)占用狀態(tài)由一個(gè)視圖或查詢接口動(dòng)態(tài)計(jì)算當(dāng)前時(shí)間范圍內(nèi)是否存在未取消的預(yù)約記錄。預(yù)約狀態(tài)我設(shè)計(jì)了四個(gè)待使用、已完成、已取消、爽約。待使用是預(yù)約成功但還沒(méi)到時(shí)間已完成是使用時(shí)間結(jié)束后系統(tǒng)自動(dòng)更新或管理員手動(dòng)確認(rèn)已取消是用戶主動(dòng)取消爽約則定義了這樣一個(gè)規(guī)則預(yù)約時(shí)間開(kāi)始后30分鐘內(nèi)未簽到自動(dòng)標(biāo)記為爽約。這套狀態(tài)機(jī)看似簡(jiǎn)單但最終落庫(kù)的時(shí)候要注意狀態(tài)字段不要用數(shù)字盡量用字符串varchar存英文枚舉值比如BOOKED、FINISHED、CANCELLED、NO_SHOW。項(xiàng)目組里新人接手時(shí)看到字符串狀態(tài)一看就懂看到0和1還得猜含義。2.3 并發(fā)防超賣(mài)唯一約束與樂(lè)觀鎖并發(fā)問(wèn)題是在做預(yù)約系統(tǒng)時(shí)最需要提前思考的地方。多個(gè)用戶同時(shí)點(diǎn)擊同一個(gè)座位的預(yù)約按鈕如果處理不當(dāng)就可能出現(xiàn)“超賣(mài)”——一個(gè)座位同一時(shí)間被預(yù)約給多個(gè)人。我用了三層機(jī)制解決這個(gè)問(wèn)題。第一層是數(shù)據(jù)庫(kù)唯一約束。在預(yù)約單表上建一個(gè)聯(lián)合唯一索引字段組合是seat_id 預(yù)約日期開(kāi)始時(shí)間。這樣數(shù)據(jù)庫(kù)層面就保證了同一座位在同一時(shí)段只能有一條有效預(yù)約記錄。只要用戶取消預(yù)約原記錄變成取消狀態(tài)新預(yù)約才能再次插入。要注意唯一索引必須帶上狀態(tài)條件嗎MySQL不支持函數(shù)索引的寫(xiě)法比較復(fù)雜所以我的做法是取消的記錄不物理刪除但預(yù)約唯一索引只約束status為生效狀態(tài)的記錄。怎么實(shí)現(xiàn)這就要用到MyBatis動(dòng)態(tài)SQL插入前先執(zhí)行一個(gè)“活性檢查”查詢確認(rèn)該座位該時(shí)間段沒(méi)有狀態(tài)為待使用/已使用的記錄再執(zhí)行插入。數(shù)據(jù)庫(kù)唯一索引用來(lái)做最后一道兜底它能攔截掉極短時(shí)間內(nèi)出現(xiàn)的并發(fā)沖突。第二層是業(yè)務(wù)層面的互斥鎖。我選擇在Service層中使用synchronized關(guān)鍵字按座位維度加鎖——更嚴(yán)謹(jǐn)?shù)淖龇ㄊ鞘褂脭?shù)據(jù)庫(kù)的悲觀鎖SELECT ... FOR UPDATE鎖住座位表的行再執(zhí)行插入。但由于自習(xí)室預(yù)約場(chǎng)景并發(fā)量不會(huì)特別高synchronized鎖綁定座位id字符串的intern方法即可滿足需求。不過(guò)使用synchronized注意鎖的粒度要細(xì)不要鎖整個(gè)方法否則所有座位的預(yù)約都會(huì)互相阻塞性能瞬間崩掉。第三層是兜底的異常處理。即使前面兩層都過(guò)去了最后一步插入時(shí)如果唯一索引沖突拋了DuplicateKeyException也要捕獲這個(gè)異常并轉(zhuǎn)成友好的業(yè)務(wù)提示“該座位已被手速更快的小伙伴預(yù)約了”。用戶看到這個(gè)提示體驗(yàn)還算可以不會(huì)覺(jué)得自己點(diǎn)了個(gè)假按鈕。3. 后端MVC架構(gòu)落地與關(guān)鍵代碼解析3.1 項(xiàng)目分層Controller、Service、Mapper到底各管什么MVC三層架構(gòu)在SpringBoot項(xiàng)目里已經(jīng)演化成更細(xì)的分層Controller層、Service層、Mapper層再外加一個(gè)entity/model層放實(shí)體類(lèi)dto層放參數(shù)對(duì)象vo層放返回結(jié)果對(duì)象。很多人剛學(xué)的時(shí)候容易把Controller寫(xiě)成“萬(wàn)能類(lèi)”所有邏輯都塞里面這是典型的錯(cuò)誤姿勢(shì)。我的分包結(jié)構(gòu)是標(biāo)準(zhǔn)做法直接照著建就行com.studyroom ├── controller // 接口層接收請(qǐng)求、校驗(yàn)參數(shù)、返回結(jié)果 ├── service // 業(yè)務(wù)層處理核心邏輯、事務(wù)控制 │ └── impl ├── mapper // MyBatis的數(shù)據(jù)訪問(wèn)接口 ├── entity // 數(shù)據(jù)庫(kù)表對(duì)應(yīng)的實(shí)體類(lèi) ├── dto // 接收前端參數(shù)的傳輸對(duì)象 ├── vo // 返回給前端的結(jié)果封裝 ├── config // 配置類(lèi)比如跨域配置、攔截器配置 ├── common // 通用類(lèi)統(tǒng)一返回結(jié)果、異常處理、常量 └── utils // 工具類(lèi)Controller層只做三件事接收參數(shù)、調(diào)用Service、返回統(tǒng)一結(jié)果對(duì)象。它不應(yīng)該出現(xiàn)任何具體的業(yè)務(wù)判斷邏輯。比如預(yù)約請(qǐng)求進(jìn)入Controller后它要做的就是把預(yù)約參數(shù)綁定成一個(gè)DTO類(lèi)傳給Service然后返回Result.success(data)。至于校驗(yàn)座位是否存在、時(shí)間是否合法、用戶是否重復(fù)預(yù)約這些全在Service里完成。Service層是業(yè)務(wù)邏輯的核心所有判斷、計(jì)算、狀態(tài)流轉(zhuǎn)都在這層完成。這里有件事需要注意涉及多表更新的操作比如取消預(yù)約需要同時(shí)修改預(yù)約狀態(tài)、更新座位運(yùn)營(yíng)狀態(tài)、可能要寫(xiě)一條操作日志必須在Service方法上標(biāo)注Transactional。否則就算第一句SQL執(zhí)行成功第二句報(bào)錯(cuò)數(shù)據(jù)庫(kù)留下臟數(shù)據(jù)排查起來(lái)極其痛苦。Mapper層就純粹是數(shù)據(jù)訪問(wèn)。接口方法的注解或XML里的SQL只負(fù)責(zé)和數(shù)據(jù)庫(kù)打交道不做運(yùn)算不做判斷把查詢結(jié)果原樣返回。我在項(xiàng)目里統(tǒng)一使用XML文件寫(xiě)SQL因?yàn)閯?dòng)態(tài)SQL標(biāo)簽如if、where、foreach在XML里可讀性更高復(fù)雜聯(lián)表查詢也好維護(hù)。簡(jiǎn)單的單表查詢用注解Select也可以但為了風(fēng)格統(tǒng)一我全部走了XML。3.2 MyBatis的XML映射與動(dòng)態(tài)SQLMyBatis的XML文件是這個(gè)項(xiàng)目里一眼看上去最繁瑣、但實(shí)際最靈活的部分。它最大的優(yōu)勢(shì)就是動(dòng)態(tài)SQL。比如管理員在后臺(tái)篩選預(yù)約記錄會(huì)有多個(gè)篩選條件按狀態(tài)查、按日期查、按自習(xí)室查、按用戶手機(jī)號(hào)查。這些條件組合起來(lái)可能幾十種情況如果全寫(xiě)死在Java代碼里那打補(bǔ)丁得累死。我的做法是這樣的用一個(gè)Map或一個(gè)DTO接收所有查詢參數(shù)然后在XML里用where標(biāo)簽if標(biāo)簽動(dòng)態(tài)拼接。這樣當(dāng)某個(gè)參數(shù)為空時(shí)對(duì)應(yīng)的SQL條件片段就不會(huì)拼進(jìn)去查詢語(yǔ)句會(huì)自適應(yīng)變化。下面是一個(gè)預(yù)約記錄分頁(yè)查詢的XML片段select idselectReservationPage resultTypecom.studyroom.vo.ReservationVO SELECT r.id, r.reservation_no, r.room_id, r.seat_id, r.user_id, u.username, u.phone, r.reserve_date, r.start_time, r.end_time, r.status, r.create_time FROM reservation r LEFT JOIN user u ON r.user_id u.id where if teststatus ! null and status ! AND r.status #{status} /if if testroomId ! null AND r.room_id #{roomId} /if if testreserveDate ! null AND r.reserve_date #{reserveDate} /if if testkeyword ! null and keyword ! AND (u.username LIKE CONCAT(%, #{keyword}, %) OR u.phone LIKE CONCAT(%, #{keyword}, %)) /if /where ORDER BY r.create_time DESC LIMIT #{offset}, #{pageSize} /select這里有個(gè)細(xì)節(jié)值得留意LIKE查詢的寫(xiě)法。我之前見(jiàn)過(guò)有人直接在Java代碼里拼好%...%再傳到SQL里這樣也work但存在注入風(fēng)險(xiǎn)。用CONCAT函數(shù)在SQL層拼接更安全。LIMIT后面的offset和pageSize用#{}參數(shù)占位MyBatis會(huì)自動(dòng)做預(yù)編譯防SQL注入。這一點(diǎn)是面試高頻考點(diǎn)也是實(shí)際開(kāi)發(fā)必須養(yǎng)成的好習(xí)慣。另外resultType和resultMap的選擇上我大部分聯(lián)表查詢用resultType直接映射到VO對(duì)象只要數(shù)據(jù)庫(kù)字段名和VO屬性名通過(guò)下劃線轉(zhuǎn)駝峰映射就能對(duì)上。需要在application.yml里開(kāi)啟map-underscore-to-camel-case: true這個(gè)配置。3.3 預(yù)約與取消預(yù)約的接口實(shí)現(xiàn)預(yù)約接口是整個(gè)系統(tǒng)最核心的接口它的實(shí)現(xiàn)邏輯我拆成了五個(gè)步驟參數(shù)校驗(yàn)、重復(fù)檢查、沖突檢查、座位狀態(tài)檢查、插入預(yù)約單。下面把關(guān)鍵代碼的思維流程講一遍。參數(shù)校驗(yàn)階段要檢查必傳字段用戶id、自習(xí)室id、座位id、預(yù)約日期、開(kāi)始時(shí)間和結(jié)束時(shí)間。開(kāi)始時(shí)間必須早于結(jié)束時(shí)間預(yù)約日期不能是過(guò)去日期。這些校驗(yàn)放在Service里能保證即使繞過(guò)前端校驗(yàn)也攔得住。重復(fù)檢查就是檢查同一個(gè)用戶同一個(gè)時(shí)間段內(nèi)是否已經(jīng)有預(yù)約。規(guī)則可以做成一個(gè)用戶同一時(shí)間段只能有一個(gè)有效預(yù)約避免“占著茅坑不拉屎”的惡意預(yù)約行為。沖突檢查則查座位在目標(biāo)時(shí)間段是否已有其他用戶的預(yù)約。座位狀態(tài)檢查要查座位的運(yùn)營(yíng)狀態(tài)是否可用。如果這個(gè)座位被管理員標(biāo)記為禁用那預(yù)約請(qǐng)求要直接拒絕。最后一步才是生成預(yù)約單狀態(tài)設(shè)為待使用同時(shí)返回給前端一個(gè)預(yù)約成功的提示和預(yù)約單號(hào)。取消預(yù)約的邏輯相對(duì)簡(jiǎn)單但要仔細(xì)考慮時(shí)間限制。我設(shè)定的規(guī)則是預(yù)約開(kāi)始時(shí)間前30分鐘允許取消已經(jīng)超過(guò)時(shí)間就只能走“超時(shí)未到”流程。這里有一個(gè)特殊處理取消操作要同步做兩件事改預(yù)約單狀態(tài)為已取消同時(shí)如果當(dāng)前沒(méi)有其他預(yù)約占用該座位座位狀態(tài)恢復(fù)為空閑。為了讓讀者更好理解我把核心的Service方法偽代碼寫(xiě)出來(lái)Override Transactional(rollbackFor Exception.class) public ReservationResponse reserve(ReserveRequest request) { // 1. 參數(shù)校驗(yàn) if (request.getStartTime().compareTo(request.getEndTime()) 0) { throw new BizException(開(kāi)始時(shí)間必須早于結(jié)束時(shí)間); } // 2. 檢查用戶是否已有沖突預(yù)約 int count reservationMapper.checkUserConflict( request.getUserId(), request.getReserveDate(), request.getStartTime(), request.getEndTime()); if (count 0) { throw new BizException(你已有同時(shí)段的預(yù)約記錄); } // 3. 檢查座位是否可用 Seat seat seatMapper.selectById(request.getSeatId()); if (seat null || SeatStatus.DISABLED.getCode().equals(seat.getStatus())) { throw new BizException(座位不可用); } // 4. 檢查座位同一時(shí)段沖突 int seatConflict reservationMapper.checkSeatConflict( request.getSeatId(), request.getReserveDate(), request.getStartTime(), request.getEndTime()); if (seatConflict 0) { throw new BizException(該座位當(dāng)前時(shí)段已被預(yù)約); } // 5. 生成預(yù)約單 Reservation reservation new Reservation(); reservation.setReservationNo(generateReservationNo()); // ... set other fields reservationMapper.insert(reservation); return ReservationResponse.from(reservation); }generateReservationNo我是這樣生成的每天日期字符串加六位隨機(jī)數(shù)比如20250601 823471。加上唯一索引防止極端情況下兩個(gè)單號(hào)撞車(chē)。這個(gè)單號(hào)的價(jià)值主要體現(xiàn)在線下場(chǎng)景自習(xí)室管理員看到單號(hào)就能快速在系統(tǒng)里查到對(duì)應(yīng)預(yù)約比用數(shù)據(jù)庫(kù)id好太多。4. Vue前端實(shí)現(xiàn)與交互細(xì)節(jié)4.1 項(xiàng)目初始化與路由設(shè)計(jì)前端用Vue腳手架創(chuàng)建項(xiàng)目后首先要裝依賴vue-router負(fù)責(zé)路由pinia負(fù)責(zé)狀態(tài)管理axios負(fù)責(zé)發(fā)HTTP請(qǐng)求element-plus或vant做UI組件庫(kù)。我這套PC端管理類(lèi)頁(yè)面比較多選的是Element Plus。路由設(shè)計(jì)我采用了動(dòng)態(tài)路由的思路登錄成功之后根據(jù)后端返回的角色信息動(dòng)態(tài)添加路由。普通用戶能訪問(wèn)的路由是首頁(yè)、自習(xí)室列表、座位預(yù)約、我的預(yù)約、個(gè)人中心管理員能額外訪問(wèn)座位管理、自習(xí)室管理、預(yù)約管理、數(shù)據(jù)統(tǒng)計(jì)。這樣避免把所有路由一次性注冊(cè)用戶手動(dòng)輸入U(xiǎn)RL訪問(wèn)不該進(jìn)的頁(yè)面直接被404或重定向。實(shí)現(xiàn)核心是在router.beforeEach的全局前置守衛(wèi)中加邏輯取到用戶的token再根據(jù)角色拼接需要?jiǎng)討B(tài)添加的路由。這個(gè)方案要注意一個(gè)問(wèn)題刷新頁(yè)面時(shí)路由會(huì)被重置必須在刷新前把路由信息存到pinia或localStorage里下次進(jìn)入時(shí)再重新addRoute。4.2 自習(xí)室列表與選座交互用戶進(jìn)入預(yù)約流程的核心路徑是選擇自習(xí)室 - 查看座位圖 - 點(diǎn)擊座位 - 確認(rèn)預(yù)約信息 - 提交成功。自習(xí)室列表頁(yè)比較簡(jiǎn)單就是一個(gè)卡片列表。每個(gè)卡片展示自習(xí)室名稱、位置、開(kāi)放時(shí)間、剩余座位數(shù)。剩余座位數(shù)不要單獨(dú)寫(xiě)死而是每次查詢時(shí)動(dòng)態(tài)計(jì)算。我這邊是用一個(gè)接口獲取所有自習(xí)室再返回每個(gè)自習(xí)室的可用座位數(shù)。座位圖是前端開(kāi)發(fā)中最需要花心思做的一塊。我設(shè)計(jì)了一個(gè)Canvas繪制的座位平面圖后端返回每個(gè)座位在自習(xí)室中的相對(duì)坐標(biāo)(x, y)前端根據(jù)坐標(biāo)繪制座位方塊不同狀態(tài)的座位用不同顏色區(qū)分綠色空閑可點(diǎn)擊、灰色已占用、黃色被選中。用戶點(diǎn)擊空閑座位后彈出側(cè)邊欄顯示預(yù)約時(shí)間選擇器選好時(shí)間段后提交。這個(gè)交互看似簡(jiǎn)單但雷區(qū)不少。最大的坑是點(diǎn)擊事件綁定。如果你用div渲染多個(gè)座位事件冒泡可能導(dǎo)致用戶點(diǎn)一個(gè)座位被判定成點(diǎn)擊另一個(gè)。解決辦法是為每個(gè)座位設(shè)置唯一的data-index屬性事件處理時(shí)用event.target.dataset.index來(lái)鎖定目標(biāo)而不是依賴事件對(duì)象的其它屬性。另外還要給選中的座位做高亮并且一定要處理用戶點(diǎn)擊A座位再點(diǎn)擊B座位的情況上一次選中的狀態(tài)要取消掉。具體到座位坐標(biāo)返回的接口設(shè)計(jì)我推薦一次返回該自習(xí)室當(dāng)天所有座位信息的列表包含id、座位編號(hào)、x坐標(biāo)、y坐標(biāo)、狀態(tài)。前端拿到數(shù)據(jù)后渲染即可。這里不要在選座時(shí)才逐個(gè)請(qǐng)求座位詳情會(huì)造成大量HTTP請(qǐng)求拖慢頁(yè)面響應(yīng)。4.3 狀態(tài)管理用戶信息與預(yù)約狀態(tài)Pinia是Vue 3官方推薦的狀態(tài)管理庫(kù)相當(dāng)于是Vuex的進(jìn)化版。它的代碼比Vuex簡(jiǎn)潔很多去掉了mutationsaction里直接改state。我把用戶登錄信息、token、預(yù)約篩選條件這些全局共享數(shù)據(jù)都放進(jìn)了Pinia。實(shí)際開(kāi)發(fā)中比較關(guān)鍵的是Token管理。用戶登錄成功后后端返回一個(gè)token我用的是JWT前端把token存到localStorage里同時(shí)設(shè)置axios的請(qǐng)求攔截器在每次請(qǐng)求前自動(dòng)把token放進(jìn)請(qǐng)求頭Authorization字段。響應(yīng)攔截器里做統(tǒng)一錯(cuò)誤處理后端返回401時(shí)自動(dòng)清除token并跳轉(zhuǎn)登錄頁(yè)返回業(yè)務(wù)錯(cuò)誤碼時(shí)直接彈出ElMessage提示用戶。預(yù)約狀態(tài)的響應(yīng)式更新也很重要。用戶成功取消一個(gè)預(yù)約后之前座位圖上對(duì)應(yīng)座位的狀態(tài)還顯示為灰色已占用但數(shù)據(jù)庫(kù)里已經(jīng)變成空閑了。這時(shí)候必須觸發(fā)數(shù)據(jù)刷新。我的做法是把當(dāng)前自習(xí)室的座位數(shù)據(jù)存到Pinia的管理模塊里取消預(yù)約成功后調(diào)用seatStore的fetchSeats方法重新拉取座位數(shù)據(jù)保證UI和數(shù)據(jù)庫(kù)狀態(tài)一致。千萬(wàn)別圖省事只在前端改一個(gè)座位狀態(tài)變量一旦刷新頁(yè)面就露餡而且并發(fā)情況下用戶看到的可能是過(guò)期數(shù)據(jù)。5. 部署運(yùn)行與常見(jiàn)問(wèn)題排查5.1 本地快速啟動(dòng)初始化SQL與配置文件整套系統(tǒng)跑起來(lái)的第一步是初始化數(shù)據(jù)庫(kù)。提前把建庫(kù)建表SQL腳本準(zhǔn)備好包括核心表數(shù)據(jù)和幾個(gè)測(cè)試用戶數(shù)據(jù)。MySQL 8.x版本要注意字符集數(shù)據(jù)庫(kù)和表都用utf8mb4而不是utf8因?yàn)閡tf8在MySQL里不是標(biāo)準(zhǔn)的四字節(jié)UTF-8emoji等特殊字符存不進(jìn)去會(huì)報(bào)錯(cuò)。這個(gè)問(wèn)題非常隱蔽排查很久才發(fā)現(xiàn)的。后端配置文件application.yml里我最常被問(wèn)到的幾個(gè)配置server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/study_room?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.studyroom.entity configuration: map-underscore-to-camel-case: trueserverTimezoneAsia/Shanghai是很多新人忽略的地方。MySQL 8.x驅(qū)動(dòng)默認(rèn)時(shí)區(qū)是UTC如果不指定查出來(lái)的時(shí)間會(huì)比本地時(shí)間早8小時(shí)預(yù)約時(shí)間的顯示全部錯(cuò)亂。allowPublicKeyRetrievaltrue這個(gè)參數(shù)是在用caching_sha2_password認(rèn)證插件時(shí)需要的不加會(huì)報(bào)Public Key Retrieval is not allowed錯(cuò)誤。5.2 高頻報(bào)錯(cuò)與解決方案我把開(kāi)發(fā)和部署中遇到的幾個(gè)高頻問(wèn)題整理成表。這些問(wèn)題都是新手期最容易觸發(fā)、且真實(shí)項(xiàng)目里也極有可能再現(xiàn)的。問(wèn)題現(xiàn)象原因解決方案Failed to configure a DataSourceapplication.yml找不到配置或類(lèi)掃描路徑不對(duì)檢查注解SpringBootApplication所在包是否能掃描到配置類(lèi)Invalid bound statement (not found)mapper接口和XML文件未綁定檢查XML文件位置是否在mapper-locations配置路徑下方法名是否一致Cannot load driver class: com.mysql.cj.jdbc.DriverMySQL驅(qū)動(dòng)未引入在pom.xml中引入mysql-connector-java依賴版本需與本地MySQL對(duì)應(yīng)日期錯(cuò)亂少8小時(shí)時(shí)區(qū)配置未設(shè)置增加serverTimezoneAsia/Shanghai參數(shù)跨域請(qǐng)求被攔截前后端端口不一致在SpringBoot中配置CorsFilter或使用CrossOrigin注解前端請(qǐng)求404或500后端接口路徑或參數(shù)名不一致用瀏覽器開(kāi)發(fā)者工具的Network面板查看具體請(qǐng)求和響應(yīng)唯一索引沖突Duplicate entry同一座位同一時(shí)間段重復(fù)預(yù)約在Service中執(zhí)行沖突檢查并捕獲異常返回友好提示跨域問(wèn)題我要單獨(dú)說(shuō)。我開(kāi)發(fā)時(shí)前端跑在5173端口Vite默認(rèn)后端跑在8080端口兩者端口不同瀏覽器攔截跨域請(qǐng)求很正常。解決方式有兩種后端統(tǒng)一配置一個(gè)CorsFilter允許指定源和指定方法另一個(gè)是后端使用Spring Cloud Gateway等網(wǎng)關(guān)代理但單機(jī)開(kāi)發(fā)時(shí)一個(gè)CorsFilter就夠用了。生產(chǎn)環(huán)境建議使用Nginx做反向代理把前端靜態(tài)文件和后端接口放到同一個(gè)域名下從根源上規(guī)避跨域。5.3 性能與并發(fā)優(yōu)化心得自習(xí)室預(yù)約這類(lèi)系統(tǒng)的并發(fā)量不會(huì)特別夸張但是某些高峰時(shí)段例如圖書(shū)館的期末復(fù)習(xí)周還是會(huì)有一波瞬間高并發(fā)。我的優(yōu)化經(jīng)驗(yàn)分三檔。第一檔是前端限流。座位圖上的座位數(shù)量有限用戶需要先選擇時(shí)間段再提交避免所有人都同時(shí)在預(yù)約按鈕上狂點(diǎn)。提交按鈕設(shè)置60秒的防重復(fù)點(diǎn)擊限制用戶操作邏輯上先攔住一部分無(wú)效請(qǐng)求。第二檔是后端緩存。熱門(mén)自習(xí)室的座位狀態(tài)數(shù)據(jù)可以緩存到Redis減少數(shù)據(jù)庫(kù)的查詢壓力。但緩存會(huì)讓數(shù)據(jù)狀態(tài)有一定的延遲需要配合緩存過(guò)期時(shí)間或者消息通知主動(dòng)失效。自習(xí)室預(yù)約系統(tǒng)的數(shù)據(jù)一致性要求并不那么高因?yàn)橛脩舨樵冏粻顟B(tài)時(shí)看到有一兩秒的延遲完全可以接受但預(yù)約提交瞬間必須讀最新數(shù)據(jù)。第三檔才是數(shù)據(jù)庫(kù)性能優(yōu)化。給預(yù)約單表建立合適的聯(lián)合索引預(yù)約日期狀態(tài)自習(xí)室id座位表建立自習(xí)室id索引用戶表手機(jī)號(hào)建唯一索引。這幾種索引組合能覆蓋絕大部分業(yè)務(wù)查詢場(chǎng)景。不要盲目給所有字段加索引寫(xiě)多讀少的字段加索引反而拖慢插入速度。還有一個(gè)經(jīng)驗(yàn)是盡量把復(fù)雜SQL拆分。比如統(tǒng)計(jì)報(bào)表需求每日預(yù)約量、座位利用率、自習(xí)室排行。這類(lèi)統(tǒng)計(jì)查詢?cè)跀?shù)據(jù)量小的時(shí)候用一條SQL就能搞定但數(shù)據(jù)量一旦上來(lái)group by和子查詢會(huì)讓數(shù)據(jù)庫(kù)壓力劇增。我的做法是把統(tǒng)計(jì)任務(wù)拆成定時(shí)任務(wù)每天凌晨用Spring Boot的Scheduled注解生成當(dāng)天的統(tǒng)計(jì)匯總數(shù)據(jù)存到統(tǒng)計(jì)表前臺(tái)展示時(shí)只需查統(tǒng)計(jì)表查詢性能提升非常明顯。6. 從課設(shè)到真實(shí)項(xiàng)目的提升點(diǎn)從一個(gè)能跑起來(lái)的課設(shè)系統(tǒng)到一個(gè)稍微接近生產(chǎn)環(huán)境的應(yīng)用中間還差幾個(gè)關(guān)鍵動(dòng)作。整理項(xiàng)目時(shí)我用下面幾條標(biāo)準(zhǔn)來(lái)衡量系統(tǒng)成熟度也可以對(duì)照看看你的項(xiàng)目卡在哪一檔。第一是日志鏈路。開(kāi)發(fā)階段print()完事直接輸出到控制臺(tái)沒(méi)問(wèn)題但部署到服務(wù)器后就必須依賴日志定位問(wèn)題。我用的方案是Logback按天滾動(dòng)切割ERROR級(jí)別和INFO級(jí)別分開(kāi)輸出。預(yù)約成功、取消、失敗這些核心操作至少記錄一條INFO日志包含用戶id、座位id和操作結(jié)果方便日后做問(wèn)題排查。第二是參數(shù)校驗(yàn)的規(guī)范化。不要在前端做了一堆校驗(yàn)就認(rèn)為萬(wàn)事大吉。后端必須用JSR 303的Valid注解做參數(shù)校驗(yàn)在DTO字段上標(biāo)注NotNull、NotBlank、Length等注解寫(xiě)起來(lái)零成本但能攔截掉大量無(wú)效請(qǐng)求。第三是接口文檔。以前很多小團(tuán)隊(duì)不愛(ài)寫(xiě)接口文檔前后端聯(lián)調(diào)靠口頭溝通效率極低。后來(lái)普遍的方案是集成SpringDoc或Swagger啟動(dòng)項(xiàng)目后自動(dòng)生成接口文檔。另一個(gè)更好維護(hù)的方式是寫(xiě)Apifox或Postman的接口集合把每個(gè)接口的請(qǐng)求參數(shù)和返回結(jié)果固化下來(lái)新成員接手時(shí)直接看接口集合就能上手不用讀一遍源碼。第四是數(shù)據(jù)安全。密碼加密使用BCrypt登錄接口加簡(jiǎn)單的驗(yàn)證碼或圖片驗(yàn)證碼做防爆破。預(yù)約的接口要驗(yàn)證當(dāng)前登錄用戶和操作對(duì)象是否一致防止通過(guò)篡改請(qǐng)求參數(shù)操作他人的預(yù)約記錄。這個(gè)越權(quán)問(wèn)題在課設(shè)里常常被忽略但在真實(shí)項(xiàng)目中屬于高危漏洞。我用的是攔截器加ThreadLocal保存當(dāng)前登錄用戶信息Service層取用戶id時(shí)統(tǒng)一從這個(gè)ThreadLocal取前端傳來(lái)的任何user_id都不作為權(quán)限判斷依據(jù)。7. 實(shí)操中的個(gè)人體會(huì)整個(gè)項(xiàng)目做完回頭復(fù)盤(pán)我最大的感受是技術(shù)選型重要但比技術(shù)選型更重要的是對(duì)業(yè)務(wù)邊界和狀態(tài)變化的清晰認(rèn)知。這套系統(tǒng)的業(yè)務(wù)本質(zhì)并不復(fù)雜就是一個(gè)座位的占用時(shí)間片管理但圍繞這個(gè)本質(zhì)展開(kāi)的字段設(shè)計(jì)、狀態(tài)流轉(zhuǎn)、并發(fā)控制、交互體驗(yàn)每一環(huán)都會(huì)決定系統(tǒng)的穩(wěn)定性和易用性。對(duì)我個(gè)人來(lái)說(shuō)動(dòng)手做一個(gè)項(xiàng)目永遠(yuǎn)比看書(shū)看視頻學(xué)得快。遇到問(wèn)題靠搜索引擎、靠官方文檔、靠上下文調(diào)試慢慢解決踩過(guò)坑的記憶最牢固。也建議你把這個(gè)項(xiàng)目跑起來(lái)之后嘗試加一個(gè)功能或者換一種實(shí)現(xiàn)方式比如把座位預(yù)約改成計(jì)數(shù)預(yù)約、加一個(gè)基于Redis的排隊(duì)功能、把統(tǒng)計(jì)報(bào)表改成圖表可視化。不要照著我寫(xiě)的代碼抄一遍就完事改造的過(guò)程中你才會(huì)真正理解哪一步為什么這么設(shè)計(jì)。