約管理系統(tǒng)：從數(shù)據(jù)庫到?jīng)_突檢測全解析)
簡介面向高校計(jì)算機(jī)相關(guān)專業(yè)畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)場景這份微信小程序琴房管理系統(tǒng)項(xiàng)目包含完整源碼、說明文檔、LW及演示視頻。系統(tǒng)按學(xué)生與管理員雙角色設(shè)計(jì)學(xué)生端支持琴房查看、預(yù)約與公告瀏覽管理員端覆蓋學(xué)生信息管理、琴房公告發(fā)布及登錄注銷等操作業(yè)務(wù)鏈路完整適合需要快速理解小程序全棧開發(fā)并產(chǎn)出畢設(shè)成果的讀者。壓縮包共1105個(gè)文件大小約25.4MB以vue、js、java、class等前后端源碼文件為主輔以wxml/wxss小程序頁面、json配置、sql數(shù)據(jù)庫腳本、docx文檔以及png/svg界面素材和mp4演示視頻目錄結(jié)構(gòu)清晰、資源類型齊全。已有188人學(xué)習(xí)下載。包內(nèi)還附帶安裝/運(yùn)行/構(gòu)建的bat腳本、關(guān)鍵文件備份與常見配置說明結(jié)合演示視頻和說明文檔可幫助讀者梳理琴房預(yù)約的業(yè)務(wù)流程、接口設(shè)計(jì)及前后端交互細(xì)節(jié)便于二次開發(fā)與答辯準(zhǔn)備。1. 琴房管理系統(tǒng)怎么做這個(gè)微信小程序項(xiàng)目到底解決什么問題琴房管理在很多學(xué)校還停留在「微信群接龍 管理員人工排表」的階段學(xué)生接龍預(yù)約到了現(xiàn)場發(fā)現(xiàn)琴房被占用管理員每天花大量時(shí)間核對時(shí)間表、處理沖突。基于微信小程序的琴房管理系統(tǒng)把整套流程搬到線上——學(xué)生打開小程序查看琴房實(shí)時(shí)狀態(tài)、按時(shí)間段預(yù)約管理員維護(hù)琴房、管理預(yù)約記錄。這類項(xiàng)目常出現(xiàn)在畢業(yè)設(shè)計(jì)和課程設(shè)計(jì)中因?yàn)闃I(yè)務(wù)邊界清晰又完整覆蓋了小程序前端、服務(wù)端接口、數(shù)據(jù)庫設(shè)計(jì)和定時(shí)任務(wù)幾個(gè)模塊。第一次做小程序全棧項(xiàng)目選它能把前后端基本功都練到評估它值不值得做核心就看一點(diǎn)預(yù)約沖突怎么用最少的代碼擋住。本文把這條線從頭到尾講透。2. 需求拆解與數(shù)據(jù)庫建模琴房預(yù)約的核心是時(shí)間沖突檢測做這類系統(tǒng)別急著寫代碼先把業(yè)務(wù)流程和表結(jié)構(gòu)想清楚。后臺(tái)的編排決定了預(yù)約邏輯的復(fù)雜度一旦表結(jié)構(gòu)定錯(cuò)后面改起來牽一發(fā)動(dòng)全身。琴房管理系統(tǒng)翻來覆去就那么幾個(gè)頁面但真正考驗(yàn)設(shè)計(jì)能力的是預(yù)約這件事怎么用數(shù)據(jù)模型表達(dá)出來。2.1 三種角色與核心業(yè)務(wù)流程預(yù)約、取消、簽到怎么串系統(tǒng)的角色其實(shí)就三類學(xué)生、管理員、定時(shí)任務(wù)。學(xué)生側(cè)重在鏈路上走查看琴房列表 → 選擇日期與時(shí)間段 → 提交預(yù)約 → 到琴房簽到 → 完成使用。管理員側(cè)重維護(hù)維護(hù)琴房信息、查看所有預(yù)約、異常情況下強(qiáng)制取消。定時(shí)任務(wù)做兜底把超時(shí)未簽到的預(yù)約標(biāo)記為爽約把過期預(yù)約歸檔。業(yè)務(wù)規(guī)則上我一般會(huì)按這幾條定同一琴房同一日期同一時(shí)間段只能存在一條有效預(yù)約。預(yù)約開始時(shí)間必須早于結(jié)束時(shí)間且落在琴房營業(yè)時(shí)間內(nèi)。只能預(yù)約未來 7 天內(nèi)的時(shí)段不能預(yù)約過去的日期。取消預(yù)約必須在開始時(shí)間之前完成。預(yù)約開始后遲到 15 分鐘未簽到視為爽約。這些規(guī)則里最容易出錯(cuò)的是第 1 條——時(shí)間沖突。判斷兩個(gè)時(shí)間段是否重疊很多人第一反應(yīng)是「新預(yù)約的開始時(shí)間是否落在已有預(yù)約的區(qū)間里」這個(gè)直覺是錯(cuò)的。正確的判定公式是只要新時(shí)段的開始早于已有時(shí)段的結(jié)束且新時(shí)段的結(jié)束晚于已有時(shí)段的開始就必然重疊。這個(gè)公式貫穿整篇文章后面的 SQL 和代碼都在圍著它轉(zhuǎn)。2.2 用三張表把業(yè)務(wù)落地user、room、booking 的字段設(shè)計(jì)與索引核心就三張表字段不需要多夠用就行。下面是推薦的表結(jié)構(gòu)。-- 用戶表 CREATE TABLE sys_user ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, openid VARCHAR(64) NOT NULL COMMENT 微信用戶唯一標(biāo)識(shí), nickname VARCHAR(50) DEFAULT COMMENT 昵稱, student_no VARCHAR(20) DEFAULT COMMENT 學(xué)號管理員可錄入, role TINYINT NOT NULL DEFAULT 0 COMMENT 0-學(xué)生 1-管理員, status TINYINT NOT NULL DEFAULT 1 COMMENT 0-禁用 1-正常, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用戶表; -- 琴房表 CREATE TABLE piano_room ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, room_name VARCHAR(50) NOT NULL COMMENT 房間名如 A101, location VARCHAR(100) DEFAULT COMMENT 位置描述, piano_type VARCHAR(30) DEFAULT COMMENT 鋼琴類型, is_open TINYINT NOT NULL DEFAULT 1 COMMENT 0-關(guān)閉 1-開放, open_time TIME DEFAULT 08:00:00 COMMENT 營業(yè)開始, close_time TIME DEFAULT 22:00:00 COMMENT 營業(yè)結(jié)束, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT琴房表; -- 預(yù)約表 CREATE TABLE booking ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, room_id INT UNSIGNED NOT NULL COMMENT 琴房 id, user_id INT UNSIGNED NOT NULL COMMENT 用戶 id, book_date DATE NOT NULL COMMENT 預(yù)約日期, start_time TIME NOT NULL COMMENT 開始時(shí)間, end_time TIME NOT NULL COMMENT 結(jié)束時(shí)間, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-已預(yù)約 1-已完成 2-已取消 3-爽約, remark VARCHAR(200) DEFAULT COMMENT 備注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_room_time (room_id, book_date, start_time, end_time), KEY idx_user_status (user_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT預(yù)約表;幾個(gè)設(shè)計(jì)要點(diǎn)說明。user 表的 openid 必須加唯一索引。微信小程序登錄拿到的是 openid它是用戶在當(dāng)前小程序下的唯一身份標(biāo)識(shí)每次登錄都用它做插入或更新重復(fù)插入會(huì)直接報(bào)錯(cuò)也能防止同一個(gè)微信號注冊出多個(gè)賬號。booking 表的 idx_room_time 聯(lián)合索引是沖突查詢的關(guān)鍵。沖突檢測的 SQL 會(huì)按 room_id 加 book_date 過濾再用 start_time 和 end_time 做區(qū)間比較這個(gè)索引能讓查詢走 range scan 而不是全表掃描。數(shù)據(jù)量幾千條時(shí)差別不明顯但到上萬條后有沒有這個(gè)索引就是毫秒級和秒級的差別。status 字段用 TINYINT 數(shù)字而不是字符串。畢業(yè)設(shè)計(jì)里很多人習(xí)慣存 booked、cancelled 這種字符串看著直觀但索引效率和代碼可讀性都不如數(shù)字枚舉。前后端約定好 0/1/2/3 的含義后端定義常量類統(tǒng)一使用比到處寫魔法數(shù)強(qiáng)得多。2.3 接口清單與鑒權(quán)方式小程序端和服務(wù)端怎么分工接口按資源拆RESTful 風(fēng)格就夠不需要引入復(fù)雜框架。核心接口如下。接口方法核心入?yún)⒄f明/api/auth/loginPOSTcode用 wx.login 的 code 換登錄態(tài) token/api/room/listGET無琴房列表與開放狀態(tài)/api/room/detailGETroomId琴房詳情含營業(yè)時(shí)間與可預(yù)約時(shí)段/api/booking/createPOSTroomId、bookDate、startTime、endTime創(chuàng)建預(yù)約/api/booking/mineGET無當(dāng)前用戶的預(yù)約記錄/api/booking/cancelPOSTbookingId取消預(yù)約/api/booking/checkinPOSTbookingId到琴房簽到/api/admin/room/savePOST琴房信息管理員維護(hù)琴房鑒權(quán)有兩種常見做法。輕量一點(diǎn)的是后端生成隨機(jī) token 存到 Redis設(shè)過期時(shí)間小程序每次請求把 token 放在 Authorization 頭里重一點(diǎn)的是直接上 JWT登錄時(shí)簽發(fā)過期時(shí)間由服務(wù)端控制。對這個(gè)項(xiàng)目來說Redis token 方案更直觀也方便管理員端做強(qiáng)制下線我一般會(huì)用這種。后端用攔截器統(tǒng)一校驗(yàn)白名單放行登錄接口其余接口都要求攜帶有效 token管理員接口再額外查一次 role 字段。3. 小程序端實(shí)現(xiàn)登錄態(tài)、琴房列表和預(yù)約提交的關(guān)鍵代碼小程序端的核心頁面就三個(gè)琴房列表頁、預(yù)約頁、我的預(yù)約頁。這一章把代碼拆開講從登錄態(tài)到預(yù)約提交每一步給出能直接用的片段。所有請求都走 wx.request業(yè)務(wù)層把 url 和 data 組織好就行。3.1 微信登錄與 Token 會(huì)話管理code 換 token 的完整鏈路微信小程序的登錄鏈路是小程序調(diào)用 wx.login 拿到一次性 code后端拿 code 去微信接口換 openid 和 session_key再生成業(yè)務(wù) token 返回給小程序。code 只能用一次且有效期很短所以小程序端不能緩存 code每次啟動(dòng)都要重新調(diào)用 wx.login。// miniprogram/utils/auth.js const TOKEN_KEY token; function login() { return new Promise((resolve, reject) { wx.login({ success: (res) { if (!res.code) { reject(new Error(wx.login 未返回 code)); return; } wx.request({ url: getApp().globalData.apiBase /api/auth/login, method: POST, data: { code: res.code }, success: (resp) { if (resp.data.code 0) { const token resp.data.data.token; wx.setStorageSync(TOKEN_KEY, token); resolve(resp.data.data); } else { reject(new Error(resp.data.msg || 登錄失敗)); } }, fail: (err) reject(err) }); }, fail: (err) reject(err) }); }); } function getToken() { return wx.getStorageSync(TOKEN_KEY); } module.exports { login, getToken, TOKEN_KEY };邏輯說明wx.login 成功后拿到 code把它 POST 給后端后端用 code 換 openid 后生成 token 返回。前端把 token 放進(jìn)本地緩存后續(xù)所有請求從緩存取。參數(shù)上注意 apiBase 是后端服務(wù)地址開發(fā)階段指向局域網(wǎng) IP 加端口正式上線必須換成已配置 HTTPS 證書的域名。提示token 失效時(shí)后端通常會(huì)返回 401小程序端應(yīng)該封裝一個(gè)請求函數(shù)統(tǒng)一攔截 401 后自動(dòng)重新登錄并重放原請求。這個(gè)習(xí)慣能幫你省掉大量「登錄態(tài)過期」導(dǎo)致的現(xiàn)場翻車。關(guān)于 session_key它用于解密微信加密數(shù)據(jù)比如手機(jī)號。琴房管理系統(tǒng)如果只是用 openid 做身份識(shí)別session_key 在后端換完就可以丟棄不用存。見過不少同學(xué)把 session_key 也寫進(jìn) user 表沒有必要除非你還要做微信手機(jī)號授權(quán)。3.2 琴房列表與狀態(tài)展示拉取數(shù)據(jù)、渲染與下拉刷新琴房列表頁的要點(diǎn)是狀態(tài)展示。后端返回的 room 里帶 status 字段前端要把它翻譯成用戶能看懂的文字和顏色而不是直接把數(shù)字渲染到頁面上。// pages/room/room.js const { getToken } require(../utils/auth.js); Page({ data: { rooms: [], loading: false }, onShow() { this.fetchRooms(); }, onPullDownRefresh() { this.fetchRooms(true); }, fetchRooms(isRefresh false) { if (this.data.loading) return; this.setData({ loading: true }); wx.request({ url: getApp().globalData.apiBase /api/room/list, header: { Authorization: Bearer getToken() }, success: (res) { if (res.data.code 0) { const rooms res.data.data.map((room) ({ ...room, statusText: this.statusText(room.status), statusClass: room-status- room.status })); this.setData({ rooms }); } else { wx.showToast({ title: res.data.msg || 加載失敗, icon: none }); } }, complete: () { this.setData({ loading: false }); if (isRefresh) wx.stopPullDownRefresh(); } }); }, statusText(status) { const map { 0: 空閑, 1: 使用中, 2: 維護(hù)中 }; return map[status] || 未知; }, goBook(e) { const roomId e.currentTarget.dataset.id; wx.navigateTo({ url: /pages/book/book?roomId roomId }); } });對應(yīng)的 WXML 片段view classroom-card wx:for{{rooms}} wx:keyid view classroom-name{{item.roomName}}/view view classroom-location{{item.location}} · {{item.pianoType}}/view view classroom-status {{item.statusClass}}{{item.statusText}}/view button typeprimary sizemini bindtapgoBook>// pages/book/book.js const { getToken } require(../utils/auth.js); const SLOT_MINUTES 60; const MAX_ADVANCE_DAYS 7; Page({ data: { roomId: , room: null, dateList: [], dateIndex: 0, slotList: [], slotIndex: -1, submitting: false }, onLoad(options) { this.setData({ roomId: options.roomId }); this.buildDateList(); this.loadRoomDetail(); }, buildDateList() { const list []; const week [日, 一, 二, 三, 四, 五, 六]; for (let i 0; i MAX_ADVANCE_DAYS; i) { const d new Date(); d.setDate(d.getDate() i); const dateStr ${d.getFullYear()}-${String(d.getMonth() 1).padStart(2, 0)}-${String(d.getDate()).padStart(2, 0)}; const label i 0 ? 今天 : i 1 ? 明天 : ${d.getMonth() 1}月${d.getDate()}日 周${week[d.getDay()]}; list.push({ dateStr, label }); } this.setData({ dateList: list }); }, loadRoomDetail() { wx.request({ url: getApp().globalData.apiBase /api/room/detail, data: { roomId: this.data.roomId }, header: { Authorization: Bearer getToken() }, success: (res) { if (res.data.code 0) { this.setData({ room: res.data.data }); this.buildSlotList(); } } }); }, buildSlotList() { const room this.data.room; if (!room) return; const slots []; const openHour parseInt(room.openTime.slice(0, 2), 10); const closeHour parseInt(room.closeTime.slice(0, 2), 10); for (let h openHour; h SLOT_MINUTES / 60 closeHour; h) { const start ${String(h).padStart(2, 0)}:00:00; const end ${String(h SLOT_MINUTES / 60).padStart(2, 0)}:00:00; slots.push({ start, end, label: ${start.slice(0, 5)} - ${end.slice(0, 5)} }); } this.setData({ slotList: slots }); }, onDateChange(e) { this.setData({ dateIndex: Number(e.detail.value), slotIndex: -1 }); }, onSlotSelect(e) { this.setData({ slotIndex: Number(e.currentTarget.dataset.index) }); }, submit() { const { roomId, dateList, dateIndex, slotList, slotIndex, submitting } this.data; if (slotIndex 0) { wx.showToast({ title: 請選擇時(shí)間段, icon: none }); return; } if (submitting) return; this.setData({ submitting: true }); const date dateList[dateIndex].dateStr; const slot slotList[slotIndex]; wx.request({ url: getApp().globalData.apiBase /api/booking/create, method: POST, header: { Authorization: Bearer getToken() }, data: { roomId: roomId, bookDate: date, startTime: slot.start, endTime: slot.end }, success: (res) { if (res.data.code 0) { wx.showToast({ title: 預(yù)約成功, icon: success }); setTimeout(() wx.navigateBack(), 1500); } else { wx.showToast({ title: res.data.msg || 預(yù)約失敗, icon: none }); } }, complete: () { this.setData({ submitting: false }); } }); } });邏輯說明日期生成用循環(huán)加 7 天第一二天顯示「今天」「明天」后面的顯示具體日期和星期這個(gè)細(xì)節(jié)在演示時(shí)很加分。時(shí)間片按 room.openTime 和 closeTime 解析出小時(shí)數(shù)循環(huán)生成整點(diǎn)時(shí)段。submitting 標(biāo)志防止用戶重復(fù)點(diǎn)擊提交這個(gè)在預(yù)約場景里是必須的不然一次點(diǎn)擊發(fā)出兩個(gè)請求就會(huì)出現(xiàn)「我只點(diǎn)了一次怎么訂了兩條」。注意一個(gè)邊界時(shí)間片生成只考慮了整點(diǎn)如果琴房營業(yè)時(shí)間是 08:30 到 21:30這種寫法生成的時(shí)段會(huì)不準(zhǔn)。穩(wěn)妥的做法是后端在 room/detail 接口里直接返回可預(yù)約時(shí)間片數(shù)組前端只負(fù)責(zé)渲染。這樣營業(yè)時(shí)間、粒度、特殊日期的規(guī)則全部收斂在后端一處前端永遠(yuǎn)不用自己去推。4. 后端服務(wù)與沖突控制把預(yù)約規(guī)則寫成可執(zhí)行的代碼后端是這類系統(tǒng)的重頭戲。預(yù)約創(chuàng)建、沖突檢測、超時(shí)釋放這三塊寫好了項(xiàng)目核心邏輯就立住了。這一章以 Java Spring Boot 的寫法為例其他語言思路一致SQL 部分可以直接搬過去。4.1 預(yù)約創(chuàng)建的完整流程參數(shù)校驗(yàn)、沖突檢測與事務(wù)預(yù)約創(chuàng)建的接口不能只是簡單 insert它要按順序做五件事參數(shù)校驗(yàn)、琴房校驗(yàn)、營業(yè)時(shí)間校驗(yàn)、沖突檢測、插入。任何一步失敗都返回業(yè)務(wù)錯(cuò)誤。Transactional(rollbackFor Exception.class) public Booking createBooking(BookingDTO dto, Long userId) { // 1. 基本參數(shù)校驗(yàn) if (dto.getStartTime().compareTo(dto.getEndTime()) 0) { throw new BusinessException(開始時(shí)間必須早于結(jié)束時(shí)間); } if (dto.getBookDate().isBefore(LocalDate.now())) { throw new BusinessException(不能預(yù)約過去的日期); } // 2. 琴房存在且開放 PianoRoom room roomMapper.selectById(dto.getRoomId()); if (room null || room.getIsOpen() ! 1) { throw new BusinessException(琴房不存在或未開放); } // 3. 時(shí)間必須落在琴房營業(yè)時(shí)間范圍內(nèi) if (dto.getStartTime().isBefore(room.getOpenTime()) || dto.getEndTime().isAfter(room.getCloseTime())) { throw new BusinessException(預(yù)約時(shí)間超出琴房營業(yè)時(shí)間); } // 4. 行鎖 沖突檢測 int conflict bookingMapper.countConflictForUpdate( dto.getRoomId(), dto.getBookDate(), dto.getStartTime(), dto.getEndTime()); if (conflict 0) { throw new BusinessException(該時(shí)間段已被預(yù)約請選擇其他時(shí)間); } // 5. 插入預(yù)約記錄 Booking booking new Booking(); booking.setRoomId(dto.getRoomId()); booking.setUserId(userId); booking.setBookDate(dto.getBookDate()); booking.setStartTime(dto.getStartTime()); booking.setEndTime(dto.getEndTime()); booking.setStatus(BookingStatus.BOOKED); bookingMapper.insert(booking); return booking; }邏輯說明第 1 步擋住「開始晚于結(jié)束」和「預(yù)約過去日期」兩種低級錯(cuò)誤這類請求根本不該進(jìn)到數(shù)據(jù)庫。第 3 步校驗(yàn)營業(yè)時(shí)間前端選了 21:30 但琴房 21:00 關(guān)門這里直接拒絕。第 4 步是核心countConflictForUpdate 會(huì)先鎖住相關(guān)記錄再統(tǒng)計(jì)避免兩個(gè)并發(fā)請求同時(shí)通過檢查。第 5 步插入后事務(wù)提交整個(gè)過程要么全部成功要么全部回滾不會(huì)出現(xiàn)「沖突檢測通過了但插入失敗」的臟狀態(tài)。注意Transactional 一定要加 rollbackFor Exception.class。Spring 默認(rèn)只在 RuntimeException 時(shí)回滾拋?zhàn)远x checked 異常時(shí)事務(wù)不回滾數(shù)據(jù)就寫進(jìn)去了這個(gè)細(xì)節(jié)坑過很多人。還有一個(gè)容易踩的坑有的同學(xué)把沖突檢測拆成獨(dú)立 service 方法然后在 createBooking 里調(diào)用。如果這個(gè)方法沒有事務(wù)傳播檢查完再插入的間隙另一個(gè)請求可能已經(jīng)插入了同一時(shí)段。所以檢測和插入必須在同一個(gè)事務(wù)方法里這是硬要求。4.2 沖突檢測 SQL 的正確寫法區(qū)間重疊判定與索引利用沖突檢測的 SQL 是全文最重要的幾行代碼。select idcountConflictForUpdate resultTypeint SELECT COUNT(*) FROM booking WHERE room_id #{roomId} AND book_date #{bookDate} AND status 0 AND start_time lt; #{endTime} AND end_time gt; #{startTime} FOR UPDATE /select邏輯說明新預(yù)約時(shí)段是 [startTime, endTime]已有預(yù)約時(shí)段是 [start_time, end_time]。兩者重疊的充要條件是新開始時(shí)間早于已有結(jié)束時(shí)間且新結(jié)束時(shí)間晚于已有開始時(shí)間。寫成 SQL 就是 start_time #{endTime} AND end_time #{startTime}。再加 book_date 限定同一天status 0 只統(tǒng)計(jì)有效預(yù)約排除已取消和已歸檔的記錄。反例值得單獨(dú)說。有同學(xué)會(huì)寫成下面這兩種-- 反例一只覆蓋「完全包含」的情況 WHERE start_time #{startTime} AND end_time #{endTime} -- 反例二只看已有預(yù)約的開始時(shí)間是否落在新時(shí)段內(nèi) WHERE start_time BETWEEN #{startTime} AND #{endTime}反例一漏掉了「新時(shí)段橫跨已有時(shí)段」的部分重疊反例二漏掉了「已有時(shí)段橫跨新時(shí)段」的場景。實(shí)測中這兩種寫法會(huì)各放走一批沖突預(yù)約等管理員在后臺(tái)看到記錄重了再去手工取消就很被動(dòng)。FOR UPDATE 是 MySQL InnoDB 的行鎖語法配合 idx_room_time 索引它會(huì)鎖住命中的索引區(qū)間。并發(fā)場景下兩個(gè)請求同時(shí)查同一琴房同一天的數(shù)據(jù)后到的會(huì)等先到事務(wù)提交后才繼續(xù)這樣沖突檢測就變成串行執(zhí)行不會(huì)出現(xiàn)兩人同時(shí)訂走同一時(shí)段的情況。這個(gè)鎖粒度對這個(gè)項(xiàng)目足夠沒必要上 Redis 分布式鎖。idx_room_time 聯(lián)合索引room_id, book_date, start_time, end_time覆蓋了查詢的過濾條件MySQL 會(huì)走索引 range scan數(shù)據(jù)量到十萬級也不會(huì)慢。如果這個(gè)項(xiàng)目用于期末設(shè)計(jì)這屬于「可展示的性能設(shè)計(jì)點(diǎn)」答辯時(shí)值得拿出來講。4.3 超時(shí)釋放與簽到定時(shí)任務(wù)讓預(yù)約狀態(tài)自動(dòng)流轉(zhuǎn)預(yù)約狀態(tài)不能永遠(yuǎn)停在「已預(yù)約」。到了時(shí)間沒來系統(tǒng)要自動(dòng)釋放琴房并標(biāo)記爽約當(dāng)天用完了要標(biāo)記完成。這些靠定時(shí)任務(wù)和簽到接口配合完成。Component public class BookingScheduler { Autowired private BookingMapper bookingMapper; // 每分鐘跑一次已預(yù)約但開始時(shí)間已過 15 分鐘的標(biāo)記為爽約 Scheduled(cron 0 * * * * ?) public void markNoShow() { ListBooking list bookingMapper.findExpiredNoShows(); for (Booking b : list) { b.setStatus(BookingStatus.NO_SHOW); bookingMapper.updateById(b); } } // 每天凌晨 2 點(diǎn)把前一天的記錄批量歸檔為已完成 Scheduled(cron 0 0 2 * * ?) public void archiveYesterday() { bookingMapper.archiveByDate(LocalDate.now().minusDays(1)); } }對應(yīng)的 SQL-- 找出已超時(shí)未簽到的預(yù)約 SELECT * FROM booking WHERE status 0 AND (book_date CURDATE() OR (book_date CURDATE() AND start_time DATE_SUB(CURTIME(), INTERVAL 15 MINUTE)))邏輯說明markNoShow 的判定條件是「開始時(shí)間已過去 15 分鐘且狀態(tài)仍是已預(yù)約」。這里故意留 15 分鐘緩沖學(xué)生可能因?yàn)槁飞系R晚到幾分鐘直接到點(diǎn)就釋放很容易引發(fā)投訴。archiveYesterday 是每天凌晨的兜底任務(wù)把前一天未完成的記錄批量歸檔。cron 表達(dá)式里0 * * * * ?表示每分鐘第 0 秒執(zhí)行0 0 2 * * ?表示每天凌晨 2 點(diǎn)整執(zhí)行。簽到接口單獨(dú)說一下。學(xué)生到琴房后點(diǎn)「簽到」后端要校驗(yàn)該預(yù)約屬于當(dāng)前用戶、狀態(tài)是已預(yù)約、當(dāng)前時(shí)間不早于預(yù)約開始時(shí)間然后狀態(tài)改成已完成。有個(gè)細(xì)節(jié)容易漏預(yù)約明天 10:00現(xiàn)在簽到必須拒絕預(yù)約今天 10:00 而現(xiàn)在是 10:05允許簽到。只判斷「日期相等」而忽略當(dāng)前時(shí)刻會(huì)導(dǎo)致預(yù)約還沒開始就能提前簽到的笑話邏輯。到這里系統(tǒng)核心鏈路已經(jīng)通了前端選時(shí)間、后端擋住沖突、定時(shí)任務(wù)兜底釋放。第 5 章把開發(fā)中最高發(fā)的幾個(gè)問題集中排一遍雷。5. 琴房管理系統(tǒng)避坑指南5 個(gè)高發(fā)問題與排查方法這一章按「現(xiàn)象 → 原因 → 解決」的格式寫都是這個(gè)項(xiàng)目里反復(fù)出現(xiàn)的問題每一類我都見過不止一次。你如果正在調(diào)試直接對照著查比從頭翻日志快得多。5.1 沖突檢測漏掉「部分重疊」導(dǎo)致重復(fù)預(yù)約現(xiàn)象A 同學(xué)約了 10:00-11:00B 同學(xué)竟然還能約 10:30-11:30后臺(tái)出現(xiàn)兩條重疊預(yù)約。原因沖突檢測 SQL 寫成了 start_time #{startTime} AND end_time #{endTime}只判斷新時(shí)段是否完整包含在已有時(shí)段內(nèi)。B 的 10:30-11:30 和 A 的 10:00-11:00 是交叉重疊新開始 10:30 落在 A 的時(shí)段內(nèi)但新結(jié)束 11:30 超出了 A 的結(jié)束時(shí)間條件不成立于是被放行。解決改用區(qū)間重疊判定 start_time #{endTime} AND end_time #{startTime}。改完用三種用例驗(yàn)證新時(shí)段在已有時(shí)段內(nèi)部、新時(shí)段橫跨已有時(shí)段、新時(shí)段與已有時(shí)段首尾相接前兩個(gè)必須返回沖突第三個(gè)在邊界恰好相切時(shí)允許通過。我一般會(huì)把這幾個(gè)用例寫進(jìn)單元測試防止后續(xù)改動(dòng)時(shí)悄悄回歸。5.2 并發(fā)預(yù)約「超賣」同一時(shí)段被兩人同時(shí)訂走現(xiàn)象兩個(gè)學(xué)生同時(shí)間隔幾百毫秒提交同一琴房同一時(shí)段的預(yù)約兩個(gè)接口都返回成功數(shù)據(jù)庫里兩條記錄。原因沒有加鎖的「先查詢后插入」存在競態(tài)窗口。請求 A 查到?jīng)_突數(shù)為 0還沒插入請求 B 也查到?jīng)_突數(shù)為 0接著兩個(gè)請求都執(zhí)行插入沖突檢測形同虛設(shè)。解決在沖突檢測 SQL 末尾加 FOR UPDATE并讓檢測與插入處于同一事務(wù)中。后到的請求會(huì)等待先到事務(wù)提交后再執(zhí)行查詢此時(shí)沖突數(shù)變成 1預(yù)約被拒絕。如果項(xiàng)目用的是 PostgreSQL對應(yīng)語法是 FOR KEY SHARE如果不想依賴數(shù)據(jù)庫鎖可以在 booking 表加唯一索引room_id, book_date, start_time做兜底插入沖突時(shí)直接報(bào)錯(cuò)再用異常重試邏輯處理。5.3 預(yù)約時(shí)間憑空差 8 小時(shí)數(shù)據(jù)庫時(shí)區(qū)問題現(xiàn)象小程序端選了 10:00 提交數(shù)據(jù)庫里存的是 02:00管理后臺(tái)看到的預(yù)約時(shí)間全部不對。原因Java 的 LocalDateTime 和 MySQL 的 DATETIME 在時(shí)區(qū)解析上出現(xiàn)偏差。常見的是 JDBC 連接串里沒有指定 serverTimezone驅(qū)動(dòng)用了默認(rèn)時(shí)區(qū)跟服務(wù)器系統(tǒng)時(shí)區(qū)不一致導(dǎo)致時(shí)間偏移。解決在 JDBC 連接串上顯式指定時(shí)區(qū)寫成 jdbc:mysql://localhost:3306/piano?serverTimezoneAsia/Shanghai。同時(shí)約定前后端傳輸時(shí)間一律用字符串格式如 10:00:00不傳時(shí)間戳。TIME 類型本身不涉及時(shí)區(qū)換算用字符串傳遞能避開大部分時(shí)區(qū)坑。這屬于典型的「開發(fā)環(huán)境不出錯(cuò)、一換機(jī)器就翻車」的問題答辯前一定要換臺(tái)機(jī)器部署驗(yàn)證一遍。5.4 開發(fā)者工具正常、真機(jī)請求失敗域名與 HTTPS現(xiàn)象微信開發(fā)者工具里所有接口都通掃碼到真機(jī)上一片空白控制臺(tái)報(bào) request:fail url not in domain list。原因小程序真機(jī)環(huán)境強(qiáng)制要求后臺(tái)接口走 HTTPS且域名必須在小程序后臺(tái)配置為 request 合法域名。開發(fā)工具默認(rèn)不校驗(yàn)合法域名本地 http 接口能通但真機(jī)不認(rèn)。解決開發(fā)階段在開發(fā)者工具的詳情設(shè)置里勾選「不校驗(yàn)合法域名、TLS 版本以及 HTTPS 證書」這只解決本機(jī)調(diào)試。要真機(jī)完整跑通需要準(zhǔn)備一個(gè)已配置 HTTPS 證書的域名在小程序后臺(tái)配好 request 合法域名再把后端接口地址從局域網(wǎng) IP 換成線上域名。證書和域名校驗(yàn)是硬條件沒有捷徑。演示視頻建議在真機(jī)網(wǎng)絡(luò)通暢時(shí)錄制別在開發(fā)工具里錄兩者觀感差很多。5.5 前端選了合法時(shí)間、后端卻報(bào)「超出營業(yè)時(shí)間」現(xiàn)象前端時(shí)間選擇器最多到 21:00但用戶改一下請求參數(shù)就能提交 22:00 的預(yù)約或者前端按 60 分鐘生成時(shí)間片后端允許提交 30 分鐘的時(shí)段預(yù)約粒度混亂。原因前端的時(shí)間組裝邏輯和后端校驗(yàn)規(guī)則是兩套代碼沒有統(tǒng)一。用戶只要繞過前端界面直接調(diào)接口就能提交任意時(shí)間。解決把「可預(yù)約時(shí)段」的完整定義收斂到后端。常見做法是后端 room/detail 接口直接返回該琴房可預(yù)約的時(shí)間片數(shù)組前端渲染時(shí)直接用不做二次計(jì)算后端 create 接口再做兜底校驗(yàn)即使前端被改非法時(shí)間也會(huì)被拒絕。一句話前端做體驗(yàn)后端做規(guī)則互不越界。6. 讓項(xiàng)目在答辯現(xiàn)場不翻車預(yù)置數(shù)據(jù)與演示路徑項(xiàng)目能跑和能演示是兩回事。很多同學(xué)代碼寫完了上臺(tái)演示時(shí)現(xiàn)場預(yù)約、現(xiàn)場等數(shù)據(jù)結(jié)果網(wǎng)絡(luò)慢、時(shí)間對不上、頁面轉(zhuǎn)圈。提前預(yù)置數(shù)據(jù)是最有效的規(guī)避手段。預(yù)置數(shù)據(jù)的核心原則讓演示路徑上的每一步都有「看起來真實(shí)」的數(shù)據(jù)支撐。下面這組 SQL 是三張表的最小演示數(shù)據(jù)集。-- 琴房 INSERT INTO piano_room (room_name, location, piano_type, is_open, open_time, close_time) VALUES (A101, 1號樓 1層, 立式鋼琴, 1, 08:00:00, 22:00:00), (A102, 1號樓 1層, 三角鋼琴, 1, 08:00:00, 22:00:00), (B201, 2號樓 2層, 電子鋼琴, 0, 09:00:00, 21:00:00); -- 用戶 INSERT INTO sys_user (openid, nickname, role, status) VALUES (demo_admin_openid, 管理員, 1, 1), (demo_student_openid, 演示學(xué)生, 0, 1); -- 預(yù)約一條待使用、一條已取消、一條已完成 INSERT INTO booking (room_id, user_id, book_date, start_time, end_time, status) VALUES (1, 2, DATE_ADD(CURDATE(), INTERVAL 1 DAY), 10:00:00, 11:00:00, 0), (1, 2, DATE_ADD(CURDATE(), INTERVAL 1 DAY), 14:00:00, 15:00:00, 2), (2, 2, DATE_ADD(CURDATE(), INTERVAL -1 DAY), 08:00:00, 09:00:00, 1);預(yù)約數(shù)據(jù)里用 DATE_ADD(CURDATE(), INTERVAL 1 DAY) 替代寫死的日期這個(gè)細(xì)節(jié)很關(guān)鍵它保證任何一天打開演示環(huán)境數(shù)據(jù)都是「明天有預(yù)約」不會(huì)因?yàn)闀r(shí)間推移全部過期。演示數(shù)據(jù)永遠(yuǎn)新鮮這是答辯演示最省心的一條技巧。演示路徑我一般按這個(gè)順序走登錄進(jìn)首頁看到三間琴房狀態(tài)各異 → 點(diǎn)開 A101 看到明天的時(shí)段列表 → 選 10:00-11:00 提交預(yù)約成功 → 切到「我的預(yù)約」看到剛剛的記錄 → 取消再重新預(yù)約 → 打開管理員視角看全部預(yù)約記錄。整條路徑覆蓋登錄、查詢、創(chuàng)建、取消、管理五個(gè)核心功能五分鐘講完節(jié)奏剛好。另一個(gè)容易忽略的點(diǎn)提前把演示用的賬號登錄態(tài)保持住別在現(xiàn)場等 wx.login 轉(zhuǎn)圈。正式演示前五分鐘在演示手機(jī)上完整走一遍登錄流程確認(rèn) token 有效再把小程序切到后臺(tái)待命?，F(xiàn)場只做操作不做登錄。做這個(gè)項(xiàng)目時(shí)我最大的教訓(xùn)是把「代碼寫完」當(dāng)成「項(xiàng)目做完」結(jié)果第一次聯(lián)調(diào)時(shí)被沖突檢測的邊界條件打臉。如果你正在做這個(gè)方向我建議把第 4 章的三種重疊用例寫進(jìn)測試跑通了再談演示。開發(fā)里多留一分敬畏答辯時(shí)就少一分慌張。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取 基于微信小程序的琴房預(yù)約管理系統(tǒng)：從數(shù)據(jù)庫到?jīng)_突檢測全解析
簡介面向高校計(jì)算機(jī)相關(guān)專業(yè)畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)場景這份微信小程序琴房管理系統(tǒng)項(xiàng)目包含完整源碼、說明文檔、LW及演示視頻。系統(tǒng)按學(xué)生與管理員雙角色設(shè)計(jì)學(xué)生端支持琴房查看、預(yù)約與公告瀏覽管理員端覆蓋學(xué)生信息管理、琴房公告發(fā)布及登錄注銷等操作業(yè)務(wù)鏈路完整適合需要快速理解小程序全棧開發(fā)并產(chǎn)出畢設(shè)成果的讀者。壓縮包共1105個(gè)文件大小約25.4MB以vue、js、java、class等前后端源碼文件為主輔以wxml/wxss小程序頁面、json配置、sql數(shù)據(jù)庫腳本、docx文檔以及png/svg界面素材和mp4演示視頻目錄結(jié)構(gòu)清晰、資源類型齊全。已有188人學(xué)習(xí)下載。包內(nèi)還附帶安裝/運(yùn)行/構(gòu)建的bat腳本、關(guān)鍵文件備份與常見配置說明結(jié)合演示視頻和說明文檔可幫助讀者梳理琴房預(yù)約的業(yè)務(wù)流程、接口設(shè)計(jì)及前后端交互細(xì)節(jié)便于二次開發(fā)與答辯準(zhǔn)備。1. 琴房管理系統(tǒng)怎么做這個(gè)微信小程序項(xiàng)目到底解決什么問題琴房管理在很多學(xué)校還停留在「微信群接龍 管理員人工排表」的階段學(xué)生接龍預(yù)約到了現(xiàn)場發(fā)現(xiàn)琴房被占用管理員每天花大量時(shí)間核對時(shí)間表、處理沖突。基于微信小程序的琴房管理系統(tǒng)把整套流程搬到線上——學(xué)生打開小程序查看琴房實(shí)時(shí)狀態(tài)、按時(shí)間段預(yù)約管理員維護(hù)琴房、管理預(yù)約記錄。這類項(xiàng)目常出現(xiàn)在畢業(yè)設(shè)計(jì)和課程設(shè)計(jì)中因?yàn)闃I(yè)務(wù)邊界清晰又完整覆蓋了小程序前端、服務(wù)端接口、數(shù)據(jù)庫設(shè)計(jì)和定時(shí)任務(wù)幾個(gè)模塊。第一次做小程序全棧項(xiàng)目選它能把前后端基本功都練到評估它值不值得做核心就看一點(diǎn)預(yù)約沖突怎么用最少的代碼擋住。本文把這條線從頭到尾講透。2. 需求拆解與數(shù)據(jù)庫建模琴房預(yù)約的核心是時(shí)間沖突檢測做這類系統(tǒng)別急著寫代碼先把業(yè)務(wù)流程和表結(jié)構(gòu)想清楚。后臺(tái)的編排決定了預(yù)約邏輯的復(fù)雜度一旦表結(jié)構(gòu)定錯(cuò)后面改起來牽一發(fā)動(dòng)全身。琴房管理系統(tǒng)翻來覆去就那么幾個(gè)頁面但真正考驗(yàn)設(shè)計(jì)能力的是預(yù)約這件事怎么用數(shù)據(jù)模型表達(dá)出來。2.1 三種角色與核心業(yè)務(wù)流程預(yù)約、取消、簽到怎么串系統(tǒng)的角色其實(shí)就三類學(xué)生、管理員、定時(shí)任務(wù)。學(xué)生側(cè)重在鏈路上走查看琴房列表 → 選擇日期與時(shí)間段 → 提交預(yù)約 → 到琴房簽到 → 完成使用。管理員側(cè)重維護(hù)維護(hù)琴房信息、查看所有預(yù)約、異常情況下強(qiáng)制取消。定時(shí)任務(wù)做兜底把超時(shí)未簽到的預(yù)約標(biāo)記為爽約把過期預(yù)約歸檔。業(yè)務(wù)規(guī)則上我一般會(huì)按這幾條定同一琴房同一日期同一時(shí)間段只能存在一條有效預(yù)約。預(yù)約開始時(shí)間必須早于結(jié)束時(shí)間且落在琴房營業(yè)時(shí)間內(nèi)。只能預(yù)約未來 7 天內(nèi)的時(shí)段不能預(yù)約過去的日期。取消預(yù)約必須在開始時(shí)間之前完成。預(yù)約開始后遲到 15 分鐘未簽到視為爽約。這些規(guī)則里最容易出錯(cuò)的是第 1 條——時(shí)間沖突。判斷兩個(gè)時(shí)間段是否重疊很多人第一反應(yīng)是「新預(yù)約的開始時(shí)間是否落在已有預(yù)約的區(qū)間里」這個(gè)直覺是錯(cuò)的。正確的判定公式是只要新時(shí)段的開始早于已有時(shí)段的結(jié)束且新時(shí)段的結(jié)束晚于已有時(shí)段的開始就必然重疊。這個(gè)公式貫穿整篇文章后面的 SQL 和代碼都在圍著它轉(zhuǎn)。2.2 用三張表把業(yè)務(wù)落地user、room、booking 的字段設(shè)計(jì)與索引核心就三張表字段不需要多夠用就行。下面是推薦的表結(jié)構(gòu)。-- 用戶表 CREATE TABLE sys_user ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, openid VARCHAR(64) NOT NULL COMMENT 微信用戶唯一標(biāo)識(shí), nickname VARCHAR(50) DEFAULT COMMENT 昵稱, student_no VARCHAR(20) DEFAULT COMMENT 學(xué)號管理員可錄入, role TINYINT NOT NULL DEFAULT 0 COMMENT 0-學(xué)生 1-管理員, status TINYINT NOT NULL DEFAULT 1 COMMENT 0-禁用 1-正常, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用戶表; -- 琴房表 CREATE TABLE piano_room ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, room_name VARCHAR(50) NOT NULL COMMENT 房間名如 A101, location VARCHAR(100) DEFAULT COMMENT 位置描述, piano_type VARCHAR(30) DEFAULT COMMENT 鋼琴類型, is_open TINYINT NOT NULL DEFAULT 1 COMMENT 0-關(guān)閉 1-開放, open_time TIME DEFAULT 08:00:00 COMMENT 營業(yè)開始, close_time TIME DEFAULT 22:00:00 COMMENT 營業(yè)結(jié)束, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT琴房表; -- 預(yù)約表 CREATE TABLE booking ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, room_id INT UNSIGNED NOT NULL COMMENT 琴房 id, user_id INT UNSIGNED NOT NULL COMMENT 用戶 id, book_date DATE NOT NULL COMMENT 預(yù)約日期, start_time TIME NOT NULL COMMENT 開始時(shí)間, end_time TIME NOT NULL COMMENT 結(jié)束時(shí)間, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-已預(yù)約 1-已完成 2-已取消 3-爽約, remark VARCHAR(200) DEFAULT COMMENT 備注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_room_time (room_id, book_date, start_time, end_time), KEY idx_user_status (user_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT預(yù)約表;幾個(gè)設(shè)計(jì)要點(diǎn)說明。user 表的 openid 必須加唯一索引。微信小程序登錄拿到的是 openid它是用戶在當(dāng)前小程序下的唯一身份標(biāo)識(shí)每次登錄都用它做插入或更新重復(fù)插入會(huì)直接報(bào)錯(cuò)也能防止同一個(gè)微信號注冊出多個(gè)賬號。booking 表的 idx_room_time 聯(lián)合索引是沖突查詢的關(guān)鍵。沖突檢測的 SQL 會(huì)按 room_id 加 book_date 過濾再用 start_time 和 end_time 做區(qū)間比較這個(gè)索引能讓查詢走 range scan 而不是全表掃描。數(shù)據(jù)量幾千條時(shí)差別不明顯但到上萬條后有沒有這個(gè)索引就是毫秒級和秒級的差別。status 字段用 TINYINT 數(shù)字而不是字符串。畢業(yè)設(shè)計(jì)里很多人習(xí)慣存 booked、cancelled 這種字符串看著直觀但索引效率和代碼可讀性都不如數(shù)字枚舉。前后端約定好 0/1/2/3 的含義后端定義常量類統(tǒng)一使用比到處寫魔法數(shù)強(qiáng)得多。2.3 接口清單與鑒權(quán)方式小程序端和服務(wù)端怎么分工接口按資源拆RESTful 風(fēng)格就夠不需要引入復(fù)雜框架。核心接口如下。接口方法核心入?yún)⒄f明/api/auth/loginPOSTcode用 wx.login 的 code 換登錄態(tài) token/api/room/listGET無琴房列表與開放狀態(tài)/api/room/detailGETroomId琴房詳情含營業(yè)時(shí)間與可預(yù)約時(shí)段/api/booking/createPOSTroomId、bookDate、startTime、endTime創(chuàng)建預(yù)約/api/booking/mineGET無當(dāng)前用戶的預(yù)約記錄/api/booking/cancelPOSTbookingId取消預(yù)約/api/booking/checkinPOSTbookingId到琴房簽到/api/admin/room/savePOST琴房信息管理員維護(hù)琴房鑒權(quán)有兩種常見做法。輕量一點(diǎn)的是后端生成隨機(jī) token 存到 Redis設(shè)過期時(shí)間小程序每次請求把 token 放在 Authorization 頭里重一點(diǎn)的是直接上 JWT登錄時(shí)簽發(fā)過期時(shí)間由服務(wù)端控制。對這個(gè)項(xiàng)目來說Redis token 方案更直觀也方便管理員端做強(qiáng)制下線我一般會(huì)用這種。后端用攔截器統(tǒng)一校驗(yàn)白名單放行登錄接口其余接口都要求攜帶有效 token管理員接口再額外查一次 role 字段。3. 小程序端實(shí)現(xiàn)登錄態(tài)、琴房列表和預(yù)約提交的關(guān)鍵代碼小程序端的核心頁面就三個(gè)琴房列表頁、預(yù)約頁、我的預(yù)約頁。這一章把代碼拆開講從登錄態(tài)到預(yù)約提交每一步給出能直接用的片段。所有請求都走 wx.request業(yè)務(wù)層把 url 和 data 組織好就行。3.1 微信登錄與 Token 會(huì)話管理code 換 token 的完整鏈路微信小程序的登錄鏈路是小程序調(diào)用 wx.login 拿到一次性 code后端拿 code 去微信接口換 openid 和 session_key再生成業(yè)務(wù) token 返回給小程序。code 只能用一次且有效期很短所以小程序端不能緩存 code每次啟動(dòng)都要重新調(diào)用 wx.login。// miniprogram/utils/auth.js const TOKEN_KEY token; function login() { return new Promise((resolve, reject) { wx.login({ success: (res) { if (!res.code) { reject(new Error(wx.login 未返回 code)); return; } wx.request({ url: getApp().globalData.apiBase /api/auth/login, method: POST, data: { code: res.code }, success: (resp) { if (resp.data.code 0) { const token resp.data.data.token; wx.setStorageSync(TOKEN_KEY, token); resolve(resp.data.data); } else { reject(new Error(resp.data.msg || 登錄失敗)); } }, fail: (err) reject(err) }); }, fail: (err) reject(err) }); }); } function getToken() { return wx.getStorageSync(TOKEN_KEY); } module.exports { login, getToken, TOKEN_KEY };邏輯說明wx.login 成功后拿到 code把它 POST 給后端后端用 code 換 openid 后生成 token 返回。前端把 token 放進(jìn)本地緩存后續(xù)所有請求從緩存取。參數(shù)上注意 apiBase 是后端服務(wù)地址開發(fā)階段指向局域網(wǎng) IP 加端口正式上線必須換成已配置 HTTPS 證書的域名。提示token 失效時(shí)后端通常會(huì)返回 401小程序端應(yīng)該封裝一個(gè)請求函數(shù)統(tǒng)一攔截 401 后自動(dòng)重新登錄并重放原請求。這個(gè)習(xí)慣能幫你省掉大量「登錄態(tài)過期」導(dǎo)致的現(xiàn)場翻車。關(guān)于 session_key它用于解密微信加密數(shù)據(jù)比如手機(jī)號。琴房管理系統(tǒng)如果只是用 openid 做身份識(shí)別session_key 在后端換完就可以丟棄不用存。見過不少同學(xué)把 session_key 也寫進(jìn) user 表沒有必要除非你還要做微信手機(jī)號授權(quán)。3.2 琴房列表與狀態(tài)展示拉取數(shù)據(jù)、渲染與下拉刷新琴房列表頁的要點(diǎn)是狀態(tài)展示。后端返回的 room 里帶 status 字段前端要把它翻譯成用戶能看懂的文字和顏色而不是直接把數(shù)字渲染到頁面上。// pages/room/room.js const { getToken } require(../utils/auth.js); Page({ data: { rooms: [], loading: false }, onShow() { this.fetchRooms(); }, onPullDownRefresh() { this.fetchRooms(true); }, fetchRooms(isRefresh false) { if (this.data.loading) return; this.setData({ loading: true }); wx.request({ url: getApp().globalData.apiBase /api/room/list, header: { Authorization: Bearer getToken() }, success: (res) { if (res.data.code 0) { const rooms res.data.data.map((room) ({ ...room, statusText: this.statusText(room.status), statusClass: room-status- room.status })); this.setData({ rooms }); } else { wx.showToast({ title: res.data.msg || 加載失敗, icon: none }); } }, complete: () { this.setData({ loading: false }); if (isRefresh) wx.stopPullDownRefresh(); } }); }, statusText(status) { const map { 0: 空閑, 1: 使用中, 2: 維護(hù)中 }; return map[status] || 未知; }, goBook(e) { const roomId e.currentTarget.dataset.id; wx.navigateTo({ url: /pages/book/book?roomId roomId }); } });對應(yīng)的 WXML 片段view classroom-card wx:for{{rooms}} wx:keyid view classroom-name{{item.roomName}}/view view classroom-location{{item.location}} · {{item.pianoType}}/view view classroom-status {{item.statusClass}}{{item.statusText}}/view button typeprimary sizemini bindtapgoBook>// pages/book/book.js const { getToken } require(../utils/auth.js); const SLOT_MINUTES 60; const MAX_ADVANCE_DAYS 7; Page({ data: { roomId: , room: null, dateList: [], dateIndex: 0, slotList: [], slotIndex: -1, submitting: false }, onLoad(options) { this.setData({ roomId: options.roomId }); this.buildDateList(); this.loadRoomDetail(); }, buildDateList() { const list []; const week [日, 一, 二, 三, 四, 五, 六]; for (let i 0; i MAX_ADVANCE_DAYS; i) { const d new Date(); d.setDate(d.getDate() i); const dateStr ${d.getFullYear()}-${String(d.getMonth() 1).padStart(2, 0)}-${String(d.getDate()).padStart(2, 0)}; const label i 0 ? 今天 : i 1 ? 明天 : ${d.getMonth() 1}月${d.getDate()}日 周${week[d.getDay()]}; list.push({ dateStr, label }); } this.setData({ dateList: list }); }, loadRoomDetail() { wx.request({ url: getApp().globalData.apiBase /api/room/detail, data: { roomId: this.data.roomId }, header: { Authorization: Bearer getToken() }, success: (res) { if (res.data.code 0) { this.setData({ room: res.data.data }); this.buildSlotList(); } } }); }, buildSlotList() { const room this.data.room; if (!room) return; const slots []; const openHour parseInt(room.openTime.slice(0, 2), 10); const closeHour parseInt(room.closeTime.slice(0, 2), 10); for (let h openHour; h SLOT_MINUTES / 60 closeHour; h) { const start ${String(h).padStart(2, 0)}:00:00; const end ${String(h SLOT_MINUTES / 60).padStart(2, 0)}:00:00; slots.push({ start, end, label: ${start.slice(0, 5)} - ${end.slice(0, 5)} }); } this.setData({ slotList: slots }); }, onDateChange(e) { this.setData({ dateIndex: Number(e.detail.value), slotIndex: -1 }); }, onSlotSelect(e) { this.setData({ slotIndex: Number(e.currentTarget.dataset.index) }); }, submit() { const { roomId, dateList, dateIndex, slotList, slotIndex, submitting } this.data; if (slotIndex 0) { wx.showToast({ title: 請選擇時(shí)間段, icon: none }); return; } if (submitting) return; this.setData({ submitting: true }); const date dateList[dateIndex].dateStr; const slot slotList[slotIndex]; wx.request({ url: getApp().globalData.apiBase /api/booking/create, method: POST, header: { Authorization: Bearer getToken() }, data: { roomId: roomId, bookDate: date, startTime: slot.start, endTime: slot.end }, success: (res) { if (res.data.code 0) { wx.showToast({ title: 預(yù)約成功, icon: success }); setTimeout(() wx.navigateBack(), 1500); } else { wx.showToast({ title: res.data.msg || 預(yù)約失敗, icon: none }); } }, complete: () { this.setData({ submitting: false }); } }); } });邏輯說明日期生成用循環(huán)加 7 天第一二天顯示「今天」「明天」后面的顯示具體日期和星期這個(gè)細(xì)節(jié)在演示時(shí)很加分。時(shí)間片按 room.openTime 和 closeTime 解析出小時(shí)數(shù)循環(huán)生成整點(diǎn)時(shí)段。submitting 標(biāo)志防止用戶重復(fù)點(diǎn)擊提交這個(gè)在預(yù)約場景里是必須的不然一次點(diǎn)擊發(fā)出兩個(gè)請求就會(huì)出現(xiàn)「我只點(diǎn)了一次怎么訂了兩條」。注意一個(gè)邊界時(shí)間片生成只考慮了整點(diǎn)如果琴房營業(yè)時(shí)間是 08:30 到 21:30這種寫法生成的時(shí)段會(huì)不準(zhǔn)。穩(wěn)妥的做法是后端在 room/detail 接口里直接返回可預(yù)約時(shí)間片數(shù)組前端只負(fù)責(zé)渲染。這樣營業(yè)時(shí)間、粒度、特殊日期的規(guī)則全部收斂在后端一處前端永遠(yuǎn)不用自己去推。4. 后端服務(wù)與沖突控制把預(yù)約規(guī)則寫成可執(zhí)行的代碼后端是這類系統(tǒng)的重頭戲。預(yù)約創(chuàng)建、沖突檢測、超時(shí)釋放這三塊寫好了項(xiàng)目核心邏輯就立住了。這一章以 Java Spring Boot 的寫法為例其他語言思路一致SQL 部分可以直接搬過去。4.1 預(yù)約創(chuàng)建的完整流程參數(shù)校驗(yàn)、沖突檢測與事務(wù)預(yù)約創(chuàng)建的接口不能只是簡單 insert它要按順序做五件事參數(shù)校驗(yàn)、琴房校驗(yàn)、營業(yè)時(shí)間校驗(yàn)、沖突檢測、插入。任何一步失敗都返回業(yè)務(wù)錯(cuò)誤。Transactional(rollbackFor Exception.class) public Booking createBooking(BookingDTO dto, Long userId) { // 1. 基本參數(shù)校驗(yàn) if (dto.getStartTime().compareTo(dto.getEndTime()) 0) { throw new BusinessException(開始時(shí)間必須早于結(jié)束時(shí)間); } if (dto.getBookDate().isBefore(LocalDate.now())) { throw new BusinessException(不能預(yù)約過去的日期); } // 2. 琴房存在且開放 PianoRoom room roomMapper.selectById(dto.getRoomId()); if (room null || room.getIsOpen() ! 1) { throw new BusinessException(琴房不存在或未開放); } // 3. 時(shí)間必須落在琴房營業(yè)時(shí)間范圍內(nèi) if (dto.getStartTime().isBefore(room.getOpenTime()) || dto.getEndTime().isAfter(room.getCloseTime())) { throw new BusinessException(預(yù)約時(shí)間超出琴房營業(yè)時(shí)間); } // 4. 行鎖 沖突檢測 int conflict bookingMapper.countConflictForUpdate( dto.getRoomId(), dto.getBookDate(), dto.getStartTime(), dto.getEndTime()); if (conflict 0) { throw new BusinessException(該時(shí)間段已被預(yù)約請選擇其他時(shí)間); } // 5. 插入預(yù)約記錄 Booking booking new Booking(); booking.setRoomId(dto.getRoomId()); booking.setUserId(userId); booking.setBookDate(dto.getBookDate()); booking.setStartTime(dto.getStartTime()); booking.setEndTime(dto.getEndTime()); booking.setStatus(BookingStatus.BOOKED); bookingMapper.insert(booking); return booking; }邏輯說明第 1 步擋住「開始晚于結(jié)束」和「預(yù)約過去日期」兩種低級錯(cuò)誤這類請求根本不該進(jìn)到數(shù)據(jù)庫。第 3 步校驗(yàn)營業(yè)時(shí)間前端選了 21:30 但琴房 21:00 關(guān)門這里直接拒絕。第 4 步是核心countConflictForUpdate 會(huì)先鎖住相關(guān)記錄再統(tǒng)計(jì)避免兩個(gè)并發(fā)請求同時(shí)通過檢查。第 5 步插入后事務(wù)提交整個(gè)過程要么全部成功要么全部回滾不會(huì)出現(xiàn)「沖突檢測通過了但插入失敗」的臟狀態(tài)。注意Transactional 一定要加 rollbackFor Exception.class。Spring 默認(rèn)只在 RuntimeException 時(shí)回滾拋?zhàn)远x checked 異常時(shí)事務(wù)不回滾數(shù)據(jù)就寫進(jìn)去了這個(gè)細(xì)節(jié)坑過很多人。還有一個(gè)容易踩的坑有的同學(xué)把沖突檢測拆成獨(dú)立 service 方法然后在 createBooking 里調(diào)用。如果這個(gè)方法沒有事務(wù)傳播檢查完再插入的間隙另一個(gè)請求可能已經(jīng)插入了同一時(shí)段。所以檢測和插入必須在同一個(gè)事務(wù)方法里這是硬要求。4.2 沖突檢測 SQL 的正確寫法區(qū)間重疊判定與索引利用沖突檢測的 SQL 是全文最重要的幾行代碼。select idcountConflictForUpdate resultTypeint SELECT COUNT(*) FROM booking WHERE room_id #{roomId} AND book_date #{bookDate} AND status 0 AND start_time lt; #{endTime} AND end_time gt; #{startTime} FOR UPDATE /select邏輯說明新預(yù)約時(shí)段是 [startTime, endTime]已有預(yù)約時(shí)段是 [start_time, end_time]。兩者重疊的充要條件是新開始時(shí)間早于已有結(jié)束時(shí)間且新結(jié)束時(shí)間晚于已有開始時(shí)間。寫成 SQL 就是 start_time #{endTime} AND end_time #{startTime}。再加 book_date 限定同一天status 0 只統(tǒng)計(jì)有效預(yù)約排除已取消和已歸檔的記錄。反例值得單獨(dú)說。有同學(xué)會(huì)寫成下面這兩種-- 反例一只覆蓋「完全包含」的情況 WHERE start_time #{startTime} AND end_time #{endTime} -- 反例二只看已有預(yù)約的開始時(shí)間是否落在新時(shí)段內(nèi) WHERE start_time BETWEEN #{startTime} AND #{endTime}反例一漏掉了「新時(shí)段橫跨已有時(shí)段」的部分重疊反例二漏掉了「已有時(shí)段橫跨新時(shí)段」的場景。實(shí)測中這兩種寫法會(huì)各放走一批沖突預(yù)約等管理員在后臺(tái)看到記錄重了再去手工取消就很被動(dòng)。FOR UPDATE 是 MySQL InnoDB 的行鎖語法配合 idx_room_time 索引它會(huì)鎖住命中的索引區(qū)間。并發(fā)場景下兩個(gè)請求同時(shí)查同一琴房同一天的數(shù)據(jù)后到的會(huì)等先到事務(wù)提交后才繼續(xù)這樣沖突檢測就變成串行執(zhí)行不會(huì)出現(xiàn)兩人同時(shí)訂走同一時(shí)段的情況。這個(gè)鎖粒度對這個(gè)項(xiàng)目足夠沒必要上 Redis 分布式鎖。idx_room_time 聯(lián)合索引room_id, book_date, start_time, end_time覆蓋了查詢的過濾條件MySQL 會(huì)走索引 range scan數(shù)據(jù)量到十萬級也不會(huì)慢。如果這個(gè)項(xiàng)目用于期末設(shè)計(jì)這屬于「可展示的性能設(shè)計(jì)點(diǎn)」答辯時(shí)值得拿出來講。4.3 超時(shí)釋放與簽到定時(shí)任務(wù)讓預(yù)約狀態(tài)自動(dòng)流轉(zhuǎn)預(yù)約狀態(tài)不能永遠(yuǎn)停在「已預(yù)約」。到了時(shí)間沒來系統(tǒng)要自動(dòng)釋放琴房并標(biāo)記爽約當(dāng)天用完了要標(biāo)記完成。這些靠定時(shí)任務(wù)和簽到接口配合完成。Component public class BookingScheduler { Autowired private BookingMapper bookingMapper; // 每分鐘跑一次已預(yù)約但開始時(shí)間已過 15 分鐘的標(biāo)記為爽約 Scheduled(cron 0 * * * * ?) public void markNoShow() { ListBooking list bookingMapper.findExpiredNoShows(); for (Booking b : list) { b.setStatus(BookingStatus.NO_SHOW); bookingMapper.updateById(b); } } // 每天凌晨 2 點(diǎn)把前一天的記錄批量歸檔為已完成 Scheduled(cron 0 0 2 * * ?) public void archiveYesterday() { bookingMapper.archiveByDate(LocalDate.now().minusDays(1)); } }對應(yīng)的 SQL-- 找出已超時(shí)未簽到的預(yù)約 SELECT * FROM booking WHERE status 0 AND (book_date CURDATE() OR (book_date CURDATE() AND start_time DATE_SUB(CURTIME(), INTERVAL 15 MINUTE)))邏輯說明markNoShow 的判定條件是「開始時(shí)間已過去 15 分鐘且狀態(tài)仍是已預(yù)約」。這里故意留 15 分鐘緩沖學(xué)生可能因?yàn)槁飞系R晚到幾分鐘直接到點(diǎn)就釋放很容易引發(fā)投訴。archiveYesterday 是每天凌晨的兜底任務(wù)把前一天未完成的記錄批量歸檔。cron 表達(dá)式里0 * * * * ?表示每分鐘第 0 秒執(zhí)行0 0 2 * * ?表示每天凌晨 2 點(diǎn)整執(zhí)行。簽到接口單獨(dú)說一下。學(xué)生到琴房后點(diǎn)「簽到」后端要校驗(yàn)該預(yù)約屬于當(dāng)前用戶、狀態(tài)是已預(yù)約、當(dāng)前時(shí)間不早于預(yù)約開始時(shí)間然后狀態(tài)改成已完成。有個(gè)細(xì)節(jié)容易漏預(yù)約明天 10:00現(xiàn)在簽到必須拒絕預(yù)約今天 10:00 而現(xiàn)在是 10:05允許簽到。只判斷「日期相等」而忽略當(dāng)前時(shí)刻會(huì)導(dǎo)致預(yù)約還沒開始就能提前簽到的笑話邏輯。到這里系統(tǒng)核心鏈路已經(jīng)通了前端選時(shí)間、后端擋住沖突、定時(shí)任務(wù)兜底釋放。第 5 章把開發(fā)中最高發(fā)的幾個(gè)問題集中排一遍雷。5. 琴房管理系統(tǒng)避坑指南5 個(gè)高發(fā)問題與排查方法這一章按「現(xiàn)象 → 原因 → 解決」的格式寫都是這個(gè)項(xiàng)目里反復(fù)出現(xiàn)的問題每一類我都見過不止一次。你如果正在調(diào)試直接對照著查比從頭翻日志快得多。5.1 沖突檢測漏掉「部分重疊」導(dǎo)致重復(fù)預(yù)約現(xiàn)象A 同學(xué)約了 10:00-11:00B 同學(xué)竟然還能約 10:30-11:30后臺(tái)出現(xiàn)兩條重疊預(yù)約。原因沖突檢測 SQL 寫成了 start_time #{startTime} AND end_time #{endTime}只判斷新時(shí)段是否完整包含在已有時(shí)段內(nèi)。B 的 10:30-11:30 和 A 的 10:00-11:00 是交叉重疊新開始 10:30 落在 A 的時(shí)段內(nèi)但新結(jié)束 11:30 超出了 A 的結(jié)束時(shí)間條件不成立于是被放行。解決改用區(qū)間重疊判定 start_time #{endTime} AND end_time #{startTime}。改完用三種用例驗(yàn)證新時(shí)段在已有時(shí)段內(nèi)部、新時(shí)段橫跨已有時(shí)段、新時(shí)段與已有時(shí)段首尾相接前兩個(gè)必須返回沖突第三個(gè)在邊界恰好相切時(shí)允許通過。我一般會(huì)把這幾個(gè)用例寫進(jìn)單元測試防止后續(xù)改動(dòng)時(shí)悄悄回歸。5.2 并發(fā)預(yù)約「超賣」同一時(shí)段被兩人同時(shí)訂走現(xiàn)象兩個(gè)學(xué)生同時(shí)間隔幾百毫秒提交同一琴房同一時(shí)段的預(yù)約兩個(gè)接口都返回成功數(shù)據(jù)庫里兩條記錄。原因沒有加鎖的「先查詢后插入」存在競態(tài)窗口。請求 A 查到?jīng)_突數(shù)為 0還沒插入請求 B 也查到?jīng)_突數(shù)為 0接著兩個(gè)請求都執(zhí)行插入沖突檢測形同虛設(shè)。解決在沖突檢測 SQL 末尾加 FOR UPDATE并讓檢測與插入處于同一事務(wù)中。后到的請求會(huì)等待先到事務(wù)提交后再執(zhí)行查詢此時(shí)沖突數(shù)變成 1預(yù)約被拒絕。如果項(xiàng)目用的是 PostgreSQL對應(yīng)語法是 FOR KEY SHARE如果不想依賴數(shù)據(jù)庫鎖可以在 booking 表加唯一索引room_id, book_date, start_time做兜底插入沖突時(shí)直接報(bào)錯(cuò)再用異常重試邏輯處理。5.3 預(yù)約時(shí)間憑空差 8 小時(shí)數(shù)據(jù)庫時(shí)區(qū)問題現(xiàn)象小程序端選了 10:00 提交數(shù)據(jù)庫里存的是 02:00管理后臺(tái)看到的預(yù)約時(shí)間全部不對。原因Java 的 LocalDateTime 和 MySQL 的 DATETIME 在時(shí)區(qū)解析上出現(xiàn)偏差。常見的是 JDBC 連接串里沒有指定 serverTimezone驅(qū)動(dòng)用了默認(rèn)時(shí)區(qū)跟服務(wù)器系統(tǒng)時(shí)區(qū)不一致導(dǎo)致時(shí)間偏移。解決在 JDBC 連接串上顯式指定時(shí)區(qū)寫成 jdbc:mysql://localhost:3306/piano?serverTimezoneAsia/Shanghai。同時(shí)約定前后端傳輸時(shí)間一律用字符串格式如 10:00:00不傳時(shí)間戳。TIME 類型本身不涉及時(shí)區(qū)換算用字符串傳遞能避開大部分時(shí)區(qū)坑。這屬于典型的「開發(fā)環(huán)境不出錯(cuò)、一換機(jī)器就翻車」的問題答辯前一定要換臺(tái)機(jī)器部署驗(yàn)證一遍。5.4 開發(fā)者工具正常、真機(jī)請求失敗域名與 HTTPS現(xiàn)象微信開發(fā)者工具里所有接口都通掃碼到真機(jī)上一片空白控制臺(tái)報(bào) request:fail url not in domain list。原因小程序真機(jī)環(huán)境強(qiáng)制要求后臺(tái)接口走 HTTPS且域名必須在小程序后臺(tái)配置為 request 合法域名。開發(fā)工具默認(rèn)不校驗(yàn)合法域名本地 http 接口能通但真機(jī)不認(rèn)。解決開發(fā)階段在開發(fā)者工具的詳情設(shè)置里勾選「不校驗(yàn)合法域名、TLS 版本以及 HTTPS 證書」這只解決本機(jī)調(diào)試。要真機(jī)完整跑通需要準(zhǔn)備一個(gè)已配置 HTTPS 證書的域名在小程序后臺(tái)配好 request 合法域名再把后端接口地址從局域網(wǎng) IP 換成線上域名。證書和域名校驗(yàn)是硬條件沒有捷徑。演示視頻建議在真機(jī)網(wǎng)絡(luò)通暢時(shí)錄制別在開發(fā)工具里錄兩者觀感差很多。5.5 前端選了合法時(shí)間、后端卻報(bào)「超出營業(yè)時(shí)間」現(xiàn)象前端時(shí)間選擇器最多到 21:00但用戶改一下請求參數(shù)就能提交 22:00 的預(yù)約或者前端按 60 分鐘生成時(shí)間片后端允許提交 30 分鐘的時(shí)段預(yù)約粒度混亂。原因前端的時(shí)間組裝邏輯和后端校驗(yàn)規(guī)則是兩套代碼沒有統(tǒng)一。用戶只要繞過前端界面直接調(diào)接口就能提交任意時(shí)間。解決把「可預(yù)約時(shí)段」的完整定義收斂到后端。常見做法是后端 room/detail 接口直接返回該琴房可預(yù)約的時(shí)間片數(shù)組前端渲染時(shí)直接用不做二次計(jì)算后端 create 接口再做兜底校驗(yàn)即使前端被改非法時(shí)間也會(huì)被拒絕。一句話前端做體驗(yàn)后端做規(guī)則互不越界。6. 讓項(xiàng)目在答辯現(xiàn)場不翻車預(yù)置數(shù)據(jù)與演示路徑項(xiàng)目能跑和能演示是兩回事。很多同學(xué)代碼寫完了上臺(tái)演示時(shí)現(xiàn)場預(yù)約、現(xiàn)場等數(shù)據(jù)結(jié)果網(wǎng)絡(luò)慢、時(shí)間對不上、頁面轉(zhuǎn)圈。提前預(yù)置數(shù)據(jù)是最有效的規(guī)避手段。預(yù)置數(shù)據(jù)的核心原則讓演示路徑上的每一步都有「看起來真實(shí)」的數(shù)據(jù)支撐。下面這組 SQL 是三張表的最小演示數(shù)據(jù)集。-- 琴房 INSERT INTO piano_room (room_name, location, piano_type, is_open, open_time, close_time) VALUES (A101, 1號樓 1層, 立式鋼琴, 1, 08:00:00, 22:00:00), (A102, 1號樓 1層, 三角鋼琴, 1, 08:00:00, 22:00:00), (B201, 2號樓 2層, 電子鋼琴, 0, 09:00:00, 21:00:00); -- 用戶 INSERT INTO sys_user (openid, nickname, role, status) VALUES (demo_admin_openid, 管理員, 1, 1), (demo_student_openid, 演示學(xué)生, 0, 1); -- 預(yù)約一條待使用、一條已取消、一條已完成 INSERT INTO booking (room_id, user_id, book_date, start_time, end_time, status) VALUES (1, 2, DATE_ADD(CURDATE(), INTERVAL 1 DAY), 10:00:00, 11:00:00, 0), (1, 2, DATE_ADD(CURDATE(), INTERVAL 1 DAY), 14:00:00, 15:00:00, 2), (2, 2, DATE_ADD(CURDATE(), INTERVAL -1 DAY), 08:00:00, 09:00:00, 1);預(yù)約數(shù)據(jù)里用 DATE_ADD(CURDATE(), INTERVAL 1 DAY) 替代寫死的日期這個(gè)細(xì)節(jié)很關(guān)鍵它保證任何一天打開演示環(huán)境數(shù)據(jù)都是「明天有預(yù)約」不會(huì)因?yàn)闀r(shí)間推移全部過期。演示數(shù)據(jù)永遠(yuǎn)新鮮這是答辯演示最省心的一條技巧。演示路徑我一般按這個(gè)順序走登錄進(jìn)首頁看到三間琴房狀態(tài)各異 → 點(diǎn)開 A101 看到明天的時(shí)段列表 → 選 10:00-11:00 提交預(yù)約成功 → 切到「我的預(yù)約」看到剛剛的記錄 → 取消再重新預(yù)約 → 打開管理員視角看全部預(yù)約記錄。整條路徑覆蓋登錄、查詢、創(chuàng)建、取消、管理五個(gè)核心功能五分鐘講完節(jié)奏剛好。另一個(gè)容易忽略的點(diǎn)提前把演示用的賬號登錄態(tài)保持住別在現(xiàn)場等 wx.login 轉(zhuǎn)圈。正式演示前五分鐘在演示手機(jī)上完整走一遍登錄流程確認(rèn) token 有效再把小程序切到后臺(tái)待命?，F(xiàn)場只做操作不做登錄。做這個(gè)項(xiàng)目時(shí)我最大的教訓(xùn)是把「代碼寫完」當(dāng)成「項(xiàng)目做完」結(jié)果第一次聯(lián)調(diào)時(shí)被沖突檢測的邊界條件打臉。如果你正在做這個(gè)方向我建議把第 4 章的三種重疊用例寫進(jìn)測試跑通了再談演示。開發(fā)里多留一分敬畏答辯時(shí)就少一分慌張。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取