做一個能真正落地用的疲勞駕駛識別系統比想象中要折騰得多。這個項目是我自己從模型選型到前后端部署完整跑了一遍的核心就是用 YOLOv8/v10/v11/v12 這幾個版本的檢測模型做眼睛、嘴巴、頭部的狀態(tài)識別后端用 SpringBoot 搭一套前后端分離的 Web 服務前端提供實時監(jiān)控和交互界面最后再接一個大模型接口對連續(xù)幀檢測結果做更聰明的綜合判斷。整個過程踩了不少坑也摸出了一些特別值得分享的經驗。這篇文章就圍繞這個系統的完整實現路徑來寫從模型怎么選、數據怎么標、服務怎么拆到部署調試、常見問題排查一次性講清楚適合想自己動手做一遍目標檢測Web應用的同學參考。1. 項目背景與整體設計思路1.1 為什么疲勞駕駛檢測值得用 YOLO 系列來做疲勞駕駛識別的核心任務是判斷駕駛員的眼睛是否閉合、嘴巴是否打哈欠、頭部是否頻繁點頭或傾斜。這些行為在視頻里其實是典型的“小目標”和“局部遮擋”問題但好在檢測對象相對固定只需要在駕駛員面部區(qū)域做精細分析。傳統的圖像處理方法比如人臉關鍵點EAR計算也能做但魯棒性不夠好一旦駕駛員戴墨鏡、歪頭、光照變化劇烈關鍵點就容易飄。換成目標檢測模型之后可以直接把“閉眼”“張嘴”等作為一個類別框出來模型自己學習特征視覺干擾的容忍度高很多。YOLO 系列在這里的優(yōu)勢很明確單階段檢測、速度快、工程化成熟。從 v8 到 v12模型結構一直在優(yōu)化但共同點是部署方便從訓練到導出 ONNX 再到用 TensorRT 加速鏈路很順暢。對一個需要實時處理攝像頭視頻流的系統來說檢測延遲每毫秒都很寶貴YOLO 在這方面的表現比兩階段模型更適合實際場景。1.2 前后端分離和 SpringBoot 的定位為什么后端要用 SpringBoot原因是我自己最熟的 Java 技術棧是一方面另一方面是 SpringBoot 在業(yè)務接口、權限控制、定時任務、數據庫操作這些方面生態(tài)太完善了。疲勞駕駛系統除了要處理模型推理還需要管理用戶、設備、報警記錄、歷史查詢這些工程化能力用 SpringBoot 寫起來效率很高。而模型推理部分則是典型的 Python 強項。用 Python 加載 PyTorch 模型、處理圖像、調用 GPU 加速比在 Java 里折騰 JNI 和 PyTorch 的 Java API 要省事得多。所以最好的架構就是把系統拆成“SpringBoot 業(yè)務服務 Python 推理服務”兩個獨立進程中間用 HTTP 通信。前端完全獨立部署通過 RESTful API 和 WebSocket 跟后端交互這就是典型的前后端分離。這套結構的好處是每一層都能單獨擴容比如攝像頭多了推理服務可以多起幾個實例業(yè)務層完全不用動。1.3 系統整體架構與數據流向整體流程可以概括成一句話視頻流進前端前端抽幀后發(fā)給后端后端再轉發(fā)給推理服務做檢測檢測結果回到后端記錄同時大模型綜合分析結果給出疲勞等級最終推送到前端大屏展示和報警。在物理部署上Python 推理服務和 SpringBoot 服務可以放在同一臺 GPU 服務器上也可以分開。前端頁面用 Nginx 托管訪問后端 API。視頻流的話既可以前端直接訪問攝像頭 RTSP 流也可以后端的 WebSocket 主動推送處理后的結果幀。架構里比較關鍵的是數據協議。檢測結果要包含目標類別閉眼、打哈欠、低頭、正常、邊界框坐標、置信度、時間戳、駕駛員編號。這些信息經過后端結構化以后一部分存入數據庫一部分推送給前端繪制框另一部分喂給大模型做語義分析。設計好這個數據模型后面每一步都會順很多。2. 模型選型與訓練要點2.1 YOLOv8/v10/v11/v12 的核心差異對比很多第一次做選型的人會糾結到底用哪個版本我的建議是先別盯著“最新”兩個字要看自己的硬件條件和場景要求。四代模型我都實際訓練過總結起來各有脾氣版本核心特點推理速度GPU小目標效果易用性/生態(tài)YOLOv8anchor-free結構成熟官方支持全流程快中上極高文檔多社區(qū)問題基本都能搜到YOLOv10去掉 NMS端到端部署更簡潔更快中等相對較高但需要留意輸出格式變化YOLOv11改進 Backbone增強特征提取mAP 有提升和 v8 接近更好較高訓練接口延續(xù) v8 習慣YOLOv12加入注意力機制小目標更友好略慢于 v10最好相對較低部分訓練細節(jié)需要自己調實際對比下來v8 最適合當基線模型因為訓練參數大家都熟踩坑成本低v10 因為去掉了 NMS確有速度優(yōu)勢但部署時輸出層變了解析要跟著改v11 在 mAP 上比 v8 有小幅提升算是不錯的中期選擇v12 在閉眼這類小目標上提升最明顯但 GPU 稍微差一點的話速度下降也明顯。所以我的選型邏輯是如果算力充足、要求精度最高用 v12如果要在老顯卡或者 CPU 上跑用 v8 最穩(wěn)。2.2 疲勞駕駛數據集構建與標注規(guī)范訓練模型的根基是數據。閉環(huán)的數據集至少要有四類正常睜眼、閉眼、打哈欠張嘴、低頭/左顧右盼。有人會想用公開數據集但疲勞駕駛場景非常特殊不同攝像頭安裝角度、車內光照、駕駛員臉型差異都很大公開數據很難完全覆蓋。我自己是采用“公開數據集模擬駕駛環(huán)境自采”的方式在模型車和實驗室里架攝像頭找?guī)讉€人分別模擬正常駕駛和疲勞狀態(tài)錄了上百段視頻再抽幀篩選。標注的時候特別注意三點。第一閉眼和半閉眼要區(qū)分開或者在標注時統一成“閉眼”但邊界要清晰眼睛只剩一條縫時算閉眼還是睜眼最好在標注規(guī)范里明確。第二打哈欠時嘴巴張開的程度也要定義好張嘴超過一定閾值才算正樣本。第三樣本均衡很關鍵正常睜眼的幀數會遠多于閉眼和打哈欠需要做欠采樣或數據增強。我用的是某標注工具導出 YOLO 格式的 txt 文件每行是類別 x_center y_center width height。2.3 訓練配置與調參經驗訓練 YOLO 的配置有很多可調項但核心就幾個輸入分辨率、batch size、epochs、優(yōu)化器、數據增強策略。輸入分辨率我建議用 640 起步如果閉眼檢測精度不夠再嘗試 960。分辨率提高能明顯改善小目標檢測但訓練和推理速度都會下降。batch size 受顯存限制我實測 8GB 顯存下用 640 分辨率batch 8 差不多再大就 OOM。epochs 一般 100 到 200配合早停機制看驗證集 mAP 變化。優(yōu)化器直接用默認的 SGD 或 AdamW 都行關鍵是學習率策略。數據增強里最有用的幾個是隨機亮度對比度模擬光線變化、隨機旋轉和透視模擬頭部姿態(tài)變化、隨機裁剪模擬攝像頭角度差異。但注意不要增強過頭比如翻轉就只做水平翻轉垂直翻轉會讓臉變成倒著的真實場景不可能出現。訓練完成后先用測試集看各類別的 mAP。如果閉眼類別 mAP 明顯低優(yōu)先補閉眼樣本而不是盲目加訓練輪數。我遇到過閉眼和正常睜眼的 mAP 相差十幾個點補了一批閉眼數據后效果立竿見影。2.4 模型導出與轉換細節(jié)訓練出的 PyTorch 模型權重不能直接塞給 Java 或者 Python 推理服務使用通常要轉換成 ONNX 再轉成推理引擎格式。如果部署在 GPU 上轉 TensorRT 是首選如果只有 CPU轉 OpenVINO 更合適。導出 ONNX 時要注意幾個坑。第一YOLO 模型的輸出形狀是[batch, 4 classes, grid_h * grid_w]或類似不同版本結構不同導出后需要寫后處理邏輯。第二opset版本盡量選高一點否則某些算子會丟失。第三輸入動態(tài)維度建議關閉固定為 640x640能提升 TensorRT 轉換成功率代價是送入模型的圖像必須做 letterbox 縮放并記錄縮放比例。我在導出 v10 的時候踩過一次坑因為 v10 去掉了 NMS輸出層不同直接用 v8 的后處理解析會導致結果全是零。后來查看模型結構文檔才明白需要根據輸出 shape 判斷特征圖類別數再寫對應的解碼函數。3. 后端 SpringBoot 服務與模型推理集成3.1 項目模塊劃分與工程結構整個后端工程我分成了三個 Maven 模塊server-adminSpringBoot 主服務負責鑒權、設備管理、報警存儲、接口封裝。detect-client封裝對 Python 推理服務的 HTTP 客戶端提供統一的檢測請求方法。common存放公共實體、DTO、常量。獨立推理服務是一個 FastAPI 應用單獨一個項目倉庫。用 FastAPI 而不是 Flask是因為它有類型校驗、自動文檔、異步支持接口對接起來體驗更好。為什么推理服務一定要獨立除了技術棧差異還因為模型推理是 CPU/GPU 密集型操作如果和 SpringBoot 跑在同一個 JVM 里一旦檢測請求并發(fā)上來JVM 的 GC 和 GPU 爭用會讓系統抖動。分開之后SpringBoot 只做業(yè)務編排Python 服務只做推理職責清晰也方便橫向擴容。3.2 推理服務接口設計Python 推理服務暴露的接口要設計得簡單而穩(wěn)定。我常用的是POST /detect Content-Type: multipart/form-data file: 圖像文件 params: - driver_id: 駕駛員編號 返回 { code: 0, data: { boxes: [ {class: 1, class_name: closed_eye, confidence: 0.92, x1: 120, y1: 80, x2: 180, y2: 140} ], image_width: 640, image_height: 640, inference_ms: 28 } }接口內部先做圖像解碼再做 letterbox 縮放轉為張量推理后解析輸出最后把檢測框坐標還原到原始圖像坐標系。這里要特別小心坐標還原很多人在前端 canvas 上畫框偏移就是因為忘了按縮放比例換算。除了單幀檢測推理服務還要支持連續(xù)幀序列檢測或者配合視頻流抽幀。因為 SpringBoot 每次轉發(fā)一張圖的話網絡開銷比較大。更高效的方式是推理服務內部維護一個消息隊列SpringBoot 只把視頻幀通過 WebSocket 推送到推理服務由推理服務批量處理再把結果批量返回。不過我用的實現比較簡單HTTP 單次請求也能滿足 10 路攝像頭的需求關鍵看幀率限制。3.3 SpringBoot 核心業(yè)務實現SpringBoot 這邊的接口設計主要圍繞這個幾個場景用戶登錄和權限管理JWT 令牌角色包括管理員、監(jiān)控員。設備管理增刪改查攝像頭每個攝像頭綁定一個駕駛員或車輛。檢測請求接收前端上傳的圖像調用推理服務拿到結果后保存到數據庫并根據規(guī)則判斷是否觸發(fā)報警。報警記錄查詢按時間、人員、設備篩選歷史記錄。WebSocket 推送檢測結果實時推送到前端。調用 Python 推理服務的代碼我用的是 Spring 的RestTemplate現在也可以用WebClient但RestTemplate足夠穩(wěn)定。注意超時時間一定要設檢測接口如果 GPU 排隊可能耗時超過 5 秒。我設置的是連接超時2秒、讀取超時10秒同時用線程池隔離避免一個慢請求拖垮整個 Web 服務。保存到數據庫時除了保存檢測框還要保存原始圖片的 Base64 編碼或者文件路徑。這個很重要否則事后復盤報警記錄時沒有圖像證據。數據庫表設計至少包括detect_recordid, driver_id, device_id, timestamp, image_path, result_json, fatigue_level, status。3.4 前后端分離鑒權與會話設計前后端分離后傳統的 Cookie Session 不再適用我用 JWT 做無狀態(tài)鑒權。用戶在登錄接口換取 token后續(xù)請求在 Header 里帶Authorization: Bearer token。SpringBoot 里用一個攔截器或 Spring Security 過濾器校驗 token 即可。WebSocket 的鑒權要單獨處理。因為 WebSocket 握手走的是 HTTP 協議升級可以在握手請求的 header 里帶上 token在后端實現一個HandshakeInterceptor校驗。我踩過一個坑前端用原生 WebSocket 時header 里不能隨意自定義字段所以很多前端會選擇把 token 放到 URL 查詢參數里雖然不優(yōu)雅但簡單可行。生產環(huán)境建議用 STOMP 框架支持 CONNECT 幀的傳參能正規(guī)一點。跨域配置也要做好。前端頁面如果部署在http://localhost:8081后端 API 在http://localhost:8080那 SpringBoot 里要配置 CORS 允許指定源、指定請求頭、指定方法否則瀏覽器會攔截所有 AJAX 請求。我習慣把允許的域名放到配置文件里方便切換環(huán)境。4. Web 交互界面與大模型智能分析集成4.1 前端框架與頁面布局前端我用的技術棧是 Vue 3 Element Plus ECharts這套組合開發(fā)監(jiān)控類界面效率很高。頁面核心功能包括登錄/權限控制。實時監(jiān)控大屏左側顯示攝像頭視頻流中間用 canvas 覆蓋顯示檢測框右側是實時統計圖表疲勞指數曲線、各類別檢測計數。歷史記錄頁面支持按時間范圍查詢報警記錄回看抓拍圖片和當時的檢測結果。設備管理頁面增刪改查攝像頭信息。大屏的視覺設計要點是信息密度高但不能亂。我習慣把屏幕劃分成三欄中間大畫布放視頻流和檢測框左側放設備列表右側放圖表和實時報警列表。視頻流用 H5 的 video 標簽播放 RTSP 流時瀏覽器原生不支持 RTSP需要先經過后端轉碼成 WebRTC 或 HLS 流。更輕量的方案是前端通過 WebSocket 接收后端推送的 JPEG 幀流然后利用 canvas 逐幀繪制同時繪制檢測框。這種方式延遲低實現也簡單很適合內網局域網使用。4.2 實時視頻流傳輸與處理這里有個取舍直接讓前端拉攝像頭 RTSP 流并解碼對瀏覽器來說基本不可能。所以常見做法是后端用 FFmpeg 拉流并轉成 MJPEG 或 HLS。我采用了 WebSocket JPEG 幀的推送方式。具體流程是SpringBoot 每 100ms 從攝像頭拉一幀圖像轉成長度較小的 JPEG質量調成 70 左右通過 WebSocketBinaryMessage推送給前端。前端收到二進制數據后用Blob轉成圖片再畫到 canvas 上。接下來這一幀也可以發(fā)給推理服務做檢測檢測框的坐標通過另一條 WebSocket 消息推送。前端收到檢測結果后在 canvas 上重新繪制圖像和框。這個方式的優(yōu)點是實時性高能保持端到端延遲在 300ms 以內。缺點是對前端的繪圖性能有一定要求如果一幀圖像是 1280x720每秒20幀客戶端如果性能不好會卡頓。優(yōu)化的辦法是只繪制檢測區(qū)域的縮放圖或者降低到15幀。4.3 大模型智能分析模塊的設計與接入檢測模型只能告訴你“這一幀里有哪些目標”但疲勞駕駛是一個時間維度上的判斷。單幀眼睛閉合可能是因為眨眼幾秒內頻繁閉合才更有可能是疲勞。大模型的價值就在這里把一段時間內的檢測序列拼接成自然語言提示讓大模型做推理和總結。我接的大模型接口是一個通用的中文對話 API。接入之前要先把檢測結果轉成文本比如每 10 秒為一個窗口統計這個窗口內閉眼幀數占比、打哈欠次數、低頭次數然后構造提示詞你是駕駛安全分析助手。以下是一段10秒內的檢測統計數據 閉眼幀占比15% 打哈欠次數2 低頭次數1 平均置信度0.85 請判斷駕駛員疲勞程度等級正常、輕度疲勞、中度疲勞、高度疲勞并給出理由和安全建議。用JSON輸出。大模型返回的內容可以是 JSON 格式方便直接解析。我在提示詞里明確要求“只輸出JSON”并且配置了輸出格式參數。如果用的是支持結構化輸出的API也可以直接用 schema 約束。接入的關鍵細節(jié)是控制成本和延遲。每 10 秒調用一次大模型對一個攝像頭來說一天有 8640 次調用費用和響應壓力不小。我的優(yōu)化策略是先用規(guī)則判斷是否到了需要大模型介入的程度。比如如果閉眼占比小于 5%直接用規(guī)則結果返回“正?！辈徽{用大模型只有當閉眼占比超過閾值或者短時內出現多次哈欠才觸發(fā)大模型做深度分析。這樣可以省下大量調用。另外大模型調用是 IO 密集型操作不能放在處理視頻流的線程里否則會阻塞實時性。我用了一個異步任務池處理大模型請求完成后把結果寫入數據庫并通過 WebSocket 推送給前端。4.4 報警與數據可視化報警規(guī)則最常用的是 PERCLOS單位時間內眼睛閉合時間占比。行業(yè)里一般以閉眼幀數占總幀數的比例來判斷比如連續(xù) 20 秒內閉眼比例超過 20%就認為是嚴重疲勞?；跈z測結果我做了兩層報警即時報警某幀檢測到閉眼且置信度高觸發(fā)提示。周期報警按時間窗口聚合模型輸出結合大模型疲勞等級觸發(fā)不同程度的聲光報警。前端收到報警消息后頁面頂部彈出紅色告警條同時播放聲音。ECharts 用來畫疲勞指數曲線橫軸是時間縱軸是每個時間窗口的綜合疲勞分曲線平滑處理后會更有趨勢感。安全提醒要注意報警信息不能只展示給監(jiān)控員還要支持短信或企業(yè)微信消息推送。我的系統預留了消息推送接口目前用的是一個模擬的 HTTP 回調實際使用時可以對接第三方短信服務。5. 部署實施與性能優(yōu)化5.1 Docker 化部署方案整套系統的部署我完全用 Docker Compose 編排包含五個容器容器鏡像基礎說明web-servereclipse-temurin:17-jreSpringBoot 服務端口 8080detect-serverpython:3.10-slimFastAPI 推理服務掛載模型文件GPU 時啟用 nvidia runtimeweb-frontendnginx:alpine前端靜態(tài)資源端口 80反向代理后端 APIdatabasemysql:8.0業(yè)務數據存儲redisredis:7-alpine緩存、WebSocket 會話管理、任務隊列如果推理服務需要用 GPUdocker-compose.yml里要指定gpus: all同時需要機器上已安裝 NVIDIA Container Toolkit。我第一次部署時忘了加這個容器跑起來之后 Python 代碼報找不到 CUDA排查了半天才發(fā)現是 runtime 沒配置。Dockerfile 寫 Python 推理服務時要注意減小體積只拷貝requirements.txt、模型文件和源碼不要拷貝訓練用的數據集。模型文件我直接打進鏡像因為模型體積不會太大一般在幾十 MB避免啟動時去外部下載。5.2 性能瓶頸與調優(yōu)系統上線后最直接的瓶頸往往是推理服務。檢測一張 640x640 圖像在 GTX 1660 上大約需要 20ms但在 CPU 上可能要 500ms 以上。如果所有攝像頭都要實時檢測必須對幀率做限制。我的做法是每個攝像頭抽幀率限制為 5 FPS也就是每 200ms 處理一幀。對于有 10 個攝像頭的情況總推理負載是每秒 50 幀GPU 利用率大約在 60%~80%。這個抽幀率對疲勞檢測完全夠用閉眼動作持續(xù)至少 300ms5 FPS 能捕獲到關鍵狀態(tài)。推理服務內部也用上了隊列。FastAPI 是異步框架但模型推理是 CPU/GPU 同步操作并發(fā)請求會排隊。我用了asyncio的 Lock 限制同時只能有一個推理任務否則顯存會爆。如果要提升并發(fā)可以起多個推理進程每個進程各自加載模型再用 Redis 做任務分發(fā)。網絡傳輸也是隱性瓶頸。前端上傳原始圖像再返回檢測結果圖像體積會直接影響延遲。我在推理服務里加了圖像壓縮邏輯先按比例縮小到最長邊 800px再轉成 JPEG quality80這樣單張圖不超過 100KB走內網非常快。5.3 合規(guī)與隱私保護疲勞駕駛系統會持續(xù)采集駕駛員面部圖像屬于敏感個人信息落地時必須做隱私保護。我的方案是所有圖像數據默認不保留原始視頻流只保留觸發(fā)報警前后的關鍵幀。數據庫中的圖像路徑不能包含人員姓名等直接標識信息用隨機 UUID 命名。攝像頭采集區(qū)域要避開無關路人。系統權限要分級只有授權管理員才能查看帶有面部的抓拍圖。這些都是經過實際項目驗證的底線尤其在企業(yè)內部項目里數據合規(guī)問題不是技術問題是能不能上線的問題。即使技術實現再完善隱私保護不到位也會被叫停。6. 踩坑記錄與問題排查6.1 常見問題速查表我把這大半年開發(fā)維護中遇到的典型問題整理成了一張表遇到類似情況可以先對著查現象可能原因解決方案前端檢測框位置錯位letterbox 縮放后沒有還原坐標原圖在推理服務統一負責坐標還原前端直接用原始坐標WebSocket 頻繁斷開代理服務器對空閑連接超時前端每 30 秒發(fā)心跳包后端設置超過 60 秒無消息自動斷開推理服務顯存泄漏推理輸入張量沒有釋放使用torch.no_grad()并在每次推理后主動清理變量大模型返回內容解析失敗提示詞沒有嚴格要求 JSON 格式增加輸出格式約束并做異常重試與默認值回退第一次請求特別慢模型和 CUDA 上下文初始化在服務啟動時執(zhí)行一次預熱推理把 CUDA 模塊加載好攝像頭 RTSP 流斷流網絡抖動或攝像頭連接數限制后端增加自動重連機制啟動守護線程定期檢查流狀態(tài)數據庫記錄增長過快每幀都保存檢測結果只保存報警幀和周期統計結果單幀正常狀態(tài)不落庫6.2 推理精度與速度權衡心得我在實際使用中最大的體會是不要盲目追求模型最強。v12 在閉眼檢測精度上確實好一些但如果目標是做到 5 路以上攝像頭并發(fā)實時檢測v8 的推理速度優(yōu)勢更能保證體驗。后來我把生產環(huán)境穩(wěn)定在 YOLOv8s 上閉眼檢測的 mAP 達到了 0.895 FPS 下延遲 30ms 左右完全夠用。v10 和 v12 還是要留在實驗環(huán)境里對比著玩。v10 的無 NMS 設計確實讓推理延后處理簡單了很多但官方權重在閉眼這個小類別上表現略遜于 v11。v12 的提升需要更大的訓練數據量才能發(fā)揮出來如果只是幾百張標注圖反而容易過擬合。模型蒸餾也是個可以考慮的方向。用 v12 作為教師模型把知識蒸餾給 v8s 的學生模型可以在精度和速度之間找到一個更好的平衡點。我做過一次蒸餾實驗v8s 的 mAP 提升了大約 3%基本接近 v11 的效果但速度沒有犧牲太多。這種方案適合有一定調優(yōu)時間的團隊。6.3 實用的調試技巧調試這類多服務系統最怕的就是問題出現后難以定位。我養(yǎng)成了一套自己的調試習慣分享出來很有用。日志必須全鏈路帶 traceId。在 SpringBoot 里用攔截器生成一個 traceId放入 MDC然后在調用 Python 推理服務時把這個 traceId 放在 HTTP Header 里傳給 FastAPIFastAPI 的日志同樣打印這個 traceId。這樣不管是前端報錯還是后端報錯只要拿著 traceId 就能把整個請求鏈路串起來看。離線回放功能一定要做。我寫了一個模擬推送腳本可以從本地視頻文件讀取幀按照時間間隔把幀發(fā)送給 SpringBoot 服務。這樣不用天天坐在車里測試只要拿著錄制好的疲勞駕駛視頻就能反復驗證檢測邏輯和報警規(guī)則。壓測別忽略大模型環(huán)節(jié)。很多人壓測時只關注檢測接口忽略了前端不斷調用大模型分析接口的并發(fā)。我用 JMeter 模擬多個設備同時觸發(fā)疲勞分析結果發(fā)現線程池滿了導致接口超時。后來把線程池參數調大并且增加了一個排隊緩沖問題就解決了。最后再分享一點個人體會這套系統做完之后我最意外的不是模型精度而是工程整合要花的時間遠超訓練模型。模型訓練可能只占三成工作量剩下七成都在做前后端聯調、接口協議對齊、異常處理、部署上線。如果你也想從零做一套類似的項目建議先定好接口協議和數據結構再動手實現各個模塊。還有一個深坑是不同 YOLO 版本的輸出格式看起來差不多實際上差別不小換模型版本時后處理代碼一定要寫單元測試否則上線那天絕對會踩雷。希望這篇文章能幫你繞開我走過的彎路。