1. 從搶工位這件小事說起AI 實驗室預約系統(tǒng)到底要解決什么但凡在高校實驗室或者企業(yè) AI 研發(fā)團隊待過的人大概率都經歷過這樣的場景早上九點沖到實驗室發(fā)現(xiàn)唯一一臺帶 A100 的機器已經被占滿微信群里問誰在用三號機半小時沒人回導師臨時要跑一組對比實驗結果發(fā)現(xiàn)預約表還停留在 Excel 階段最后一條記錄是上周三。這些看起來是管理問題本質上其實是信息同步和資源調度的問題。我所在的實驗室去年就踩過這個坑。當時我們有三臺訓練服務器、兩臺推理機、若干臺帶消費級顯卡的工作站外加一批共享的攝像頭、機械臂和邊緣設備。人不多二十來號人但設備沖突幾乎天天發(fā)生。最開始用共享文檔登記后來發(fā)現(xiàn)有人改完不保存、有人直接覆蓋別人的時間段再后來換成在線表格又出現(xiàn)了時區(qū)混亂、并發(fā)編輯沖突的問題。折騰了兩個月我決定干脆自己寫一套預約系統(tǒng)。技術選型上我沒有太多猶豫后端用Django DRF前端用Vue 3數據庫用MySQL。原因很直接——Django 自帶 ORM、Admin 后臺和權限體系DRF 能把接口層做得干凈利落Vue 3 的 Composition API 寫交互邏輯比 Options API 舒服太多而 MySQL 在團隊里大家都熟運維成本低。這套組合不是最時髦的但對于一個實驗室內部系統(tǒng)來說穩(wěn)定、好維護、上手快才是第一位的。這篇文章我會把整個系統(tǒng)的設計思路、關鍵實現(xiàn)、踩過的坑和實測經驗完整講一遍。適合正在做類似內部工具的后端或全棧開發(fā)者也適合想拿一個真實項目練手 Django Vue 3 的同學。我不會只貼代碼更重要的是講清楚每個決策背后的理由——為什么這么設計、不這么設計會出什么問題、實際跑起來之后又遇到了哪些意料之外的情況。2. 需求拆解預約系統(tǒng)遠不止選個時間段那么簡單2.1 表面需求與真實需求的差距如果只看表面預約系統(tǒng)的需求好像很簡單用戶選設備、選時間、提交、完事。但真正落地的時候你會發(fā)現(xiàn)光是時間這一項就能衍生出一堆問題。比如預約是按小時還是按半小時跨天怎么算提前多久可以預約能不能取消取消要不要扣信用分設備維護期間怎么處理已有預約這些問題如果不在設計階段想清楚后面改起來就是災難。我在動手之前花了兩天時間把實驗室里所有人拉過來開了個短會讓大家把最煩的事情列出來。結果整理出來大概有這么幾類沖突問題同一時間段被兩個人預約或者預約了但人沒來設備空轉。權限問題新生不應該直接預約高價值設備需要導師審批或者通過考核?？梢娦詥栴}不知道某臺設備當前狀態(tài)是空閑、使用中還是維護中。記錄問題出了問題要追溯誰在什么時候用了哪臺機器跑了什么任務。通知問題預約成功、即將開始、被取消這些節(jié)點需要有人知道。這五類問題基本覆蓋了系統(tǒng)的核心功能邊界。我最終把需求歸納成四個模塊設備管理、預約調度、權限審批、使用記錄。每個模塊下面再細分具體功能點形成一份可以對照開發(fā)的需求清單。2.2 角色劃分與權限模型實驗室場景里的角色其實比想象中復雜。我最后定義了四種角色角色權限范圍典型操作普通成員查看設備、預約低權限設備、查看自己的記錄預約工作站、取消自己的預約高級成員預約全部設備、發(fā)起審批預約訓練服務器、審批新人的高權限申請管理員設備增刪改、查看全部記錄、處理異常添加新設備、強制取消沖突預約訪客只讀查看設備狀態(tài)和空閑時段這套權限模型用 Django 的 Groups 和 Permissions 就能實現(xiàn)不需要自己造輪子。但有一個細節(jié)要注意Django 默認的權限粒度是模型級別的add/change/delete/view而我們需要的是能不能預約某類設備這種業(yè)務級權限。我的做法是在模型層加一個required_level字段然后在視圖層做校驗而不是硬塞進 Django 的權限系統(tǒng)里。這樣邏輯更清晰也更好維護。2.3 時間槽設計為什么我放棄了自由時間段最開始我想做的是自由時間段——用戶自己填開始和結束時間。聽起來很靈活但實際測試下來問題很多有人填 9:00 到 9:01有人填 9:00 到 23:59時間粒度完全不可控統(tǒng)計和沖突檢測都變得很麻煩。后來我改成了固定時間槽方案每天從 8:00 到 22:00按 30 分鐘切分一共 28 個槽位。用戶預約的時候選連續(xù)的槽位系統(tǒng)自動合并成時間段。這個方案的好處是沖突檢測變成簡單的區(qū)間重疊判斷數據庫索引也好建。代價是靈活性降低但對于實驗室場景來說30 分鐘粒度完全夠用。提示如果你的場景需要更細的粒度可以把槽位改成 15 分鐘但要注意槽位數量會翻倍前端渲染和數據庫查詢都要相應優(yōu)化。3. 后端架構Django DRF 的分層設計與關鍵實現(xiàn)3.1 項目結構與應用拆分Django 項目最容易犯的錯誤就是所有代碼堆在一個 app 里。我一開始也差點這么干后來及時拆開了。最終的 app 劃分是這樣的lab_booking/ ├── config/ # 項目配置 ├── accounts/ # 用戶與權限 ├── devices/ # 設備管理 ├── bookings/ # 預約核心邏輯 ├── approvals/ # 審批流程 └── records/ # 使用記錄與統(tǒng)計拆分的依據是職責邊界accounts 管人devices 管物bookings 管調度approvals 管流程records 管歷史。每個 app 內部的 models、serializers、views、urls 各自獨立跨 app 的引用通過外鍵或者 service 層函數完成。這里有個經驗不要為了拆分而拆分。如果你的系統(tǒng)只有三五個模型硬拆成五個 app 反而增加復雜度。我之所以拆是因為預約邏輯和審批邏輯確實有獨立的業(yè)務規(guī)則混在一起會讓 views.py 膨脹到上千行。3.2 核心模型設計Booking 模型的字段取舍預約系統(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)幾個關鍵決策點第一start_time 和 end_time 用 DateTimeField 而不是分開的日期和時間字段。這樣區(qū)間查詢和沖突檢測都簡單MySQL 的索引也能直接用上。第二status 用字符串枚舉而不是布爾字段。預約狀態(tài)至少有 pending、approved、rejected、cancelled、completed 五種用布爾字段根本表達不了。字符串枚舉配合 choices 約束既清晰又不容易出錯。第三purpose 字段設為可空。一開始我設成必填結果用戶抱怨每次都要寫用途太麻煩。后來改成選填但管理員可以在后臺看到填寫率用于后續(xù)分析。第四沒有加 is_deleted 軟刪除字段。這是刻意的——預約記錄屬于審計數據不應該被物理刪除。取消操作只是把 status 改成 cancelled記錄永遠保留。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ū)間重疊判斷的標準寫法就是start_time end AND end_time start。但問題出在并發(fā)上兩個用戶同時提交預約兩個請求都通過了沖突檢測然后都寫入數據庫結果就沖突了。解決方案有兩種一種是在數據庫層加唯一約束但區(qū)間重疊沒法用簡單的唯一約束表達另一種是用事務加行鎖。我最終采用的是悲觀鎖 事務的方案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(該時間段已被預約) return Booking.objects.create(...)select_for_update()會在事務期間鎖住設備行第二個請求必須等第一個事務提交后才能繼續(xù)這時候沖突檢測就能正確攔截了。實測下來即使模擬 50 個并發(fā)請求搶同一個時間段也只有一個人能成功。注意select_for_update()必須在事務內使用否則會報錯。另外 MySQL 的存儲引擎必須是 InnoDBMyISAM 不支持行鎖。3.4 DRF 序列化器的分層策略DRF 的序列化器我分了三層列表序列化器、詳情序列化器、寫入序列化器。列表用輕量字段詳情帶關聯(lián)信息寫入只接受必要字段。這樣做的好處是接口返回的數據量可控前端渲染也更快。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(結束時間必須晚于開始時間) return attrs這里有個細節(jié)寫入序列化器的 validate 只做基礎校驗真正的沖突檢測放在視圖層的事務里。因為序列化器的 validate 不在事務內如果在這里查數據庫做沖突檢測還是會遇到并發(fā)問題。4. 前端實現(xiàn)Vue 3 組合式 API 下的預約交互設計4.1 為什么選 Vue 3 而不是 Vue 22024 年還在糾結 Vue 2 和 Vue 3 的人我的建議是直接用 Vue 3。Composition API 在處理復雜交互邏輯時的優(yōu)勢太明顯了——預約頁面涉及時間槽選擇、設備篩選、表單校驗、狀態(tài)同步用 Options API 寫會散落在 data、methods、computed 各處而用 Composition API 可以把相關邏輯組織在一個函數里。我用的技術棧是 Vue 3 Vite Pinia Element Plus。Vite 的啟動速度比 Webpack 快一個數量級Pinia 比 Vuex 簡潔很多Element Plus 的日期選擇器和表格組件開箱即用省了大量樣式工作。4.2 時間槽選擇器的實現(xiàn)思路時間槽選擇器是整個前端最復雜的組件。我的實現(xiàn)思路是后端提供一個接口返回某設備某天的所有槽位狀態(tài)前端渲染成一個網格用戶點擊選擇連續(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 數組里每個元素包含 index、start、end、status 四個字段。status 有 available、booked、maintenance 三種。前端根據 status 渲染不同顏色只有 available 的槽位可以點擊。這里有個體驗優(yōu)化點用戶選擇多個槽位時如果中間有不連續(xù)的應該自動提示或者自動補齊。我最初沒做這個處理結果有用戶選了 9:00-10:00 和 11:00-12:00中間空了一小時提交后系統(tǒng)報錯說時間段不連續(xù)。后來我在 toggleSlot 里加了連續(xù)性檢查不連續(xù)的選擇會自動清空重新選。4.3 狀態(tài)管理與接口封裝Pinia 的 store 我按業(yè)務模塊劃分userStore 管登錄狀態(tài)和權限deviceStore 管設備列表和篩選條件bookingStore 管預約數據和提交邏輯。每個 store 只負責自己的領域跨 store 的通信通過組件層協(xié)調。接口封裝用 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) } )這個封裝看起來簡單但省掉了每個組件里重復的錯誤處理代碼。實測下來前端代碼量減少了大概 30%。5. 數據庫與部署MySQL 配置和實際運行中的坑5.1 MySQL 版本選擇與字符集配置MySQL 我用的是 8.0 版本。為什么不選 5.7因為 8.0 的窗口函數、CTE 和 JSON 支持更好而且默認字符集是 utf8mb4不用像 5.7 那樣手動改配置。安裝過程在 Windows 上稍微麻煩一點需要先初始化數據目錄再注冊服務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 里也要對應配置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 在數據截斷或類型不匹配時直接報錯而不是靜默處理。這在開發(fā)階段能幫你提前發(fā)現(xiàn)很多數據問題。5.2 索引設計與查詢優(yōu)化預約系統(tǒ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);索引順序很關鍵device_id 選擇性最高放最前start_time 用于范圍查詢放中間status 放最后。實測下來這個索引讓查詢從全表掃描的 200ms 降到了 5ms 以內。另一個容易忽略的點是分頁。預約記錄會隨時間不斷累積如果不分頁列表接口遲早會拖垮數據庫。我用的是 DRF 的 LimitOffsetPagination默認每頁 20 條前端滾動加載。5.3 部署方案為什么我選了 Docker Compose部署這塊我糾結過很久。裸機部署簡單直接但環(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)境隔離、數據持久化。踩過的坑是 MySQL 容器首次啟動需要初始化時間web 容器如果啟動太快會連不上數據庫。解決辦法是在 web 的啟動腳本里加一個等待循環(huán)或者用depends_on配合 healthcheck。6. 實測中的意外情況與排查記錄6.1 時區(qū)問題一個讓預約時間全部錯亂的坑系統(tǒng)上線第一天就出事了用戶預約的是下午 2 點但列表里顯示的是早上 6 點。排查了半天發(fā)現(xiàn)是時區(qū)配置不一致導致的。Django 的USE_TZTrue會把時間存成 UTC但 MySQL 容器默認時區(qū)是 UTC而前端顯示用的是本地時間中間差了 8 小時。解決方案是三層統(tǒng)一Django 的TIME_ZONE設為Asia/ShanghaiMySQL 容器加TZ: Asia/Shanghai環(huán)境變量前端用 dayjs 做格式化時明確指定時區(qū)。改完之后時間就對了。提示涉及時間的系統(tǒng)一定要在開發(fā)階段就把時區(qū)問題解決掉。等到數據寫進去再改遷移成本會非常高。6.2 并發(fā)預約的邊界情況前面提到的select_for_update()方案在大多數情況下工作正常但有一個邊界情況如果兩個請求預約的是不同設備它們不應該互相阻塞。我最初的實現(xiàn)是鎖整個 Booking 表結果性能很差。后來改成鎖 Device 行不同設備的預約就能并行了。還有一個情況是同一用戶重復提交。用戶手快點了兩次提交按鈕結果創(chuàng)建了兩條預約。前端加防抖只能緩解根本解決要在后端做冪等。我的做法是在 Booking 模型上加一個request_id字段前端每次提交生成一個 UUID后端檢測到重復 request_id 就直接返回已有記錄。6.3 前端時間槽渲染的性能問題設備多的時候時間槽網格會變得很大。我們有 10 臺設備每臺 28 個槽位如果一次性渲染所有設備的槽位就是 280 個 DOM 節(jié)點再加上每個節(jié)點的狀態(tài)樣式頁面會明顯卡頓。優(yōu)化方案是虛擬滾動 按需加載。默認只渲染當前選中設備的槽位切換設備時再加載。同時用v-memo緩存已渲染的槽位避免不必要的重渲染。改完之后頁面切換設備的響應時間從 800ms 降到了 100ms 以內。7. 這套系統(tǒng)跑了一年之后的一些體會系統(tǒng)上線到現(xiàn)在差不多一年累計處理了三千多條預約記錄沖突率從最初的每周好幾次降到了幾乎為零。但比數字更有意思的是一些使用習慣上的變化。比如有了使用記錄之后大家開始自覺填寫預約用途因為月底統(tǒng)計的時候能看到誰跑了多少實驗、用了多少機時。這種透明度反過來促進了資源分配的公平性。再比如審批流程上線后新生預約高價值設備需要導師確認設備誤操作的情況明顯減少。技術上如果讓我重新做一遍有幾個地方會調整一是前端會更早引入 TypeScript現(xiàn)在純 JS 寫復雜組件確實容易出類型錯誤二是會把通知功能做成獨立的服務而不是塞在 Django 的 signal 里因為 signal 的調試體驗實在一般三是數據庫會考慮加一個只讀從庫把統(tǒng)計查詢和業(yè)務查詢分開。如果你也在做類似的內部工具我的建議是先把核心流程跑通再考慮擴展功能。預約系統(tǒng)的核心就是不沖突和可追溯把這兩件事做扎實其他都是錦上添花。至于技術選型Django Vue 3 MySQL 這套組合對于中小規(guī)模系統(tǒng)來說開發(fā)效率和維護成本都很平衡值得一試。