基于YOLO与SpringBoot的疲劳驾驶检测系统：从模型训练到前后端部署全解析

做一个能真正落地用的疲劳驾驶识别系统，比想象中要折腾得多。这个项目是我自己从模型选型到前后端部署完整跑了一遍的，核心就是用 YOLOv8/v10/v11/v12 这几个版本的检测模型做眼睛、嘴巴、头部的状态识别，后端用 SpringBoot 搭一套前后端分离的 Web 服务，前端提供实时监控和交互界面，最后再接一个大模型接口，对连续帧检测结果做更聪明的综合判断。整个过程踩了不少坑，也摸出了一些特别值得分享的经验。这篇文章就围绕这个系统的完整实现路径来写，从模型怎么选、数据怎么标、服务怎么拆，到部署调试、常见问题排查，一次性讲清楚，适合想自己动手做一遍目标检测+Web应用的同学参考。

1. 项目背景与整体设计思路

1.1 为什么疲劳驾驶检测值得用 YOLO 系列来做

疲劳驾驶识别的核心任务，是判断驾驶员的眼睛是否闭合、嘴巴是否打哈欠、头部是否频繁点头或倾斜。这些行为在视频里其实是典型的“小目标”和“局部遮挡”问题，但好在检测对象相对固定，只需要在驾驶员面部区域做精细分析。传统的图像处理方法（比如人脸关键点+EAR计算）也能做，但鲁棒性不够好，一旦驾驶员戴墨镜、歪头、光照变化剧烈，关键点就容易飘。换成目标检测模型之后，可以直接把“闭眼”“张嘴”等作为一个类别框出来，模型自己学习特征，视觉干扰的容忍度高很多。

YOLO 系列在这里的优势很明确：单阶段检测、速度快、工程化成熟。从 v8 到 v12，模型结构一直在优化，但共同点是部署方便，从训练到导出 ONNX 再到用 TensorRT 加速，链路很顺畅。对一个需要实时处理摄像头视频流的系统来说，检测延迟每毫秒都很宝贵，YOLO 在这方面的表现比两阶段模型更适合实际场景。

1.2 前后端分离和 SpringBoot 的定位

为什么后端要用 SpringBoot？原因是我自己最熟的 Java 技术栈是一方面，另一方面是 SpringBoot 在业务接口、权限控制、定时任务、数据库操作这些方面生态太完善了。疲劳驾驶系统除了要处理模型推理，还需要管理用户、设备、报警记录、历史查询，这些工程化能力用 SpringBoot 写起来效率很高。

而模型推理部分则是典型的 Python 强项。用 Python 加载 PyTorch 模型、处理图像、调用 GPU 加速，比在 Java 里折腾 JNI 和 PyTorch 的 Java API 要省事得多。所以最好的架构就是把系统拆成“SpringBoot 业务服务 + Python 推理服务”两个独立进程，中间用 HTTP 通信。前端完全独立部署，通过 RESTful API 和 WebSocket 跟后端交互，这就是典型的前后端分离。这套结构的好处是每一层都能单独扩容，比如摄像头多了，推理服务可以多起几个实例，业务层完全不用动。

1.3 系统整体架构与数据流向

整体流程可以概括成一句话：视频流进前端，前端抽帧后发给后端，后端再转发给推理服务做检测，检测结果回到后端记录，同时大模型综合分析结果给出疲劳等级，最终推送到前端大屏展示和报警。

在物理部署上，Python 推理服务和 SpringBoot 服务可以放在同一台 GPU 服务器上，也可以分开。前端页面用 Nginx 托管，访问后端 API。视频流的话，既可以前端直接访问摄像头 RTSP 流，也可以后端的 WebSocket 主动推送处理后的结果帧。

架构里比较关键的是数据协议。检测结果要包含：目标类别（闭眼、打哈欠、低头、正常）、边界框坐标、置信度、时间戳、驾驶员编号。这些信息经过后端结构化以后，一部分存入数据库，一部分推送给前端绘制框，另一部分喂给大模型做语义分析。设计好这个数据模型，后面每一步都会顺很多。

2. 模型选型与训练要点

2.1 YOLOv8/v10/v11/v12 的核心差异对比

很多第一次做选型的人会纠结到底用哪个版本，我的建议是先别盯着“最新”两个字，要看自己的硬件条件和场景要求。四代模型我都实际训练过，总结起来各有脾气：

实际对比下来，v8 最适合当基线模型，因为训练参数大家都熟，踩坑成本低；v10 因为去掉了 NMS，确有速度优势，但部署时输出层变了，解析要跟着改；v11 在 mAP 上比 v8 有小幅提升，算是不错的中期选择；v12 在闭眼这类小目标上提升最明显，但 GPU 稍微差一点的话，速度下降也明显。所以我的选型逻辑是：如果算力充足、要求精度最高，用 v12；如果要在老显卡或者 CPU 上跑，用 v8 最稳。

2.2 疲劳驾驶数据集构建与标注规范

训练模型的根基是数据。闭环的数据集至少要有四类：正常睁眼、闭眼、打哈欠张嘴、低头/左顾右盼。有人会想用公开数据集，但疲劳驾驶场景非常特殊，不同摄像头安装角度、车内光照、驾驶员脸型差异都很大，公开数据很难完全覆盖。我自己是采用“公开数据集+模拟驾驶环境自采”的方式，在模型车和实验室里架摄像头，找几个人分别模拟正常驾驶和疲劳状态，录了上百段视频，再抽帧筛选。

标注的时候特别注意三点。第一，闭眼和半闭眼要区分开，或者在标注时统一成“闭眼”，但边界要清晰，眼睛只剩一条缝时算闭眼还是睁眼？最好在标注规范里明确。第二，打哈欠时嘴巴张开的程度也要定义好，张嘴超过一定阈值才算正样本。第三，样本均衡很关键，正常睁眼的帧数会远多于闭眼和打哈欠，需要做欠采样或数据增强。我用的是某标注工具，导出 YOLO 格式的 txt 文件，每行是：类别 x_center y_center width height。

2.3 训练配置与调参经验

训练 YOLO 的配置有很多可调项，但核心就几个：输入分辨率、batch size、epochs、优化器、数据增强策略。

输入分辨率我建议用 640 起步，如果闭眼检测精度不够，再尝试 960。分辨率提高能明显改善小目标检测，但训练和推理速度都会下降。batch size 受显存限制，我实测 8GB 显存下用 640 分辨率，batch 8 差不多，再大就 OOM。epochs 一般 100 到 200，配合早停机制看验证集 mAP 变化。优化器直接用默认的 SGD 或 AdamW 都行，关键是学习率策略。

数据增强里最有用的几个是：随机亮度对比度（模拟光线变化）、随机旋转和透视（模拟头部姿态变化）、随机裁剪（模拟摄像头角度差异）。但注意不要增强过头，比如翻转就只做水平翻转，垂直翻转会让脸变成倒着的，真实场景不可能出现。

训练完成后，先用测试集看各类别的 mAP。如果闭眼类别 mAP 明显低，优先补闭眼样本，而不是盲目加训练轮数。我遇到过闭眼和正常睁眼的 mAP 相差十几个点，补了一批闭眼数据后效果立竿见影。

2.4 模型导出与转换细节

训练出的 PyTorch 模型权重不能直接塞给 Java 或者 Python 推理服务使用，通常要转换成 ONNX 再转成推理引擎格式。如果部署在 GPU 上，转 TensorRT 是首选；如果只有 CPU，转 OpenVINO 更合适。

导出 ONNX 时要注意几个坑。第一，YOLO 模型的输出形状是[batch, 4 + classes, grid_h * grid_w]或类似，不同版本结构不同，导出后需要写后处理逻辑。第二，opset版本尽量选高一点，否则某些算子会丢失。第三，输入动态维度建议关闭，固定为 640x640，能提升 TensorRT 转换成功率，代价是送入模型的图像必须做 letterbox 缩放并记录缩放比例。

我在导出 v10 的时候踩过一次坑，因为 v10 去掉了 NMS，输出层不同，直接用 v8 的后处理解析会导致结果全是零。后来查看模型结构文档才明白，需要根据输出 shape 判断特征图类别数，再写对应的解码函数。

3. 后端 SpringBoot 服务与模型推理集成

3.1 项目模块划分与工程结构

整个后端工程我分成了三个 Maven 模块：

• server-admin：SpringBoot 主服务，负责鉴权、设备管理、报警存储、接口封装。
• detect-client：封装对 Python 推理服务的 HTTP 客户端，提供统一的检测请求方法。
• common：存放公共实体、DTO、常量。

独立推理服务是一个 FastAPI 应用，单独一个项目仓库。用 FastAPI 而不是 Flask，是因为它有类型校验、自动文档、异步支持，接口对接起来体验更好。

为什么推理服务一定要独立？除了技术栈差异，还因为模型推理是 CPU/GPU 密集型操作，如果和 SpringBoot 跑在同一个 JVM 里，一旦检测请求并发上来，JVM 的 GC 和 GPU 争用会让系统抖动。分开之后，SpringBoot 只做业务编排，Python 服务只做推理，职责清晰，也方便横向扩容。

3.2 推理服务接口设计

Python 推理服务暴露的接口要设计得简单而稳定。我常用的是：

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 上画框偏移，就是因为忘了按缩放比例换算。

除了单帧检测，推理服务还要支持连续帧序列检测，或者配合视频流抽帧。因为 SpringBoot 每次转发一张图的话，网络开销比较大。更高效的方式是推理服务内部维护一个消息队列，SpringBoot 只把视频帧通过 WebSocket 推送到推理服务，由推理服务批量处理，再把结果批量返回。不过我用的实现比较简单，HTTP 单次请求也能满足 10 路摄像头的需求，关键看帧率限制。

3.3 SpringBoot 核心业务实现

SpringBoot 这边的接口设计主要围绕这个几个场景：

• 用户登录和权限管理：JWT 令牌，角色包括管理员、监控员。
• 设备管理：增删改查摄像头，每个摄像头绑定一个驾驶员或车辆。
• 检测请求：接收前端上传的图像，调用推理服务，拿到结果后保存到数据库，并根据规则判断是否触发报警。
• 报警记录查询：按时间、人员、设备筛选历史记录。
• WebSocket 推送：检测结果实时推送到前端。

调用 Python 推理服务的代码我用的是 Spring 的RestTemplate，现在也可以用WebClient，但RestTemplate足够稳定。注意超时时间一定要设，检测接口如果 GPU 排队，可能耗时超过 5 秒。我设置的是连接超时2秒、读取超时10秒，同时用线程池隔离，避免一个慢请求拖垮整个 Web 服务。

保存到数据库时，除了保存检测框，还要保存原始图片的 Base64 编码或者文件路径。这个很重要，否则事后复盘报警记录时没有图像证据。数据库表设计至少包括：detect_record（id, driver_id, device_id, timestamp, image_path, result_json, fatigue_level, status）。

3.4 前后端分离鉴权与会话设计

前后端分离后，传统的 Cookie Session 不再适用，我用 JWT 做无状态鉴权。用户在登录接口换取 token，后续请求在 Header 里带Authorization: Bearer token。SpringBoot 里用一个拦截器或 Spring Security 过滤器校验 token 即可。

WebSocket 的鉴权要单独处理。因为 WebSocket 握手走的是 HTTP 协议升级，可以在握手请求的 header 里带上 token，在后端实现一个HandshakeInterceptor校验。我踩过一个坑：前端用原生 WebSocket 时，header 里不能随意自定义字段，所以很多前端会选择把 token 放到 URL 查询参数里，虽然不优雅，但简单可行。生产环境建议用 STOMP 框架，支持 CONNECT 帧的传参，能正规一点。

跨域配置也要做好。前端页面如果部署在http://localhost:8081，后端 API 在http://localhost:8080，那 SpringBoot 里要配置 CORS 允许指定源、指定请求头、指定方法，否则浏览器会拦截所有 AJAX 请求。我习惯把允许的域名放到配置文件里，方便切换环境。

4. Web 交互界面与大模型智能分析集成

4.1 前端框架与页面布局

前端我用的技术栈是 Vue 3 + Element Plus + ECharts，这套组合开发监控类界面效率很高。页面核心功能包括：

• 登录/权限控制。
• 实时监控大屏：左侧显示摄像头视频流，中间用 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 上。接下来，这一帧也可以发给推理服务做检测，检测框的坐标通过另一条 WebSocket 消息推送。前端收到检测结果后，在 canvas 上重新绘制图像和框。

这个方式的优点是实时性高，能保持端到端延迟在 300ms 以内。缺点是对前端的绘图性能有一定要求，如果一帧图像是 1280x720，每秒20帧，客户端如果性能不好会卡顿。优化的办法是只绘制检测区域的缩放图，或者降低到15帧。

4.3 大模型智能分析模块的设计与接入

检测模型只能告诉你“这一帧里有哪些目标”，但疲劳驾驶是一个时间维度上的判断。单帧眼睛闭合可能是因为眨眼，几秒内频繁闭合才更有可能是疲劳。大模型的价值就在这里：把一段时间内的检测序列拼接成自然语言提示，让大模型做推理和总结。

我接的大模型接口是一个通用的中文对话 API。接入之前要先把检测结果转成文本，比如每 10 秒为一个窗口，统计这个窗口内闭眼帧数占比、打哈欠次数、低头次数，然后构造提示词：

你是驾驶安全分析助手。以下是一段10秒内的检测统计数据： 闭眼帧占比：15% 打哈欠次数：2 低头次数：1 平均置信度：0.85 请判断驾驶员疲劳程度（等级：正常、轻度疲劳、中度疲劳、高度疲劳），并给出理由和安全建议。用JSON输出。

大模型返回的内容可以是 JSON 格式，方便直接解析。我在提示词里明确要求“只输出JSON”，并且配置了输出格式参数。如果用的是支持结构化输出的API，也可以直接用 schema 约束。

接入的关键细节是控制成本和延迟。每 10 秒调用一次大模型，对一个摄像头来说一天有 8640 次调用，费用和响应压力不小。我的优化策略是：先用规则判断是否到了需要大模型介入的程度。比如如果闭眼占比小于 5%，直接用规则结果返回“正常”，不调用大模型；只有当闭眼占比超过阈值或者短时内出现多次哈欠，才触发大模型做深度分析。这样可以省下大量调用。

另外，大模型调用是 IO 密集型操作，不能放在处理视频流的线程里，否则会阻塞实时性。我用了一个异步任务池处理大模型请求，完成后把结果写入数据库，并通过 WebSocket 推送给前端。

4.4 报警与数据可视化

报警规则最常用的是 PERCLOS（单位时间内眼睛闭合时间占比）。行业里一般以闭眼帧数占总帧数的比例来判断，比如连续 20 秒内闭眼比例超过 20%，就认为是严重疲劳。基于检测结果，我做了两层报警：

• 即时报警：某帧检测到闭眼且置信度高，触发提示。
• 周期报警：按时间窗口聚合模型输出，结合大模型疲劳等级，触发不同程度的声光报警。

前端收到报警消息后，页面顶部弹出红色告警条，同时播放声音。ECharts 用来画疲劳指数曲线，横轴是时间，纵轴是每个时间窗口的综合疲劳分，曲线平滑处理后会更有趋势感。

安全提醒要注意：报警信息不能只展示给监控员，还要支持短信或企业微信消息推送。我的系统预留了消息推送接口，目前用的是一个模拟的 HTTP 回调，实际使用时可以对接第三方短信服务。

5. 部署实施与性能优化

5.1 Docker 化部署方案

整套系统的部署我完全用 Docker Compose 编排，包含五个容器：

如果推理服务需要用 GPU，docker-compose.yml里要指定gpus: all，同时需要机器上已安装 NVIDIA Container Toolkit。我第一次部署时忘了加这个，容器跑起来之后 Python 代码报找不到 CUDA，排查了半天才发现是 runtime 没配置。

Dockerfile 写 Python 推理服务时要注意减小体积，只拷贝requirements.txt、模型文件和源码，不要拷贝训练用的数据集。模型文件我直接打进镜像，因为模型体积不会太大（一般在几十 MB），避免启动时去外部下载。

5.2 性能瓶颈与调优

系统上线后最直接的瓶颈往往是推理服务。检测一张 640x640 图像，在 GTX 1660 上大约需要 20ms，但在 CPU 上可能要 500ms 以上。如果所有摄像头都要实时检测，必须对帧率做限制。

我的做法是每个摄像头抽帧率限制为 5 FPS，也就是每 200ms 处理一帧。对于有 10 个摄像头的情况，总推理负载是每秒 50 帧，GPU 利用率大约在 60%~80%。这个抽帧率对疲劳检测完全够用，闭眼动作持续至少 300ms，5 FPS 能捕获到关键状态。

推理服务内部也用上了队列。FastAPI 是异步框架，但模型推理是 CPU/GPU 同步操作，并发请求会排队。我用了asyncio的 Lock 限制同时只能有一个推理任务，否则显存会爆。如果要提升并发，可以起多个推理进程，每个进程各自加载模型，再用 Redis 做任务分发。

网络传输也是隐性瓶颈。前端上传原始图像再返回检测结果，图像体积会直接影响延迟。我在推理服务里加了图像压缩逻辑，先按比例缩小到最长边 800px，再转成 JPEG quality=80，这样单张图不超过 100KB，走内网非常快。

5.3 合规与隐私保护

疲劳驾驶系统会持续采集驾驶员面部图像，属于敏感个人信息，落地时必须做隐私保护。我的方案是：

• 所有图像数据默认不保留原始视频流，只保留触发报警前后的关键帧。
• 数据库中的图像路径不能包含人员姓名等直接标识信息，用随机 UUID 命名。
• 摄像头采集区域要避开无关路人。
• 系统权限要分级，只有授权管理员才能查看带有面部的抓拍图。

这些都是经过实际项目验证的底线，尤其在企业内部项目里，数据合规问题不是技术问题，是能不能上线的问题。即使技术实现再完善，隐私保护不到位也会被叫停。

6. 踩坑记录与问题排查

6.1 常见问题速查表

我把这大半年开发维护中遇到的典型问题整理成了一张表，遇到类似情况可以先对着查：

6.2 推理精度与速度权衡心得

我在实际使用中最大的体会是：不要盲目追求模型最强。v12 在闭眼检测精度上确实好一些，但如果目标是做到 5 路以上摄像头并发实时检测，v8 的推理速度优势更能保证体验。后来我把生产环境稳定在 YOLOv8s 上，闭眼检测的 mAP 达到了 0.89，5 FPS 下延迟 30ms 左右，完全够用。

v10 和 v12 还是要留在实验环境里对比着玩。v10 的无 NMS 设计确实让推理延后处理简单了很多，但官方权重在闭眼这个小类别上表现略逊于 v11。v12 的提升需要更大的训练数据量才能发挥出来，如果只是几百张标注图，反而容易过拟合。

模型蒸馏也是个可以考虑的方向。用 v12 作为教师模型，把知识蒸馏给 v8s 的学生模型，可以在精度和速度之间找到一个更好的平衡点。我做过一次蒸馏实验，v8s 的 mAP 提升了大约 3%，基本接近 v11 的效果，但速度没有牺牲太多。这种方案适合有一定调优时间的团队。

6.3 实用的调试技巧

调试这类多服务系统，最怕的就是问题出现后难以定位。我养成了一套自己的调试习惯，分享出来很有用。

日志必须全链路带 traceId。在 SpringBoot 里用拦截器生成一个 traceId，放入 MDC，然后在调用 Python 推理服务时，把这个 traceId 放在 HTTP Header 里传给 FastAPI，FastAPI 的日志同样打印这个 traceId。这样不管是前端报错还是后端报错，只要拿着 traceId 就能把整个请求链路串起来看。

离线回放功能一定要做。我写了一个模拟推送脚本，可以从本地视频文件读取帧，按照时间间隔把帧发送给 SpringBoot 服务。这样不用天天坐在车里测试，只要拿着录制好的疲劳驾驶视频，就能反复验证检测逻辑和报警规则。

压测别忽略大模型环节。很多人压测时只关注检测接口，忽略了前端不断调用大模型分析接口的并发。我用 JMeter 模拟多个设备同时触发疲劳分析，结果发现线程池满了导致接口超时。后来把线程池参数调大，并且增加了一个排队缓冲，问题就解决了。

最后再分享一点个人体会：这套系统做完之后，我最意外的不是模型精度，而是工程整合要花的时间远超训练模型。模型训练可能只占三成工作量，剩下七成都在做前后端联调、接口协议对齐、异常处理、部署上线。如果你也想从零做一套类似的项目，建议先定好接口协议和数据结构，再动手实现各个模块。还有一个深坑是不同 YOLO 版本的输出格式看起来差不多，实际上差别不小，换模型版本时，后处理代码一定要写单元测试，否则上线那天绝对会踩雷。希望这篇文章能帮你绕开我走过的弯路。