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