簡介面向微信小程序開發(fā)學(xué)習(xí)者與Java全棧初學(xué)者這是一份駕校預(yù)約管理系統(tǒng)的完整源碼包。項(xiàng)目基于微信開發(fā)者工具后端采用SSM框架與MySQL數(shù)據(jù)庫B/S架構(gòu)分為學(xué)員、教練、管理員三類角色包含首頁、個(gè)人中心、學(xué)員管理、教練管理、駕校信息管理、駕校車輛管理、教練預(yù)約管理、考試信息管理、預(yù)約考試管理、系統(tǒng)管理等模塊游客無需登錄也可瀏覽公開信息。壓縮包共1209個(gè)文件以png、js、vue、java、json等類型為主涵蓋前端圖標(biāo)、小程序頁面、Vue后臺(tái)組件、Java接口與項(xiàng)目配置總大小12.28MB。目前已有463人下載學(xué)習(xí)。配套說明文檔與一鍵安裝、運(yùn)行、構(gòu)建腳本便于快速啟動(dòng)項(xiàng)目資源目錄劃分清晰適合課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)以及想理解小程序預(yù)約類系統(tǒng)完整實(shí)現(xiàn)流程的讀者參考。1. 駕校預(yù)約管理系統(tǒng)不是“做幾個(gè)頁面”是讓教練、時(shí)段、庫存和核銷轉(zhuǎn)成一條閉環(huán)駕校預(yù)約管理系統(tǒng)聽起來像是“選個(gè)教練、挑個(gè)時(shí)間、存一條記錄”但真拿去給駕校用你會(huì)發(fā)現(xiàn)最核心的需求是學(xué)員能自助約課、改期、取消教練能看到自己一天什么時(shí)候被約了前臺(tái)要能核銷、統(tǒng)計(jì)、處理爽約。這個(gè)標(biāo)題里的小程序項(xiàng)目就是把這一整套流程壓縮到微信里學(xué)員不裝 App、教練不拿紙質(zhì)表打開小程序就能操作。對(duì)剛接觸小程序開發(fā)的人來說它是一個(gè)比“電商練手”更貼近真實(shí)業(yè)務(wù)的樣本對(duì)正在接駕校、培訓(xùn)機(jī)構(gòu)私活的人來說它直接對(duì)得上驗(yàn)收清單。真正讓這類項(xiàng)目翻車的往往不是頁面難看而是“同一個(gè)時(shí)段被兩個(gè)人同時(shí)約上”這種并發(fā)問題以及預(yù)約狀態(tài)一亂、核銷對(duì)不上賬的連鎖反應(yīng)。下面按我自己的落地習(xí)慣把這套系統(tǒng)的選型、表結(jié)構(gòu)、前端實(shí)現(xiàn)和排錯(cuò)順序拆開講。2. 技術(shù)棧選型原生微信小程序還是 uni-app駕校預(yù)約為什么不能一上來就寫頁面2.1 原生微信小程序與 uni-app 的真實(shí)差異拿到“微信小程序項(xiàng)目之駕校預(yù)約管理系統(tǒng)”這種源碼包第一件事不是打開開發(fā)工具而是確定這套前端是用原生微信小程序?qū)懙倪€是 uni-app 轉(zhuǎn)出來的。兩者在工程結(jié)構(gòu)上差別很大原生工程里你會(huì)看到pages、app.js、app.json直接導(dǎo)入微信開發(fā)者工具就能跑uni-app 工程則是src/pages加uni_modules需要先npm install、再用 HBuilderX 或 CLI 打包成微信小程序產(chǎn)物目錄才是開發(fā)者工具能認(rèn)的。從落地角度說駕校預(yù)約這種業(yè)務(wù)基本只發(fā)生在微信生態(tài)里學(xué)員掃駕校的碼就進(jìn)小程序不存在“同一個(gè)人還要在支付寶里再約一次”的強(qiáng)需求。所以我一般建議除非你一早確定要同時(shí)發(fā)抖音、支付寶、微信三端否則不要為了“多端”硬上 uni-app。uni-app 確實(shí)能把一套 Vue 語法編譯到多端但代價(jià)是每次改完都要走一次“打包”流程遇到自定義組件、分包加載、原生插件時(shí)調(diào)試鏈路比原生長一截。很多新手在 uniapp 微信小程序打包時(shí)踩到source size 2612kb exceed max limit 2mb就是因?yàn)闆]有意識(shí)到小程序主包有 2MB 硬限制把圖片、SDK、公共庫全塞進(jìn)了一個(gè)包里。反過來說如果這個(gè)駕校預(yù)約項(xiàng)目是課程設(shè)計(jì)要求里面有“管理后臺(tái) 小程序 數(shù)據(jù)庫設(shè)計(jì)文檔”那 uni-app 也不是不能用因?yàn)楹笈_(tái)界面可以復(fù)用同一套 Vue 代碼做成 H5省得再寫一套。但你要接受一個(gè)事實(shí)出問題的人多數(shù)不在業(yè)務(wù)邏輯而在“打包出的包太大”或“原生組件不兼容”。所以我的選擇順序是單純做微信端、工期緊、想少踩坑用原生要交作業(yè)展示多端能力、后臺(tái)也要復(fù)用才考慮 uni-app并且從第一天就做分包。2.2 后端選型PHP / Java / Node 在預(yù)約場(chǎng)景里的取舍前端只是入口預(yù)約管理系統(tǒng)真正的體力活在接口層。常見的源碼包里后端出現(xiàn)頻率最高的是 PHP 和 Java Spring Boot也有 Node 寫的。駕駛培訓(xùn)行業(yè)的小型駕校通常已經(jīng)是 PHP 或 Java 的存量系統(tǒng)小程序只是新加一個(gè) C 端入口這時(shí)后端語言沒得選要順著老系統(tǒng)來。如果是從零開始我的建議是按你的維護(hù)能力選而不是按“哪個(gè)熱門”選。PHP 的優(yōu)勢(shì)是部署門檻低隨便一臺(tái)虛擬主機(jī)就能跑很多源碼包的說明文檔也是以 PHP MySQL 為主線適合課程設(shè)計(jì)或者小駕校自用。Java Spring Boot 適合要接大量并發(fā)、要寫復(fù)雜報(bào)表、要把預(yù)約和財(cái)務(wù)對(duì)賬打通的情況但環(huán)境要求高M(jìn)aven 依賴一堆新手第一次跑起來容易耗一小時(shí)在配置上。Node 適合本來就會(huì) JavaScript 的人寫接口快但線上部署和進(jìn)程守護(hù)要自己多留心。需要強(qiáng)調(diào)的是預(yù)約系統(tǒng)對(duì)后端的要求不只是“能存數(shù)據(jù)”而是“并發(fā)下不超賣”這一點(diǎn)跟語言無關(guān)跟事務(wù)和鎖的寫法有關(guān)。所以我會(huì)先把后端能力當(dāng)成“黑匣子”測(cè)試用并發(fā)請(qǐng)求打它而不是看它用了什么框架。2.3 拿到“源碼說明”包后先做三件事看文檔、倒數(shù)據(jù)庫、對(duì)接口約定標(biāo)題里帶著“(源碼說明)”說明包里應(yīng)該有配套文檔。我拿到這類項(xiàng)目包的習(xí)慣是先翻說明再看數(shù)據(jù)庫腳本最后才導(dǎo)入代碼。很多人的誤區(qū)是先把小程序跑起來結(jié)果白屏了才想起去看接口地址浪費(fèi)半小時(shí)。說明文檔里通常會(huì)寫清楚三件事數(shù)據(jù)庫初始化腳本在哪、后臺(tái)賬號(hào)密碼是什么、小程序需要改哪些配置項(xiàng)。這些信息不全時(shí)我會(huì)先按目錄猜常見結(jié)構(gòu)是server放后端、sql放建表語句、docs放設(shè)計(jì)文檔。數(shù)據(jù)庫腳本導(dǎo)入后我會(huì)重點(diǎn)核對(duì)幾張表用戶表、教練表、課時(shí)表、預(yù)約表。駕校預(yù)約的核心資源不是學(xué)員而是“教練 車 時(shí)段”的組合。如果表里沒有記錄“每個(gè)時(shí)段最多可預(yù)約人數(shù)”的字段那這個(gè)源碼包的預(yù)約邏輯大概率是閹割版——先查再插入并發(fā)一高就會(huì)重復(fù)預(yù)約。這一步確認(rèn)清楚后面所有頁面開發(fā)才會(huì)踏實(shí)。小程序端要改的無非是app.js里的request域名、登錄密鑰以及每個(gè)接口的url前綴。記住源碼包能不能落地不在代碼多高級(jí)而在接口約定和數(shù)據(jù)字典能不能對(duì)上。3. 數(shù)據(jù)模型與預(yù)約狀態(tài)機(jī)先把“庫存”算清楚再寫接口3.1 駕校預(yù)約管理系統(tǒng)的表結(jié)構(gòu)設(shè)計(jì)預(yù)約系統(tǒng)最怕“看起來像論壇約個(gè)課就是插一條記錄”。如果約課只是往appointment表里 insert那同一時(shí)間教練就會(huì)被兩個(gè)人同時(shí)約走因?yàn)檎l都沒有檢查“這個(gè)時(shí)段還剩幾個(gè)名額”。所以第一步是設(shè)計(jì)出能反映資源庫存的表結(jié)構(gòu)。駕校的核心資源是教練和教練車一個(gè)教練一天可以分多個(gè)時(shí)段每個(gè)時(shí)段理論上只能服務(wù)固定數(shù)量學(xué)員通常是一對(duì)一。我常用的建表語句如下CREATE TABLE coach ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, phone VARCHAR(20), status TINYINT DEFAULT 1 COMMENT 1可用 0停用 ); CREATE TABLE course_schedule ( id INT PRIMARY KEY AUTO_INCREMENT, coach_id INT NOT NULL, course_date DATE NOT NULL, slot_id INT NOT NULL COMMENT 時(shí)段編號(hào) 1上午 2下午 3晚上, capacity INT DEFAULT 1 COMMENT 該時(shí)段可約人數(shù), booked INT DEFAULT 0 COMMENT 已約人數(shù), version INT DEFAULT 0 COMMENT 樂觀鎖版本號(hào), UNIQUE KEY uk_date_slot (coach_id, course_date, slot_id) ); CREATE TABLE appointment ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, schedule_id INT NOT NULL, status TINYINT DEFAULT 1 COMMENT 1已預(yù)約 2已取消 3已完成 4爽約, cancel_reason VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_schedule (student_id, schedule_id) );這套結(jié)構(gòu)強(qiáng)調(diào)三件事。第一course_schedule是庫存表capacity和booked分別代表總量和已約量每次預(yù)約都要保證booked capacity。第二教練、日期、時(shí)段三個(gè)字段組成唯一索引防止同一批數(shù)據(jù)里出現(xiàn)重復(fù)排課。第三appointment表里不直接存教練和時(shí)段而是存schedule_id這樣改排課表的時(shí)候預(yù)約記錄不用跟著動(dòng)。version字段先留著后面做樂觀鎖要用。實(shí)際項(xiàng)目里我還會(huì)加一個(gè)cancel_log表記錄取消操作因?yàn)轳{校經(jīng)常需要知道“誰頻繁爽約、哪個(gè)時(shí)段的取消率最高”。這不算過度設(shè)計(jì)是運(yùn)營必須的數(shù)據(jù)。你要是嫌表多起碼也要把a(bǔ)ppointment里的狀態(tài)字段留出來否則后面做核銷的時(shí)候會(huì)發(fā)現(xiàn)根本沒有狀態(tài)可流轉(zhuǎn)。3.2 防止重復(fù)預(yù)約的原子扣減與狀態(tài)流轉(zhuǎn)預(yù)約接口寫得好不好直接在并發(fā)下見分曉。最常見的錯(cuò)誤寫法是先SELECT booked FROM course_schedule WHERE id ?判斷小于 capacity再INSERT INTO appointment最后UPDATE course_schedule SET booked booked 1。這一步看代碼沒毛病但兩個(gè)學(xué)員同時(shí)請(qǐng)求時(shí)兩個(gè)請(qǐng)求都讀到booked0然后都插入預(yù)約記錄最后都執(zhí)行加一結(jié)果這里約滿了兩個(gè)人實(shí)際上超賣了。正確做法是把“檢查庫存 扣減”放在一個(gè)原子操作里用數(shù)據(jù)庫的行鎖保證同一時(shí)刻只有一個(gè)請(qǐng)求能成功扣減UPDATE course_schedule SET booked booked 1 WHERE id ? AND booked capacity;這條 UPDATE 影響行數(shù)為 1說明扣減成功才允許繼續(xù)插入預(yù)約記錄影響行數(shù)為 0說明時(shí)段已滿直接返回“該時(shí)段已約滿”?？弁陰齑嬖俨迦腩A(yù)約并且這兩個(gè)動(dòng)作要在同一個(gè)事務(wù)里任何一步失敗都要回滾讓booked恢復(fù)原樣。后端代碼里大概是這個(gè)形態(tài)// 以 Node 為例使用 mysql2 驅(qū)動(dòng) const conn await pool.getConnection(); try { await conn.beginTransaction(); const [result] await conn.execute( UPDATE course_schedule SET booked booked 1 WHERE id ? AND booked capacity, [scheduleId] ); // affectedRows 1 才代表搶到了名額 if (result.affectedRows 0) { await conn.rollback(); return { code: 1, message: 該時(shí)段已約滿請(qǐng)換一個(gè)時(shí)段 }; } await conn.execute( INSERT INTO appointment (student_id, schedule_id, status) VALUES (?, ?, 1), [studentId, scheduleId] ); await conn.commit(); return { code: 0, message: 預(yù)約成功 }; } catch (err) { await conn.rollback(); throw err; } finally { conn.release(); }參數(shù)說明affectedRows是 MySQL 執(zhí)行 UPDATE 后返回的受影響行數(shù)它能告訴你這個(gè) UPDATE 是不是真正改到了數(shù)據(jù)。這里的scheduleId是預(yù)約接口傳入的排課記錄 IDstudentId是登錄后服務(wù)端解析出來的用戶 ID不能拿前端傳的 userId 直接用不然學(xué)員可以把別人的 ID 塞進(jìn)來替別人約課。事務(wù)的beginTransaction和commit保證“扣庫存”和“建預(yù)約”要么同時(shí)成功要么同時(shí)失敗。3.3 取消預(yù)約與時(shí)段過期庫存回滾和違約標(biāo)記怎么處理有預(yù)約就必然有取消取消邏輯看起來只是把a(bǔ)ppointment的狀態(tài)改成“已取消”但別忘了把庫存還回去。這一步同樣要放在事務(wù)里先改預(yù)約狀態(tài)再booked booked - 1。順序別反不然出現(xiàn)“狀態(tài)已取消但庫存沒恢復(fù)”的半截?cái)?shù)據(jù)后面統(tǒng)計(jì)約滿率全錯(cuò)。駕校場(chǎng)景比較特殊的是“爽約”的處理。學(xué)員約了早上八點(diǎn)的課教練把車和人都空出來了學(xué)員沒來這個(gè)時(shí)段已經(jīng)不可能再補(bǔ)給別人所以不能簡單地取消并回滾庫存而是要標(biāo)記為“爽約”系統(tǒng)可以記一次違約累計(jì)多次限制預(yù)約。實(shí)現(xiàn)上我一般會(huì)根據(jù)當(dāng)前時(shí)間判斷距離預(yù)約時(shí)段開始還有足夠時(shí)間比如 4 小時(shí)允許正常取消并回滾庫存如果已進(jìn)入倒計(jì)時(shí)或者已經(jīng)過了開始時(shí)間就只能由管理員手動(dòng)取消學(xué)員端只能看到“已過期”狀態(tài)。這種規(guī)則不寫死在 SQL 里而是由后端在取消接口里判斷前端只負(fù)責(zé)引導(dǎo)用戶確認(rèn)。狀態(tài)流轉(zhuǎn)的完整鏈條是已預(yù)約 → 已取消 / 已完成 / 爽約。核銷動(dòng)作只允許把已預(yù)約變成已完成取消動(dòng)作只允許把已預(yù)約變成已取消。如果表里出現(xiàn)“已取消”直接跳到“已完成”的記錄基本可以判定接口邏輯里少了狀態(tài)校驗(yàn)。調(diào)試的時(shí)候可以在后端加一個(gè)狀態(tài)機(jī)的校驗(yàn)函數(shù)每次更新狀態(tài)時(shí)檢查“當(dāng)前狀態(tài)是否允許跳到目標(biāo)狀態(tài)”不滿足就報(bào)錯(cuò)。這一步能擋住大多數(shù)臟數(shù)據(jù)。4. 小程序端從登錄到核銷手寫核心頁面與請(qǐng)求邏輯4.1 微信小程序登錄獲取手機(jī)號(hào)兩種方式怎么選駕校預(yù)約一定要拿到學(xué)員手機(jī)號(hào)因?yàn)轭A(yù)約成功要發(fā)通知、教練要聯(lián)系學(xué)員確認(rèn)上車點(diǎn)。微信小程序登錄獲取手機(jī)號(hào)有兩種常見方式選錯(cuò)會(huì)直接影響審核和上線。第一種是傳統(tǒng)方式用wx.login拿到臨時(shí)code發(fā)給后端后端調(diào)用微信接口換openid然后讓學(xué)員在小程序里手填手機(jī)號(hào)后端發(fā)驗(yàn)證碼。這種方式實(shí)現(xiàn)簡單、不用企業(yè)認(rèn)證也能測(cè)通但用戶體驗(yàn)多了一步并且驗(yàn)證碼短信有成本。第二種是使用微信提供的手機(jī)號(hào)快速驗(yàn)證組件學(xué)員點(diǎn)一下授權(quán)按鈕微信直接把手機(jī)號(hào)傳給后端體驗(yàn)最好但要求小程序必須完成認(rèn)證且該能力對(duì)個(gè)人主體小程序不開放。很多個(gè)人開發(fā)者在這里會(huì)被卡住審核時(shí)發(fā)現(xiàn)沒有權(quán)限只能退回手填手機(jī)號(hào)。我這里建議如果是公司主體的駕校項(xiàng)目優(yōu)先用手機(jī)號(hào)快速驗(yàn)證組件如果是個(gè)人項(xiàng)目或畢設(shè)就老老實(shí)實(shí)走“登錄 手填手機(jī)號(hào) 短信驗(yàn)證”。核心代碼大致是// 前端手機(jī)號(hào)快速驗(yàn)證組件 button open-typegetPhoneNumber bindgetphonenumberonGetPhone 獲取手機(jī)號(hào) /button// 前端拿到加密數(shù)據(jù)后交給后端解析 Page({ async onGetPhone(e) { if (e.detail.errMsg ! getPhoneNumber:ok) { wx.showToast({ title: 需要授權(quán)手機(jī)號(hào), icon: none }); return; } const res await wx.cloud.callFunction({ name: decodePhone, data: { code: e.detail.code } }); // res.result.phone 就是手機(jī)號(hào) } });參數(shù)說明e.detail.code是微信返回的動(dòng)態(tài)令牌只能在后端配合 session_key 換取手機(jī)號(hào)不能在前端直接讀出手機(jī)明文。如果是普通 HTTP 后端前端只能把code原樣 POST 給服務(wù)端服務(wù)端再按文檔調(diào)接口。這里最容易踩的坑是把openid和手機(jī)號(hào)混為一談OpenID 只能標(biāo)識(shí)“這是哪個(gè)微信用戶”不能當(dāng)手機(jī)號(hào)用。4.2 選教練、選時(shí)段、提交預(yù)約的核心代碼預(yù)約頁面的交互主線是選日期 → 選教練 → 選時(shí)段 → 提交。提交前要把日期、教練、時(shí)段拼成可校驗(yàn)的三個(gè)參數(shù)傳給后端后端再拿著教練 ID 和日期去查排課表。前端代碼不復(fù)雜但“重復(fù)提交”這個(gè)坑必須防用戶手快點(diǎn)兩次按鈕就可能發(fā)出兩個(gè)相同請(qǐng)求即使后端有庫存扣減兜底也會(huì)產(chǎn)生兩條預(yù)約記錄。所以提交按鈕要在請(qǐng)求發(fā)出后立即禁用成功或失敗后再恢復(fù)。!-- wxml 片段 -- view classslot-list view wx:for{{slots}} wx:keyslotId classslot-item {{item.disabled ? disabled : }} >Page({ data: { date: , coachId: , slotId: , submitting: false }, onSelectSlot(e) { this.setData({ slotId: e.currentTarget.dataset.id }); }, async onSubmit() { const { date, coachId, slotId, submitting } this.data; if (submitting) return; // 重復(fù)提交攔截 if (!date || !coachId || !slotId) { wx.showToast({ title: 請(qǐng)選擇完整, icon: none }); return; } this.setData({ submitting: true }); try { const res await wx.request({ url: https://api.example.com/appointment/create, method: POST, data: { date, coachId, slotId } }); if (res.data.code 0) { wx.showToast({ title: 預(yù)約成功, icon: success }); // 跳轉(zhuǎn)到預(yù)約記錄頁 } else { wx.showToast({ title: res.data.message, icon: none }); } } finally { this.setData({ submitting: false }); } } });這里的date是形如2025-06-15的日期字符串slotId是排課表里具體的時(shí)段 ID而不是“上午”“下午”這種前端自己翻譯出來的值。后端必須用slotId coachId作為唯一鍵去查course_schedule不要用日期加中文時(shí)段名去拼否則數(shù)據(jù)庫里存什么你會(huì)徹底失控。wx.request的url必須是https且在微信公眾平臺(tái)配過合法域名開發(fā)時(shí)可以在開發(fā)者工具里關(guān)掉域名校驗(yàn)但真機(jī)預(yù)覽就一定要配好。4.3 自定義導(dǎo)航欄與頁面?zhèn)鲄㈨敳繉?dǎo)航欄高度怎么適配預(yù)約系統(tǒng)里“本周日期橫滑選擇器”很常見這種頁面通常想用自定義導(dǎo)航欄才能把標(biāo)題欄和選擇器做成一體。自定義導(dǎo)航欄不是把navigationStyle改成custom就完事真正麻煩的是狀態(tài)欄高度和膠囊按鈕位置在不同的手機(jī)上都不同適配不好就會(huì)出現(xiàn)標(biāo)題頂?shù)綌z像頭、按鈕錯(cuò)位的情況。微信沒有直接暴露狀態(tài)欄高度一般用wx.getMenuButtonBoundingClientRect()拿膠囊按鈕的位置再結(jié)合wx.getSystemInfoSync()里的statusBarHeight算導(dǎo)航欄總高度。常見做法是const rect wx.getMenuButtonBoundingClientRect(); const system wx.getSystemInfoSync(); const navHeight rect.bottom (rect.top - system.statusBarHeight) * 2;這段代碼里navHeight是自定義導(dǎo)航欄的推薦高度單位是 px。rect.top是膠囊到屏幕頂部的距離system.statusBarHeight是系統(tǒng)狀態(tài)欄高度兩者的差值就是膠囊上方的留白乘以 2 再加膠囊底部的留白基本能得到一個(gè)視覺協(xié)調(diào)的導(dǎo)航欄高度。拿到這個(gè)值后設(shè)置成外層容器的padding-top整個(gè)頁面內(nèi)容就不會(huì)被劉海屏吞掉。很多參考項(xiàng)目里寫死44px在全面屏上就會(huì)顯得局促這是微信小程序頂部導(dǎo)航欄高度這個(gè)熱搜詞背后最常被問的問題。字段傳參方面從列表頁跳到詳情頁參數(shù)復(fù)雜時(shí)要用encodeURIComponent包一層防止特殊字符截?cái)唷?. 預(yù)約系統(tǒng)的常見坑與排錯(cuò)從白屏到重復(fù)預(yù)約5.1 現(xiàn)象真機(jī)預(yù)覽白屏模擬器正常模擬器里能正常打開真機(jī)預(yù)覽卻是白屏第一反應(yīng)不應(yīng)該是查代碼而是查“請(qǐng)求域名”。微信開發(fā)者工具默認(rèn)勾選了“不校驗(yàn)合法域名”所以工具里請(qǐng)求任何 HTTP 接口都能通甚至localhost也行。真機(jī)上這個(gè)校驗(yàn)是強(qiáng)制生效的未配置的域名直接請(qǐng)求失敗頁面拿不到數(shù)據(jù)就白在那里。解決方法是登錄微信公眾平臺(tái)在“開發(fā)管理 → 服務(wù)器域名”里把后端接口的 HTTPS 域名加到request合法域名列表而且域名必須是備案過的不能是 IP。如果你只是臨時(shí)演示也可以打開開發(fā)者工具的真機(jī)調(diào)試并在“項(xiàng)目設(shè)置”里勾選“不校驗(yàn)合法域名”但這樣只能給你自己看發(fā)給別人一樣白屏。這個(gè)坑在校驗(yàn)域名前后最容易讓人誤判成“代碼寫錯(cuò)了”其實(shí)后端日志里全是 CORS 或證書報(bào)錯(cuò)。5.2 現(xiàn)象兩個(gè)學(xué)員“同時(shí)”約到了同一個(gè)時(shí)段約同一個(gè)時(shí)段兩個(gè)人都收到“預(yù)約成功”這是并發(fā)問題最典型的形態(tài)。原因基本可以鎖定為后端先 SELECT 再 INSERT沒有把“檢查名額”和“扣減名額”做成原子操作。兩條請(qǐng)求同時(shí)讀到booked0都認(rèn)為自己還有名額于是都插入成功。解決辦法就是把 3.2 里的原子 UPDATE 用起來配合事務(wù)。如果業(yè)務(wù)太復(fù)雜一條 SQL 解決不了也可以給course_schedule表加樂觀鎖UPDATE 時(shí)帶version當(dāng)前版本更新成功后version1失敗就重試。但原子 UPDATE 已經(jīng)足夠覆蓋駕校預(yù)約這種量級(jí)。修復(fù)后一定要用并發(fā)工具跑一次復(fù)測(cè)見 6.1。5.3 現(xiàn)象日期選完列表不刷新約到的還是前一天時(shí)段列表沒跟著日期變多半是頁面把第一次加載的數(shù)據(jù)緩存住了或者change事件里用的日期格式不對(duì)。常見原因有兩個(gè)一是日期組件返回的是new Date()對(duì)象直接setData后變成了字符串接口收到后解析出“昨天”二是小程序頁面棧的上一頁沒有在onShow里重新拉取數(shù)據(jù)導(dǎo)致返回時(shí)列表還是舊的。解決方法是前端先把日期格式化成YYYY-MM-DD再傳給后端預(yù)約記錄頁在onShow里重新調(diào)用列表接口而不是依賴onLoad只加載一次。如果后端返回的日期比前端少了 8 小時(shí)那就是時(shí)區(qū)問題統(tǒng)一在接口層約定按YYYY-MM-DD的字符串傳參不要傳“相對(duì)當(dāng)前時(shí)間”的時(shí)間戳。5.4 現(xiàn)象體驗(yàn)版登錄不上后端一直報(bào) code 無效wx.login返回的code是有時(shí)效且只能用一次的。如果你后端的登錄解密邏輯把同一個(gè)code連續(xù)拿去換openid第二次就會(huì)報(bào)“code 無效”。還有一個(gè)很隱蔽的問題開發(fā)者工具里的appid和體驗(yàn)版所屬的appid不一致前端拿到的是 A 項(xiàng)目的 code后端用了 B 項(xiàng)目的密鑰去解必然失敗。解決方法是先核對(duì)小程序后臺(tái)的 appid 和后端配置的 appid 是否一致再檢查登錄接口是否對(duì)同一個(gè) code 做了緩存。最容易忽略的是一鍵登錄按鈕被用戶點(diǎn)了兩遍前端每點(diǎn)一次就調(diào)一次wx.login但用戶心態(tài)是“手機(jī)號(hào)沒出來就再點(diǎn)一下”導(dǎo)致舊 code 被重復(fù)使用。前端要做防重復(fù)點(diǎn)擊后端要做 code 消費(fèi)失敗時(shí)的友好報(bào)錯(cuò)。5.5 現(xiàn)象uniapp 打包后主包超過 2MB 上限如果你用的是 uni-app編譯成微信小程序時(shí)經(jīng)?？吹絪ource size 2612kb exceed max limit 2mb。這不代表你的業(yè)務(wù)有多龐大而是很多依賴被打進(jìn)了主包。最常見的是把完整的uview、colorui這類 UI 庫全量引入或者把后端 SDK、加密庫都塞進(jìn)main.js再或者圖片直接 base64 進(jìn)代碼里。解決思路是分包、抽組件、圖片走 CDN。微信小程序主包只放頁面骨架和公共依賴教練詳情、預(yù)約記錄、用戶中心這些低頻頁面全部放到subpackages里從頁面名到資源路徑都要對(duì)應(yīng)調(diào)整。UI 庫改成按需引入如果只是用幾個(gè)組件復(fù)制對(duì)應(yīng)文件過來反而比全量引入更小。這里的取舍是主包大小決定首屏加載速度分包越干凈真機(jī)體驗(yàn)越順調(diào)試時(shí)也不至于為 2MB 邊界反復(fù)重構(gòu)。6. 讓預(yù)約系統(tǒng)經(jīng)得起真車流量壓測(cè)、訂閱消息與核銷閉環(huán)6.1 用最簡單的方式給預(yù)約接口做并發(fā)壓測(cè)?？荚囶A(yù)約、寒暑假約車高峰期流量會(huì)突然漲起來。不要等到上線當(dāng)天才發(fā)現(xiàn)接口扛不住用wrk或者一段帶Promise.all的 Node 腳本就能模擬并發(fā)。重點(diǎn)壓兩個(gè)接口創(chuàng)建預(yù)約和取消預(yù)約。壓測(cè)時(shí)關(guān)注三件事有沒有超賣、響應(yīng)時(shí)間是否穩(wěn)定、數(shù)據(jù)庫連接池有沒有爆。命令行跑法如下wrk -t4 -c50 -d10s -s create-appointment.lua http://api.example.com/appointment/create壓測(cè)腳本會(huì)帶不同studentId并發(fā)發(fā)起預(yù)約。跑完不要只盯著 QPS 數(shù)字而是對(duì)數(shù)據(jù)庫查一遍course_schedule的booked是否等于appointment表里狀態(tài)為“已預(yù)約”的記錄數(shù)。對(duì)不上就是邏輯有洞對(duì)得上并且響應(yīng)時(shí)間控制在幾百毫秒內(nèi)才算過基本門檻。這個(gè)測(cè)試要留著每次都跑比改完代碼拍胸脯有用得多。6.2 訂閱消息預(yù)約成功提醒的正確觸發(fā)方式駕校預(yù)約成功后學(xué)員需要收到“預(yù)約成功”“明日練車提醒”之類的通知。微信官方現(xiàn)在把模板消息換成了訂閱消息關(guān)鍵限制是小程序必須在用戶點(diǎn)擊按鈕時(shí)調(diào)wx.requestSubscribeMessage不能在接口返回成功后再偷偷彈窗。也就是說提交預(yù)約的按鈕事件里應(yīng)該先讓用戶確認(rèn)訂閱授權(quán)再發(fā)預(yù)約請(qǐng)求。async onSubmit() { await wx.requestSubscribeMessage({ tmplIds: [預(yù)約成功通知模板ID] }); // 用戶選“總是保持以上選擇”或點(diǎn)允許后再走預(yù)約接口 this.doCreateAppointment(); }注意這個(gè)授權(quán)結(jié)果只代表“下一次消息可以發(fā)”不能存下來長期發(fā)。如果用戶拒絕預(yù)約流程也要繼續(xù)只是不發(fā)通知。所以這里不要因?yàn)橛脩魶]點(diǎn)允許就中斷預(yù)約而是把它做成一個(gè)增強(qiáng)體驗(yàn)。真正的重要信息比如“教練臨時(shí)請(qǐng)假”還需要在后端做二次確認(rèn)機(jī)制不能只依賴訂閱消息。6.3 二維碼核銷與取消預(yù)約的回滾順序教練端“掃一掃核銷”是這個(gè)系統(tǒng)的最后一環(huán)。學(xué)員預(yù)約成功后后端生成一個(gè)帶預(yù)約號(hào)或簽名字符串的二維碼教練用小程序的掃一掃功能讀取再調(diào)核銷接口。核銷接口必須冪等同一個(gè)二維碼掃第二次后端要返回“該預(yù)約已完成”而不是報(bào)錯(cuò)或再次核銷成功。實(shí)現(xiàn)上預(yù)約號(hào)用隨機(jī)串生成數(shù)據(jù)庫里加唯一索引核銷時(shí)先查狀態(tài)再原子更新UPDATE appointment SET status 3 WHERE id ? AND status 1;這條 SQL 只有狀態(tài)為“已預(yù)約”的記錄會(huì)被更新成“已完成”影響行數(shù)為 0 就說明狀態(tài)已變化直接給前端返回“不可重復(fù)核銷”。至于取消預(yù)約的回滾順序一定是先改預(yù)約狀態(tài)為“已取消”再讓course_schedule的booked減一。如果先減庫存再改狀態(tài)中間出現(xiàn)異常就會(huì)出現(xiàn)“約了課的人沒記錄、名額卻空出來”的永久性臟數(shù)據(jù)。把這兩個(gè)操作放進(jìn)同一個(gè)事務(wù)讓 MySQL 替你保證要么都成功、要么都失敗。我做第一個(gè)預(yù)約項(xiàng)目時(shí)就吃過這個(gè)虧取消了三條記錄后庫存全部對(duì)不上只能手動(dòng)寫腳本清洗那感覺比改代碼痛苦得多。這些邊界問題都處理完這套駕校預(yù)約管理系統(tǒng)才算真正能交付而不是只能在模擬器里點(diǎn)兩下。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取