1. 從搶工位這件小事說起AI 實驗室預(yù)約系統(tǒng)到底要解決什么但凡在高校實驗室或者企業(yè) AI 研發(fā)團隊待過的人大概率都經(jīng)歷過這樣的場景早上九點沖到實驗室發(fā)現(xiàn)唯一一臺帶 A100 的機器已經(jīng)被占滿微信群里問誰在用三號機半小時沒人回導(dǎo)師臨時要跑一組對比實驗結(jié)果發(fā)現(xiàn)預(yù)約表還停留在 Excel 階段最后一條記錄是上周三。這些看起來是管理問題本質(zhì)上其實是信息同步和資源調(diào)度的問題。我所在的實驗室去年就踩過這個坑。當(dāng)時我們有三臺訓(xùn)練服務(wù)器、兩臺推理機、若干臺帶消費級顯卡的工作站外加一批共享的攝像頭、機械臂和邊緣設(shè)備。人不多二十來號人但設(shè)備沖突幾乎天天發(fā)生。最開始用共享文檔登記后來發(fā)現(xiàn)有人改完不保存、有人直接覆蓋別人的時間段再后來換成在線表格又出現(xiàn)了時區(qū)混亂、并發(fā)編輯沖突的問題。折騰了兩個月我決定干脆自己寫一套預(yù)約系統(tǒng)。技術(shù)選型上我沒有太多猶豫后端用Django DRF前端用Vue 3數(shù)據(jù)庫用MySQL。原因很直接——Django 自帶 ORM、Admin 后臺和權(quán)限體系DRF 能把接口層做得干凈利落Vue 3 的 Composition API 寫交互邏輯比 Options API 舒服太多而 MySQL 在團隊里大家都熟運維成本低。這套組合不是最時髦的但對于一個實驗室內(nèi)部系統(tǒng)來說穩(wěn)定、好維護(hù)、上手快才是第一位的。這篇文章我會把整個系統(tǒng)的設(shè)計思路、關(guān)鍵實現(xiàn)、踩過的坑和實測經(jīng)驗完整講一遍。適合正在做類似內(nèi)部工具的后端或全棧開發(fā)者也適合想拿一個真實項目練手 Django Vue 3 的同學(xué)。我不會只貼代碼更重要的是講清楚每個決策背后的理由——為什么這么設(shè)計、不這么設(shè)計會出什么問題、實際跑起來之后又遇到了哪些意料之外的情況。2. 需求拆解預(yù)約系統(tǒng)遠(yuǎn)不止選個時間段那么簡單2.1 表面需求與真實需求的差距如果只看表面預(yù)約系統(tǒng)的需求好像很簡單用戶選設(shè)備、選時間、提交、完事。但真正落地的時候你會發(fā)現(xiàn)光是時間這一項就能衍生出一堆問題。比如預(yù)約是按小時還是按半小時跨天怎么算提前多久可以預(yù)約能不能取消取消要不要扣信用分設(shè)備維護(hù)期間怎么處理已有預(yù)約這些問題如果不在設(shè)計階段想清楚后面改起來就是災(zāi)難。我在動手之前花了兩天時間把實驗室里所有人拉過來開了個短會讓大家把最煩的事情列出來。結(jié)果整理出來大概有這么幾類沖突問題同一時間段被兩個人預(yù)約或者預(yù)約了但人沒來設(shè)備空轉(zhuǎn)。權(quán)限問題新生不應(yīng)該直接預(yù)約高價值設(shè)備需要導(dǎo)師審批或者通過考核。可見性問題不知道某臺設(shè)備當(dāng)前狀態(tài)是空閑、使用中還是維護(hù)中。記錄問題出了問題要追溯誰在什么時候用了哪臺機器跑了什么任務(wù)。通知問題預(yù)約成功、即將開始、被取消這些節(jié)點需要有人知道。這五類問題基本覆蓋了系統(tǒng)的核心功能邊界。我最終把需求歸納成四個模塊設(shè)備管理、預(yù)約調(diào)度、權(quán)限審批、使用記錄。每個模塊下面再細(xì)分具體功能點形成一份可以對照開發(fā)的需求清單。2.2 角色劃分與權(quán)限模型實驗室場景里的角色其實比想象中復(fù)雜。我最后定義了四種角色角色權(quán)限范圍典型操作普通成員查看設(shè)備、預(yù)約低權(quán)限設(shè)備、查看自己的記錄預(yù)約工作站、取消自己的預(yù)約高級成員預(yù)約全部設(shè)備、發(fā)起審批預(yù)約訓(xùn)練服務(wù)器、審批新人的高權(quán)限申請管理員設(shè)備增刪改、查看全部記錄、處理異常添加新設(shè)備、強制取消沖突預(yù)約訪客只讀查看設(shè)備狀態(tài)和空閑時段這套權(quán)限模型用 Django 的 Groups 和 Permissions 就能實現(xiàn)不需要自己造輪子。但有一個細(xì)節(jié)要注意Django 默認(rèn)的權(quán)限粒度是模型級別的add/change/delete/view而我們需要的是能不能預(yù)約某類設(shè)備這種業(yè)務(wù)級權(quán)限。我的做法是在模型層加一個required_level字段然后在視圖層做校驗而不是硬塞進(jìn) Django 的權(quán)限系統(tǒng)里。這樣邏輯更清晰也更好維護(hù)。2.3 時間槽設(shè)計為什么我放棄了自由時間段最開始我想做的是自由時間段——用戶自己填開始和結(jié)束時間。聽起來很靈活但實際測試下來問題很多有人填 9:00 到 9:01有人填 9:00 到 23:59時間粒度完全不可控統(tǒng)計和沖突檢測都變得很麻煩。后來我改成了固定時間槽方案每天從 8:00 到 22:00按 30 分鐘切分一共 28 個槽位。用戶預(yù)約的時候選連續(xù)的槽位系統(tǒng)自動合并成時間段。這個方案的好處是沖突檢測變成簡單的區(qū)間重疊判斷數(shù)據(jù)庫索引也好建。代價是靈活性降低但對于實驗室場景來說30 分鐘粒度完全夠用。提示如果你的場景需要更細(xì)的粒度可以把槽位改成 15 分鐘但要注意槽位數(shù)量會翻倍前端渲染和數(shù)據(jù)庫查詢都要相應(yīng)優(yōu)化。3. 后端架構(gòu)Django DRF 的分層設(shè)計與關(guān)鍵實現(xiàn)3.1 項目結(jié)構(gòu)與應(yīng)用拆分Django 項目最容易犯的錯誤就是所有代碼堆在一個 app 里。我一開始也差點這么干后來及時拆開了。最終的 app 劃分是這樣的lab_booking/ ├── config/ # 項目配置 ├── accounts/ # 用戶與權(quán)限 ├── devices/ # 設(shè)備管理 ├── bookings/ # 預(yù)約核心邏輯 ├── approvals/ # 審批流程 └── records/ # 使用記錄與統(tǒng)計拆分的依據(jù)是職責(zé)邊界accounts 管人devices 管物bookings 管調(diào)度approvals 管流程records 管歷史。每個 app 內(nèi)部的 models、serializers、views、urls 各自獨立跨 app 的引用通過外鍵或者 service 層函數(shù)完成。這里有個經(jīng)驗不要為了拆分而拆分。如果你的系統(tǒng)只有三五個模型硬拆成五個 app 反而增加復(fù)雜度。我之所以拆是因為預(yù)約邏輯和審批邏輯確實有獨立的業(yè)務(wù)規(guī)則混在一起會讓 views.py 膨脹到上千行。3.2 核心模型設(shè)計Booking 模型的字段取舍預(yù)約系統(tǒng)的核心模型是 Booking我前后改了四版才定下來。最終字段如下class Booking(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE) device models.ForeignKey(Device, on_deletemodels.CASCADE) start_time models.DateTimeField() end_time models.DateTimeField() status models.CharField(max_length20, choicesSTATUS_CHOICES) purpose models.TextField(blankTrue) created_at models.DateTimeField(auto_now_addTrue) updated_at models.DateTimeField(auto_nowTrue)幾個關(guān)鍵決策點第一start_time 和 end_time 用 DateTimeField 而不是分開的日期和時間字段。這樣區(qū)間查詢和沖突檢測都簡單MySQL 的索引也能直接用上。第二status 用字符串枚舉而不是布爾字段。預(yù)約狀態(tài)至少有 pending、approved、rejected、cancelled、completed 五種用布爾字段根本表達(dá)不了。字符串枚舉配合 choices 約束既清晰又不容易出錯。第三purpose 字段設(shè)為可空。一開始我設(shè)成必填結(jié)果用戶抱怨每次都要寫用途太麻煩。后來改成選填但管理員可以在后臺看到填寫率用于后續(xù)分析。第四沒有加 is_deleted 軟刪除字段。這是刻意的——預(yù)約記錄屬于審計數(shù)據(jù)不應(yīng)該被物理刪除。取消操作只是把 status 改成 cancelled記錄永遠(yuǎn)保留。3.3 沖突檢測一個容易被低估的難點沖突檢測看起來簡單實際上是最容易出 bug 的地方。我最初的實現(xiàn)是這樣的def has_conflict(device, start, end): return Booking.objects.filter( devicedevice, status__in[pending, approved], start_time__ltend, end_time__gtstart ).exists()這個邏輯本身沒問題區(qū)間重疊判斷的標(biāo)準(zhǔn)寫法就是start_time end AND end_time start。但問題出在并發(fā)上兩個用戶同時提交預(yù)約兩個請求都通過了沖突檢測然后都寫入數(shù)據(jù)庫結(jié)果就沖突了。解決方案有兩種一種是在數(shù)據(jù)庫層加唯一約束但區(qū)間重疊沒法用簡單的唯一約束表達(dá)另一種是用事務(wù)加行鎖。我最終采用的是悲觀鎖 事務(wù)的方案from django.db import transaction transaction.atomic def create_booking(user, device, start, end): device Device.objects.select_for_update().get(iddevice.id) if has_conflict(device, start, end): raise ConflictError(該時間段已被預(yù)約) return Booking.objects.create(...)select_for_update()會在事務(wù)期間鎖住設(shè)備行第二個請求必須等第一個事務(wù)提交后才能繼續(xù)這時候沖突檢測就能正確攔截了。實測下來即使模擬 50 個并發(fā)請求搶同一個時間段也只有一個人能成功。注意select_for_update()必須在事務(wù)內(nèi)使用否則會報錯。另外 MySQL 的存儲引擎必須是 InnoDBMyISAM 不支持行鎖。3.4 DRF 序列化器的分層策略DRF 的序列化器我分了三層列表序列化器、詳情序列化器、寫入序列化器。列表用輕量字段詳情帶關(guān)聯(lián)信息寫入只接受必要字段。這樣做的好處是接口返回的數(shù)據(jù)量可控前端渲染也更快。class BookingListSerializer(serializers.ModelSerializer): device_name serializers.CharField(sourcedevice.name, read_onlyTrue) user_name serializers.CharField(sourceuser.username, read_onlyTrue) class Meta: model Booking fields [id, device_name, user_name, start_time, end_time, status] class BookingCreateSerializer(serializers.ModelSerializer): class Meta: model Booking fields [device, start_time, end_time, purpose] def validate(self, attrs): if attrs[start_time] attrs[end_time]: raise serializers.ValidationError(結(jié)束時間必須晚于開始時間) return attrs這里有個細(xì)節(jié)寫入序列化器的 validate 只做基礎(chǔ)校驗真正的沖突檢測放在視圖層的事務(wù)里。因為序列化器的 validate 不在事務(wù)內(nèi)如果在這里查數(shù)據(jù)庫做沖突檢測還是會遇到并發(fā)問題。4. 前端實現(xiàn)Vue 3 組合式 API 下的預(yù)約交互設(shè)計4.1 為什么選 Vue 3 而不是 Vue 22024 年還在糾結(jié) Vue 2 和 Vue 3 的人我的建議是直接用 Vue 3。Composition API 在處理復(fù)雜交互邏輯時的優(yōu)勢太明顯了——預(yù)約頁面涉及時間槽選擇、設(shè)備篩選、表單校驗、狀態(tài)同步用 Options API 寫會散落在 data、methods、computed 各處而用 Composition API 可以把相關(guān)邏輯組織在一個函數(shù)里。我用的技術(shù)棧是 Vue 3 Vite Pinia Element Plus。Vite 的啟動速度比 Webpack 快一個數(shù)量級Pinia 比 Vuex 簡潔很多Element Plus 的日期選擇器和表格組件開箱即用省了大量樣式工作。4.2 時間槽選擇器的實現(xiàn)思路時間槽選擇器是整個前端最復(fù)雜的組件。我的實現(xiàn)思路是后端提供一個接口返回某設(shè)備某天的所有槽位狀態(tài)前端渲染成一個網(wǎng)格用戶點擊選擇連續(xù)槽位。const slots ref([]) const selectedSlots ref([]) async function loadSlots(deviceId, date) { const res await api.get(/api/devices/ deviceId /slots/, { params: { date } }) slots.value res.data.slots } function toggleSlot(slot) { if (slot.status ! available) return const idx selectedSlots.value.indexOf(slot.index) if (idx 0) { selectedSlots.value.splice(idx, 1) } else { selectedSlots.value.push(slot.index) } }后端返回的 slots 數(shù)組里每個元素包含 index、start、end、status 四個字段。status 有 available、booked、maintenance 三種。前端根據(jù) status 渲染不同顏色只有 available 的槽位可以點擊。這里有個體驗優(yōu)化點用戶選擇多個槽位時如果中間有不連續(xù)的應(yīng)該自動提示或者自動補齊。我最初沒做這個處理結(jié)果有用戶選了 9:00-10:00 和 11:00-12:00中間空了一小時提交后系統(tǒng)報錯說時間段不連續(xù)。后來我在 toggleSlot 里加了連續(xù)性檢查不連續(xù)的選擇會自動清空重新選。4.3 狀態(tài)管理與接口封裝Pinia 的 store 我按業(yè)務(wù)模塊劃分userStore 管登錄狀態(tài)和權(quán)限deviceStore 管設(shè)備列表和篩選條件bookingStore 管預(yù)約數(shù)據(jù)和提交邏輯。每個 store 只負(fù)責(zé)自己的領(lǐng)域跨 store 的通信通過組件層協(xié)調(diào)。接口封裝用 axios 加攔截器統(tǒng)一處理 token 注入、錯誤提示和 loading 狀態(tài)const api axios.create({ baseURL: import.meta.env.VITE_API_BASE }) api.interceptors.request.use(config { const token localStorage.getItem(token) if (token) config.headers.Authorization Bearer token return config }) api.interceptors.response.use( res res.data, err { ElMessage.error(err.response?.data?.detail || 請求失敗) return Promise.reject(err) } )這個封裝看起來簡單但省掉了每個組件里重復(fù)的錯誤處理代碼。實測下來前端代碼量減少了大概 30%。5. 數(shù)據(jù)庫與部署MySQL 配置和實際運行中的坑5.1 MySQL 版本選擇與字符集配置MySQL 我用的是 8.0 版本。為什么不選 5.7因為 8.0 的窗口函數(shù)、CTE 和 JSON 支持更好而且默認(rèn)字符集是 utf8mb4不用像 5.7 那樣手動改配置。安裝過程在 Windows 上稍微麻煩一點需要先初始化數(shù)據(jù)目錄再注冊服務(wù)mysqld --initialize-insecure --datadirD:\tool\mysql-8.0.46-winx64\data mysqld --install MySQL80 --defaults-fileD:\tool\mysql-8.0.46-winx64\my.ini net start MySQL80my.ini里必須配好字符集否則中文會亂碼[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_unicode_ci [client] default-character-setutf8mb4Django 的 settings 里也要對應(yīng)配置DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: lab_booking, USER: lab_user, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { charset: utf8mb4, init_command: SET sql_modeSTRICT_TRANS_TABLES, }, } }注意init_command里的 STRICT_TRANS_TABLES 很重要它會讓 MySQL 在數(shù)據(jù)截斷或類型不匹配時直接報錯而不是靜默處理。這在開發(fā)階段能幫你提前發(fā)現(xiàn)很多數(shù)據(jù)問題。5.2 索引設(shè)計與查詢優(yōu)化預(yù)約系統(tǒng)最頻繁的查詢是某設(shè)備某天的預(yù)約列表對應(yīng)的 SQL 大概是SELECT * FROM bookings_booking WHERE device_id 1 AND start_time 2025-01-15 00:00:00 AND start_time 2025-01-16 00:00:00 AND status IN (pending, approved);為了這個查詢我建了一個聯(lián)合索引CREATE INDEX idx_device_time_status ON bookings_booking (device_id, start_time, status);索引順序很關(guān)鍵device_id 選擇性最高放最前start_time 用于范圍查詢放中間status 放最后。實測下來這個索引讓查詢從全表掃描的 200ms 降到了 5ms 以內(nèi)。另一個容易忽略的點是分頁。預(yù)約記錄會隨時間不斷累積如果不分頁列表接口遲早會拖垮數(shù)據(jù)庫。我用的是 DRF 的 LimitOffsetPagination默認(rèn)每頁 20 條前端滾動加載。5.3 部署方案為什么我選了 Docker Compose部署這塊我糾結(jié)過很久。裸機部署簡單直接但環(huán)境依賴容易出問題Kubernetes 太重實驗室這點規(guī)模用不上。最后選了 Docker Compose三個容器MySQL、Django用 gunicorn、Nginx托管 Vue 打包后的靜態(tài)文件并反代 API。services: db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: lab_booking volumes: - mysql_data:/var/lib/mysql web: build: ./backend command: gunicorn config.wsgi:application --bind 0.0.0.0:8000 depends_on: - db nginx: image: nginx:alpine ports: - 80:80 volumes: - ./frontend/dist:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/conf.d/default.conf這套方案的好處是一鍵啟動、環(huán)境隔離、數(shù)據(jù)持久化。踩過的坑是 MySQL 容器首次啟動需要初始化時間web 容器如果啟動太快會連不上數(shù)據(jù)庫。解決辦法是在 web 的啟動腳本里加一個等待循環(huán)或者用depends_on配合 healthcheck。6. 實測中的意外情況與排查記錄6.1 時區(qū)問題一個讓預(yù)約時間全部錯亂的坑系統(tǒng)上線第一天就出事了用戶預(yù)約的是下午 2 點但列表里顯示的是早上 6 點。排查了半天發(fā)現(xiàn)是時區(qū)配置不一致導(dǎo)致的。Django 的USE_TZTrue會把時間存成 UTC但 MySQL 容器默認(rèn)時區(qū)是 UTC而前端顯示用的是本地時間中間差了 8 小時。解決方案是三層統(tǒng)一Django 的TIME_ZONE設(shè)為Asia/ShanghaiMySQL 容器加TZ: Asia/Shanghai環(huán)境變量前端用 dayjs 做格式化時明確指定時區(qū)。改完之后時間就對了。提示涉及時間的系統(tǒng)一定要在開發(fā)階段就把時區(qū)問題解決掉。等到數(shù)據(jù)寫進(jìn)去再改遷移成本會非常高。6.2 并發(fā)預(yù)約的邊界情況前面提到的select_for_update()方案在大多數(shù)情況下工作正常但有一個邊界情況如果兩個請求預(yù)約的是不同設(shè)備它們不應(yīng)該互相阻塞。我最初的實現(xiàn)是鎖整個 Booking 表結(jié)果性能很差。后來改成鎖 Device 行不同設(shè)備的預(yù)約就能并行了。還有一個情況是同一用戶重復(fù)提交。用戶手快點了兩次提交按鈕結(jié)果創(chuàng)建了兩條預(yù)約。前端加防抖只能緩解根本解決要在后端做冪等。我的做法是在 Booking 模型上加一個request_id字段前端每次提交生成一個 UUID后端檢測到重復(fù) request_id 就直接返回已有記錄。6.3 前端時間槽渲染的性能問題設(shè)備多的時候時間槽網(wǎng)格會變得很大。我們有 10 臺設(shè)備每臺 28 個槽位如果一次性渲染所有設(shè)備的槽位就是 280 個 DOM 節(jié)點再加上每個節(jié)點的狀態(tài)樣式頁面會明顯卡頓。優(yōu)化方案是虛擬滾動 按需加載。默認(rèn)只渲染當(dāng)前選中設(shè)備的槽位切換設(shè)備時再加載。同時用v-memo緩存已渲染的槽位避免不必要的重渲染。改完之后頁面切換設(shè)備的響應(yīng)時間從 800ms 降到了 100ms 以內(nèi)。7. 這套系統(tǒng)跑了一年之后的一些體會系統(tǒng)上線到現(xiàn)在差不多一年累計處理了三千多條預(yù)約記錄沖突率從最初的每周好幾次降到了幾乎為零。但比數(shù)字更有意思的是一些使用習(xí)慣上的變化。比如有了使用記錄之后大家開始自覺填寫預(yù)約用途因為月底統(tǒng)計的時候能看到誰跑了多少實驗、用了多少機時。這種透明度反過來促進(jìn)了資源分配的公平性。再比如審批流程上線后新生預(yù)約高價值設(shè)備需要導(dǎo)師確認(rèn)設(shè)備誤操作的情況明顯減少。技術(shù)上如果讓我重新做一遍有幾個地方會調(diào)整一是前端會更早引入 TypeScript現(xiàn)在純 JS 寫復(fù)雜組件確實容易出類型錯誤二是會把通知功能做成獨立的服務(wù)而不是塞在 Django 的 signal 里因為 signal 的調(diào)試體驗實在一般三是數(shù)據(jù)庫會考慮加一個只讀從庫把統(tǒng)計查詢和業(yè)務(wù)查詢分開。如果你也在做類似的內(nèi)部工具我的建議是先把核心流程跑通再考慮擴展功能。預(yù)約系統(tǒng)的核心就是不沖突和可追溯把這兩件事做扎實其他都是錦上添花。至于技術(shù)選型Django Vue 3 MySQL 這套組合對于中小規(guī)模系統(tǒng)來說開發(fā)效率和維護(hù)成本都很平衡值得一試。