最近好幾個高校的實(shí)驗(yàn)室管理員朋友跑來問我能不能把實(shí)驗(yàn)室預(yù)約從“微信群接龍Excel排課表”里解放出來。聊了一圈我給的方案都是同一個小程序 Python后端做一套實(shí)驗(yàn)室預(yù)約排課系統(tǒng)。小程序負(fù)責(zé)學(xué)生端和管理員端的使用入口Python負(fù)責(zé)預(yù)約規(guī)則、排課沖突檢測和數(shù)據(jù)接口這套組合對于實(shí)驗(yàn)室這類場景來說輕量、夠用、還特別好落地。這篇文章把我做這個系統(tǒng)的完整思路、核心代碼和踩過的坑一次說清楚正在做類似課設(shè)或者真想給實(shí)驗(yàn)室做個小工具的朋友可以直接拿走參考。1. 項(xiàng)目整體設(shè)計(jì)與技術(shù)選型1.1 為什么前端選小程序而不是App或Web頁面實(shí)驗(yàn)室預(yù)約這個場景有個特點(diǎn)使用頻次不算高但用的時候都特別急。今天老師臨時調(diào)課學(xué)生小組明天要做實(shí)驗(yàn)沒人愿意為了預(yù)約一次額外下載一個App。小程序天然適合這種“低頻剛需”的場景掃碼進(jìn)入、用完即走不用安裝也不用擔(dān)心安卓和蘋果應(yīng)用市場的審核流程。如果你還在糾結(jié)要不要用uniapp開發(fā)我的建議是分情況。如果項(xiàng)目只面向微信生態(tài)直接寫原生微信小程序就夠了開發(fā)工具順手、調(diào)試方便、API文檔也全。如果你們學(xué)校未來可能有支付寶小程序、抖音小程序的需求才值得用uniapp做多端適配但學(xué)習(xí)成本和打包配置的復(fù)雜度會明顯上升。相比之下原生小程序的wxml、wxss、js這套東西和前端基礎(chǔ)語法幾乎同源做過網(wǎng)頁開發(fā)的人一周就能上手。另外有個現(xiàn)實(shí)問題實(shí)驗(yàn)室預(yù)約系統(tǒng)往往還要對接企業(yè)微信或?qū)W校內(nèi)部的通知體系微信原生生態(tài)在這塊最省事。還有一點(diǎn)別忽略小程序不用處理跨平臺設(shè)備的碎片化問題。安卓和鴻蒙的返回鍵邏輯、iOS的鍵盤彈出方式、各種機(jī)型的劉海屏適配原生小程序都被微信統(tǒng)一處理得差不多了。如果自己搞App光是這些細(xì)節(jié)就能消耗掉半個開發(fā)周期。所以除非有明確的多端訴求否則不要讓“想做App”的沖動主導(dǎo)技術(shù)選型。1.2 后端為什么選Python而不是Java或Node.js后端選型上我毫不猶豫選了Python。理由很實(shí)際實(shí)驗(yàn)室預(yù)約排課系統(tǒng)的核心難度不在并發(fā)量而在排課規(guī)則和預(yù)約沖突的判斷。Python寫這類業(yè)務(wù)邏輯非常流暢幾行就能表達(dá)一個復(fù)雜的判斷條件而且字典、列表這些數(shù)據(jù)結(jié)構(gòu)處理前端傳來的JSON參數(shù)特別自然。Python做后端的優(yōu)勢在校園和中小企業(yè)場景里體現(xiàn)得尤其明顯。開發(fā)周期短一個人一周就能把核心接口寫完調(diào)試方便報錯信息直觀生態(tài)里有Flask、FastAPI、Django這些成熟框架按需選擇就行。我自己偏愛FastAPI因?yàn)樗钱惒娇蚣苄阅鼙菷lask好還能自動生成OpenAPI文檔小程序端的人看接口文檔都省了。如果團(tuán)隊(duì)里都是Python新手選Flask更穩(wěn)資料最多、坑最少。很多人在這個項(xiàng)目里糾結(jié)“用Python會不會性能不夠”這就是想多了。高校實(shí)驗(yàn)室的預(yù)約并發(fā)量高峰期也就幾百個人同時搶晚上幾個時段FastAPI加一個MySQL完全扛得住。真正決定系統(tǒng)好不好用的是你能不能把排課沖突規(guī)則寫對而不是語言本身快不快。當(dāng)然你要是想鍛煉自己也可以試試用Java Spring Boot但那個開發(fā)成本會明顯高對實(shí)驗(yàn)室預(yù)約這種項(xiàng)目來說有些大材小用。1.3 系統(tǒng)整體架構(gòu)和數(shù)據(jù)流整套系統(tǒng)的架構(gòu)非常簡單核心就三層小程序前端、Python后端接口、MySQL數(shù)據(jù)庫。小程序端負(fù)責(zé)頁面展示和交互比如實(shí)驗(yàn)室列表、日期選擇、時段預(yù)約、管理員審核后端用FastAPI暴露RESTful接口處理登錄鑒權(quán)、預(yù)約創(chuàng)建、沖突檢測、排課數(shù)據(jù)查詢數(shù)據(jù)庫存所有持久化數(shù)據(jù)包括用戶、實(shí)驗(yàn)室、預(yù)約記錄、排課課程。小程序通過wx.request請求后端的http接口數(shù)據(jù)格式統(tǒng)一走JSON。具體的請求流程可以這樣理解學(xué)生打開小程序先用微信code登錄后端調(diào)微信接口拿到openid并返回一個自定義token之后每次請求都帶上token后端校驗(yàn)身份學(xué)生選擇實(shí)驗(yàn)室、日期、時間段并提交預(yù)約后端先檢查這個時段是否已經(jīng)被課程占用、是否已被別人預(yù)約、是否超過實(shí)驗(yàn)室容量全部通過才寫入數(shù)據(jù)庫管理員端則負(fù)責(zé)導(dǎo)入實(shí)驗(yàn)課表、設(shè)置實(shí)驗(yàn)室開放時間、處理學(xué)生預(yù)約的審核和取消。這套流程不復(fù)雜但每個環(huán)節(jié)都有坑后面我逐個拆。2. 核心功能拆解與關(guān)鍵流程設(shè)計(jì)2.1 用戶端登錄、實(shí)驗(yàn)室列表、預(yù)約下單用戶端最核心的三個功能是登錄、查看實(shí)驗(yàn)室、提交預(yù)約。登錄這塊微信小程序一定要用wx.login拿到臨時code再把code傳給后端由后端調(diào)用微信的code2Session接口換取openid。這里有個特別容易被新手忽略的點(diǎn)小程序端絕對不要自己去請求微信接口換openid因?yàn)槟前補(bǔ)ppSecret暴露給了前端等于是把用戶數(shù)據(jù)脫褲子給人看。正確做法是后端持有appSecretcode每次用完就失效后端拿到openid后生成自己的token返回給小程序端后續(xù)請求都帶這個自定義token。實(shí)驗(yàn)室列表頁面要展示實(shí)驗(yàn)室名稱、所在位置、可容納人數(shù)、當(dāng)前開放狀態(tài)、今天的空閑時段。這里需要注意的是實(shí)驗(yàn)室列表不能一次性把所有數(shù)據(jù)都返回分頁是必須的否則數(shù)據(jù)量大了小程序渲染會卡。我習(xí)慣用limit和offset做簡單的分頁每個頁面加載20條觸底時再拉下一頁。預(yù)約下單是整個系統(tǒng)最敏感的操作。前端讓用戶選擇日期、時段、實(shí)驗(yàn)類型、參與人數(shù)然后提交給后端。千萬不要在前端做預(yù)約是否沖突的判斷就認(rèn)為萬事大吉更不要直接把數(shù)據(jù)寫進(jìn)數(shù)據(jù)庫。前端的判斷只是體驗(yàn)優(yōu)化真正的沖突檢查和寫入限制必須在后端完成因?yàn)榍岸舜a可以被抓包改參數(shù)繞過限制。小程序抓包這個事我就不細(xì)說了但做開發(fā)的一定要默認(rèn)所有前端傳參都不可信。2.2 管理員端排課導(dǎo)入、預(yù)約審核、數(shù)據(jù)統(tǒng)計(jì)很多做預(yù)約系統(tǒng)的人容易忽略管理端其實(shí)管理端的復(fù)雜度比用戶端還要高。排課是整個系統(tǒng)的靈魂學(xué)生預(yù)約是在課程剩下的空余時間上做文章的所以課程排課必須可靠。我建議的排課方式是管理員在后臺按實(shí)驗(yàn)室、按周次導(dǎo)入課程表。導(dǎo)入方式可以支持手工添加也可以支持Excel批量導(dǎo)入。Excel導(dǎo)入聽起來高級但從實(shí)際使用來看手工添加反而更穩(wěn)因?yàn)榻^大多數(shù)實(shí)驗(yàn)室一個星期就那么幾十節(jié)課手工一條條加也就十幾分鐘。批量導(dǎo)入Excel需要處理格式兼容、日期解析、重復(fù)行等問題開發(fā)成本和收益不成正比除非你們有幾十個實(shí)驗(yàn)室才建議做。預(yù)約審核這塊可以做成“提交即生效”和“需要管理員審批后生效”兩種模式。對于校園實(shí)驗(yàn)室我更推薦前一種即提交即生效但設(shè)置一個防沖突檢查和信用分機(jī)制。學(xué)生預(yù)約成功后如果爽約三次拉入黑名單限制預(yù)約兩周。這樣既保證使用效率又減少管理員的負(fù)擔(dān)。人工審批模式適合有特殊設(shè)備的實(shí)驗(yàn)室比如貴重儀器房需要老師確認(rèn)才能通過。數(shù)據(jù)統(tǒng)計(jì)也不能缺。管理員需要知道每個實(shí)驗(yàn)室的使用率、每個時段的預(yù)約熱度、每個院系的使用情況。這些數(shù)據(jù)可以指導(dǎo)下一學(xué)期的排課比如某個實(shí)驗(yàn)室周三下午總是被約滿可以考慮多排專業(yè)實(shí)驗(yàn)課某個設(shè)備孤島實(shí)驗(yàn)室長期無人用就應(yīng)該重新分配用途。簡單用SQL聚合查詢就能出報表沒必要上大數(shù)據(jù)組件。2.3 預(yù)約排課的核心沖突檢測規(guī)則沖突檢測是這個系統(tǒng)最核心、也最容易寫錯的地方。規(guī)則其實(shí)不難我把它拆成下面幾條第一時間不能重疊。學(xué)生預(yù)約的時段不能被課程表里的課程占用也不能被其他已成功的預(yù)約占用。判斷區(qū)間重疊有一個經(jīng)典公式現(xiàn)有預(yù)約開始時間小于新預(yù)約結(jié)束時間且現(xiàn)有預(yù)約結(jié)束時間大于新預(yù)約開始時間兩者同時成立即沖突。用代碼寫就是 prev_start new_end and prev_end new_start。第二實(shí)驗(yàn)室容量限制。預(yù)約人數(shù)不能超過實(shí)驗(yàn)室最大容納人數(shù)這個在請求參數(shù)里做校驗(yàn)前端也可以做一個提示但后端必須再查一次數(shù)據(jù)庫里的容量字段。第三同一用戶同一時間段不能重復(fù)預(yù)約。學(xué)生可以一次約多個時段但不能同一個時段約兩個不同實(shí)驗(yàn)室否則會造成名額浪費(fèi)。后端要用用戶ID加時間的唯一性查詢。第四課程優(yōu)先于自由預(yù)約。如果某實(shí)驗(yàn)室在周一上午第1-2節(jié)有固定實(shí)驗(yàn)課那這個時間段學(xué)生自由預(yù)約必須被拒絕除非管理員設(shè)置可預(yù)約數(shù)量增量。課程排課數(shù)據(jù)可以單獨(dú)存一張表在預(yù)約檢查時先查課程表再查預(yù)約表。我踩過的最大坑是以為只要在Python代碼里做判斷就足夠了但并發(fā)情況下兩個請求同時通過檢查然后同時寫入數(shù)據(jù)庫就會產(chǎn)生超賣。所以除了業(yè)務(wù)代碼判斷數(shù)據(jù)庫層面必須加唯一索引或利用事務(wù)后面我在代碼部分詳細(xì)講。3. 數(shù)據(jù)庫設(shè)計(jì)與核心代碼實(shí)現(xiàn)3.1 數(shù)據(jù)表結(jié)構(gòu)設(shè)計(jì)數(shù)據(jù)庫我選MySQL原因很簡單校園環(huán)境里讓老師裝個Redis或者M(jìn)ongoDB不現(xiàn)實(shí)MySQL基本是標(biāo)配而且這類系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)非常規(guī)整用關(guān)系型數(shù)據(jù)庫最合適。如果只是開發(fā)學(xué)習(xí)或者本機(jī)演示SQLite也能跑起來只要把數(shù)據(jù)庫連接串改一下就行。第一張表是用戶表保存所有小程序用戶和管理員。字段包括id、openid、昵稱、頭像、角色student/admin、學(xué)號/工號、手機(jī)號、信用分、創(chuàng)建時間。openid必須加唯一索引這是用戶身份的唯一標(biāo)識。第二張表是實(shí)驗(yàn)室表。字段包括id、名稱、地址、容量、負(fù)責(zé)人、設(shè)備說明、是否開放預(yù)約、開放開始時間、開放結(jié)束時間、備注。重點(diǎn)在于“是否開放預(yù)約”這個狀態(tài)位管理員可以臨時關(guān)閉某個實(shí)驗(yàn)室進(jìn)行設(shè)備維護(hù)。第三張表是課程排課表。字段包括id、實(shí)驗(yàn)室id、課程名稱、教師、星期幾、開始節(jié)次、結(jié)束節(jié)次、開始周次、結(jié)束周次、單雙周標(biāo)記、備注。這里我用“星期幾開始節(jié)次結(jié)束節(jié)次”表述時段比直接存日期時間更符合高校作息排課表本來就是按周重復(fù)的。如果是企業(yè)培訓(xùn)場景也可以改成具體的開始時間、結(jié)束時間。第四張表是預(yù)約記錄表。這是最核心的表字段包括id、用戶id、實(shí)驗(yàn)室id、預(yù)約日期、開始節(jié)次、結(jié)束節(jié)次、參與人數(shù)、狀態(tài)pending/approved/cancelled/completed/no_show、創(chuàng)建時間、更新時間。狀態(tài)字段要有默認(rèn)值如果是免審核模式就直接置為approved。預(yù)約記錄表建議加兩個索引一個是實(shí)驗(yàn)室id、預(yù)約日期、開始節(jié)次、結(jié)束節(jié)次用來快速查沖突另一個是用戶id、預(yù)約日期用來查用戶的預(yù)約歷史和防止重復(fù)預(yù)約。并發(fā)情況下光靠索引還不夠下面代碼段解決。3.2 后端接口實(shí)現(xiàn)以FastAPI為例環(huán)境準(zhǔn)備這里不多廢話Python 3.9以上版本安裝fastapi、uvicorn、sqlalchemy、pymysql就夠了。Linux服務(wù)器上如果自帶Python版本太低建議用源碼編譯安裝新版或者直接裝miniconda管理虛擬環(huán)境省去一堆依賴問題。登錄接口先從簡單的開始。小程序傳入code后端拿到code調(diào)微信接口換openid再生成自己的token。from fastapi import FastAPI, Depends, HTTPException import httpx, secrets from datetime import datetime from sqlalchemy.orm import Session app FastAPI() # 假設(shè)已配置微信小程序 appid, secret WX_APPID your_appid WX_SECRET your_secret app.post(/api/login) async def login(data: dict): code data.get(code) async with httpx.AsyncClient() as client: resp await client.get( https://api.weixin.qq.com/sns/jscode2session, params{ appid: WX_APPID, secret: WX_SECRET, js_code: code, grant_type: authorization_code } ) wx_data resp.json() openid wx_data.get(openid) if not openid: raise HTTPException(status_code401, detail微信登錄失敗) # 查詢或創(chuàng)建用戶然后生成 token token secrets.token_hex(16) # 將 openid token 保存到數(shù)據(jù)庫返回 token return {token: token, role: student}真實(shí)的項(xiàng)目里token要把user_id、角色、過期時間一起管理最好存到一張login_token表里每次請求通過token查到用戶。token不要直接存openid的明文關(guān)系在小程序端不然有個人信息泄露的風(fēng)險。預(yù)約接口是重點(diǎn)我們必須保證創(chuàng)建預(yù)約時檢查沖突是原子操作。簡單的方法是用數(shù)據(jù)庫行鎖但更穩(wěn)妥的做法是對預(yù)約記錄表加一個唯一約束讓數(shù)據(jù)庫幫我們擋掉并發(fā)重復(fù)插入。實(shí)際項(xiàng)目中我會在業(yè)務(wù)檢查后再執(zhí)行一次插入插入時如果撞了唯一索引捕獲IntegrityError并返回“該時段已被預(yù)約”。下面是一個簡化示例from sqlalchemy import and_, func from sqlalchemy.exc import IntegrityError app.post(/api/reserve) async def reserve(data: dict, db: Session Depends(get_db)): # 參數(shù): user_id, lab_id, reserve_date, start_period, end_period, people_count lab db.query(Lab).filter(Lab.id data[lab_id]).first() if not lab: raise HTTPException(status_code404, detail實(shí)驗(yàn)室不存在) if not lab.is_open: raise HTTPException(status_code400, detail實(shí)驗(yàn)室未開放預(yù)約) # 檢查課程排課沖突 conflict_course db.query(CourseSchedule).filter( CourseSchedule.lab_id data[lab_id], CourseSchedule.week_day data[week_day], CourseSchedule.start_period data[end_period], CourseSchedule.end_period data[start_period] ).first() if conflict_course: raise HTTPException(status_code400, detail該時段已被實(shí)驗(yàn)課占用) # 檢查普通預(yù)約沖突 conflict_reserve db.query(ReserveRecord).filter( ReserveRecord.lab_id data[lab_id], ReserveRecord.reserve_date data[reserve_date], ReserveRecord.start_period data[end_period], ReserveRecord.end_period data[start_period], ReserveRecord.status.in_([approved, pending]) ).first() if conflict_reserve: raise HTTPException(status_code400, detail該時段已被預(yù)約) record ReserveRecord( user_iddata[user_id], lab_iddata[lab_id], reserve_datedata[reserve_date], start_perioddata[start_period], end_perioddata[end_period], people_countdata[people_count], statusapproved ) db.add(record) try: db.commit() except IntegrityError: db.rollback() raise HTTPException(status_code400, detail手慢了該時段剛被別人預(yù)約) return {id: record.id, status: record.status}代碼里用了一個技巧判斷課程沖突時沒寫死“星期幾等于”而是把week_day也作為篩選條件。這里注意數(shù)據(jù)庫查詢中的區(qū)間重疊判斷要和業(yè)務(wù)需求對應(yīng)跨天、跨節(jié)次的場景要特別測試。如果是晚上20:00到21:00這種按絕對時間存的判斷方式一樣但要把日期和時間拼成一個datetime再比較。3.3 前端小程序關(guān)鍵頁面實(shí)現(xiàn)小程序端代碼分三塊頁面、請求封裝、狀態(tài)管理。頁面用來展示和交互請求封裝統(tǒng)一處理token和錯誤提示狀態(tài)管理保存用戶信息。請求封裝非常重要。我見過很多新手在每個頁面里直接寫wx.request結(jié)果token過期了到處都要改錯誤提示五花八門。建議把請求封裝成一個request.js文件類似下面這樣const BASE_URL https://api.example.com; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method, data: data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success: (res) { if (res.statusCode 200) { resolve(res.data); } else if (res.statusCode 401) { wx.navigateTo({ url: /pages/login/login }); } else { wx.showToast({ title: res.data.detail || 請求失敗, icon: none }); reject(res); } }, fail: (err) { wx.showToast({ title: 網(wǎng)絡(luò)異常, icon: none }); reject(err); } }); }); } module.exports { request };預(yù)約頁面的wxml結(jié)構(gòu)很常規(guī)核心就是日期選擇器、時段選擇、實(shí)驗(yàn)室容量提示、提交按鈕。需要注意的細(xì)節(jié)有兩個第一日期選擇器的范圍要設(shè)置min屬性為今天不能讓學(xué)生約過去的日期第二時段選擇建議用按鈕組而不是picker因?yàn)橐坏┻x擇多個連續(xù)時段picker并不方便。用戶選完時段后前端先算一下本次預(yù)約總共多少節(jié)再連同實(shí)驗(yàn)室容量一起展示減少后端失敗的挫敗感。頁面JS里調(diào)接口也要注意防重復(fù)點(diǎn)擊。把提交按鈕加一個loading狀態(tài)第一次點(diǎn)擊后禁用按鈕直到請求完成否則用戶連點(diǎn)三下會產(chǎn)生三個重復(fù)請求雖然后端有沖突檢查但會給用戶“約了好幾次”的錯覺體驗(yàn)極差。4. 常見問題與排查技巧實(shí)錄4.1 并發(fā)情況下預(yù)約超賣怎么處理這是實(shí)驗(yàn)室預(yù)約系統(tǒng)最容易出的線上事故。兩個學(xué)生同時提交同一個實(shí)驗(yàn)室同一個時段的預(yù)約后端都先查詢了一遍沒有沖突然后同時執(zhí)行插入數(shù)據(jù)庫結(jié)果兩個請求都成功了實(shí)驗(yàn)室被超賣。我在開發(fā)階段就遇到過一次當(dāng)時還以為是前端按鈕沒做防重復(fù)后來一查是并發(fā)問題。解決這個問題的核心思路是查詢和寫入之間必須有隔離性不能靠業(yè)務(wù)代碼的先后順序。最實(shí)踐的做法就是在預(yù)約記錄表上建立針對實(shí)驗(yàn)室、日期、開始節(jié)次、結(jié)束節(jié)次的聯(lián)合約束但因?yàn)闀r間區(qū)間不是枚舉唯一索引比較難設(shè)計(jì)。退而求其次可以用數(shù)據(jù)庫的行級鎖。在SQLAlchemy里通過with_for_update()鎖定實(shí)驗(yàn)室記錄行保證同一時間只有一個事務(wù)能檢查并插入預(yù)約記錄。如果項(xiàng)目并發(fā)量確實(shí)大比如全校幾千人同時搶晚上7點(diǎn)到9點(diǎn)的實(shí)驗(yàn)室那就得上消息隊(duì)列或者Redis分布式鎖。但坦白說這種校內(nèi)預(yù)約系統(tǒng)做到這個程度有點(diǎn)過度設(shè)計(jì)了。我建議先把數(shù)據(jù)庫事務(wù)和行鎖做好已經(jīng)能覆蓋絕大多數(shù)場景。并發(fā)問題的排查也簡單高并發(fā)壓測時觀察日志里有沒有同時插入成功的情況。4.2 微信登錄時session_key和token搞混微信小程序登錄流程中主流的說法是通過wx.login拿到code后端用code換openid和session_key。很多新手會把session_key存在自己的服務(wù)器然后拿來當(dāng)身份憑證這是不對的。session_key是微信會話密鑰用來解密用戶數(shù)據(jù)不應(yīng)該服務(wù)于業(yè)務(wù)系統(tǒng)的會話管理。正確做法是后端用code換到openid之后生成一個自己的token比如用secrets.token_hex(16)生成隨機(jī)字符串關(guān)聯(lián)user_id設(shè)置7天過期時間存數(shù)據(jù)庫。小程序端以后請求都帶這個token后端通過查詢token表驗(yàn)明正身。不要把openid在接口返回里暴露給小程序端雖然openid本身不能直接干壞事但它屬于用戶敏感信息接口盡量只返回用戶id和昵稱等業(yè)務(wù)必要字段。在實(shí)際開發(fā)中微信官方對js_code2session接口的調(diào)用頻率有限制如果登錄頻繁可能會有臨時接口報錯。這種情況可以做一個簡單的本機(jī)token緩存小程序啟動時如果本地已有未過期的token就直接使用不再重復(fù)wx.login只有后端返回401才重新走登錄流程。4.3 時間重疊判斷的邊界問題時間重疊判斷這個代碼寫出來只有一行但邊界問題特別多。第一次寫這個系統(tǒng)的時候我用的是“開始時間小于新結(jié)束時間且結(jié)束時間大于新開始時間”然后測試時發(fā)現(xiàn)課程表里的“9月30日”和預(yù)約表的“2025-09-30”格式不一致直接查不中。后來約定所有日期都存成date類型節(jié)次都用整數(shù)才算是徹底解決。另一個邊界問題是跨天實(shí)驗(yàn)。比如晚上實(shí)驗(yàn)室通宵開放學(xué)生預(yù)約了22:00到第二天06:00如果按“日期”作為查詢條件這條預(yù)約在第二天的記錄里就查不到導(dǎo)致第二天白天的時段被重復(fù)預(yù)約。解決辦法是預(yù)約表里存“開始時間”和“結(jié)束時間”完整datetime查詢時用兩個時間字段做區(qū)間重疊判斷而不是用日期加節(jié)次的拼接方式。如果堅(jiān)持用節(jié)次模型那就要允許結(jié)束節(jié)次大于當(dāng)天總節(jié)次并且日期順延一天這會引入很多麻煩。還有單雙周排課的問題。很多高校實(shí)驗(yàn)課是單周或雙周輪換如果課程排課表不保存“單雙周標(biāo)記”會導(dǎo)致隔周一次的實(shí)驗(yàn)課在另一周被錯誤占用。我的建議是排課表里加一個week_type字段取值為all/odd/even檢查時間沖突時把當(dāng)前預(yù)約日期對應(yīng)的教學(xué)周和week_type比對一下只有匹配才視為沖突。4.4 小程序真機(jī)預(yù)覽和HTTPS域名配置這個問題幾乎每隔幾天就會有人來問我。小程序開發(fā)工具里接口調(diào)試得好好的一上真機(jī)就白屏、請求全部失敗原因基本都是域名沒配好。小程序正式環(huán)境要求所有請求必須是HTTPS而且域名要從小程序后臺的“request合法域名”里提前配置。如果你只是本地開發(fā)可以在開發(fā)工具里勾選“不校驗(yàn)合法域名”但真機(jī)上如果還跑localhost那是連不上的因?yàn)槭謾C(jī)訪問不到你電腦上的服務(wù)需要后端部署到局域網(wǎng)可訪問的IP或者云服務(wù)器。我個人的經(jīng)驗(yàn)是開發(fā)階段直接用內(nèi)網(wǎng)穿透工具或者部署到一臺云服務(wù)器上測試不要等到上線再配域名。后端接口路徑和前端BASE_URL要一致避免出現(xiàn)開發(fā)環(huán)境是http、線上環(huán)境是https導(dǎo)致請求被攔截的情況。部署后端時用Nginx把Python服務(wù)反代到443端口配好SSL證書小程序那邊才能順暢請求。再提醒一個容易忽略的點(diǎn)小程序的request并發(fā)限制是10個。如果頁面初始化時同時發(fā)送實(shí)驗(yàn)室列表、課程表、用戶信息好幾個請求數(shù)量不多沒問題但如果后續(xù)功能膨脹了注意合并接口或者做請求隊(duì)列不然偶爾會出現(xiàn)高并發(fā)時的請求失敗。4.5 Python環(huán)境與依賴安裝的坑Python環(huán)境的坑大多是版本不一致造成的。有的服務(wù)器自帶的Python是3.6但FastAPI要求3.7以上SQLAlchemy新版也可能不兼容Python 3.6所以裝好依賴后第一步就是檢查版本。建議用虛擬環(huán)境管理項(xiàng)目依賴簡單說就是在項(xiàng)目根目錄執(zhí)行python3 -m venv venv然后source venv/bin/activate激活再pip install。這樣不會污染系統(tǒng)Python換服務(wù)器時也能靠requirements.txt一鍵恢復(fù)環(huán)境。很多新手遇到的問題是這樣本地運(yùn)行好好的上傳服務(wù)器后報ModuleNotFoundError。原因基本是忘記執(zhí)行pip install -r requirements.txt或者requirements.txt沒有把依賴寫全。生成requirements.txt最穩(wěn)妥的方法是pip freeze但要注意它會把無關(guān)的全局依賴也帶進(jìn)去所以更推薦手動維護(hù)一個干凈的依賴清單只寫fastapi、uvicorn、sqlalchemy、pymysql、httpx這幾個核心包帶上版本號。Linux系統(tǒng)上安裝Python如果使用源碼編譯千萬別忘了先安裝libssl-dev和libffi-dev否則Python編譯出來缺少ssl模塊后面調(diào)用微信HTTPS接口會直接報錯。另外pip下載慢的問題可以臨時指定清華鏡像源pip install -i https://pypi.tuna.tsinghua.edu.cn/simple 包名。這些都是老生常談但每屆學(xué)生都會踩一遍。5. 一些額外的實(shí)踐經(jīng)驗(yàn)做這個系統(tǒng)最值錢的不是代碼本身而是把一個真實(shí)業(yè)務(wù)抽象成一套可以被驗(yàn)證的邏輯。我開發(fā)的時候把大部分時間花在編寫沖突規(guī)則和測試邊界條件上反而頁面布局這些只花了兩天。如果你也在做類似項(xiàng)目我強(qiáng)烈建議先畫出完整的業(yè)務(wù)流程圖把每種角色、每個狀態(tài)、每個異常分支都標(biāo)出來再開始寫代碼。給即將上線的小項(xiàng)目三個具體建議第一先從一間實(shí)驗(yàn)室試運(yùn)行管理員手工檢查一天確認(rèn)預(yù)約準(zhǔn)確率再放開所有實(shí)驗(yàn)室第二預(yù)約成功之后一定要有消息通知最簡單的是在小程序里做個“我的預(yù)約”列表學(xué)生自己來看結(jié)果復(fù)雜點(diǎn)的可以用訂閱消息推送第三建立爽約懲罰機(jī)制否則過兩個月就會有人惡意占坑。信用分字段我已經(jīng)放在用戶表里了后續(xù)就是每次爽約扣分、定時解禁的簡單邏輯。如果后續(xù)想擴(kuò)展可以考慮把實(shí)驗(yàn)報告提交、設(shè)備借用、耗材領(lǐng)用都掛在預(yù)約單下一個實(shí)驗(yàn)室管理系統(tǒng)就慢慢成形了。但別急著一次做完先讓預(yù)約排課跑穩(wěn)定這個核心穩(wěn)定其他功能都是加分項(xiàng)。